With VMware becoming more common place in the work place, many organisations are still reluctant to deploy production SQL servers on VMware infrastructure. This has been understandable  in the past but VMware environments are now more robust and should be able to handle SQL Server.

It's worth taking the plunge; there are some very good reasons to move some of your SQL servers onto a virtual infrastructure.

Server consolidation
Probably the biggest selling point of virtualisation is the ability it provides to consolidate mission-critical applications and infrastructure services onto fewer highly scalable, highly reliable enterprise-class servers with organisations able to achieve up to 60-80 percent server utilisation thus reducing TCO across their IT infrastructure.

Simplified system management
VMware allows organisations to provision new applications and respond to system change requests in minutes not days and conduct zero-downtime hardware maintenance without waiting for maintenance windows. Its dynamic load balancing capability allows for improved flexibility and responsiveness.
Higher Availability and improved service levels.

Being able to precisely control system resources granted to virtual machines and run them across multiple processors with Virtual SMP (optional) means that resource intensive workloads like SQL server can be run on multiprocessor virtual machines. Low-cost virtual machine clusters providing hardware and software fault tolerance can be deployed on physical clustered systems protecting critical data.

Lower Cost of Disaster Recovery Capability
Using VMware organisations can create a unified disaster recovery platform using ESX Server virtual machines as standby servers. A single x86 system can host multiple disaster recovery virtual machines maintained in a hot or cold state. Stream lining disaster recovery management, increasing availability, reducing recovery time and lowering hardware and operational costs by reducing the need for one-to-one mapping of production and disaster recovery servers.

Generally, SQL installations on VMware aresimilar to that performed as they would be on physical hosts with additional optimisation performed on VMware.

I have been running SQL sever VMware since 2002 and even with the obvious benefits listed above performance has been my biggest gripe. The fact that processors, storage and its connections are generally shared means that I have kept the most demanding servers on separate high powered machines. That said, a lot of servers can be fully provisioned on high spec equipment running ESX.

There are some important areas to understand when considering moving onto VMware, chief among these are CPU, memory and disks.

For the purposes of this discussion I will be looking at the option available with VMWare's ESX server which I believe is the only viable option for a production SQL server

CPU virtualisation adds varying amounts of overhead, depending on a number of different factors. For processor-intensive applications like SQL server the CPU overhead of virtualisation is likely to result in a reduction in overall performance. However, this is mitigated to some degree by the efficient manner in which VMware balances processor loads and virtual machines running on VMware can leverage multi- cores and multi-processor configurations, making it possible to run processor-intensive workloads. VMware allows you to assign different virtual CPUs to your virtual servers.

Memory if the most common factor limiting the number of virtual machines you can run on a single physical machine IT does not reduce the memory demands of SQL or the windows operations system. VMware however, has limited memory overhead and its RAM over commitment allows better memory allocation and utilisation. IT can dynamically increase or reduce the amount of RAM assigned to a virtual machine as the application demands increase or reduce. This allows higher severe consolidation than is possible with static virtual memory.

VMware machines run complete operating systems and the stiorage requirements of SQL server need to be taken into consideration when deciding to move to a VMware infrastructure. SQL server is a I/O intensive application and the impact on disk I/O of simultaneous disk access by multiple virtual machines consolidated on a single physical server can result in performance degradation. VMware goes someway to improving I/O performance through VMFS. Centralised storage helps reduce latency and increase throughput

Disk Configuration Options
You can configure virtual machines with multiple virtual SCSI drives which appear to the virtual machine as a SCSI device attached to a SCSI adapter.

You have three physical implementation alternatives:

  • Virtual Machine File System (VMFS)
  • In a simple configuration, the virtual machines' disks are stored as files within a VMFS.
  • SCSI commands from the gust operating systems to their virtual disks are translated by the Virtualisation in to VMFS file operations.

To minimise disk I/O overhead, VMFS is optimised to run multiple virtual machines as one workload. Virtual machines can operate safely in a SAN environment where multiple ESX Server hosts share a set of LUNs because VMFS provides distributed locking of these files . VMFS is first configured as part of the ESX Server installation.

Raw Device Mapping
A Raw Device Mapping (RDM) is a special file in a VMFS volume that acts as a proxy for a raw device. The RDM provides some of the advantages of a virtual disk in the VMFS file system while keeping some advantages of direct access to physical devices. Layered applications in the virtual machine such as Microsoft Cluster Service (MSCS) or SAN snapshots might require RDMS. The use of some hardware features inherent to SAN arrays are better enabled by implementing RDM.

Virtual SCSI HBA
Just as physical SCSI HBAs allow access to physical storage devices, virtual SCSI HBAs allow virtual machines access to logical SCSI devices. Storage administrators however, are not allowed access to the physical server through the virtual HBA. Many virtual HBAs can be hidden behind a single (or multiple) FC HBAs as the SAN can see only the physical machine and its physical HBAs.

Over the years that I have worked with VMware, I have found that it is not a "one size fits all" solution for all SQL server installations but with careful consideration and planning, significant benefits can be gained from deploying some SQL servers