VMware Cloud Foundation

Single SSO Domain with Multiple Cloud Foundation Instances

So, you have adopted VMware Cloud Foundation (VCF), or maybe you have spent some time reviewing the VMware Validated Design (VVD) and found that you would like to deploy a Single SSO domain. In VVD architecture they propose having two regions with a Single SSO Domain, but natively the VCF deployment process expects a greenfield SSO domain.

As of VCF 3.8 release notes:

Provides the ability to link between the SSOs (PSCs) of two or more VMware Cloud Foundation instances so that the management and the VI workload domains are visible in each of the instances.

 

What does this mean exactly?  This translates into the ability for Region B as per the VVD, to join the SSO instance of Region A.  This allows VCF to align to the VVD from a design perspective to share SSO domains where it makes sense based upon Enhanced Linked Mode 150ms RTT limitation.  In order facilitate this, the Excel Document Deploy Parameters tab, has been updated (shown below) to and allows you to enter Region A SSO domain, PSC IP Address, and SSO Credentials.  During bringup process on Cloud Builder it will still deploy two PSC’s for that region, but they will be joined to Region A.  This will provide Enhanced Linked Mode in vCenter and allow you to manage two VCF environments Role Based Access Controls and VM’s from a single login.

The ability to join SSO domains does come with some limitations though:

  1. VCF can only join an SSO domain of another VCF instance. The first VCF deployed in your environment still needs to be greenfield.
  2. ELM limitations of 15 vCenters applies, and that is now shared between two VCF instances. This means instead of a VCF instance being allowed to have 14 Workload Domains plus Management. Only 13 workload domains could be created in a shared deployment as minimum of two would be used for management.
  3. ELM limitation of 150ms Round Trip Time for latency should be advised, this would mean sharing SSO domain between New York and Sydney will likely not be supported or advised.
  4. Patches need to stay consistent especially for PSC’s and vCenters between deployments. Patch all PSC in both VCF instances before patching vCenters, and then subsequently patch all vCenters in a timely manner.
  5. SDDC Manager in ‘Region A’ cannot see the Workload Domains created by the SDDC Manager in ‘Region B’. We are looking to address this in the future.
  6. NSX-T cannot be shared between ‘Region A’ and ‘Region B’ deployments.

This is great news for customers that are looking to align their VCF environments with the best practices in VVD and also allow for a unified vCenter support experience for their Admins. In addition this will allow for easier migrations on Day X as they will reside in the same vSphere Client, potentially as easy as a drag and drop to Region B depending upon networking and overall customer architecture.

Interested in deploying VMware Cloud Foundation in your Home Lab?  Get the info here: http://tiny.cc/getVLC and on slack at http://tiny.cc/getVLCSlack.

This content was originally created and posted on Data Reload.