The VMware vCenter Server is an important function in a vSphere environment, and it needs to be highly available. Without vCenter, you will be challenged on managing your environment and some features will not be available. In today’s article, I will discuss some of the options for increasing the availability of your vCenter Server.
Why VMware vCenter Server Is Necessary
vCenter Server has always been important, but the management features become even more vital as customers move past server virtualization. The vCenter can become a single point of failure if not designed to meet requirements when implementing additional management layers that rely on vCenter, such as vCloud Suite or Horizon Suite.
In these cases, if the vCenter Server was unavailable many operations would not be work, such as the following.
Horizon Suite – If vCenter was unavailable, the system would be unable to provision any new desktops. Sure, you might not be creating any new desktops during this outage, but if you are using linked clones that are destroyed on logout, this would be a huge issue.
vCloud Suite – You would have different services affected depending on whether you are still using vCloud Director or are using vCAC. The cloud layer would be unable to provision any new VMs, and this would be out of your control because the idea of self-service means that you are not notified when someone needs a new VM. Other tasks such as console access or ability to edit VM settings would also be affected.
vCenter Availability Options
Within a vCenter install there is the vCenter Server and the database. In vSphere 5.1 and newer you will also need to consider the vSphere web client, the inventory service, and the SSO in your high availability (HA) considerations. For the scope of this blog post we are just going to look at the vCenter server itself and the database.
vSphere High Availability – This is a very common method for the past few years for protecting vCenter Server. Under this model you are relying on the vSphere HA functionality to automatically restart the VM if the host on which it’s running goes down. This type of protection should have the vCenter VM back online in one to ten minutes, depending on settings and configuration of the infrastructure. This type of protection is easy and free with vSphere, but it does not protect you against operating system-level corruption. With an HA event your vCenter will be unavailable during the restart period.
Database HA – The database for vCenter is an important piece – the vCenter Server is of no use without it. So finding a solution that can mesh your protection levels for database layer to the vCenter Server is important. There are different methods of database clustering and mirroring to help with achieving a higher level of availability. These options will depend on what database vendor you use for your vCenter database. Be sure to check with VMware to verify the support statement around the option that you choose. I have seen many customers choose a method that increased availability but was not officially supported by VMware. They have to be willing to accept the risk and know what may be required from them if they need VMware’s support later.
vCenter Heartbeat – This method is the officially blessed and recommended method for protecting both vCenter and the database. Heartbeat works by using a pair of servers for the vCenter parts to increase availability. This allows for automated or manual failover processes and provides operating system-level protection. There is a separate license that must be purchased for Heartbeat, but the cost is worth it to meet availability requirements for most projects.
When architecting your VMware vCenter solution, be sure to closely examine your requirements when choosing how you will provide HA for your management layer.