As every administrator knows, VMware vCenter Server is a great tool for managing ESXi because it allows you to manage multiple servers and VMs from a single console application. However, vCenter isn’t infallible; if the administrator doesn’t have the foresight to restrict vCenter to a specific number of hosts, she will be faced with a long day of logging in to each host trying to locate the vCenter in a large cluster of hosts.
Fortunately, VMware recognized this shortcoming and developed a new product to address it. VCenter Server High Availability (HA) requires vSphere Appliance 6.5 and the hosts in the cluster must be ESXi 5.5 or later. VCenter also needs to be self-managed; basically, vCenter needs to be in the cluster it’s managing.
Before deploying vCenter HA, it’s important to understand how it works. When the vCenter HA feature is enabled, an additional vCenter Server instance is created on another host akin to a hot standby. Another clone functions as a witness for the first two vCenters. In the event of a failure, the witness decides which vCenter should be live, preventing split brain scenarios.
Obviously, such a setup is sensitive to network issues. The maximum acceptable network delay is 10 milliseconds. Therefore, a second private network is used to communicate between vCenter HA-enabled nodes. Each host needs to have an additional network port group. This port group manages the traffic for the vCenter HA replication traffic. This is used as a private heartbeat network.
Prior to setup, the administrator needs to set up a standard network port group specifically for the heartbeat network on each host. I’d advise keeping the traffic on an isolated network to avoid potential latency/congestion issues. This network must be different to the one that the vCenter normally listens on. As an example, I am using the network range 172.16.0.x for the heartbeat.
To set up a fully functioning vCenter HA setup, you should have a minimum of three hosts because not only is there a full live clone of vCenter, there’s also a witness vCenter that works to prevent split-brain issues.
Setting up vCenter High Availability
To set up vCenter HA, start by opening the vSphere Web Client using your administrator account, navigate to the top level of vCenter and over to the Configure tab, as shown in Figure A.
Navigate to the vCenter HA link in the left hand menu. It will initially inform you that vCenter HA is not configured, as shown in Figure B.
To configure, click Configure vCenter HA on the right side. This will present you with two options, basic and advanced, as shown in Figure C. Selecting the basic settings will do all of the hard work for you, including cloning vCenter. You can change options from the standardized default later if necessary.
Click Next to get to the next page which will ask for IP details for the new heartbeat network interface card. Remember, this needs to be a different network than the standard public interface of the appliance. Don’t forget to select the appropriate vSwitch, which you should have created earlier.
On the next page, you will need to configure additional addresses for the Passive and Witness nodes, as shown in Figure D, and then click Next.
On the last page you’ll see an overview of the deployment configuration. If necessary, you can edit details pertaining to the Passive and Witness nodes — such as location — by clicking Edit on the right side. The reason you see warnings in Figure E is because I’m only using one shared storage data store.
Finally, click Finish and the deployment will begin. Be aware that it may take a significant amount of time to deploy and configure the setup.
Something to keep in mind when using vCenter HA: When doing maintenance on the vCenter network, you should suspend the vCenter HA functionality. To do so, navigate to the vCenter HA screen and click Edit. This will present you with a number of options and descriptions of what each option does.
Assuming you’re working in a nonproduction lab environment, you can even initiate failover by clicking Initiate Failover. Once the failover is finished, you can log in to the vCenter Server just as before, but on the alternative vCenter.
This new functionality presents a long-desired utility that addresses the old issue of having HA for the vCenter itself. It wasn’t possible before due to the fact that fault tolerance only ever supported a single CPU at the time.