One of the new features Microsoft introduced in Windows Server 2012 R2 was support for using virtual hard disks...
as shared storage for guest clusters. Although the concept of virtual hard disk sharing probably sounds simple, there are a number of requirements you must meet if you plan to use shared virtual hard disks in this way. Let's take a look the various requirements as well as some best practices.
The first thing that you need to understand about shared storage for guest clusters is that the shared virtual hard disk is used only for hosting guest clustered resources, such as SQL servers or infrastructure roles. The shared virtual hard disk cannot be used for hosting operating system files.
This limitation makes sense if you think about the way that a physical cluster works. In a physical cluster, each cluster node contains its own operating system disk. The shared storage is used for keeping the cluster roles running, not for protecting the cluster node’s operating system. The same basic concept applies to guest clusters. Each guest cluster node uses its own dedicated virtual hard disk for the operating system, but all of the guest cluster nodes collectively make use of the shared virtual hard disk.
Of course, this raises the question of whether there is anything you can do to protect the operating system volume for the individual guest cluster nodes. Microsoft recommends that guest clusters be deployed on top of physical clusters in which each cluster node is running Hyper-V. This makes it possible to treat individual VMs as cluster roles. In other words, each node in your guest cluster can be protected by the host cluster, while the guest cluster continues to protect its own workload.
As previously mentioned, there are a number of different requirements pertaining to the shared virtual hard disk. The first requirement is that the virtual hard disk must be in VHDX format. VHD files are not supported for use as shared virtual hard disks.
Another requirement is that the shared virtual hard disk must be physically located on a supported storage type. One option is to store the shared VHDX file on a Cluster Shared Volume (CSV) that is used by the physical cluster. The CSV should reside on block storage. The other option is to store the shared VHDX file on a scale out file server and then make the VHDX file available through an SMB file share. If this approach is used then the file server must support SMB 3.0.
Storing the shared VHDX file on a CSV works great for organizations that have a SAN in place. The advantage of using a scale out file server is that doing so makes guest clustering much more practical for organizations that do not have a SAN. Support for SMB allows guest clusters to be based around the use of low cost, commodity storage.
Microsoft’s requirements for shared storage don’t revolve solely around the physical storage requirements, there are also VM-related requirements. Both Generation 1 and Generation 2 VMs are supported for use with shared virtual hard disks. However, the guest cluster nodes must be running either Windows Server 2012 or Windows Server 2012 R2. If you choose to use Windows Server 2012 as the guest operating system, then you must upgrade the Integration Services to the Windows Server 2012 R2 version.
As you can see, shared virtual hard disks make it a lot easier to create guest clusters in Hyper-V environments. The shared virtual hard disks can reside on a CSV, or they can exist on a scale out file server that exists outside of the Hyper-V cluster.