vCenter High Availability Deployment and Testing in my Home Lab

Home / Home-Lab / vCenter High Availability Deployment and Testing in my Home Lab

Since I upgraded my home lab to vSphere 6.5 I wanted to test the vCenter high availably feature.  In this post we will discuss vCenter High Availability (VCHA) deployment (step by step installation) and we are also going to test the feature and see how the system is responding.

So what is VCHA?:

VCHA is a way to eliminate single point of failure when it comes to the vCenter appliance. The architecture of VCHA includes three vCenter nodes, active node, passive node and witness node, which serves as a quorum only. VCHA supports both embedded and external PSC configuration, and if you use external PSC configuration you will need to use load balancer when designing your solution (supported load balancers are Netscaler,F5 BIG-IP and NSX Edge).

When you deploy VCHA, the system clones the current vCenter twice, one for the passive node and one for the witness node. The system also creates a private network between the three nodes. The VCHA private network is used for vCenter database and configuration file replication between the nodes and also for heart beat mechanism.

If you use a vSphere cluster with DRS enabled, you will not have to worry about the vCenter nodes placement; if you don’t use DRS, place each vCenter node on a different ESXi host to eliminate single point of failure (you will need at least 3 ESXi hosts).

So what happens if the active node fails?:

I tested that scenario in my home lab. Under the hood the passive node vNIC1 becomes online, gARP is initiated to let the management network know that the new active vCenter node is the previous passive node. At this point replication between the vCenter nodes is paused until the failed vCenter node is back online or redeployed.

Source:VMware vSphere High availability guide .

VCHA Pre-Requisites:

  • vCenter 6.5 appliance with single vCenter license (standard license is sufficient and no need for 3 licenses)
  • vCenter Deployment size small or greater
  • Sufficient disk space – depends on your current vCenter deployment size
  • Less then 10ms latency on VCHA private network
  • Diffrent subnet for VCHA
  • Prepare three IP’s for the new VCHA subnet

Deployment:

In my lab I have a single vCenter with embedded configuration.  In the following section, I will demonstrate step by step how I configure my lab environment to use the VCHA feature.

Here is a summary of the steps to deploy  VCHA:

  • Create separate PortGroup on your vSwitch/vDS
  • In the vCenter configuration page, click on vCenter HA and then click on Configure
  • Choose the basic configuration (default)
  • Provide the VCHA IP for the active vCenter node and then select the PortGroup for the VCHA subnet (I created the PortGroup ahead of time)
  • Provide the VCHA IP for the passive vCenter node and the witness node.
  • Review the warning and error, you can choose a ESXi host, datastore and network placement for the passive and witness vCenter nodes.
  • Review and click on finish.
  • The process takes a little time (finished within 15 min on my system), once all is done you can review the VCHA status.

Testing:

To test the VCHA feature, I forcefully poweroff the ESXi host that runs the Active vCenter node. When I did that I temporarily lost connection to the web GUI, and when I refreshed the browser, I got the message “failover in progress”. Once the failover is done, I got my GUI back. I checked the VCHA status and started back the powered off ESXi host.

Below are the screenshots for the steps described above:

Deploying:

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

 

Testing:

1. POWER OFF AND REFRESH

2.CHECK STATUS

3. power back on

 

 

Thanks for reading.

Mordi.

 

 

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *