Up to now all vSphere 5.1/5.5 installations I have done so far have been deployed with the Single Sign On service in basic mode, also now known as „for your first vCenter Server” option.
But I felt it’s time to familiarize with other deployment scenarios and this is what I want to share with this post. A scenario I was interested in was to get a single pane of glass for multiple vCenter servers. OK so let’s see what we need to do to get the desired result.
When installing SSO 5.5 you will be asked to choose from one of the deployment modes:
Basic Mode / Single Sign-On for your first vCenter Server
This mode should be used when installing the very first or an independent SSO instance.
High Availability Cluster / Multiple Single Sign-On instances in the same location
This mode basically was designed to support multiple SSO instances in the same site to provide high availability for the service. Both SSO instances share the same database & identity sources. It’s important to mention that if you want it to work properly you will have to do some additional configuration tasks: Configuring VMware vCenter Single Sign On for High Availability
Multi-Site / Multiple Single Sign-On instances in different locations
This mode is designed to deploy multiple vCenter servers across multiple locations. Along with the vCenter server comes a local SSO instance or HA Cluster per site.
Ok know we (or at least I) know which options we have when deploying SSO and understand the major differences. It seems that the Multi-Site option is the one I was looking for. As I was digging deeper I found a bunch of requirements and dependencies which need to be met that the single pane of glass thing works out:
- This mode is required when using Linked Mode
- Linked Mode is required to get all vCenter servers on a single pane of glass
- The local SSO instances must belong to the same AD/LDAP domain as the first/main SSO
- Also the local SSO instances must have a local domain controller available to enable fast logins
- Last but not least, to be able to join a Linked Mode group the vCenter server needs to be licensed as a Standard edition. Foundation/Essentials editions do not support Linked Mode
This is how it should look from a logical perspective
All SSO instances belong to the same vSphere authentication domain and so settings like identity sources are identical across both sites. Each site is still authenticating users via the local SSO instance which at this point doesn’t provide failover capabilities between sites. If the SSO instance in Site 1 is down. users & the Linked Mode partner will lose access to the vCenter server in Site 1.
Now it’s lab time! Theory is good, but doing it yourself is even better.
My lab is currently running a vCenter server 5.5 with ALL components deployed on the same virtual machine. So of course the SSO service has been installed with the first option “for your first vCenter Server” and the vCenter server is a member of my domain which is also added as identity source. So a pretty straight forward setup.
To simulate a remote location I deployed an additional domain controller within the same domain to represent the local AD server. Then I deployed a new vCenter server which I joined to the same Domain using the local AD server. So far so good, then it was time to install all the vCenter server components. As usual I started with the SSO and selected the “Multiple Single Sign-On instances in different locations” and named it accordingly:
All other components like the Web Client, Inventory Service or the vCenter server itself need to connect to a SSO instance. I registered all of them with the local SSO instance:
Linked Mode! As mentioned earlier it’s required to use Linked Mode to get the single pane of glass.
After the setup completed both vCenter servers appeared in both web clients.The final step was to assign proper permission to both vCenter servers and that was it.I’m planning to follow up this post with some additional scenarios and a HA deployment.