Now you understand what vCenter Single Sign-On (SSO) provides, as you start to design or upgrade to your vSphere 5.1 environment, particular attention needs to be given in the planning stages around the placement and configuration of the SSO server. This will always be the first component to be installed; regardless of fresh install or upgrading from a previous version. The SSO server can be deployed in a number of configurations and I will explain these options and too why you may use each option.
During the installation process you will be presented with the below screen which is a key decision on which deployment method of SSO you would like to deploy. It is very important that you have planned your SSO deployment as changing this configuration later is possible but not an easy achievement. The two main configurations presented here are:
Basic vCenter Single Sign-On:
Most common deployment option (VMware recommended)
This is a single standalone instance of the SSO server that supports the connectivity of Active Directory, OpenLDAP, Local Operating System and SSO embedded users and groups.
This typically would be local to the vCenter Server
Used by the vCenter Server Simple Install option.
Preinstalled with the vCenter Server Appliance
When to use basic vCenter Single Sign-On:
If you have a single vCenter server of any supported inventory size (up to 1,000 hosts / 10,000 VMs).
If you have multiple geographically dispersed locations each with a local vCenter servers and have no requirement for a single pane of glass view provided by vCenter Linked Mode.
You are using the vCenter Server Appliance (VCSA).
Basic Node configuration of vCenter Single Sign-On server will meet the requirements of most vSphere 5.1 customers and typically maintains the same architecture of previous vCenter server environments.
Create a Primary Node for a vCenter Single Sign-On Installation:
This is a single SSO server instance configured as a Primary within an advanced configurations like vCenter Single Sign-On server High Availability (SSO HA) or same SSO security domain placement in geographically separated locations (SSO Multisite).
Requires the installable version of SSO (Windows Only).
Supports the connectivity of Active Directory, OpenLDAP and SSO embedded users and groups. Does not support the use of local operating system user accounts.
Only one Primary node can exist in a single SSO environment
The Primary configuration allows for further configuration options to support the vCenter Single Sign-On high availability and remote site architectures.
High Availability
This is a SSO server instance that connects to an SSO primary server and provides local failover of the SSO server when both the primary server and high availability. servers are placed behind a network load balancer (e.g. Apache HTTPD or vCNS).
Supports Failover only, does not load balance requests between SSO nodes.
SSO HA can only support the primary SSO server or SSO Multisite server with one HA Backup server.
Requires the installable version of SSO (Windows Only).
Supports the connectivity of Active Directory, OpenLDAP and SSO embedded users and groups. Does not support the use of local operating system user accounts.
High availability backup nodes share the same database as configured when installing the primary node.
Does not provide failover or redundancy of SSO database
When to use the High Availability Backup vCenter Single Sign-On server
If you have multiple vCenter servers within the same physical location and plan for a centralized SSO environment.
High Availability of the vCenter Single Sign-On server is required and does not plan to use vSphere HA or vCenter Server Heartbeat (preferred).
I have found the SSO HA configuration to be complex, with the updating of certificates, using a third party network load balancer for failover and then provide no protection for the database to why I do not recommend it when discussing with customers. A standalone basic SSO service with vSphere HA or vCenter Server Heartbeat will provide a simple centralized solution with added functionality of database protection (if local to the standalone SSO server) in this scenario.
Multisite
This is a single SSO server instance that is used to provide a local copy of the primary SSO server instance at remote sites for local authentication. WAN authentication is not recommended with SSO.
Requires the installable version of SSO (Windows Only).
Supports the connectivity of Active Directory, OpenLDAP and SSO embedded users and groups. Does not support the use of local operating system user accounts.
Does not provide site redundancy of the SSO solution, if one SSO site fails you do not get redirected to another site for authentication.
Manual export/import of the database tables is required (scripts provided) between all SSO Multisite instances to manually maintain database synchronization. This is required whenever an update of any SSO Multisite server instances receives SSO configurations, SSO policies or embedded users/groups updates. This typically is not an everyday or every week task.
Local Multisite SSO server instances must be a member of the same Active Directory / OpenLDAP domain that the primary SSO server is a member of and have a local domain controller available.
By default SSO Multisite will only provide local resource visibility, and not a single pane of glass view across multiple vCenter Servers that are geographically separated and running SSO Multisite.
When to use the Multisite vCenter Single Sign-On server
If you are using Linked Mode.
If multiple vCenter Servers require the ability to communicate with each other.
If you are required to have one single vCenter Single Sign-On server security domain throughout your organization.
In general SSO Multisite removes the risk of slow WAN based authentications however with all the manual steps required to maintain SSO synchronization, I would only recommend the use SSO Multisite if you are using vCenter Linked Mode of which SSO Multisite is a requirement.
I hope this information has helped you understand the different configurations of vCenter Single Sign-On and to when you would use each configuration.
