One of the most anticipated features of vSphere 6.5 is native high availability for vCenter Server. No additional product like vCenter Server Heartbeat or no third party feature like MSCS/WFCS is needed.
The first thing to point out is that this feature is exclusive for the vCenter Server Appliance 6.5.
Windows vCenter Server 6.5 will still support MSCS/WFCS to provide high availability.
The high-level design of VCHA is that we have a three node cluster. An “active” node and a “passive” VM – the “passive” being a full clone of the original “active” and lastly a “witness” VM which is a stripped down clone of the original “active”.
The Witness is not capable of ever taking over the role of active and becoming a usable vCenter Server instance.
A minimum of two nodes must be online. You cannot suffer the loss of more than one node in the VCHA cluster and expect to continue to have service.
File-level replication constantly takes place between the current Active and Passive. This is done using Linux RSYNC and keeps all the configurations and service state in sync.
Native vPostgres DB replication handles the VCDB and VUMDB replication.
If the current Active node suffers a failure then the current Passive node will take over the role and become the new Active node. There is no change in FQDN.
If a failover occurs, replication will reverse as long as the former active, now passive, comes back and re-joins the VCHA Cluster.
Replication should always be flowing from the current active to the current passive.
The VCHA Team has done some tremendous work to really simplify and streamline the deployment of VCHA.
We have two deployment options. Basic and Advanced.
I’m not a fan of those terms, but think of Basic = Automated and Advanced = Manual.
Both methods give the exact same end result.
Basic is the preferred method. It automates the entire process for you. All you need to do is provide a few IP Address, and the compute and storage location for the passive and witness nodes. It takes care of everything else. It will also automatically create a DRS Anti-Affinity rule to keep the three VMs separate.
Basic can be done if the VCSA VM is located in the same SSO Domain as vCenter Server itself.
The following video is a quick demo of a Basic Deployment. As you can see, the VCSA VM resides within the vCenter Inventory.
If the VCSA is a Virtual Machine managed by a completely separate vCenter Server (i.e. a separate management VC) then you would need to use the Advanced method. The reason for this is, if the VC you are enabling VCHA on cannot locate itself as a VM, it cannot automate the clones of itself in this release and must rely on the user to manually perform the clone operations.
When doing the Advanced option you must:
- Manually add a second NIC on the VCSA VM attached to your VCHA Network Portgroup.
- Via the VAMI (https://IP_FQDN:5480) configure a static IP address for the internal VCHA Network.
- Launch the VCHA Configuration Wizard and choose Advanced.
- Provide the IP Addresses you want to assign to the Peer and Witness node.
- Clone the VCSA VM Twice, ensuring to also use Guest Customization to provide the unique IP Addresses you entered previously to the second NIC of each clone.
- Power on each node and complete the Wizard.
The following is a quick demo of an Advanced deployment. As you can see the VCSA named vcsa-02 does not exist as a VM in it’s own Inventory. We will manually clone this VM from it’s Managing VC.