In my first post of the vSphere 6.5 series, I mentioned about vCenter High Availability (VCHA) along with the other improvements and new features that are part of the VCSA 6.5.
vCenter High Availability (VCHA) is one of those features that works right out of the box and does not require any additional products or Microsoft clustering to make it work.
As mentioned before, vCenter High Availability (VCHA) is only available for VCSA 6.5 and cannot be used with Windows version of the vCenter Server.
If you are going to use Windows vCenter Server which I do not recommend as VCSA is the preferred deployment type going forward, you can still use Microsoft clustering to provide redundancy to the vCenter Server.
vCenter High Availability (VCHA) Prerequisites
- An instance of the vCenter Server Appliance deployed.
- Separate datastores to deploy all three nodes.
- At the least three ESXi hosts to deploy the three nodes.
- A public IP Address that will be used to connect to the active node. (provided during the installation of the appliance).
- Three private IP addresses (1 IP per node) for replication and internal communication called the internal cluster network.
vCenter High Availability (VCHA) Configuration
vCenter High Availability can be configured by creating a three-node cluster that contains the Active node, Passive node, and the Witness node.
An active node is the VCSA that was first deployed and is being used in the environment to manage all the workloads. This is the primary node that will use when connecting using Web Client and any third-party applications. This is accessed using the Public IP Address.
We then deploy a Passive Node which is identical to the Active node, same CPU, Memory, and disk. This is done through a Cloning Process.
The Third node is the Witness node, a lightweight node that is there to form the Cluster Quorum.
How vCenter High Availability (VCHA) Works
vCenter High Availability (VCHA) for vCenter Server Appliance helps recover against both hardware and software failures. This is typically in minutes, the time required to switch the services between the nodes.
When you activate the vCenter High Availability (VCHA) feature for a vCenter Server Appliance, the appliance node that is protected is called the 'active' node.
Two other appliance nodes are created: a 'passive' node and a ‘witness‘ node.
If the vCenter Server Appliance active node fails, the passive node takes over the role of the active node.
This is possible because the state of the active node is replicated to the passive node. The state of the appliance is captured in a vPostgres database that is embedded in the appliance and also in the configuration files.
There are two different types of replication that take place here:
- File-level replication: This is the replication of the configuration files and the service state and is done using Linux RSYNC.
- Native vPostgres DB replication: This is done to replicate the VCDB database and the VUM database if you are using vCenter Update Manager.
If the active node has a failure, then the current Passive node takes on the role of the Active node. The Public IP address is switched from the Active to the Passive node and the clients now connect to the now active node, once the vCenter Services are started.
Well, that is all I have for today. In the next post, we will look at the different deployment types available for vCenter High Availability (VCHA).
I hope this has been informative and thank you for reading!
