SQL Server and Virtualization – Part 3 – Disk

Hey,

Ok, so the third and final part of my little series on virtualization and SQL Server, the disk.

In my opinion, laying out a disk on VM is the area which most closely resembles it’s physical server counterpart. It doesn’t really have the hidden pitfalls that memory and CPU bring to the table. So treat it from a layout perspective as if it were a regular server. By that I mean have your two partitions for Data and logs, have another for archive files if you had them before, partition for TempDB etc. It’s well documented on best practices for DB file layout so I won’t go into that again.

Where the considerations come in are whether to go for raw LUN’s or VMDK’s, and to be honest, I wouldn’t consider it a huge dilemma. Raw LUNS give the VM direct access to your storage, taking out the Virtual disk layer. It removes a step, so will be slightly faster. However, if you need to be able to punish your disk to that degree, chances are your server isn’t a good candidate for virtualization.

With the VMDK (Virtual Disks) I believe the benefits far outweigh the performance hit. The flexibility for your ESX admin to move your machines around, tier storage, edit disks on the fly, move your drive from a RAID 5 to a RAID 10 array if you need more performance and many other useful benefits (fall under the VM management rather than SQL side, so talk to your VM guy!). Rather than give opinions, I’ll give you a list of pros and cons for each method and let you decide.

RAW Device Mapping
Pro’s
Can outperform VMDK
Dedicated piece of storage for your VM, won’t be any other systems contending for your throughput
SAN management is a bit more bedded in, so you may trust your SAN backups/replication over Hyper Visor

Con’s
SRM is effectively useless as LUNS can’t be transferred without expensive SAN replication methods
You’re stuck with your array (If you find a RAID 5 array too slow, you have to build a new RAID 10 and migrate)
Growing a partition requires downtime to add more disks, reconfigure the array, and re-present

VMDK’s
Pro’s
Super manageable by your ESX admin, SRM can bring your VM up on a completely different site almost transparently
To move your disk to faster storage, ESX Admin just has to tell the vmdk to move
To grow a partition ESX admin just has to allocate more space and it’s automatically presented to the VM
Takes some functionality away from your SAN software

Con’s
Another layer between your machine and the hardware
Can be slightly slower than RAW LUN access
In a shared pool it may have disk performance troubles caused by other hosts, but set up properly this is unlikely
Takes some functionality away from your SAN software

I’ll leave it at that! There’s a good discussion on the VMware forums surrounding storage if you fancy going a bit more in depth : http://communities.vmware.com/thread/73745

The only other recommendation I would make with the disks is to allocate all of the space you are going to give them up front. There is an option to assign a set amount of space to your VM, but don’t actually take up any storage until the VM actually requests it. So if you have a partition linked to a VMDK file, and the partition is 500GB, you can tell it not to allocate space straight away, so if you only use 20GB of the 500GB allocated, then your VMDK file will only be 20GB. This is useful if you don’t want to eat up all of your space straight away, or want to over commit on disk space and take a chance, but from a performance perspective it’s not a good idea.

Take the scenario above, the first 20GB gets allocated in one contiguous block on the SAN. Now another VM comes on board and it’s VMDK get’s the next contiguous block. The first VM now needs another 5GB, which gives it the next contiguous block. So it doesn’t sound too bad until you realise that you’ve just created fragmentation at your PARTITION level. So you have DB fragmentation, windows disk fragmentation, AND storage fragmentation coming into play. Whereas if you pre-allocated your space, the entire 500GB would be one happy contiguous being, and you would never hit storage fragmentation on it as it will never grow or shrink.

So that’s it for this mini series, I hope this has given you a little bit of insight into why virtualizing SQL is a little more complex than regular application servers.

I know I link to this guy more often than not, but if you can, I would highly recommend signing yourself up for this webcast. It’s a 4 hour session on Virtualizing SQL Server on VMWare, and if you are seriously considering migrating to VM’s, it will really give you a fighting chance of it all going well. I’m not affiliated with these guys at all, but I did sign up for the last round of this session, and it was excellent. It costs $195, but if you can manage it, or get your company to manage it, it’s very much worthwhile. It goes into WAY more depth than I have, and than most guides out there have.

http://vmware4sql.eventbrite.com/

Best of luck with your Virtualization projects! If I can be of any help, as always, please feel free to contact me.

Thanks,

Stephen