Installing vCenter Single Sign On in a multisite deployment (2034074)
Introduction to Multisite Single Sign On Deployments
The vCenter Single Sign On multisite configuration is designed for deployments with multiple physical locations. Installing a Single Sign On instance at each site allows fast access to local authentication-related services. Each Single Sign On instance is connected to the local instances of the AD (LDAP) servers and has its own database with local users and groups.
Multisite deployment is useful when a single administrator needs to administer vCenter Server instances that are deployed on geographically dispersed sites. To view all vCenter Server instances from a single vSphere Client, you must configure the vCenter Server instances in Linked Mode.
Note: Multisite Single Sign On deployment is designed only for faster local access to authentication-related services. It does not provide failover between Single Sign On servers on different sites. When the Single Sign On instance on one site fails, its role is not taken over by a peer Single Sign On instance on another site. All authentication requests on the failed site will fail, even if peer sites are fully functional.
In multisite Single sign On deployments, each site is represented by one Single Sign On instance: one Single Sign On server, or a high-availability cluster. The Single Sign On site entry point is the machine that other sites communicate with. This is the only machine that needs to be visible from the other sites. In a clustered deployment, the entry point of the site is the machine where the load balancer is installed.Note: For further information, please see: vCenter Single Sign-On Deployment Modes
Planning a Single Sign On Deployment
Before you install Single Sign On, consider carefully the future requirements for the deployment to determine whether a multisite or high-availability deployment is appropriate. If you install a Single Sign On instances in basic mode, you cannot later promote the instance to a multisite node.
Order of Installation for Single Sign On Instances
You can install the Single Sign On nodes in a multisite deployment in any order. The Single Sign On installer uses the terms primary and secondary only to distinguish between the node that is installed first and any node that is installed later and points to a previously installed node. Any node that is installed after the primary node can point to any node that is already installed. For example, the third node can point to either the first or second node.
For example, let's consider a corporation MyCompany, with offices in San Francisco, New York, and London. The New York site is the headquarters and connects with both the London and San Francisco sites. The London and San Francisco sites do not connect with each other. The MyCompany multisite Single Sign On deployment would proceed in the following steps.
- The administrators in London set up the first Single Sign On instance.
- The New York IT team sets up the second Single Sign On instance, pointing it to the London instance.
- The San Francisco IT team sets up the third Single Sign On instance, pointing it to the New York instance.
Connectivity Between Single Sign On Instances and Between Single Sign On Instances and Other vSphere Components
After you install Single Sign On, no connectivity between the Single Sign On servers is necessary, because there is no automatic replication of data between Single Sign On instances.
There are no components in the vSphere suite that communicate with multiple Single Sign On servers. Each vSphere component should be configured to communicate with its local Single Sign On instance for faster access.
Single Sign On and Active Directory
If you use Active Directory in your infrastructure and you want the Single Sign On server to add Active Directory automatically as a Single Sign On identity source, you must install Single Sign On on a machine joined to the Active Directory domain. In this case, all machines on which Single Sign On servers will be installed must be joined to the same domain. The domain controllers might be different, but the Single Sign On server will discover and add the local one.
Single Sign On and vCenter Server Linked Mode
You can join vCenter Server instances in Linked Mode only when all of the instances are registered in the same Single Sign On deployment. This includes Single Sign On instances installed on different sites. When vCenter Server B on site B is joined to vCenter Server A on site A, the join tool establishes connection both to Single Sign On A and Single Sign On B.
Replicating Data Between Single Sign On Sites
Automatic replication of data between Single Sign On Sites is not supported. Whenever you make a change to one of the Single Sign On instances, you must perform a manual data export and import operation with a command-line tool. The data to replicate includes local users and groups and the configuration of the STS server. Because this data rarely changes, you can schedule replications once a day or week, as appropriate. For information about manually replicating data between servers in a multisite Single Sign On deployment, see Manually Replicate Data in a Multisite vCenter Single Sign-On Deployment section in the vSphere Security Guide.
The sites work in a disconnected state, unaware of each others' execution and progress. When you import data on a Single Sign On server, its entire current state is overridden, so you lose all changes that were made since the last propagation.
CAUTION: To ensure that data remains in sync during the manual replication process, do not make any changes to the data to be replicated, for example adding or deleting identity sources or local users.
For example, let's look again at MyCompany. After Single Sign On is set up, the MYCompany IT team starts configuring their vCenter Server instances: first in San Francisco, then in London, and last in New York. During each vCenter Server installation, an application user is created for the vCenter Server instance. The correct deployment sequence takes the following steps:
- Install vCenter Server in San Francisco.
- Export the San Francisco data and import it to the London site.
- Install vCenter Server in London.
- Export the London data and import it to the New York site.
- Install vCenter Server in New York.
- Export the New York data and import it both in London and San Francisco
Note that these steps represent an accumulative change replication. Changes to one node are transported only to the node where the next changes will occur. After the last planned change is done, changes have been propagated to all nodes.
Alternatively, you can execute the replication sequentially. After a change in one node occurs, replicate it to all other nodes before making a change on any other node. During setup of the virtual infrastructure on each site, the better practice is to use the accumulative approach, which needs fewer steps, as the changes are planned and executed in a relatively short time span. For regular, ongoing operations, use the sequential approach.
- installing a high-availability Single Sign On deployment, see Configuring vCenter Single Sign On for High Availability (2033588).
- configuring an Apache load balancer, see Setting up Apache load balancing software with vCenter Single Sign On (2034157).
- installing vCenter Single Sign On, see vSphere Installation and Setup and vSphere Upgrade for version 5.1.
- At Site A, install the primary Single Sign On node.
- In the Single Sign On installation wizard panel vCenter Single Sign On Deployment Type, select Create the primary node for a new vCenter Single Sign On installation.
- In the panel that asks you to Select single node type, select Create the primary node for a new vCenter Single Sign On installation.
- Complete the Single Sign On installation wizard.
- At Site B, install a secondary Single Sign On node, pointing to Site A.
- In the Single Sign On installation wizard panel vCenter Single Sign On Deployment Type, select Join an existing vCenter Single Sign On installation.
- For the node type, select Multisite, and point to the Single Sign On primary node that you created in step 1.
Enter the FQDN or IP address, Single Sign On HTTPS port, and the password admin@System-Domain for the primary Single Sign On node. Note: If Site A is a high-availability cluster, enter the address of the Site A load balancer.
- Complete the Single Sign On installation wizard.