vCenter Server Heartbeat (vCSHB) is a great mechanism for protecting vCenter Server and related or supporting services, such as its Microsoft SQL database or Horizon View Composer. However, with any solution of this magnitude, there will be points in the design to which careful consideration needs to be applied.
Physical vs. Virtual
Unless you have a very good reason to change, stick with your existing deployment model for your primary vCenter Server. That is, if you currently have a virtual or physical vCenter Server, unless you’re having problems or business requirements dictate otherwise, stick with what you have for your primary vCenter Server.
There are some requirements around the secondary machine for both physical and virtual scenarios, which are:
Virtual Secondary
Virtual Primary
Similar CPU (including resource management settings)
Memory configuration (including resource management settings)
Appropriate resource pool priorities
Each virtual machine used in the Virtual to Virtual pair must be on a separate ESX host to guard against failure at the host level.
If using more than one NIC, each virtual NIC must use a separate virtual switch.
Physical Primary
Similar CPU
Identical Memory
Physical Secondary
Hardware
Similar CPU
Similar memory
Identical number of NICs to the Primary server
Drive letters must match the Primary server
Available disk space must be greater than or equal to the Primary server
Software
OS version and Service Pack version must match the Primary server
OS must be installed to the same driver letter and directory as on the Primary server
Machine name must be different from the Primary server prior to installing vCenter Server Heartbeat
Set up in a workgroup prior to installing vCenter Server Heartbeat
System date, time, and time zone settings must be consistent with the Primary server
The decision of whether to use a virtual or physical secondary will rest upon the same types of requirements you had for your primary. A virtual secondary will be easier to create (using either a vSphere clone (V2V) or a VM created by vCenter Converter (P2V)) and easier to manage as a VM. You also get DRS, HA, and all the other niceties that come with vSphere. You may want to choose a physical secondary if you have particular requirements that make a virtual vCenter Server impossible. In my experience, these are typically artificial requirements placed on IT by the business, but I’ll get off my virtualization-first soapbox for now.
Single NIC vs. Multi NIC
Either single NIC or multi NIC are valid deployment options, especially within V2V or P2V deployment scenarios where the hypervisor can provide network redundancy for a single NIC. In a P2P deployment, multi NIC can provide additional resiliency against network failure.
LAN Deployment vs. WAN Deployment
This is the simplest deployment model, where you’re deploying a secondary machine for high availability (HA), typically within a single datacenter, with a single, shared, Principal (public) IP address. The obvious requirement here is that both the primary and secondary server have access to the same layer 2 network segment, so if you’re thinking about deploying vCSHB in multiple datacenters in LAN deployment mode, you’ll have to stretch layer 2 across both datacenters.
WAN deployment offers the flexibility to deploy your primary and secondary servers on different subnets or simply for a DR use case, but there are some additional requirements:
Persistent static routing configured for the channel connection(s) where routing is required
One NIC minimum, two NICs (1 x Public and 1 x Channel) are recommended
At least one Domain Controller at the Disaster Recovery (DR) site
If the Primary and DR site uses the same subnet:
During install, follow the steps for a LAN or VLAN on the same subnet
Both servers in the vCenter Server Heartbeat pair use the same Public IP address
If the Primary and DR site use different subnets:
During install, follow the steps for a WAN
Both servers in the vCenter Server Heartbeat pair require a separate Principal (Public) IP address and VMware Channel IP address
Provide a user account with rights to update DNS using the DNSUpdate.exe utility provided as a component of vCenter Server Heartbeat through vCenter Server Heartbeat Console Applications > Tasks > User Accounts
VMware recommends integrating Microsoft DNS into AD so that DNSUpdate.exe can identify all DNS Servers that require updating
Refer to the following articles in the VMware Knowledge Base:
Knowledge base article 1008571 – Configuring DNS with VMware vCenter Server Heartbeat in a WAN Environment
Knowledge base article 1008605 – Configuring vCenter Server Heartbeat to Update BIND9 DNS Servers Deployed in a WAN
Conclusion
vCenter Server Heartbeat can provide a great (and supported!) method of protecting your vCenter Server. Follow a few simple guidelines and your deployment will have the proper footing to be a success.