vCenter Single Sign On has a considerable amount of changes in vSphere 5.5, with few major ones. Many of these changes have went undetected or unnoticed by the Virtual Infrastructure Admins. If you have deployed vSphere 5.5 and missed these changes or planning to install vCenter SSO 5.5 and want to learn what has changed from the vSphere 5.1 days, then this post is for you:
Below is the list of the major changes introduced in vCenter Single Sign On:
vCenter SSO Architecture Improvements:
1- Multi master: Unlike 5.1, vCenter SSO 5.5 has A built-in automatic multi-master replication architecture that ensure that all SSO instances are always kept in sync. While this sound great, most admins are not sure what it means nor how it affect the way they design SSO. To understand the value of this change, you must understand how SSO worked in 5.1. and how that changed in 5.5.
In 5.1 if you wanted to enable SSO for multiple vCenters in your environment, you needed to point all of them to the same SSO instance which made all of those vCenters dependent on that single SSO instance. This has made that single SSO instance to be crucial for the operation of all of your vCenters, as if that SSO instance goes down you will not be able to access any of your vCenters. For that reason, many customers had to implement a more complex/costly availability mechanisms for SSO like SSO HA and vCenter Heartbeat.
On the other hand, vCenter SSO 5.5 has dramatically changed this with the introduction of automatic Multi-master replication architecture. The below image should help you understand how this new multi-master replication architecture work:
Looking at the above image it shows an environment with three vCenters, where each of them is deployed with its own SSO instance(Something that many probably would not done in vSphere 5.1). As vCenter SSO 5.5 allow you to have a Multi-master replication across the different SSO instances, each of the SSO instances dataset is replicated to all other SSO instances and in turn the user can use a single SSO token issued by any of these SSO instances to login to any of the vCenters, while limiting the effect of SSO instance failure to a single vCenter.
The above image actually demonstrate how each of the vCenter SSO is a master for its own set of entries and replicate it to other connected SSO instances. For example, the Yellow data set(Colors are for demonstration purpose only) is owned by the 1st vCenter SSO and it is replicating a copy of it to the 2nd and 3rd vCenter SSO, similarly the 2nd vCenter SSO instance own the Red data set and replicating it to the 1st and 3rd vCenter SSO instances. As you can see this architectural change has added a lot of resiliency to SSO, and limited the affect of a single SSO instance going down to a single vCenter.
One important note though which seems to mislead a lot of people, this Mulit-master replication is not meant to provide SSO redundancy. For example, if in the above images if the first instance of vCenter SSO which is installed on the same VMs as the 1st vCenter fail, you will not be able to access your first vCenter. While the other vCenter SSO instances have a copy of that particular vCenter SSO data it can not stand for it when it goes down. For vCenter SSO redundancy, you should utilize vSphere HA or vCenter Heartbeat.
2- Built in replication: This has been covered in the Multi master section above, though one thing I would like to add is now the replication in Multi-site implementation is automated and a part of vCenter SSO 5.5, unlike in 5.1 where you had to create and schedule replication scripts independently.
3- Site awareness: Unlike vCenter Single Sign On 5.1, vCenter SSO now is site aware which means it can be configured with replication partners when going across sites rather than having to set it up with a replication mesh(Where every node is replicating to every other node – not the most efficient use of your bandwidth), which is way more bandwidth efficient for remote site and add design flexibility.
4- SSO Database eliminated: vCenter SSO 5.5 does not require a database any more. This is one less database to worry about and maintain.
vCenter Single Sign On 5.5 Installation Improvements:
Installation of vCenter SSO has been considerably simplified in version 5.5, by allowing you to choose between scenarios that can easily be identified to how they relate to your environment rather than what confused many in 5.1. The new installation scenarios/options are as below:
- First server in a new domain
- Add a server in an existing domain
- Add a server in an existing domain with a new site
Another installation improvement, that vCenter SSO does not require it’s own database with all those username and database naming restrictions that used to cause many installation to fail in 5.1.
SSO Diagnostic & Troubleshooting Tools:
VMware has introduced a full suite of vCenter SSO diagnostics and troubleshooting tools, that were most welcomed by the community.
When installing your 2nd vCenter SSO as a new site you would point back to the first because you have no other option. What about the 3rd though? Would you point to the 2nd? Or point to your original? Point to the geographically closer one? Does it matter? There seams to be no clear information on who you pair with on install when setting up the 3rd vCenter SSO. Would be very interested on you perspective on this. Thank you.