In the first article in this series, we explored the enhancements to Hyper-V and Windows Failover Clustering in Windows Server 2008 R2. Specifically, we explored the new zero-downtime Live Migration.
Hyper-V Live Migration is a significant step forward, because it brings the ability of true failover -- and thus load balancing – during business hours without affecting the computing environment. In Hyper-V R2, Windows Failover Clustering has been updated to store multiple VMs on each logical unit number (LUN) without having to fail over each VM during a migration via the Cluster Shared Volumes feature. This article explains how to use Cluster Shared Volumes to improve virtual host resource utilization.
Hyper-V version 1.0: One virtual machine for each LUN
Clearly, one VM for every LUN is inefficient. Think about traditional NT file system (NTFS) and how failover clustering makes use of their disk resources. In the last version of Failover Clustering, each node in a cluster was aware that it did or did not own a virtual disk resource. The entire disk resource, regardless of the files and folders in it, was the boundary of cluster resource management.
This is problematic because an individual VM is also a cluster resource that depends on a particular node. So failover with a cluster resource requires the simultaneous failover of its dependant disk resource as well. With multiple VMs on the same LUN, failover of one VM took all the VMs with it. With Hyper-V version 1.0, this didn't occur because of any problem intrinsic to virtualization itself, but rather was a limitation of the Windows Failover Clustering feature on which Hyper-V relies.
To address this issue, Hyper-V R2 contains Cluster Shared Volumes that eliminates the requirement that each highly available VM run inside its own storage LUN. Windows Failover Clustering benefits from this feature as it wraps around NTFS and enables the physical nodes of a cluster to be aware of files and folders on a disk resource, in addition to the disk resource itself. While the disk resource is still formatted with the NTFS file system, Cluster Shared Volumes makes the cluster nodes more aware of what is stored inside those disk resources.
Many Microsoft environments have yet to move to Hyper-V R2. They may be waiting because of the management nightmare associated with creating and administering dozens, or even hundreds, of extra LUNs. If you're in this situation, you should know that Windows Server 2008 R2 and the improvements to Windows Failover Clustering eliminate this management burden and make smooth the transition process.
Using Cluster Shared Volumes to increase virtual host resource use
Enabling Cluster Shared Volumes is simple once you have a Windows Server 2008 R2 cluster in place. In the Failover Cluster Manager console, click Enable Cluster Shared Volumes in the Actions pane. You will receive a warning that says Cluster Shared Volumes should be used only for Hyper-V VMs, and that files and folders on the Cluster Shared Volumes-enabled drive must be created through either Hyper-V Manager or the Failover Cluster Manager.
This warning is important because, as I mentioned previously, the file system itself hasn't changed. Checks and balances that are managed by the cluster itself are layered on top of the NTFS file system. These checks and balances ensure that one cluster node doesn't mistakenly believe it owns a file or folder that it doesn't. As a result, once you've enabled Cluster Shared Volumes on a disk resource, you should never directly access that disk resource again. Instead, allow the management consoles for Hyper-V and clustering to do the job for you.
After agreeing to the warning, you should then choose which existent disk resources should be converted for use as Cluster Shared Volumes. Enabling Cluster Shared Volumes creates a new folder on each cluster node at C:\ClusterStorage. Like the data on the disk resource, the data in this location should also be left alone and managed through one of the official consoles. This location contains metadata about the disk resources and the data stored in each of them.
Once you've created a VM, enabling it for Live Migration requires that you store the virtual machine in Cluster Shared Volumes. You also need to create a special Live Migration network dedicated to Live Migration's latency-intolerant migration process. This can be done by clicking on the Properties button in the Services and Applications menu in Failover Cluster Manager, and then clicking the Network for Live Migration tab. Check the box next to the network you have created that is dedicated specifically for Live Migration traffic.
After completion, initializing a migration should take far less time than with previous versions. If your environment makes use of System Center Virtual Machine Manager and its PRO Tips integrations with System Center Operations Manager, you can create rules that enable dynamic load balancing across hosts. These load-balancing rules can be based on performance characteristics, in much the same way that VMware's Dynamic Resource Scheduling feature does the same for that platform.
|Greg Shields, MCSE, is an independent author and consultant based in Denver with many years of IT architecture and enterprise administration experience. He is an IT trainer and speaker on such IT topics as Microsoft administration, systems management and monitoring, and virtualization. His recent book Windows Server 2008: What's New/What's Changed is available from Sapien Press.|
Dig deeper on Microsoft Hyper-V and Virtual Server