So you've decided that you want to virtualize some SQL Server machines, but you've got some storage concerns. Concerns are good when it comes to moving SQL Server machines from the physical world to the virtual world. I'll do my best to address any concerns that you might have about storage performance in the virtual world.
Whether you're using VMware's vSphere or Microsoft's Hyper-V, you need to take special care with your high-load database disks to ensure that they'll have the I/O resources available to meet the applications' demands today and in the future. You have main three storage options for your virtual machines (VMs):
- Use traditional virtual disks. In the Hyper-V platform, they're called Virtual Hard Disks (.vhd). In the vSphere platform, they're called virtual machine disks (.vmdk).
- Mount a volume (or LUN in a SAN environment) to a VM, passing it through the hypervisor. In the Hyper-V platform, this technique is referred to as using pass-through disks. In the vSphere world, it's known as a raw device mapping.
- Use iSCSI to directly link the Fibre Channel storage array to the VM. To use this option, your storage array must support iSCSI or you must have a device within your storage environment that supports converting iSCSI traffic to and from the storage array.
Using Virtual Disks
Virtual disks are what systems administrators typically set up by default. They're files created on the host OS's storage (either as local storage or storage provided by a storage array) and mounted within the VM as physical disks. The host will use a set of disks in a RAID array (which is a set of disks attached to the back of the server via a SCSI connection) or a Fibre Channel storage array. The OS running within the VM will see these as traditional SCSI disks. The performance of these virtual disks will depend on a few factors:
- How many physical disks are hosting the data
- How fast those physical disks are
- How many other VMs are using the same physical RAID array
- How much I/O the other VMs are using on the physical RAID array
For example, if your virtualization platform has five disks in a RAID 5 array and 40 VMs use that single RAID array to store their data, you probably don't have enough I/O for your SQL Server machine to use, unless it has only the smallest of I/O requirements. With that said, if those five disks are changed from standard Fibre Channel SAN disks to solid state disks (SSDs), you'll probably have enough I/O capacity available. SSDs support much faster data transfer rates than normal rotating disks because the SSDs don't have any spinning heads or moving arms.
There's a small performance penalty when using virtual disks. The engineers at VMware told me to expect about a 2 or 3 percent performance penalty. I expect the performance penalty is about the same in Hyper-V. If you have a RAID array that will store only SQL Server data files, using a virtual disk on a RAID array is a perfectly acceptable solution, provided that you're okay with the slight performance penalty.