vCenter High Availability
/
This feature was introduced with vCenter 6.5 and allows the vCenter Server Appliance to be clustered using an active/passive failover configuration. Most environments have usually relied on vSphere HA to protect vCenter against hardware failure and this may be fine where several minutes of downtime can be tolerated. Some applications such as vRealize Automation or VMware Horizon View Composer rely on vCenter to run workflows or provision cloned desktops and not having access to vCenter has the potential to cause service disruption. Another consideration is patching or upgrading vCenter as this typically requires a reboot and causes downtime. vCenter HA significantly reduces the amount of downtime by having a second node in standby mode running on a different ESXi host. A third node is used as a witness to act as tie breaker to prevent split-brain scenarios and is a light weight copy of the active node. All three nodes communicate with each other using a dedicated vCenter HA network which needs to be separate from the management network.
Before getting started there are a few prerequisites that need to be met so I’d encourage you to review the documentation first.
Enabling vCenter HA is straightforward and available to anyone with the vCenter Standard license and no additional vCenter licenses are required. Below I’ll run through the basic configuration workflow in one of my labs.
The first step is to configure a new port group to support the vCenter HA traffic. This is the private network used for replication and heartbeats between the nodes. I’ve just added a new port group to my vDS using a new VLAN ID.
To support vCenter HA a second NIC is required on the appliance. The basic workflow is supposed to automatically configure the NIC however I had to complete this step manually. To configure this select the vCenter server, click configure, click VM Hardware then click edit.
Add a new NIC and connect it to the port group configured earlier.
Login to the vCenter Appliance Management console.
Click networking
Click edit to configure the NIC settings
Configure an IP address for the second NIC and click OK. Then logout of the Appliance Management console.
Login to the vSphere Web Client, click on the vCenter, choose configuration, then click configure.
I’ve chosen the basic configuration which completes much of the work for me. The advanced configuration allows you to have more control over the process but you need to manually clone the nodes.
Enter an IP address for the passive node and the witness appliance.
Review the configuration and click next to continue.
I’m using vSAN in this lab and had a compatibility warning message informing me the peer node is on the same datastore. I can safely ignore this warning as vSAN only uses a single datastore.
Click finish to start the process.
The vCenter Server appliance will be cloned to another host and this process may take some time depending on your environment. Following this the witness node will be deployed.
Once the deployment is complete we now have 2 new virtual machines, one is the peer or secondary node and the other a witness node. We can also see the status of the nodes and initiate failover if required.
It’s great to see VMware building some native high availability functionality to vCenter but it’s important to understand this currently just protects the vCenter component and not the PSC. If you have an embedded vCenter and PSC then you are fully protected. If using an external PSC, then consideration needs to be given on how to make the PSC highly available. Unfortunately this adds some complexity as load balancers are required, such as Netscaler, F5 BIG-IP or NSX Edge.
