Taking vCenter Server's Pulse

VMware's vCenter Server Heartbeat makes sure your virtual infrastructure keeps right on ticking.

• By Rick Vanover
• 07/01/2009

VMware Inc. recently released a high-availability feature, called vCenter Server Heartbeat 5.5, for its vCenter Server virtualization management platform. With vCenter Server Heartbeat, you can ensure failover and failback for vCenter Server-arguably the weakest link in VMware Infrastructure-and all of its components.

Let's do a checkup on vCenter Server Heartbeat.

Pre-Operating Procedures
To get a sense of how invaluable vCenter Heartbeat might prove, consider these business and infrastructure implications should vCenter Server go offline:

• Chargeback environments: A gap in time between failure and remedy could cut off the revenue stream in a chargeback model.
• VMware Site Recovery Manager (SRM): Site failover would not be possible.
• VMware Lab Manager: The provisioning process would be unable to accommodate new machines. However, linked clone virtual machines (VMs) remain online even if vCenter Server is offline.
• VMware View: Probably the best vCenter Heartbeat use case. Client log-ons would become unavailable because VMware View Composer would not be able to spawn new VMs for client requests. But, as is the case with Lab Manager, availability for running VMs for View clients would not be affected if vCenter Server is offline.
• Performance data: No performance data would be collected.
• Licensing stopgap: If vCenter Server stays offline for more than 14 days, a licensing-protection mechanism would shut down the underlying hosts.

vCenter Heartbeat is implemented after vCenter Server is up and running. To protect vCenter Server, consider a few critical planning points, mostly revolving around networking. Above all, you must dedicate an interface-and possibly a network connection-to the replication traffic explicitly.

Networking Concerns
A second important decision point when planning a vCenter Heartbeat-protected installation is IP addressing. If you prefer hosting the secondary vCenter Server in a remote location, you have to select the vCenter Heartbeat WAN functionality when installing the availability feature. If the primary and secondary systems are going to be on the same subnet, select the LAN configuration. For different IP subnets, you should use the WAN configuration.

[Click on image for larger view.]

Figure 1. The main console for vCenter Server Heartbeat, showing protection status.

In our test installation, we selected the WAN configuration. In the WAN scenario, the vCenter Heartbeat software will need to update DNS records to reflect the change. This currently works with Active Directory-integrated DNS.

Beyond networking, pay attention to storage provisioning for the secondary vCenter Server, and be generous. During the installation, a full backup of the primary vCenter Server is sent to the secondary system. After the installation on the primary server, the installation process is repeated on the secondary system with slightly different options. One of the steps includes a restore of the backup taken in the first step to bring the operating environments of the two systems in line.

At this point, the vCenter Server Heartbeat is ready for use. If you've used a Neverfail product before, elements of the interface will be familiar.

Once the protection is underway, vCenter Heartbeat provides clear indications that vCenter Server is protected on the secondary system. The setup in Figure 1 uses a local SQL Server database; while the database service is stopped the database files are updated by vCenter Heartbeat.

Server CPR
In my usage, failover in vCenter Heartbeat happened quickly and correctly. The default configuration allows for three consecutive missed heartbeats; this accommodates most network anomalies. Should a failover occur, the secondary system console displays a series of messages that indicate the loss of heartbeats with the primary server. Some time is required to replicate the DNS record associated with the computer name for WAN implementations where the secondary system is on a different VLAN. Connectivity to vCenter Server is briefly interrupted to accommodate the switchover process and the DNS is updated, if necessary, for the WAN configuration.

Failover technologies have their weaknesses, but vCenter Heartbeat has tools to deal with them. Some of the more common failover occurrences include "false failovers" and "split-brain symptoms."

A false failover is a scenario that can indicate a failure in the primary system by the secondary system, when a failure has not actually occurred. This can happen with vCenter Heartbeat when there's a significant disruption in the channel adapter. To avoid this, keep this interface and network highly available to avoid any surprises.

A split-brain symptom can cause a false failover when the private network does not allow replication traffic, yet both systems are visible on the public network. vCenter Heartbeat minimizes this problem with a built-in feature called "split-brain avoidance."

Pricing for vCenter Heartbeat is per vCenter Server, and all options require some level of support. An additional vCenter Server license is not required, but Windows licensing for the secondary vCenter Server is needed. The lowest entry point is $12,100 Gold support, providing service 12 hours per day, Monday through Friday, for one year. Discounts may be available through VMware channel partners.

Prognosis
vCenter Heartbeat does its job of protecting vCenter Server well, but that doesn't mean it's a requirement for every vCenter Server. I don't think it's worth the price for most small and midsize VMware Infrastructure 3 installations. However, if you leverage features such as VMware View, VMware Lab Manager or VMware Site Recovery Manager, it may be well worth the price for your organization-those components are useless without a highly available vCenter Server.