As I’ve written in a previous post, 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 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
- 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
- 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:
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.