CSV LUN sizing Best Practices
When I first looked at Clustered Shared Volumes (CSV), I had the following kind of questions in mind:
-
When was Microsoft going to publish guidance on the number of virtual machines (VMs) per LUN when implementing CSV?
-
What were the lessons learned from PV-TAP and RDP-TAP customers?
-
What kind of numbers (VMs per LUN) had been tested?
-
How many virtual machines per LUN would be supported? My expectation here was around 30 – 40 virtual machines.
None of that information has been forth coming as yet, so I have decided to document some thoughts on the subject, and hoped that this post might inspire others to respond with their own input. Firstly let me remind you about CSV’s statistics:
|
|
CSV
|
|
Max Volume Size
|
256TB
|
|
Min Volume Size
|
1MB
|
|
Max # Partitions
|
128
|
|
LUN Concatenation
|
Hardware LUN Expansion
|
|
Data Migration
|
Seamless
|
|
Supported Hardware
|
Commodity
|
|
Storage Type
|
FC, iSCSI, NAS, SAS
|
|
Multi-path Support
|
Industry Standard
|
|
iSCSI Initiator Support
|
Industry Standard
|
|
Write I/O Performance
|
Fast
|
|
Metadata Updates
|
Fast
|
|
Max Number of LUNs
|
2000+
|
|
Directory Structure
|
Unrestricted
|
|
Max # of Files per Volume
|
4+ Billion
|
|
LUN Presentation
|
Flexible Storage Model
|
|
Price
|
Free
|
One of the first things to consider is the limitations of your Storage Area Network (SAN). The limitations I have in mind are in terms of the maximum number of hosts that can access a single LUN or the maximum LUN size. These limitations on the face of it might simply be firmware limitations and so you may need to apply the latest firmware updates to achieve the desired configuration maximums. For example older HP StorageWorks Enterprise Virtual Arrays e.g. EVA 3000 have a 2 TB LUN limitation. With newer EVAs this limitation has been raised to 32 TB. Note, that the number of hosts that can access a single LUN on the EVA is 256 (far more that the maximum number of hosts in a Windows Failover Cluster).
Sizing the disks themselves involves selecting the correct type of disks e.g. Fibre Channel or SATA, the correct drive speed and the right number of drives to achieve the required IOPs (I/O operations per second) for your workload. How you decide to carve up your disk group i.e. implementing many LUNs spread across a single disk group versus each LUN being on a separate disk group, is really a function of the performance requirements of your workload.
Finally there are some practical requirements based on your data capacity needs and you can determine this requirement once you know how many VMs you plan to store on a single CSV LUN. For every VM you will need the following:
-
Actual storage space for the VMs Virtual Hard Disk (VHD) or VHDs as your application might require separate disks for the operating system, data or logs.
-
Additional storage space for any Saved State (.BIN and .VSV files – note that the BIN file can be as large as the amount of memory allocated to the VM. In normal terms however the BIN file is likely to be slightly smaller in size. Don’t be deceived by this point, because when you start the VM the size of the BIN file will increase to the amount of memory allocated to the VM). The VSV file is smaller in size and is typically less than 10 MB in size.
-
Additional storage space for any snapshots/checkpoints (AVHD – this is harder to predict as the delta file increases based on use). This might only be an issue in a Test/Development environment where snapshots/checkpoints are used and less of an issue in production.
Patrick Lownds