vCenter Server Heartbeat, the concept, deployment and considerations!

One of the great products from VMware, yet least talked about, is the vCenter Server Heartbeat. I’ve been always fascinated with anything that helps achieve high-availability and uptime for applications, and our product here under the spotlight is no exception to that. Unfortunately there is no evaluation version for it available, so no videos this time, only screenshots (extracted from the VMworld 2009 session)

Why would you use it?
Despite that fact that you can use VMware’s HA to protect your vCenter Server, this can be achieved only when you run it as a VM, while many customers and deployments out there (me included) still use the vCenter as a physical server. Even in case of using VMs, things like HA and FT (available in vSphere4) will only protect you from hardware failures, not an application or OS crashing. From here the vCenter HB (my own acronym!) is appealing! Whether it’s your vCenter service, network connectivity or even the OS, the vCenter HB can protect you from any failure that may occur through these elements.

How to start?
This is the core beauty of the product, you don’t need to restructure or design your vCenter architecture from the scratch, it’s as simple as this:
If you run physical: You can wither P2V to a new VM, or Backup/Restore to another physical server.
If you run virtual: You only need to clone the VM and you’re done.

How it works?
The vCenter HB works pretty much like a traditional cluster, you need to have a private link between the Active/Passive nodes, to maintain the heartbeat process. vCenter HB hides the passive node from the network using packet filtering, so it’s not entirely like MSCS where you have separate IP address for each node and virtual IP to operate on.

The vCenter HB has an additional mechanism to ensure the health of the active node, it’s not just a matter of a ping-response process, in fact, it can failover based on other criterias like: the CPU utilization is getting very high, the disk I/O .. and so forth.

The switchover scenarios:
Manual Switchover: This is obviously a manual process when the SysAdmin wants to perform a planned maintenance on the vCenter Server/Components.
Auto Switchover: This is the process of switching over from one node to another based on the health and criterias you set your self, like performance degradation, or even in the event of the application failure.

Failover: this is scenario happens when the complete hardware goes down, the OS crashes or the private link is down.

It’s worth mentioning here also that the vCenter Hearthbeat has a great feature for replicating specific files/fodders that you choose. One of the things that I can think of is the Sysprep files for example, you may change/add from time to time the associatedfiles for Sysprep in your active node, and map the same on the passive node. Through vCenter Heartbeat you can have this piece of mind by setting your own replication for specific folders to have that automated for you.

Some considerations when deploying the solution:

There are some considerations that you need to be aware of prior to deploying the solution, listed below in no specific order:

  • vCenter Server Heartbeat currently works only on windows OS, there is no support yet for the up-coming release of the Linux based vCenter Server.
  • vCenter HB can protect other components like: Update Manager, License Server, Capacity Planer, Converter and SQL server “only” if they run on the same protected vCenter server.
  • There is no support now for other vCenter products like: Lab Manager, SRM, Lifecycle and Stage Manager. In case of a switchover/failover, it will appear to these other applications that the vCenter was just restarted, each product (SRM for example) handle the restoration process of the connection between itself and the vCenter Server. It is in the roadmap of the vCenter heartbeat that these applications will be protected out-of-the-box.
Share Button