If you would like to read the other parts in this article series please go to:
- Taking a Fresh Look at Hyper-V Clusters (Part 1)
- Taking a Fresh Look at Hyper-V Clusters (Part 3)
- Taking a Fresh Look at Hyper-V Clusters (Part 4)
- Taking a Fresh Look at Hyper-V Clusters (Part 5)
- Taking a Fresh Look at Hyper-V Clusters (Part 6)
- Taking a Fresh Look at Hyper-V Clusters (Part 7)
- Taking a Fresh Look at Hyper-V Clusters (Part 8)
Introduction
In the first article in this series, I discussed some of the more recent changes that Microsoft has made with regard to the quorum model used in failover clustering. Of course the title of this article is “Taking a Fresh Look at Hyper-V Clusters” and the changes to the quorum model impact all manner of failover clusters. Since I have hardly mentioned Hyper-V at all so far, I want to spend this article talking about some of the virtualization specific improvements that Microsoft has made to failover clustering in Windows Server 2012 R2.
Before I Begin
Before I get started discussing improvements to failover clustering, I want to quickly mention a change that Microsoft made to their support policy starting in Windows Server 2012. That change is that Microsoft now requires a one to one relationship between virtual machines and virtual machine clustered roles. In other words, you will need to define a separate cluster role for each virtual machine that you want to make fault tolerant.
Drain on Shutdown
Perhaps the most welcome improvement that Microsoft has made to failover clustering is that there is now an automatic drain on shut down for clustered virtual machines. In Windows Server 2012, if you forgot to put a Hyper-V cluster node into maintenance mode prior to shutting down a cluster node on which the virtual machines were running, the virtual machines would be put into a saved state. Those virtual machines would then be moved to another cluster node. In most cases, the virtual machines would be automatically powered back up. However, there were some situations in which the virtual machines remained powered off due to performance problems.
In the previous paragraph, I suggested that Drain on Shutdown might be the most welcome of the new clustering features. My reason for saying this is that with the way that failover clustering worked before, a simple administrative mistake could result in an outage. If an administrator forgot to put a cluster node into maintenance mode (or didn’t know that they were supposed to use maintenance mode) prior to a shut down then there was a service interruption for the virtual machines that were running on that cluster node. The service interruption would last until the virtual machines could be brought back online on a different node.
As you have probably guessed, Microsoft has improved things. Now, if a cluster node gets shut down, the virtual machines are automatically live migrated to another cluster node. The end result is that there is no service interruption.
It is worth noting that in spite of the improvements that Microsoft has made, Microsoft still recommends putting cluster nodes into maintenance mode prior to performing a shutdown.
Virtual Machine Network Health Detection
Another improvement in Windows Server 2012 R2 is network health detection at the virtual machine level. In Windows Server 2012, if a virtual machine were to lose connectivity with a virtual network then the virtual machine would continue to run, just as though nothing were wrong.
In Windows Server 2012 R2, Microsoft has made it possible for Windows to monitor virtual network connectivity. If a virtual machine loses connectivity with a virtual network then it is possible for the virtual machine to be automatically live migrated in hopes that the virtual machine will be able to reestablish connectivity to the virtual network once it reaches the destination cluster node.
As handy as this feature is, it is worth noting that live migrations in response to a loss of connectivity to a virtual network can be enabled or disabled on an as needed basis. The reason for this is that there might be certain situations in which you do not want an automatic live migration to occur. For instance, if your failover cluster is already running near capacity then you might not wish to allow low priority virtual machines to fail over in response to lost connectivity.
Similarly, some virtual machines may be connected to multiple virtual network segments. Imagine for a moment in which a virtual machine still has connectivity on its primary segment, but loses connectivity on a segment that is used for backups. That type of situation might not warrant an automatic failover.
If you think about the two examples that I just provided, you will notice that there is a key difference between them. In the first example, a low priority virtual machine has fully lost all connectivity to the virtual network. In the second example however, the virtual machine has connectivity to one network segment, but has lost connectivity to another.
The reason why I point this out is because virtual machine failover does not necessarily have to be triggered in response to a full network connectivity failure. It is possible to monitor network connectivity health on a per segment basis. In the case of my second example for instance, you might want to trigger an automatic failover if the virtual machine’s primary network segment loses connectivity, but do nothing if the backup network segment loses connectivity.
The process of enabling virtual network health detection is surprisingly simple. To do so, open the Hyper-V Manager and then select the virtual machine that you want to configure. Right click on the virtual machine and choose the Settings command from the resulting shortcut menu. When you do, you will be taken to the virtual machine’s Settings screen.
Now, locate the virtual network adapter that is connected to the network segment for which you wish to enable health monitoring. Expand the listing for the network adapter and select the Advanced Features container. You may now protect the network segment by selecting the Protected Network check box, as shown in Figure A.
Figure A: You can enable network protection on a per virtual network segment basis.
Shared Virtual Hard Disk
There is one last new failover clustering feature that directly benefits Hyper-V virtual machines. Starting in Windows Server 2012 R2, Microsoft chose to begin supporting shared virtual hard disks for use in guest clusters. In other words, the guest cluster nodes are able to use a centrally located virtual hard disk file as a shared storage device.
Windows Server 2012 made it possible to create guest clusters, but to be fully supported those guest cluster nodes had to connect to iSCSI or Fibre Channel storage. The problem with doing so is that in multi-tenant or user self-service environments you probably don’t want to expose the details of your physical storage architecture.
Shared virtual hard disks allow you to place a layer of abstraction between a guest cluster and physical storage. The shared virtual hard disk must be in VHDX format and must reside on either a cluster shared volume or on an SMB share on a scale out file server.
Conclusion
As you can see, Microsoft has made some improvements to failover clustering in Windows Server 2012 R2 that are truly beneficial to Hyper-V environments. In the next article in this series, we will set up a Hyper-V failover cluster and begin examining some best practices for virtual machine fault tolerance.
If you would like to read the other parts in this article series please go to:
- Taking a Fresh Look at Hyper-V Clusters (Part 1)
- Taking a Fresh Look at Hyper-V Clusters (Part 3)
- Taking a Fresh Look at Hyper-V Clusters (Part 4)
- Taking a Fresh Look at Hyper-V Clusters (Part 5)
- Taking a Fresh Look at Hyper-V Clusters (Part 6)
- Taking a Fresh Look at Hyper-V Clusters (Part 7)
- Taking a Fresh Look at Hyper-V Clusters (Part 8)
