Clustering SQL Server Virtual Machines

When planning server consolidation initiatives, particularly if using a structured offering and tools like SVAM and MAP, underutilized database servers are a frequent consolidation candidate. Similarly, if you have already widely implemented virtualization, then virtualizing database servers for new software deployments is also a common desire. As you consolidate and create more VMs, high availability becomes a requirement, particularly for database servers.

Until recently, Microsoft did not support clustering virtual machines running SQL server. You could cluster the hosts underneath of SQL VMs but you couldn’t cluster the VMs running SQL and remain supported. Fortunately, after finishing a large amount of testing that was required, this support policy has been changed and you can now cluster SQL VMs on Hyper-V and SVVP validated virtualization platofrms. See this article for the details: 956893.

The change in support policy opens up many new consolidation and software deployment scenarios. We have a site dedicated to SQL virtualization here and a great whitepaper on virtualizing SQL 2008 here.

Given all that, does it make sense to virtualize SQL (or any database)? The answer is an absolute, definite, maybe! Virtualization fan boys (like me) will say yes in many cases. Traditionalists in high end applications (both Microsoft’s and others) in a lot of cases will say no as they bare the scars of implementations gone bad due to going cheap on hardware or underestimating demand. Their concerns should not be ignored as they are usually based on deep experience with their apps.

What I think is unacceptable are blanket statements that “Product X should never be virtualized” or “never virtualize the database for Product Y”. These are poor excuses for trying to skip proper architecture and design. Just as bad are the vendors that promote “virtualizing everything” without any regard for performance, licensing, cost, or support considerations. This is also poor architecture and design.

Using proper capacity and availability planning practices, it is not that difficult to get to fact-based decisions on whether to virtualize a server workload or not. SQL is one of the more challenging ones as the product itself provides substantial consolidation options by supporting multiple instances and multiple databases per server/cluster. Almost all of our product groups now are releasing specific virtualization guidance (SQL, MOSS, OCS, etc.)

One of the most important considerations in this design process is the maximum size of a single virtual machine supported by your virtualization platform of choice. This will be the scale unit against which your capacity and availability requirements must be compared. If your workload doesn’t scale out well and requires a large single database server with 32 cores, that will not be a good candidate (or even possible) to virtualize as the major hypervisors today only support between 4 and 8 cores per VM. If your workload is able to scale out then this limitation can be worked around by using a greater number of smaller VMs that total up to the required capacity but you must consider the cost and management considerations of doing so (more VMs to manage, more agents, more licenses, etc).

It seems to be my mantra lately but there is no one size fits all when it comes to infrastructure architecture. That’s the fun part of this line of work, the art and science of good architecture which is a process. Beware of architects and vendors showing up and declaring that there is only one true way…