Installing vCenter Single Sign-On in a multisite deployment

Products

VMware vCenter Server

Issue/Introduction

This topic describes how to prepare for and install a multisite vCenter Single Sign-On deployment in vSphere 5.1.

Introduction to Multisite vCenter Single Sign-On Deployments

The vCenter Single Sign-On multisite configuration is designed for deployments with multiple physical locations. Installing a vCenter Single Sign-On instance at each site allows fast access to local authentication-related services. Each vCenter 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 or Web 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, having installed the London SSO node against San Francisco's SSO node.
Install vCenter Server in London.
Export the London data and import it to the New York site, having installed the New York SSO node against San Francisco's SSO node.
Install vCenter Server in New York.
Export the New York data and import it both in London and San Francisco

For additional guidance on exporting and importing vCenter Single Sign-On configuration data, see Exporting and importing for manual Single Sign-On (SSO) replication in VMware vCenter Server 5.1.x (2038677).

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.

Environment

VMware vCenter Server 5.1.x

Resolution

This procedure installs a simple multisite deployment.

For information on:

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.

To install vCenter Single Sign-On in a multisite deployment:

At Site A, install the primary Single Sign-On node.
1. 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.
2. In the panel that asks you to Select single node type, select Create the primary node for a new vCenter Single Sign On installation.
3. Complete the Single Sign-On installation wizard.
At Site B, install a secondary Single Sign-On node, pointing to Site A.
1. In the Single Sign-On installation wizard panel vCenter Single Sign-On Deployment Type, select Join an existing vCenter Single Sign On installation.
2. 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.
3. Complete the Single Sign-On installation wizard.

Additional Information

For translated versions of this article, see: