Home > Blogs > VMware vSphere Blog


vCenter Single Sign-On – Part 3: Availability

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.

  1. 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.
  2. 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.
  3. 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.

vCenter Single Sign-On – Part 1: What is vCenter Single Sign-On?
vCenter Single Sign-On – Part 2: Deployment Options
vCenter Single SIgn-On – Part 4: Pre Install Requirements

23 thoughts on “vCenter Single Sign-On – Part 3: Availability

  1. Loren

    For me, the issue with availability for the SSO service derives from the fact that it can be installed separately from the vCenter Server. This means that now when we can’t login to vCenter, there is an additional server to troubleshoot. This is an extra layer of complexity, which imposes additional expertise requirements on the help desk and administrators operating the virtual environment. More likely, the people will not change and so we’ll run into people jumping to conclusions about the problem based on inaccurate information, and perhaps even start twisting the wrong knob and making the problem worse.

    With a highly available SSO configuration, we would have the ability to generate an alert when availability is reduced but not fully compromised. This buys us time to properly identify the source of the problem and have the right people do the troubleshooting.

    I would actually prefer the option to have fully independent SSO servers that aren’t even aware of each other. No shared database; each would point to their own instance. Configuration of each would be done independently (where joined to a domain, we’re not expecting to ever need to configure the SSO server after the initial setup, which would be scripted). This SSO ‘farm’ would be behind a load balancer, and the vCenter servers would be registered with each SSO instance. In this architecture, which is really fairly simple, SSO is highly available and the SSO servers have no dependency on each other.

    1. Justin KingJustin King Post author

      Thanks Loren, this is why I wrote this post, SSO HA does not provide the level of availability that vSphere HA or vCenter Heartbeat can provide.

      1. ThomasNas

        Hi Justin, great post.
        I have a question. We are looking at settiing up a new vsphere 5.1 environment in which we want full redundancy. We were thinking about following setup.

        vcenter 5.1 with heartbeat => standby vcenter

        SSO with hearbeat => standby SSO

        SQL server with heartbeat => standby SSO

        Is it possible to host the DB’s for vcenter and SSO on the same SQL and have this protected by heartbeat ?

        And what would be the correct steps to implement ?
        First install both DB’s, clone DB server and install heartbeat ?

        Thanks !

        1. Justin KingJustin King Post author

          first I have to ask why separate SSO? it is small and relatively static and a component of VC.

          You would upgrade/install the 5.1 environment, SSO and VC DBs can be on same DB server. Once on vSphere 5.1 you can proceed with HB6.5 by cloning each VM (no customizations) and follow install steps of HB itself.

          unless your managing 100s of hosts I would stick with a single VC VM and DB VM both with HB

          1. ThomasNas

            Hi Justin,

            We are a service provider with a fairly large amount of hosts and vms

            So after you recommendations, we are thinking about following setup

            server 1 : SQL server with vcenter and SSO DBs, protected by HB

            server 2 : vcenter, SSO and inventory service, protected by HB

            server 3 : Web client ( located in DMZ). Can this also be protected by HB ?

            Regards

  2. Pingback: vCenter Single Sign-On – Part 2: Deployment Options | VMware vSphere Blog - VMware Blogs

  3. Pingback: vCenter Single Sign-On – Part 3: Availability | VMware vSphere Blog - VMware Blogs

  4. Craig

    Justin,

    On your numbered points for “Based on the type of environment SSO will be servicing, will determine the best approach for SSO availability.” #2 you write: “When deployed in this manner you can keep the database local (it will not grow in size or change frequently)…” What are your thoughts on using the Express Database packaged with it, compared to using an existing database server. My configuration will have my Server vCenter and my View vCenter using this SSO server and I would like for one of them have to rely on the others database server and have it locally contained. I guess I am a little hesitant on using an Express version, though, as I have had issues during upgrades of my Update Manager servers that have used Express in the past. What are your thoughts?

    1. Craig

      **correction above**

      “…I would like for one of them to NOT have to rely on the others database server…”

      1. Justin King

        I do recommend myself the use of SQL Express local to SSO for the SSO DB. This keeps all dependencies local and provides complete options for backup and availability. Alternatively you can also install full SQL but a license is required for that, have you looked at using the appliance with builtin vPostgres and just running SSO and web client?

        1. Craig

          I did not. Is there an appliance that just has the SSO feature on it? (I am not seeing it on the downloads site). I have plug-ins like NetApp VSC I am using on my current vCenter Server.

          1. Justin King

            the appliance is full vCenter, you can enable just SSO (and maybe web client) and deploy that as a standalone with embedded database to meet the centralized needs of a physical location

  5. Greg Laverdiere

    We currently have SSO running with its own DB on the same VM as our vCenter service. Everything is protected with VMware HA and I am ok with that.

    Now we are in the process of building a second vCenter to be dedicated to our VDI infrastructure. At this time the goal is to link the second vc to the existing SSO instance.

    I am trying to mitigate the risk of collateral damage… in this case if I lose my primary server running SSO+VC1, I would also lose VC2 running on the second server

    As this is the only risk I am trying to mitigate, I find that all the deployment scenarios add way too many layers of complexity that can also fail… external DB… load balancer, etc… Gives me the feeling that increase the risk factor way too much to address a rather simple issue.

    What about having a single vm dedicated to SSO… 1vCpu protected by Fault Tolerance? would keep a single instance… local db?

    Any thoughts?

    Thanks
    G.

    1. Justin King

      when multiple local vCenters are present, separating SSO to a centralized model works well and something I recommend to prevent bringing the whole environment down. Ideally running a local SSO to each VC is simplest but this also requires a local web client for each VC and adds multiple management points. One item to note with VDI is do you have separate administrators? using a centralized SSO will show all VCs including the VDI VCs, this can be controlled with roles/permissions on the VC but just something to think about if you typically isolated the VDI from server infrastructure.

      1. Greg Laverdiere

        Thanks.. .One thing we want to achieve is a single-pane of glass…

        I would prefer to stick to a simple SSO deployment… Any thoughts on protecting a dedicated VM for SSO through Fault Tolerance

        G.

        1. Craig

          The SSO requires two or more logical processors, and Fault Tolerance is still restricted to a max of a single CPU.

          1. Justin King

            full VC requires 2 or more CPUs. If just running SSO you can actually use a single CPU and thus have FT as an option

  6. Pingback: vCenter Single Sign-On – Part 4: Pre Install Requirements | VMware vSphere Blog - VMware Blogs

  7. dedicated server

    Excellent blog here! Also your site loads up fast!
    What host are you using? Can I get your affiliate link to your host?
    I wish my site loaded up as fast as yours lol

  8. Ryan

    We have three separate VC servers in different Continents. None are using link mode as we had problems with this in the past. As it stands today each site is managed and updated independently with its own web console. We have no heartbeat setup, If we lose VC we don’t mind as the VM’s are up but just at reduced functionality.

    I am looking at installing the following setup for the upgrade.

    VM 1: 4 vCPU, 12 GB Ram: VC Server + SSO (100 Hosts)- Protected by vSphere HA

    VM 2: 2 vCPU 12 GB Ram: SQL 2008 with VC Database + SSO Database- Protected by vSphere HA

    Based on what you have said above its most likely best to go with basic however is there any issue of moving the SSO database to the other SQL server vs local, I would think the only difference would be that it needs an ODBC connection. Any pitfalls to think of here like SSL Certs needed?

    1. Ryan

      Also forgot to note the web client and inventory service would also be on the VC / SSO server.

Comments are closed.