Prevent software failures with vCenter Server High Availability
New to vCenter Server 6.5, VCHA ensures high availability for a vSphere deployment with minimal impact on vCenter Server and vSphere host performance.
Anyone who deals with storage in a data canter is familiar with the concept of high availability. VMware vCenter Server High Availability, a new feature in vCenter Server 6.5, takes this concept and applies it to vSphere's primary administrative and management tool.
The idea behind vCenter Server High Availability (VCHA) is simple: Create an active/passive configuration in which file replication takes place between the active and passive nodes. This replication uses additional virtualized Network Interface Cards (vNIC) which are located on a separate virtual LAN.
This configuration also replicates the PostgreSQL database used by vCenter Server Appliance (vCSA) and vSphere Update Manager synchronously to the passive node using built-in native replication technology from the PostgreSQL database.
You can activate vCenter Server High Availability on a VM with both vCSA and Platform Services Controller installed or on a VM with just Platform Services Controller -- both architectures are fully supported.
As shown in Figure A, VCHA is actually a three-node cluster: You have an active node, passive node and the third node, which is used as a witness. The witness node runs a tie-breaker code and is used as decision-maker in case of failure or a network partition between active and passive node.
During a failover if the active node is unreachable, the passive node is promoted to active; a witness node can never become an active node.
There are two configuration options when running the vCenter Server High Availability wizard, and which configuration you choose depends on single sign-on (SSO). If your data center only has one SSO and your vCenter Server is in that domain, you should be fine using the basic configuration, which is selected by default. However, if your architecture includes another site that uses a different SSO domain, you'll need to choose the advanced configuration.
The advanced configuration is more flexible, but requires quite a few manual steps, beginning with adding a second vNIC. Cloning the primary VM and creating a secondary node with all the necessary reconfigurations -- VM name, IP address changes, NetBIOS name changes and so on -- are also manual processes. However, VCHA gives you the option to place the passive node in another site or data center through the advanced configuration.
Once you've created the three-node cluster, the heartbeat communicates over the private IP network -- a network that is created automatically in the basic configuration.
When your configuration is complete, you'll notice that another view has become active; this view allows you to monitor nodes within your vCenter Server High Availability cluster.
You can test the HA capability of the system within vCenter Server by initiating a failover operation or testing a maintenance mode in which you disable automatic failover, but keep replication between the nodes. You can also completely disable replication or destroy the three-node vCenter Server High Availability configuration, including deleting the passive and witness VMs, with this same interface. Additionally, you can deploy VCHA via PowerCLI. This three-node cluster can only lose a single node.
Major improvements to HA in vCenter Server 6.5
VCenter High Availability makes up for shortcomings
What can we expect in the latest version of vCSA?