VMware vSphere 6.5 – Native vCenter High Availability (VCSA 6.5 only

vSphere 6.0, VMware pushes the VCSA appliance further forward. In the past, the appliance has had limited scalability, limited support, or limited features. Not all architectural options were supported, so as a result, users were forced to used Windows based vCenters in order to be able to have features which they needed for their enterprise environments. The 6.5 release changes everything.

Not only that the features/functions parity is now equal with Windows based vCenter, but we have new features appearing in the VCSA based vCenter, which will not benefit the Windows-based deployments. We have now the VUM built-in, but also, the VCSA 6.5 supports Native vCenter High Availability.

VMware vSphere 6.5 also brings Virtual Hardware 13 allowing you to create and run VMs with up to 6TB of memory, UEFI secure boot for guest OS.
Let’s get back to Native vCenter High Availability (HA). As you know, previously there has been several options whether you wanted to assure an HA for your vCenter Server. Some of them were not easy to implement, like MSCS. To do a quick recap on those solutions, they were basically four of them

• vSphere High Availability (HA) – vCenter server VM gets restarted on another host within your cluster. Traditional.
• vSphere Fault Tolerance (FT) – only in 6.0 (4.x, 5.0, 5.1 or 5.5 were not supported)
• Microsoft clustering – WSFC/MSCS – Windows Server Failover Clustering or Microsoft Server Failover Clustering to protect a Windows-based vCenter Server. There was a support for using Microsoft SQL Cluster Service for use as a back-end database.
• vCenter server Heartbeat – separate solution from VMware. A Paid product. This solution wasn’t a real commercial success. VMware has announced end of Availability for all vCenter Server Heartbeat versions.

Native vCenter High Availability (HA) – for VCSA only!!

This year, with vSphere 6.5, VMware introduces new, simplified Native vCenter server High Availability (HA) for VCSA 6.5. As being said, only vCenter server appliance (VCSA) based architectures will be supported.
What’s in and how it works?

• Active-Passive deployments with Witness – synchronous DB replication, and file-based replication.
• Requirements – there will be a new, second vNIC added (eth1) during the configuration (wizard based). A private network as an only requirement to have a subnet of the primary network.

You can see the schema below….

There is no need for L2 network requirements or VXLAN.

For which scenarios?

You can have one VCSA in one datacenter (active) and passive VCSA in another datacenter. The VCSA vPostgress DB will have synchronous replication. VMware uses native vPostgres replication mechanism.
There are some latency requirements. (will be added here later).
File-based replication is near real-time based replication for some files that lays outside of VCSA. (Witness).

Two ways to enable VCSA HA:

There is two configuration options, two workflows, within the assistant:

• Basic – minimum info is required through a wizard, like IP information, if you have DRS/storage DRS and then the system will create for you active and passive nodes for you, and create affinity and anti-affinity rules. Or you can manually select nodes where you want to two VCSAs to run. The system will create the eth1 vNIC interfaces and you’ll also need to provide port groups where you want to attach this vNICs, and setup the replication.
• Advanced – a bit more complex. You have to manually clone the VMs (active, passive and witness), provide IP information. But the advanced workflow allows you to place the VM for example, into another datacenter, or another site, with different IP addresses etc… We don’t have further details on this just yet, but we’ll update the post when the product will be GA.