How it works...

Enabling VCHA will configure a second network adapter for the Active node and configures it to connect to the VCHA network. The VCHA network should be a different subnet than the primary (management) network of the vCenter. It then clones two copies of the active node. One of the clones is configured as the Passive node and the other as the Witness node.

The following screenshot depicts the architecture of VCHA. The Active node synchronously replicates the vPostGres Database (VCDB) to the Passive node using Native PostgreSQL replication. The changes to the configuration files are asynchronously replicated to the passive node using Linux Remote Sync (Rsync). See the following diagram, vCenter Native HA Architecture:

It is important to note that no data is replicated to the Witness node. It only acts as a tie-breaker (quorum) for the VCHA cluster. 

If the Active node fails, then the cluster fails over, and the Passive node takes the identity (FQDN/IP address) of the vCenter Server. It does so by sending a gratuitous ARP, which notifies the network of the new MAC address. 

If the Passive node fails for any reason, the cluster will be in a degraded state, therefore preventing automatic/manual failovers.  You will need to either repair or redeploy the node.  The following screenshot shows the REDEPLOY option being made available on an affected cluster:                

                         

If the Witness node fails, then the cluster enters a degraded state, therefore preventing automatic/manual failovers. You will need to either repair or redeploy the node.                                           

Externalizing the PSCs is a deprecated concept in vCenter 6.7. Hence, there is no real need to deploy external PSCs and then place them behind a network load balancer.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.223.32.230