Before we continue with the pre-requisites and installation of SSO we need to complete the planning of our vSphere install/upgrade design and this includes the desired level of availability required, if any.
When speaking to partners and customers I am often stumbled by the amount of attention and time that is placed on individual SSO availability. My response is bluntly why? followed by the question on what do you use today to protect vCenter server? to which the response is typically nothing or vSphere HA, sometimes vCenter Heartbeat. Don’t get me wrong my background is in business continuity and the way I look at it, SSO is an authentication component of the vCenter server, nothing more, nothing less and so when looking to protect SSO, the solution you choose for protecting vCenter server will provide the best protection of all vCenter components. If you choose not to protect the vCenter server then no protection of SSO is required, if SSO goes down, you bring down the vCenter server management, if only vCenter server goes down, you’re in the same situation, without vCenter server your not going to have much use for an SSO server unless shared with multiple vCenter servers (see below). There are solutions that enable themselves with SSO but these all have a dependency on the vCenter server to be operational. I understand that when reading up on SSO at the excellent vSphere 5.1 Documentation Center, there is a configuration called SSO HA (not to be confused with vSphere HA) and as this is an installable configuration, some believe this is the only option for SSO availability which is not correct. While this solution works, it can be very complex to setup, requires the use of third party technologies but does it give me anymore protection than say vSphere HA? I hope to answer this for you.
Before vSphere 5.1 we had a couple of solutions for protecting vCenter server but as we all know when vCenter server goes down, the hosts and VMs continue to run, do I really need to protect vCenter server? Well in short yes due to all the solutions that depend on vCenter server but the level of protection may differ between the required recovery time objectives (RTO).
Available Options for Protecting vCenter Single Sign-On
Backup and Restore – while any availability solution should not replace the process of backup and restore, this does provide a granular way of recovery whether by tape, disk or snapshot but the recovery time is typically measured in hours to days and requires manual intervention. Note that any backup solution needs to be independent of vCenter server, solutions like VMware Data Protection require an operational vCenter with functioning SSO server to restore a virtual machine.
vSphere HA – this has been an industry standard for the uptime of virtual machines and on detection of a vSphere hosts (ESXi) failure or a failed response to a configured VMtools heartbeat will automatically reboot the virtual machine onto another operational host within the vSphere cluster. This detection is usually within seconds, a virtual machine can be fully rebooted within minutes and provides redundancy from vSphere hosts failures and or virtual machine operating system crashes. vSphere HA does not have any knowledge of the application running inside the virtual machine.
SSO HA – this is an SSO install configuration that allows the instance to be paired with a second SSO server and both placed behind a third party network load balancer to provide failover of the SSO application only (no vCenter server protection). Failover of the SSO application can occur within seconds and depends on the type of network load balancer utilized on how this failover is triggered (loss of IP address/MAC etc). This solution does not provide protection of the SSO database which is separate and shared between the two SSO servers.
vCenter Server Heartbeat – this is a solution for providing vCenter server protection (physical or virtual) and can protect against hosts failure as well as adds application level monitoring and intelligence of all vCenter server components. The vCenter Heartbeat is installed directly onto the vCenter server (or vCenter server component) and provides replication of changes to a cloned virtual machine which can take over as a failure event is triggered. Recovery can be by component restart, entire application restart or entire failover of component/application to its paired virtual machine(s) and recovery is measured in minutes.
You may think I’m leaving one off, database clustering solutions! The reason I do not mention this is because VMware does not officially support Oracle RAC or Microsoft Failover clustering technologies for the vCenter server database (and its components databases). This is due to the fact these technologies are external and not tested by VMware. This does not necessarily mean they will not work, advanced knowledge is required to successfully deploy these technologies with vCenter server however VMware will not support solutions that are not tested in-house.
I have mentioned what our options are to support availability of the SSO server and recovery time objectives to each but there is a little more that needs to be discussed to help you chose the right solution for you (provided you are still seeking uptime of vCenter server / SSO)
Based on the type of environment SSO will be servicing, will determine the best approach for SSO availability.
Single vCenter server – I always like to keep it simple and place SSO local to vCenter server in basic mode and then add the availability solution. If the single vCenter/SSO server is virtual you can place in a vSphere HA enabled cluster and be protected with no further configuration. vCenter Heartbeat can be used if a higher requirement on protection (the application) is required as well being the only solution for availabiltiy if vCenter/SSO is on a physical server.
Multiple vCenter servers in a single location – you may want to have a centralized SSO server for the local physical location and move it to a dedicated standalone SSO server. This is the use case that I believe confuses most and why SSO HA is often selected. The standalone SSO server, if virtual can be placed in a vSphere HA enabled cluster and be protected with no further configuration, simple. vCenter Heartbeat can be used if application protection is required as well and is the only solution for availabiltiy if SSO is on a physical server. When deployed in this manner you can keep the database local (it will not grow in size or change frequently) and have complete protection of the centralized SSO environment with either vSphere HA or vCenter Heartbeat which SSO HA cannot provide.
Remote vCenter servers – you would treat the same as option one or two depending on deployment of vCenter servers at each location, you do not want to use a remote centralized SSO environment for vCenter server authentication.
Now back to my original question, the attention to SSO HA and does it offer the most protection, the answer is no which hopefully I have explained by now. SSO HA requires knowledge of third party networking technologies and today still leaves the database as a single point of failure which to why I do not recommend it as a true single high availability solution for SSO; the failover it provides is measurable to that of vSphere HA where SSO has a separate database server and with additional complexity. VMware is looking into adding support for database clustering technologies in the future and even when this happens, do you really need three solutions just to provide vCenter server authentication, I’m a fan of simple! vSphere HA and vCenter Heartbeat are much more attractive solutions for the complete protection of SSO.
The takeaway here is SSO protection does not provide any benefit without vCenter protection and so protecting one without the other becomes redundant; the solution chosen for vCenter protection will also provide same protection for SSO without any additional complexity or knowledge of third party technologies.
