Configuring a Hyper-V cluster to make use of Cluster Shared Volumes may be relatively easy, but there are a number of precautions to take and details to consider if you want to avoid storage bottlenecks. Without proper storage planning, virtual machine performance can suffer. The right virtual storage provisioning comes from incorporating disk I/O, resource sharing and virtual hard disk provisioning methods into Cluster Shared Volume configurations.
Choosing the right number of Cluster Shared Volumes
Much of the published information on Cluster Shared Volumes seems to imply that a single Cluster Shared Volume acts as the storage repository for the entire cluster. In actuality, a single Hyper-V cluster can make use of multiple Cluster Shared Volumes. As such, you will need to decide whether it is more beneficial to use a single Cluster Shared Volume or multiple Cluster Shared Volumes.
Often, you can find the answer to this question by looking at your
Using a single Cluster Shared Volume also has its advantages. A single shared volume costs less and is easier to manage than multiple Cluster Shared Volumes. If a single volume provides your VMs with adequate disk I/O and room for future growth, then this option will be best. If not, you will need to create multiple volumes.
Avoiding disk contention
The very nature of server virtualization means that multiple virtual servers will be sharing a finite pool of physical hardware resources. Resource sharing itself is not problematic, but you should avoid contention whenever possible. Contention results from two or more VMs competing for an inadequate amount of physical resources.
More things to consider for Hyper-V storage planning
Overview of Hyper-V Cluster Shared Volumes
Alternatives to failover clusters
Getting to know Windows Server 2012 Hyper-V clusters
One of the most common ways to limit disk contention is to create Cluster Shared Volumes composed of a large number of physical hard disks, which distributes the workload across multiple disks. Creating both high-performance and low-performance shared volumes and using them for specific purposes could also help to limit contention.
Some organizations, for example, create one relatively low-performance Cluster Shared Volume and use it to host the virtual hard disks (VHDs) that act as the system drives for virtual servers. The system drives generally contain the VM's operating system, pagefile, and application binaries.
In this configuration, a much higher performance volume stores VHDs that act as data drives for the virtual servers. This approach ensures the high-performance hardware does not get bogged down hosting VM system drives. The high-performance volume only hosts VHDs that require a high performance disk infrastructure.
Picking a virtual hard disk provisioning method
When configuring your Cluster Shared Volume, will you use thin provisioning or thick provisioning for VHDs? Both types of provisioning have advantages and disadvantages.
Thin provisioning saves a considerable amount of space. When VHD files are thinly provisioned, physical space on the Cluster Shared Volume is consumed as needed. The VHDs dynamically expand until they reach maximum capacity but only consume as much physical disk space as is needed to accommodate the data residing within it.
For example, a thinly provisioned VHD file may initially use less than 1 GB of disk space, but it has the capacity to expand up to 50 GB if needed. Thick provisioning allocates all of the potential physical disk space upon creation, meaning the full 50 GB would be reserved for the VHD file, regardless of whether all the space is initially needed. Thick provisioning, however, delivers better performance than thin provisioning.
There is a lot to consider when planning to use Cluster Shared Volume. The decisions you make will usually be based on budget and performance requirements. However, talk to your vendors to see if they have any hardware-specific recommendations you should consider for virtual storage provisioning.
This was first published in February 2013