Introduction
VMware’s logic is that vCenter is used to manage so many Tier 1 applications and that makes vCenter, itself, a Tier 1 application. We all know that Tier 1 applications need to be highly available. So, if VMware’s logic is right, then vCenter also needs to be highly available. That is where vCenter Heartbeat steps in.
Of course, this logic is true only if you feel that vCenter is worthy of that Tier 1 application status. At large enterprises they may not have to think about this question at all. These companies may have a large team of virtualization admins who use vCenter around the clock. They may have even opened up access to vCenter to various parts of the business who use it to manage their virtual machines. Obviously, in cases like these, there is more than just an inconvenience to a single admin if vCenter goes down.
However, at other companies who use vCenter, they have to first ponder the question as to what would be lost if vCenter were suddenly not available. I can tell you that the ESX hosts and Guest VMs will continue to work fine. vCenter is not required for ESX functionality but it is required for specific, more advanced, features of virtual infrastructure. For example, VMHA will still function but DRS will not. For the entire list see- What if my VirtualCenter server crashes?
What is vCenter Heartbeat?
So we said that vCenter Heartbeat provides vCenter high availability but what, exactly, does it check and attempt to protect you from?
-
OS failures on the vCenter server
-
Hardware failure of the vCenter server
-
Network failures affecting the vCenter server
-
Application failures on the vCenter server (like the vCenter services or SQL server failure where the vCenter data is located)
The backup vCenter server will even take over for the primary server if there is significant application performance degradation.
How does it work? vCenter Heartbeat server works by replicating all vCenter configuration and data to the secondary passive server using (hopefully) a dedicated network channel. The secondary server is really up all the time, with the live configuration of the active server, but an IP packet filter is masking it from the active network.
Here is what it looks like:
Figure 1: vCenter Heartbeat Server application (Graphic courtesy of VMworld Europe presentation TA15)
And here is a diagram of how it works:
Figure 2: Graceful transfer of vCenter server from active to passive (Graphic courtesy of VMworld Europe presentation TA15)
VMware’s vCenter Heartbeat was announced at VMworld Europe 2009 and it is already used by over 130,000 customers around the world when announced. How can that be, you ask? No, VMware didn’t come up with this product out of the blue. VMware is really just reselling NeverFail under the name. According to this story at Virtualization.info (VMware kills another ecosystem with vCenter Server Heartbeat 1.0), VMware has an exclusive agreement with NeverFail. That agreement means that VMware will not resell other products from competitors nor can NeverFail sell this product on their own any longer. In the same story, it’s pointed out how this new exclusive agreement effectively kills all competition from a variety of companies who were previously partners with VMware.
vCenter Heartbeat is available for $9995 per vCenter or $12,995 when bundled with vCenter server.
How can vCenter Heartbeat help you?
More specifically, vCenter Heartbeat provides continuous monitoring of vCenter connectivity, databases, and components, license server, and update manager. I was very pleased to see that it does indeed work across a LAN or WAN. Thus, Heartbeat provides offsite replication and availability for vCenter. I also think that it’s great that it has only a small impact on the performance of the virtual infrastructure. Unlike some other clustering solutions, Heartbeat is hardware agnostic so you can use a physical server as a primary server and a virtual server as a secondary server, etc.
We know that if you did run vCenter on a virtual machine, you could partially protect it using VMHA. However, that isn’t going to work over a WAN nor does it help if the SQL data is not on the vCenter server. Plus, VMHA has no application awareness of vCenter and could care less if the services won’t start (for example). That said, according to Virtualization.info, 60% of customers still run vCenter on physical machines.
There are several design configurations for implementing vCenter Heartbeat. For example, you could have physical to physical, physical to virtual, or virtual to virtual.
Initially, to create the secondary server, the primary server is cloned. If the primary is already a virtual server, you can simply clone it using the VI Client. If the primary server is a physical server, you would have to clone it using a P2V conversion tool like VMware Converter.
Keep in mind that Heartbeat does not just protect vCenter but also other VI components installed on the vCenter server such as Update Manager, License Server, Capacity Planner, and VMware Converter Enterprise.
For Oracle users out there, you should know that VMware Heartbeat only works only if you use MS SQL Server as your vCenter Server database. Thing brings up an important point – that the vCenter database does not have to be on the same server as vCenter for Heartbeat to protect vCenter.
For more information on vCenter Heartbeat, consider the VMworld 2009 session – Protecting your vCenter Server with Server Heartbeat, which offers both a Video and PDF
For VMware’s official site where you can purchase (but not evaluate) Heartbeat, visit: VMware vCenter Heartbeat.
