Virtualization Strategies for the CIO
Requires Free Membership to View
Cluster Shared Volumes (CSV) -- a special NT file system volume that grants read-and-write access to all Hyper-V cluster nodes. This clustering technology allows for the Live Migration feature in Hyper-V R2 and eliminates the creation of a separate logical unit number (LUN) for every VM within the cluster, which was necessary in Hyper-V R1.
Granted, CSV may not be on par with the thin provisioning approaches of other vendors, but I will demonstrate how this clustering technology not only reduces the headaches associated with configuring Hyper-V R2 VMs but also saves valuable storage space, which translates into concrete cost savings.
Cluster Shared Volumes benefit No. 1: Reducing management complexity
Within my Hyper-V R1 environment, the largest cluster had six nodes and 106 VMs. To provision these VMs, each needed its own LUN. Over time, the process -- which required many steps to get a LUN to provision a VM -- became second nature.
(Note: Not only does a single larger CSV help in the basic provisioning of VMs, but it also aids in reducing refresh delays often seen with System Center Virtual Machine Manager. Often, it takes an extended period of time for SCVMM to recognize a new LUN in a large cluster.)
Cluster Shared Volumes benefit No. 2: Reductions in storage space requirements
Storage may be cheap, but the thought of potentially wasting hundreds of gigabytes, or even multiple terabytes, of SAN storage seems contradictory when professing the great cost savings of VMs. It has always been the "but" in virtualized storage conversations. "We can provision VMs fast, provide excellent fault tolerance and fully utilize our hosts, but we need enough disk space for the Virtual Hard Disk files, memory and snapshots -- plus, some extra space beyond that on the LUN to allow for configuration flexibility."
In my Hyper-V R1 environment, the configuration looked something like this:
Size of the VHD(s) + size of the RAM + approximately 8 GB - 10 GB = Total LUN size
The extra buffer was to allow for snapshots or RAM increases down the road. I'm sure you leave extra disk space available on your desktop hard drive, and the same philosophy is valid with Hyper-V R1 LUNs too.
These buffers, however, add a significant amount of wasted space. With the 105 LUNs example, that would mean approximately 840 GB - 1.05 TB of unutilized space. Of course, you could provision the storage space a little tighter. But if more space was needed for a snapshot, you would have to expand and extend the physical LUNs to gain the extra space, adding the potential for more configuration mistakes or delays.
After the snapshot is taken, however, you would still be left with the unwanted, extra space (also, don't forget the additional configuration time needed to do this). As a result, I decided to bite the bullet and give a standard buffer to every LUN provisioned within my Hyper-V R1 environment.
With CSV clustering technology, however, a single LUN can be used for every clustered VM -- reducing the need for excess space for each VM. Because not every VM needs snapshots or grows excessively, I restrict the excess space to about 100 GB. Using the earlier example, this method would save 740 GB -- 950 GB of space compared with my R1 deployment. In an ever-growing environment, this space can be put toward actual VMs instead of being wasted.
Cluster Shared Volumes benefit No. 3: Cost savings
The reason for upgrading to Hyper-V R2 -- or implementing its clustering technology, for that matter -- is to save hard dollars by avoiding or delaying new storage purchases, a tangible metric that even management and CEOs can get behind.
Gigabytes and terabytes may not cost as much nowadays. But if the compilation of these savings allows you to avoid upgrading to a larger SAN, the savings start to add up noticeably. Granted, this isn't Thin Provisioning, but for no added cost, you can more efficiently maintain a storage infrastructure, both technically and financially.
In my next article, I will delve deeper into saving valuable disk storage resources within a virtual environment by looking at third-party products that address some of these pain points. Until then, add to the conversation and send me your feedback.
About the expertRob McShinsky is a senior systems engineer at Dartmouth Hitchcock Medical Center in Lebanon, N.H., and has more than 12 years of experience in the industry -- including a focus on server virtualization since 2004. He has been closely involved with Microsoft as an early adopter of Hyper-V and System Center Virtual Machine Manager 2008, as well as a customer reference. In addition, he blogs at VirtuallyAware.com, writing tips and documenting experiences with various virtualization products.
This was first published in January 2010
Join the conversationComment
Share
Comments
Results
Contribute to the conversation