High availability is a critical function of any virtual server environment. Without HA, the failure of a host server would result in the outage of every VM running on that host.
VMware vSphere high availability and Microsoft Hyper-V HA serve the same purpose, but they operate somewhat differently.
VMware provides vSphere high availability through a service that the company calls HA. As is the case with Microsoft's high availability (HA) feature, vSphere high availability is based on the creation of a cluster. In VMware's case, a cluster is a collection of ESXi servers that are collectively administered by vCenter Server.
When you create a vSphere cluster, HA nominates one of the cluster hosts to act as a master host. This master host monitors the state of the other hosts in the cluster, and it is responsible for maintaining cluster-level communications with vCenter Server.
The master host monitors the other hosts in the cluster to make sure they maintain a network heartbeat. If a host stops sending a heartbeat signal to the master host, then the master host must determine whether it has simply lost communication or if the host has failed. It does this by checking to see if the host in question is still communicating with its data store. If so, the host is considered functional.
For this reason, the master host monitors the VMs. If the VMs power off, they will be restarted on a different host; it's possible to configure vSphere to respond to this type of isolation in a variety of ways. If, on the other hand, the master host determines that a host server has failed, then its VMs will be restarted on a different host in the cluster.
One of the nice things about the way VMware handles the VM restart process is that it enables administrators to prioritize VMs. That way, admins can bring the most important VMs online first. Once HA restarts those VMs, it will restart lower priority VMs until all of the VMs are running or until the remaining host resources within the cluster have been depleted.
The Microsoft approach
Microsoft's approach to providing Hyper-V HA for VMs is somewhat similar to VMware's approach, although each company has its own nuances. The biggest difference is that while VMware provides high availability as a virtualization-specific function, Microsoft provides high availability through the Windows Failover Clustering feature.
This feature can provide high availability to a variety of workload types, not just VMs. The Failover Clustering feature runs on each Hyper-V host within the cluster. Unlike the VMware approach, which requires vCenter Server, no management server is required. However, Microsoft does provide the Failover Cluster Manager, which is a built-in tool admins can use to configure and manage the cluster.
Although not a requirement in every situation, most Windows failover clusters are connected to a cluster shared volume. A cluster shared volume is a remote storage volume that is attached to each of the cluster nodes by way of Fibre Channel, iSCSI or server message block 3.0. The cluster shared volume acts as a repository for the files that make up the various VMs. Because all of the cluster nodes are attached to the same cluster shared volume, any node can access the files for any VM.
Similar to VMware environments, Hyper-V nodes communicate their status through heartbeats. If a node's heartbeat stops, then that node is assumed to have failed.
Microsoft uses a quorum model to determine what will happen in a failure situation. The workings of this model can vary significantly depending on which version of Windows admins use. Generally speaking, the quorum model is designed to ensure that the majority of the nodes are still accessible, thereby preventing a situation in which a node that has become isolated from all of the other nodes as a result of a network failure tries to take over hosting all of the running workloads.
If a Windows failover cluster detects a node failure and the cluster still has quorum, meaning that the majority of the nodes are still accessible, the cluster will move the Hyper-V HA workloads -- in this case, VMs -- off the failed node and onto a functional node. Like VMware, there is a mechanism for prioritizing VMs.
When comparing Hyper-V vs. vSphere high availability, there are many similarities. While it's true that there are certain things unique to one company or the other, neither company's high availability feature is clearly superior.