vCenter 6.5 High Availability – Overview (Part 1)

This is Part 1 of a multi-series where we will review the steps required to deploy and configure the new vCenter Server 6.5 High Availability (Native HA) solution. This is exclusive to the VCSA (vCenter Server Appliance). I’ve been looking forward to a high availability solution for vCenter for a long time now. I cannot count the number of times I’ve had discussions with customers over the years regarding vCenter and ensuring its availability. It usually would boil down to having a clear cut vSphere HA design to ensure vCenter availability and have numerous procedures in place in the event of a failure.

My goal here is to break down vCenter Server 6.5 High Availability (HA) into multiple sections and keep it simple. First we will start with a brief overview and then we will get straight into deployment.

Let’s review a few key features of the vCenter High Availability clusters:

• Replication Types – there are two (2) types of replication between the active and passive nodes. There is a native PostgreSQL “synchronous” replication for the DB. Then there is a separate “asynchronous” replication process used for external data (data not in the DB).
• Node Types – there are three (3) nodes which are all CLONED from the existing vCenter Server Appliance. The nodes types are Active, Passive and Witness.
• vCenter HA Workflows – there are two (2) types of workflows used to deploy/configure vCenter HA.
  • Basic Workflow – this procedure is very simple with minimal admin overhead. During this process the passive and witness nodes are “automatically” created. DRS anti-affinity rules are also applied to ensure the nodes are not running on the same vSphere host. The only prerequisite for the Basic Workflow is to manually create the vCenter HA Network which is nothing more than a port group on your virtual switch.
  • Advanced Workflow – There is more involvement from the administrator here as the passive and witness nodes are “manually” cloned. This workflow is used in the event the three nodes (active, passive and witness) are being deployed on separate clusters, virtual data centers or vCenter Server instances.  This workflow provides increased flexibility when designing the solution. The only prerequisites here is also manually create the vCenter HA Network and to add the second vNIC to the vCenter Server (active node).

You want your vCenter HA cluster to be effective and the only way to accomplish that is to ensure your underlying  vSphere HA/DRS cluster is designed efficiently. Let’s face facts for a moment, if your VCSA appliances are operating in a vSphere cluster and it is not designed efficiently then there is a very good chance your vCenter HA configuration may not work as intended. I can honestly say it has a high probability of not working the way you hope. You can end up with what I call the “polished turd” deployment. Yeah you read that right. Your environment may have all the bells and whistles set in vSphere and all new server equipment but the design is awful because it is ineffective due to poor planning. In this case you just have a complicated shiny piece of ________ . 🙂 Well…you get the point. Anyway…moving on!

Other requirements for vCenter HA include…

• ESXi 5.5 hosts or later (requirement); minimum of 3 ESXi hosts (recommended) to ensure vCenter HA nodes are separated.
• vSphere DRS should be enabled on the cluster.
• vCenter Server 6.5 is required for configuring vCenter HA.
• vCenter Deployment size of SMALL (4 vCPU with 16 GB RAM) or larger is required for RTO purposes. *Tiny should never be used in production*
• vCenter HA is supported/tested for VSAN, VMFS and NFS datastores.
• Network latency on the vCenter HA network must be less than 10 ms.
• vCenter HA network must be a separate network segment (subnet/VLAN) from the management segment (subnet/VLAN).

Detailed information can be found in the vSphere Availability Guide for ESXi 6.5 and vCenter Server 6.5. (Download)

Topologies for vCenter 6.5

Now lets talk about vCenter HA from an architectural point of view. First and foremost the embedded PSC and external PSC are both supported. However, it is important to know and understand the LIMITATIONS of each topology.

NOTE: You can find a list of the supported and deprecated topologies for vSphere 6.5 in KB Article 2147672.

When planning your topology it is important for you to understand your requirements first and foremost!

• What are your scalability requirements for the environment over the next # of years?
• Are there multiple sites? What does the bandwidth & network latency look like between the two sites?
• How many HA/DRS clusters are present?
• Are you licensed for multiple vCenter Server instances?
• Is there a load balancer?

These are just some of the questions you may need to ask yourself before you begin laying out your new vSphere 6.5 infrastructure. They will all play a critical factor in your planning.

Another example…let’s say you have to deploy multiple vCenter Server instances in each site with a single external PSC in each location…but then have the constraint of not owning a load balancer. How does these two factors impact your vCenter Server design & deployment? Can you deploy this model? Certainly. This implication will simply create a NEW requirement and a well documented procedure will be needed to manually point your vCenter Server to a surviving PSC in the event the local PSC fails. You would not be able to leverage the benefits of vCenter HA.

The point I want to make is to take your time, be thorough and detailed as it will only make your life easier in the future.

As for the two (2) supported topologies for vCenter HA…one topology is for environments that have a load balancer and the other is for environments that do not have a load balancer. The topology I am going to demonstrate in this “how to” article will be the more COMPLEX of the two. We will deploy two (2) external PSC appliances, a virtual load balancer and finally the vCenter Server appliance and HA configuration.

I will be using the Citrix NetScaler VPX Express Load Balancer in my step-by-step demonstration. This is a great virtual load balancer for “labbing out” your VMware environment. The demo license is good for a full year.

VMware has detailed KB Articles available for Netscaler Load Balancer, F5 BIG-IP Load Balancer and the VMware NSX Edge Load Balancer. Here are the following KB articles for configuring those appliances for load balancing your PSC appliances:

KB2147014 – Netscaler Load Balancer for vSphere PSC 6.5
KB2147038 – F5 BIG-IP Load Balancer for vSphere PSC 6.5
KB2147046 – NSX Edge Load Balancer for vSphere PSC 6.5

External PSC

If you have an External PSC requirement then you must use a load balancer. It is that simple. Two or more external PSCs can be configured to use the load balancer. I am only going to be deploying two PSCs. Once you have deployed and configured the PSCs (including the certificates) you will then deploy your vCenter Server Appliance to use the PSC VIP (Virtual IP) provided by the load balancer. Once the vCenter Server is deployed you can then use one of the two vCenter HA workflows to create (enable) your vCenter HA cluster.

The external PSC can be a VM or physical server. In my demonstration I’m deploying everything using the VCSA appliance. In the end I will have five (5) VMs:

• Two (2) external PSCs (virtual appliances).
• Three (3) virtual appliances in my vCenter HA configuration:
  • Active, Passive and Witness nodes.
  • These three nodes communicate with one another on the vCenter HA network which must have less than 10ms of latency. Simply ISOLATE this network.
• This vCenter HA model offers the highest degree of protection for your vCenter Server.

Other characteristics regarding this topology includes:

• Single Sign-On (SSO) domain
• Single Sign-On (SSO) site
• vCenter Server interfaces with the external PSCs using a 3rd party load balancer.

Embedded PSC

The embedded PSC deployment model is used in the event a load balancer is not present. There are two limitations to this particular topology…it does not support Enhanced Linked Mode (ELM); nor does it support PSC replication.

There is a total of three (3) appliances deployed in this topology…the Active, Passive and Witness nodes. All three will communicate with each other on the vCenter HA network.

This concludes Part 1 of my vCenter HA series. In Part 2 we will be covering the deployment of the PSCs followed by configuring the PSC certificates! Ahh yes…fun with certificates and OpenSSL!!

Quick Links

vCenter 6.5 HA – External PSC Deployment (Part 2)

vCenter 6.5 HA – Load Balancer Config (Part 3)

vCenter 6.5 HA – Deploy vCenter (Part 4)

vCenter 6.5 HA – Enable vCenter HA (Part 5)