I hate when people talk about disk being cheap. I want to just smack them. Disk for laptops and PC’s is cheap. Disk for fault tolerance server computing is far from cheap.
If you’re running a Hyper-V cluster then you know that you can’t just go out and buy some cheap storage. You’re looking at shared storage with cluster support. That means either a Fibre Channel or iSCSI SAN. And then there’s the disk. You could go budget and use SATA or worry about performance and go with SAS. Odds are it will be the latter which provides less storage for a higher price. Add in fault tolerance and you’ve use more expensive HBA’s, doubled your switch port requirements, etc.
At work we’re using a HP EVA with fibre channel connections via dual port HBA’s and 15K disks. We had to worry about the ability to scale. We’re a hosting company so unlike most virtualisation projects we had no end point. I couldn’t say “we have 20 machines to virtualise”. As a hosting company, 20 VM’s wouldn’t make much and wouldn’t justify the existence of a company. We also had to worry about performance.
When we deployed we use Windows Server 2008 Hyper-V. As you may know, the recommended (and VMM required) way to deploy storage for Hyper-V in a cluster is 1 LUN per VM. It’s a storage nightmare. I had to be paranoid about our processes. LUN’s, volumes, fail over cluster storage definitions and VM’s all had identical names based on a naming standard I’ve been using for years. But even with all that, I had that nightmare that I’d accidentally wipe a hosted customer’s VM if I deleted the wrong LUN on the SAN or someone wasn’t careful with documentation.
Windows Server 2008 R2 gives us the Cluster Shared Volume (CSV) for Hyper-V. Note the last bit; CSV is custom written by MS to be only used for Hyper-V. Instead of creating lots of LUNS in the SAN and managing lots of failover cluster storage definitions and tracking documentation, you simply carve out a single LUN and deploy lots of VM’s onto it. I’ve deployed a single LUN on our new cluster. It’s set up as a GPT volume and used as a CSV on our W2008 R2 cluster. That means we can simply deploy lots of VM’s onto it without worrying. Deleting VM’s doesn’t bring me to the EVA command view console to worry over accidentally deleting volumes. I just don’t need to go there anymore unless adding more space to the CSV. And sure, OpsMgr will let me know when I need to do that!
Another nice perk of the CSV is that self service deployment on a Hyper-V cluster becomes a real world possibility. Sure, you could have allocated lots of individual LUNS in W2008. But wouldn’t it be a waste if a person deployed a 50GB VM onto a 200GB LUN?
What about performance? You shouldn’t suffer at all really. Our EVA uses a concept where all storage is striped across all disks in a disk group. RAID is a secondary decision when you create the LUN. So, when you put lots of VM’s on a single CSV, they’ll all use all physical disks in the CSV.
There’s also another thing you can do. You can split storage for VM’s across different CSV’s. Maybe you have RAID1, RAID5 and RAID6 CSV’s. They all are suited for different kinds of storage, even if it is virtual. So now your virtualised SQL could have the OS and log files on a RAID1 CSV and the data files on a RAID5 CSV. You get the most from the physical storage while maintaining disk performance.
In Windows Server 2008, dynamic disks did not meet our requirements for storage because it was too slow. So we went with fixed disks. I think our experience is not unique in any regard. Our customers often don’t know what their storage requirements are going to be. We advise them to consume only what they need and take more disk later; it’s a quick operation to add space to a VHD. But even then, physical disk gets wasted. Consider a Windows Server C drive. The recommended minimum is 40GB. Our average consumption is less than 50% of that. That means 50% of physical disk for the C: drive is wasted. That means a person with a 40GB C drive who is storing 13GB in the VM is really using 40GB of physical disk, plus whatever to allow for free space and save states.
Windows Server 2008 R2 offers greater performance for dynamic disks. In fact, they nearly match the performance of fixed size disks. We’ve made the switch so we can keep costs down. That means that hypothetical consumer of 13GB of disk is really only consuming slightly more than that. Over the number of VM’s I’ve observed so far, we could save on 50% of our C: drives. Data drives are hard to figure. Early on we definitely save but storage requirements only ever go up. But we are definitely saving there too.
Oh yes, you can convert from a fixed VHD to a dynamic VHD. You just need to bring down the VM (why we won’t do this to existing customers) and have space for the new VHD to be created.
So CSV simplifies storage administration. Especially if you are in an organisation where SAN management is split from server management. Using Dynamic Disks allows you to consume only the physical disk that you need for the data you’ve stored. Add in other things like Live Migration, Core Parking, SLAT, improved networking, etc and you might want to do the cost benefit analysis of upgrading from Windows Server 2008 Hyper-V to Windows Server 2008 R2 Hyper-V. The costs of those licenses could be easily negated by the savings you’ll make on storage costs (literally consume what you use) and reduced administration.