VMworld 2017: vSphere SSO Architecture

Session: SER2940BU. Speakers: Emad Younis, Adam Eckerle

Embedded PSC: Totally supported for production usage. It’s not just test/dev. Use this model if you don’t need enhanced linked mode. This is a simple model, and use it if it supports your needs.

External PSC: Allows linking of vCenters via linked mode. Tags, roles, global permissions, licensing all replicate throughout the entire SSO domain. Up to 15 vCenters can point to a single PSC in 6.5 U1. Not recommended, but you can do it.

In vSphere 5.5 you can consolidate SSO domains. So consolidate BEFORE you deploy any 6.x versions. After you deploy any 6.x component, you are locked into your SSO domains. If doing this merge, make sure you un-install/remove the embedded SSO component before you upgrade to vSphere 6.x.

Within an SSO domain, you can’t mix versions of products. So if you have islands of vCenters, you may NOT want them linked together. This will require that you upgrade everything together. Very applicable to vBlock environments and their islands of vCenters.

A site is a logical grouping of PSCs. PSCs are multi-master and replicate every 30 seconds.

Recommendation: If you have multiple PSCs spread across multiple sites, you can optionally use “vdcrepadmin” to add more replication agreements. Do NOT add just for the sake of adding. Only add agreements if absolutely needed.

In vSphere 6.5 you can only repoint a vCenter intrasite to another PSC (not across sites). Refer to “cmsso-util”. This is not allowed due to the added latency and causing performance issues.

VMware recommends a max of 100ms between PSCs in the “same” logical site. VMware will support all PSCs in the same site, but it’s not recommended. VMware does not want vCenters talking to remote PSCs.

There’s no current method to migrate from a Windows vCenter with an external PSC o the VCSA with an embedded PSC. VMware said in the future this scenario may be possible.

You can NOT move a vCenter from one SSO domain to another (today).

Built-in SSO load balancing is possibly in a future vSphere release. No third party LB needed, such as F5 or NetScaler.

If you globally want to deploy multiple vCenters, don’t do a global SSO domain. It can be a disaster. Setup regional SSO domains for best performance.

Print Friendly, PDF & Email

Related Posts

Subscribe
Notify of
2 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
James
September 27, 2017 6:04 pm

At the end of your article you state "If you globally want to deploy multiple vCenters, don’t do a global SSO domain. It can be a disaster. Setup regional SSO domains for best performance." However, I'm not clear on where to delineate regional SSO boundaries, e.g. a WAN or continent? VMware does not provide a clear design recommendation either, including in their Validated Designs. For the international company I work for how can I design an optimal architecture given it's global footprint with a minimal number of SSO domains? Additionally, VMware is not clear on vCenter delineation either. Can a… Read more »

David
October 9, 2017 2:05 am

Great posts Derek

I'm planning for a global vCenter upgrade to 6.5 and was going to go with a Global SSO domain. Now I see your note below i'm questioning my architecture, Could you explain in a little more detail as to why not go with a Global SSO domain?

Thanks

"If you globally want to deploy multiple vCenters, don’t do a global SSO domain. It can be a disaster. Setup regional SSO domains for best performance.#