Big SSO Domain or Small?

I just recently completed the upgrade of the vCenters at my work, and it was a doozy. This was the most amount of planning that has been done for any vCenter upgrade, and mostly because the topology you go with you are pretty much stuck with. I had a dozen or so vCenters spread out across different geographies. I went with a geographic based SSO domain with each vCenter having their own external PSC. This seemed to make the most sense because Enhanced Linked Mode consolidated roles, licensing and tags. Unfortunately I did run into some issues that were exacerbated by having a larger domain, thus I want to discuss the reasons why it would have been nice to stay as a single SSO domain for each vCenter.

Adam Eckerle does has a nice flow chart in regards to what topology to choose, but there are some subtleties are lost from a decision tree/flow chart.

Pros of 1 SSO domain-to-1 vCenter:

• Can Keep PSC Embedded, which reduces the amount of external fault and reduces the number of servers
• Can also move PSC to external for HA configs
• Reduced dependencies on the health of a larger SSO domain
• No issues with PSC replication
• Don’t have to troubleshoot web-client logins to remote vCenters
• Issues are isolated to single SSO domain

Cons of 1 SSO domain-to-1 vCenter:

• Can’t share PSCs between vCenters (only really useful for HA modes since embedded PSCs wouldn’t need to share)
• Have to manage administrator account and roles for each vCenter (no central management)
• Have to manage licenses for each vCenter (no central management)
• Have to manage tags for each vCenter (no central management)
• No unified Web Client Views (SPOG)
• Have to manage external connections for SRM and VR (not auto-detected)

When I started my upgraded, more vCenters per domain was the best way to go. Minimize a lot of extra work and gain more visibility. At the end I saw issues with replication, issues with latency, unknown issues trying to join certain things and just fragility in the model. I have one vCenter which is attached to a PSC that thinks it’s joined to the same domain as another but it’s really in it’s own domain not talking/replicating. I ended up re-installing that vCenter and PSC and dealing with the loss of tags, licenses, roles and permissions (permissions was the hardest). I may write up a seperate post about this later.

Another issue that I am seeing is that one vCenter (in my large SSO domain) has a flaky Inventory Service. Once that service starts going sideways, it affects the search ability for the web client (search tries to ping all of the inventory services, though I thought this is what the PSC was for). One other things I have noticed in that large SSO domain is that loading of the web client can be severely impacted if one of the sites is not as responsive for whatever reason. When the web client launches, it seems to cull all of the services from all of the vCenters (like VR, SRM, etc) in order to present it on the main screen. If a vCenter is taking long to respond, you may see the “data service timed out because a back-end task took more than 120 seconds.”

One cosmetic issue for SRM is that in a large SSO domain you will see the SRM Sites for each SRM instance. The names of the sites are user chosen, but in my case they were the name of the vcenter, i.e. vcenter1, vcenter2, vcenter3. I had a shared site setup where there was vcenter1 <-> vcenter2, vcenter2 <-> vcenter3. In SRM 5.5.1, when you opened SRM you chose what SRM ID (which is different from SRM Site names) to use then you saw the sites. In the Web Client with SRM 6, you see all of the sites. So initially I saw vcenter1, vcenter2, vcenter2, vcenter3. in the list. I ended up re-installing those vCenters and changing the site names (for at least the shared-site SRM) to be like vcenter1.to.vcenter2, vcenter2.to.vcenter1, vcenter2.to.vcenter3, vcenter3.to.vcenter2. I think a better way would have been to show the SRM ID and then show the sites under that.

Overall I’m hopeful that I can resolve my issues, but it still makes me question why these things are so hard. VMware really should provide a way to move a vCenter to a new SSO domain easily (exporting all needed information and importing into new domain). It just seems like they are putting so much dependencies on the PSC and the SSO domain but it just makes things more complex.