With the introduction of Single Sign On in vCenter 5.1, it poses a change in behaviour for those of you using linked mode. This post will outline some of the considerations for why or why not to use linked mode with SSO and SRM in 5.1, and how to install SSO in multi-site mode in order to take advantage of linked mode.
Mostly linked mode is used by customers with Site Recovery Manager for purposes of visibility of both your protected and recovery sites including protection status and looking at the placeholders so you can see what is protected for recovery. Linked mode also gives easier license sharing between sites, so you can install the same SRM key at both sites and have automated transfer of per-VM usage between sites when migrating or failing-over between sites.
Don’t forget, that doesn’t mean you can exceed the total number for which you are licensed, e.g. if you have a 75 VM SRM license you can install that license on both sites of the linked mode install, but you are still only allowed to protect up to 75 VMs whether it’s 50 on one site and 25 on the other, or 75 at one and zero at the other. What linked mode will do is allow you to failover and then protect back while automatically deducting the protected number of VMs from the appropriate license at either site depending on where your protected VMs are running.
Linked mode is *not* a prerequisite for using SRM. Even without Linked Mode you get a lot of benefit from SRM – it will happily show you all the DR information you need, from both protected and recovery sites in a single pane of glass. SRM works just fine with or without linked mode. If you want to use it, however, be aware that with 5.1, linked mode has a new prerequisite: Namely that SSO be installed at both sites, and that it be installed very specifically in “Multisite mode”. While the SRM plugin still uses the vSphere “thick client” which does not use SSO, the backend communication of the VCs will require multisite SSO.
Linked mode vCenter instances need to authenticate against what appears to be a single SSO instance, whether it is a single SSO instance at one site, multiple SSO instances in HA mode, or multiple SSO instances in multi-site mode. Of those options when using SRM, my preference is to either not use linked mode at all, or to deploy SSO in multisite mode. A single instance or an HA cluster at one site will always introduce the risk that you can not log in during a disaster.
Of course, the other choice is to not use linked mode, and to stand up independent VC and SSO instances at each site and manage them as separate entities all together. This is of course what you will do if you don’t want or need linked mode and multisite SSO. In any of these cases, SRM will be fine and your approach and architecture will merely alter how you manage the environment.
So the purpose of this post is a quick walkthrough of how to install (or upgrade) from vSphere 5.0 to 5.1 and move to SSO linked mode for use with SRM.
The first and most important factor is that you *cannot use the simple install process* of the vCenter installer. You *must* install each component individually. This is specifically because the simple install does not expose the functions of multi-site SSO or allow you to select primary and secondary roles of the SSO servers.
So first, let’s log into the primary site vCenter Server, open the installer and choose to install SSO independently as the first step.
The first requirement is to choose the appropriate SSO deployment type. What we will want to do is to “Create the primary node for a new vCenter Single Sign On installation.” This will set up SSO as a standalone entity for your local vCenter, but also give you the ability to join the second site’s SSO install to it when we get to that stage. You could be doing a new install, an upgrade from VC 5.0, or even installing SSO on a separate system from your VC – the point remains the same, to choose to create a new primary node.
Now it will want to know a password for the SSO system domain password. Choose a good password, and write it down! We’ll need it a few times throughout the install.
The next step is to choose the SSO sign-on type. We can choose to install a basic mode or a primary node for a new multimode SSO. Here we choose to “Create the primary node for a new vCenter Single Sign On installation” which will then give us the opportunity to join other SSO instance to this one.
The rest of the steps are fairly self explanatory – Keep in mind SSO domain admin password you choose, and keep both it and the https port written down somewhere, we’ll need that again later too.
Install or upgrade the Inventory service next, (and handle the certificates however you see fit). Hold off on the other pieces (web client, client, possibly VUM…) until after you’ve installed vCenter Server, which is what you should do next.
When you install vCenter Server itself, make sure you are *not* trying to join a Linked Mode instance – we are going to create a “standalone” instance and then later join the second site’s VC to this one. Also, when entering the SSO data into the VC install wizard, you’ll need to use the same ID and password you used for “admin@System-Domain” earlier.
One thing I quite like about this install is the ability to populate the administrators group with a domain admin group. You can either choose to leave the default “Administrators” group, populate it with an ID, or as I did, give it my “domainDomain Admins” entry so all my domain admins would be automatically recognized as SSO admins.
You should then be up and running with a primary multi-node SSO operating standalone, and a standalone VC 5.1 using local inventory services and the local SSO.
At this point you can optionally upgrade this site’s SRM to 5.1, which is a very basic process and really only requires 64 bit SRAs and a 64 bit ODBC in terms of required changes to the server for doing the upgrade.
Now let’s move over to the other site and log into the secondary vCenter.
Again, we will need to run the installer component by component, rather than using the simple installer, as we need to choose various SSO options to get it working.
The first step again is to do the SSO install. Here, we choose the option to “Join an existing vCenter Single Sign On installation.” rather than to create the primary node. The primary has already been crafted on the first site, we simply want to join into it.
The next step is to choose the “Multisite” installation type. This will give us the opportunity at the bottom of the window to input all of the information for our first site’s SSO installation. Since I installed SSO on my protected site’s vCenter Server, I give it the FQDN of my primary site VC, the https port we used earlier, and the SSO domain admin password we chose earlier so it can authenticate with the remote SSO. Told you we’d need them again.
Be careful here, look this screen over a few times. I can’t tell you how many times while in a rush I’ve entered the wrong site’s information on this type of screen! Ensure you have entered the *first site’s SSO location information* and *not* the name of the current system you’re installing it in!
You will also need to enter the admin password for the *local* SSO. Since we want to use a multisite SSO, guess what you want to enter here? The same password you used for the other SSO. Keep it all in identity.
Choose a database of your preference, give the SSO it’s local IP or FQDN, an appropriate set of credentials, and then a preferred port for the local SSO.
Again, my preference here is to use the same port that was used on the other site. Makes life so much easier when you don’t have to mess around with different ports in different sites…
It will take some time to install, and ultimately all is done. You will now have a multisite SSO installation with common IDs and passwords between sites. Keep in mind, if you make *any* changes to your SSO you will need to *MANUALLY* export, copy, and import those changes to have them reflect at the other site – please see KB article 2038677 (http://kb.vmware.com/kb/2038677)
Now you can install or upgrade your inventory service on this site. There will be further certificate choices, I personally use the autogen certs so things are easier for me in my lab.
Ultimately this is also fairly straightforward. Keep in mind that when your inventory service requests the SSO information you will need to give it the *local* SSO instance information like password and URL.
It will register and install, and now it’s time for vCenter server.
When we install this, we *do* now want to choose to install it as linked mode. When the screen comes up for linked mode or standalone, make sure you choose “Join a VMware vCenter Server group using Linked Mode to share information”. This is, however, not critical at all. You can quite happily install vCenter server as a local instance using a multisite SSO and not use linked mode. To get linked mode all you would have to do is (once the inventory service and web client are installed) go into the start menu and as traditionally done, alter your vCenter to join linked mode after the fact.
At this point your recovery site SRM will need to be installed or upgraded to 5.1.
Once that is done, and SRM is functional, you should be able to log into your vSphere client or use the web client, and you can see the wealth of detail visible from linked mode.
For example, looking at the protected site, you can see visually which VMs are protected, by their special icon, but also from the same interface you can examine the recovery site and see the placeholder VM icons represented by the lightning bolt.
We can also now do some interesting license management, installing a common SRM license in both sites, giving us the ability to share the license across sites and have it automatically use up licenses from the appropriate location depending on where the protected virtual machines reside.
Throughout the install process we have built out a primary site local SSO as the primary of a multisite installation, an inventory service hooked into that local SSO instance, and then a standalone vCenter Server using those components. At the second site we have installed a secondary SSO and joined it to that of the first site, then an inventory service using its local SSO, and lastly a vCenter Server that uses its local SSO and inventory service, but is connected by linked mode to the first site’s vCenter Server. The architecture should look like this:
So, what’s left? I haven’t addressed a handful of things in this posting – first and foremost the management of a multisite SSO instance requires you to be very familiar with the change control process and management tasks necessary to export and import the environment if you make changes. Please review this carefully, and understand exactly what’s going on in the documentation for SSO at http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.install.doc%2FGUID-03E1B870-21BA-47A5-87C3-9413B077CCD0.html
The other aspect I think is important that I haven’t addressed is certificates. That is worthy of a few articles of itself, but keep in mind if you are using custom certificates for either VC or for SRM, you will need to do so across the board – we do not support using “mixed mode” certificates where one part uses custom and the other uses auto generated. And lastly – SRM 5.1 uses 2048 bit certificates, so if you’re upgrading you may have to do the whole lot!
