<h1>High Availability with Failover Clusters</h1>

Before moving on to the next chapter on my virtualization lab series, I think this might be a good opportunity to review some of the clustering options available today. I will use Windows Server Failover Clustering with Hyper-V because in today's world the trend is to combine Virtualization with High Availability (HA).

There are many ways to implement these solutions and the basic design concepts presented here can be adjusted to other virtualization platforms. Some of them will actually not guarantee a fault-tolerant solution, but most of them can be used in specific scenarios (even if only for demonstration purposes).

Two virtual machines on one physical server

In this scenario an HA cluster is built between two (or more) virtual machines on a single physical machine. Here we have a single physical server running Hyper-V and two child partitions where you run Failover Clustering. This setup does not protect against hardware failures because when the physical server fails, both (virtual) cluster nodes will fail. Therefore, the physical machine itself is a single point of failure (SPOF).

(Click to enlarge)

Obviously, this setup is not useful for true high availability, but it could be interesting for testing, training or demonstrations as a comfortable way to test different HA cluster setups without requiring much hardware resources.

Two virtual machines on two physical servers

In this second scenario, an HA cluster is built between two or more virtual machines, each of them running on different physical machines. In this setup, the SPOF of a single physical machine is eliminated. Again, the cluster manager (Windows Server 2008 Failover Clustering) is running directly in the virtual machine, i.e. it´s implemented at the Hyper-V Child level.

(Click to enlarge)

Since the cluster is running in a virtual machine it can be easily moved to other physical machines thus simplifying backup and recovery procedures. This design is fault tolerant and can sustain the failure of one of the physical servers. Given redundant network and storage infrastructure (not shown in the picture), this can be a truly highly available solution.

Mixed physical and virtual machine clustering

Here we have two physical servers (normally active nodes) each clustered with a virtual one (normally passive node). The cluster manager is on one side running directly on the physical machine and on the other side running in the virtual machine. If the physical server fails, the virtual sibling will take over the workload.

(Click to enlarge)

The advantage of this setup is the possibility to combine multiple standby nodes on one single physical machine (N to 1) whereas normally one would need a second physical machine for each standby node (Active/Passive). This offers great potential for cost savings. However, it requires careful planning not only for the sizing of the standby nodes but also to deal with the use of dissimilar hardware in the cluster. The Failover Clustering Validation Wizard can confirm the support for every specific configuration.

This design can also survive the failure of both physical servers. If we configure the network and storage infrastructure to be fault tolerant, we can have another truly highly available solution.

Clustered virtual machine with two physical servers

In contrast to the previously discussed scenarios, in this one the cluster manager is running at the Hyper-V Parent level. So the HA cluster is built between two or more physical machines just like in traditional setups without virtualization. The difference is that applications are not running directly on the physical machine but instead running in one or more virtual machines. Virtual machines themselves are configured as a resource in the cluster and are managed by the cluster manager. In case of a failure, the whole virtual machine is failed over to the standby node.

(Click to enlarge)

As you can see, this design can survive the failure of one of the physical servers. Again, with a redundant network and storage infrastructure, we can have a truly highly available solution.

Standalone laptop

This last scenario's goal is to have a single laptop hosting an entire Failover Clustering demo with Hyper-V. In order to accomplish this, we need a virtual iSCSI SAN plus two child partitions to play the role of cluster nodes. This is certainly not a true highly available solution, but it can be an interesting demo machine with no external network dependencies.

(Click to enlarge)

These are just some of the basic options and they can be combined to form many, if not all, of the previously discussed cluster architectures.