Learning vSphere 6.5-Part-8-Understanding vCenter Server High Availability (VCHA)


In last post of this series learned how to External PSC for vCSA. In this post of vSphere 6.5 series, we will look into one of the best feature which is included in v 6.5 i.e high availability for vCenter Server.

If you have missed earlier post of this series, you can read them from below links:

1: Installing and Configuring Esxi

2: VCSA Overview

3: vCenter Server and PSC Deployment Types

4: System Requirements for Installing vCenter Server

5: Installing vCenter Server on Windows

6: Deploying vCSA with embedded PSC

7: Deploying External PSC for vCSA

Customers were demanding a lot for high availability solution for vCenter Server for quite some time and VMware listened to customers and made this happen in version 6.5 of vSphere.

What is vCenter High Availability (VCHA)?

vCenter High Availability (vCenter HA) protects vCenter Server Appliance against host and hardware failures. The active-passive architecture of the solution can also help you reduce downtime significantly when you patch vCenter Server Appliance.

Note: vCenter HA is only available with vCSA and not windows based vCenter Server.

VCHA Architecture

High Availability for vCSA is achieved by creating a three-node cluster which comprises of one Active node, one Passive node, and one Witness node.

Active node is nothing but the original vCSA appliance that you deploy in your environment post deployment of external PSC. This is the primary node where you connect using the vSphere Web-Client.

The Passive Node is a clone of Active node and since this is a clone it is identical to the Active node in every aspect i.e same CPU, Memory, and disk.

The Third node is the Witness node, a lightweight node that is there to form the Cluster Quorum. Witness node is responsible to verify the heartbeat interval in order to ensure failover occurs as a result of VM unresponsiveness or a host crash.

 

vcha

Active & passive node share a common public ip. During the failover, passive node would activate its nic which is assigned with same public ip taking over the complete charge whenever active node fails. Rest of the time NIC status is down in order to avoid ip conflict.

All the three nodes communicate via an internal IP also called as cluster ip. These three nodes would share a same subnet in order to communicate internally.

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.

When the active node suffers failure, the passive node becomes active and thus help minimizing downtime for the vCenter server. Below diagram illustrates the process of failover.

vcha_2

Note: The Witness is not capable of ever taking over the role of active and becoming a usable vCenter Server instance.

How VCHA works?

When VCHA is configured and HA cluster is formed, replication starts between the active node and the passive node. The embedded database i.e vPostgres captures the state of the appliance and info about the config.

There are two different types of replication that takes place in VCHA cluster:

File-level replication: This basically consists of all the configuration and log related data being replicated which is achieved using the mechanism known as “rsync” keeping the data upto date.

vPostgres DB replication: This is done to replicate the VCDB database and the VUM database. Database replication is needed to ensure during the failover we do not lose any changes that are being actively performed on vCenter DB.

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.

vcha_1.png

When a failover occurs, the state of replication is reversed as the former active node which is now passive (because of failure) comes back online and re-joins the VCHA Cluster and becomes active again.

Note: Replication always flows from the current active to the current passive.

vcha_3

I hope this post is informational to you. Feel free to share this on social media if it is worth sharing. Be sociable 🙂

About Alex Hunt

Hi All I am Manish Kumar Jha aka Alex Hunt. I am currently working in VMware Software India Pvt Ltd as Operations System Engineer (vCloud Air Operations). I have around 5 Years of IT experience and have exposure on VMware vSphere, vCloud Director, RHEL and modern data center technologies like Cisco UCS and Cisco Nexus 1000v and NSX. If you find any post informational to you please press like and share it across social media and leave your comments if you want to discuss further on any post. Disclaimer: All the information on this website is published in good faith and for general information purpose only. I don’t make any warranties about the completeness, reliability and accuracy of this information. Any action you take upon the information you find on this blog is strictly at your own risk. The Views and opinions published on this blog are my own and not the opinions of my employer or any of the vendors of the product discussed.
This entry was posted in Vmware. Bookmark the permalink.

2 Responses to Learning vSphere 6.5-Part-8-Understanding vCenter Server High Availability (VCHA)

  1. Pingback: Learning vSphere 6.5-Part-9-Configuring vCenter Server High Availability (VCHA) | Virtual Reality

  2. Pingback: Learning vSphere 6.5-Part-10-VCHA failover testing | Virtual Reality

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s