2 PHYSICAL sites, 1 vCenter and its PSC per PHYSICAL site >>> 1 logical SSO domain site

[jftwp]

I'm wondering how best to configure our vCenter environment.  We only need 2 vCenters (external PSC model) for the entire US.  Originally, I've been thinking that I'll install a first PSC, then point vCenter in that physical site to that PSC in that newly created 'SSO site'.  Then, install a PSC in the other city/physical site, joining to the existing SSO domain by pointing to the first installed PSC and configuring as a new SSO site.  Finally, install the 2nd vCenter and point it to the 2nd installed PSC in the same SSO domain but in its own SSO site.

Then I started thinking---why configure a 2nd SSO site in the 2nd physical location at all?  The WAN links are plenty fast if I ever needed to repoint a vCenter to the other physical site's PSC (documented KB's for both inter and intra repointing available with 6.0 U1 I know).  Couldn't I simplify my deployment further by not creating a 2nd SSO site in the SSO domain?  Why not just have the 2nd PSC join the existing SSO site that was created when the 1st PSC was deployed?  Each vCenter would use the PSC specified in its PHYSICAL location at deployment time, sure/absolutely.  Having just a single SSO site with 2 PSC's in it doesn't appear to be one of the many deployment topologies that VMware has made available in various KB's etc UNLESS it's behind a hardware load balancer----and I just plain don't want to use a LB for this deployment because I don't think the complexity is worth it.  Thoughts?

[MattiasN81]

Hi.

Using 1 SSO domain and 2 PSCs is ís actually the toplology VMware recommends for a small vCenter HA environment, if you want to use cross vcenter vmotion for example you need the vcenters to be in enhanced linked mode and the same SSO domain.

i have never actually seen a deployment when a LB is in use and i would never suggest a third party solution handling core vSphere components like tieing vCenters to PSCs, smell data corruption

If the site with the active PSC fails you just repoint them to the second PSC and your good to go, all PSC is replication SSO information in realtime.

KB to VMware recommended topologies

VMware KB: List of recommended topologies for VMware vSphere 6.0.x

[jftwp]

Thanks for your comment.  I am still looking for a definitive answer (else debate/discussion) as to whether I can (or whether I should) just have one logical SSO 'site' despite having the PSC's (2 in my case, 1 in each city) in separate physical locations.  Why create a 2nd SSO site at all, given my intended layout of 1 vCenter and 1 PSC, per site, in 2 geographical/physical locations?  Why not just have a single SSO site within the context of the SSO domain?  What's the drawback, if any, of such a layout?

From what I've seen of the topology options (yes I've read that KB already), there's nothing that suggests I can't/shouldn't have a single SSO site for my 2 physical locations.  vCenter 'repointing' options that are supported as of 6.0 U1 are of 2 types:  'Intrasite' and 'Intersite', suggesting that I can repoint a vCenter from one PSC to another PSC 'intrasite' (in my case across a very low latency WAN link) in the single SSO site design I'm considering.  So why not go with a single SSO site and simplify things?  What are the cons there?  (Note: Load balancer approach remains off the table---I see very little gain for the setup effort and potential tshooting when something goes wrong with the LBs/VIPs).

[MattiasN81]

I your case i would go with one SSO domain, there are really no cons here.

The benefit with using only one SSO domain are cross vCenter vMotion and linked mode and also simplifies management

In a two SSO domain scenario the datacenters/VMware environments will be completely separate entities with no integration between them, so both sites will be its own single point of failue unless you use 2 PSCs per site, so this scenario would only add complexity and silo the environment and really not adding any benefit to it.

[jftwp]

Thanks, but you're not understanding my original question.

I am most definitely going to deploy everything within a single SSO DOMAIN.  Absolutely.  No question there.

My question is about whether to have more than one SSO SITE when I bring up a 2nd PSC in a 2nd physical location/data center from the 1st PSC.

Why would anyone---given they have low latency WAN links between 2 or 3 or more sites that are planned vCenter locations if their design calls for it---create more than one SSO SITE?

[MattiasN81]

I did misinterpret you question a bit, im sorry for that 😕

Im used to call the PSC sites containers

logical sites or "containers" only comes in to play when there is a load balancer in place, using VMware NSX load balancing capabilities for example.

Otherwise you do not need to take it into consideration.

Using two psc sites when not using a LB gives no benefit at all, it will only add complexity when you need to failover a vcenter to one PCS to another as you need to manually move the information from one PSC site to another.

And for answer you question, why do any one want to to create more than one psc site ?

When using an LB you need to create more than one site for the load balancing to work.

[jftwp]

Thanks Mattias.  That's the type of feeback I was looking for.  I have yet to come across any blog or VMware documentation that suggests NOT deploying geo-dispersed PSC's into their own SSO sites.

However, I don’t agree that you need more than one site where load balancing is concerned.  You can for example have 2 PSC’s in a single site/location with 1 or more vCenters pointing to those PSC's via VIP.  This approach is documented in VMware KB 2108548.  4th option from the top.

Anyone else beg to differ or care to comment on this topic?

[bigvern2]

Bump - exactly the same situation with vsphere 6.5

What is an SSO Site ?

Why Deploy 2 Sites with one SSO domain (is it replication traffic) - pros/cons

assuming fast WAN links why would you ever choose to deploy a second SSO SITE within the same SSO domain.

as per first post will VMware support that topology  - it isn't specifcally mentioned, either in the supported or deprecated..,