The factors that influence “How many Cluster Shared Volumes [CSV] in a Cluster & VHD’s per CSV”

Cluster shared volumes provides many benefits over a traditional cluster physical disk resource however implementation and designing of cluster shared volumes [CSV] need significant planning to get the maximum benefits out of it. The quick questions that appear during planning is how many CSV Lun’s spanned across cluster nodes, how many VHD’s per CSV, which VHD’s to club together on same CSV and what is the optimum size of a CSV Lun. By the very nature of the CSV’s, if they are in redirected access mode [whether planned or unplanned], will bring down the performance considerably and we should make sure that SMB IO happens for the minimum possible time. In today’s blog I won’t be answering these questions as there is no “one size fits all” answer but we will touch all the points which help you in figuring out the right size for your IT environment.


1. You may want to place OS and Database/logs VHD’s on separate CSV luns. You may even want to place different databases eg. SQL database VHD’s and Exchange VHD’s on separate CSV luns. You can also use CSV in conjunction with pass through disk if you need as mentioned here.

2. How much IOPS your CSV Lun can handle. You may like to get an approximate IOPS estimate of all the VHD’s you are planning to place on a specific CSV Lun, so that you take an informed decision on number of VHD’s that CSV can handle.

3. You may like to make sure that average queue length and disk latency values of CSV Lun are under permissible range after placing the VHD’s. You may like to check with your SAN vendor leveraging storage performance monitoring tools and plan Raid configuration depending on the capabilities of the Storage.

4. While calculating IOPS we not only need to consider Applications generated IOPS but also the maintenance jobs like antivirus scanning, defrag, backup etc. you may also like to consider your backup strategy and whether your backup vendor uses software provider or hardware provider for VSS. To see why it is recommended to use VSS hardware provider along with CSV and the impact of using software shadow copy provider, check here and here.

5. While deciding the size of the CSV Lun you also need to consider the time chkdsk will take to finish. However in server 2008 R2, NTFS self healing thread and improvements in chkdsk and defrag improves the customer experience.To understand how chkdsk works and how much time it takes to run depends on size of volume, number of files and their size and corruption..check here [chkdsk in server 2008 and above is better than earlier OS but you still cannot predict time it will take]

6. While planning the size of CSV Lun, you may also need to plan for VHD’s snapshots. You may also need to plan how much free space should be left available on CSV after placing the VHD’s.

7. Cluster shared volume performance counters will also help you in planning/sizing along with other performance counters. you can see how much direct Read/Write IO happening from the nodes. In same fashion you can monitor the Metadata/Redirected IO for all the placed VM’s. You may also like to spread your CSV Luns uniformly across all cluster nodes assuming all nodes have same computing resources.

Hope this article helps you in planning your CSV design and enables you to reap the maximum benefits out of Cluster shared volumes and Hyper-V host clustering.

GAURAV ANAND

Blog is based on my Personal understanding of the Technologies mentioned above and information provided is AS IS.