Right-Sizing SSO Domain

In a previous post, I lamented over whether a SSO domain should be big or small. I gave various pros and cons for having it either way, but I wanted to discuss how to try to design your SSO domain to be the right size (whether that is large or small) for your environment.

One of the main issues with a large SSO domain is that it is a larger FAULT domain, particularly with the Web Client and anything that relies on the Web Client. The Web Client tries to connect to all vCenters in the domain. If one of those vCenters is having an issue, it could affect the response time to the Web Client and thus the overall responsiveness of the Web Client. I have seen an issue with one vCenter make the Web Client unusable. With that said, having a lot of vCenters in one SSO domain has obvious consolidation advantages that can’t be overlooked (licensing, role management).

So how do you group your vCenters?  Here are a few ideas:

1. Group by physical location. If you have multiple vCenters in a single location, grouping those vCenters into a single domain (if they fit within the current limits) maximizes the SSO/PSC infrastructure in that site (only a set of SSO for that whole domain instead of sets for every vCenter).
2. Group by region
3. Group by support function. If you have a Horizon, vRA, or infrastructure  vCenter then you may want to group those together. You wouldn’t want to have issues from your vRA vcenter to cause issues with Horizon one. If you have similar functionining vCenters across multiple sites, you could group those together (Horizon vCenters across multiple sites grouped together).
4. Group by Site Recovery Manager failover sites. If you have SRM installed, having all sites in a SRM set(primary sites, shared site, etc) makes it a little easier to managee. If everything works right, you will see the SRM “Sites” all listed together without any need to manually connect since they are in the same SSO domain. If you have other “SRM”/vCenter sets, keep them in a different SSO. The SRM Sites listing can get confusing because it’s not organized by SRM “Pairs” but by SRM site name.

I went with #2, but in hindisight #4 may have been better. I basically have two vCenters per physical site, each serving a different purpose (cloud, vs non-cloud provisioning). They failover in similar manners, so they have basically the topology as shown above. Since they are all in the same SSO domain. I have eight sites listed in the web client (the shared recovery site has two sites, one paired with each vCenter), which becomes confusing. If I split those up into two SSO domains, that SRM view would be more manageable. One tradeoff to #4 for this case is that in some cases I would be required to have seperate PSCs for the second SSO domain. With #2 I could put the vCenters in the same SSO Site and have them point to either the same single PSC or different PSCs in the same site with the knowledge that I could re-point them as needed.