By Terry Engelstad
MCP, MCSE, CCNA, MCDBA, MCTS, MCITP
AIS Network Operations Manager
It’s very tempting to move Microsoft SQL Server instances to a virtualized environment, especially now that virtualization has become more sophisticated.
Theoretically, reducing the number of physical machines that you have while saving money by cutting your power, maintenance and licensing costs, may seem like the way to go. But, in a production environment, why may virtualizing a SQL Server not always be a good idea?
The problem is not the hypervisor. The problem is not the big, fast disk. The problem is resource contention. All database management systems work better when you give them their own resources. More memory, more central processing unit (CPU), more disk – it doesn’t matter. The bottom line is: Just throw dedicated resources at a database management system (DBMS) and it will work better. While the virtual machines (VMs) run very well, there is likely going to be a noticeable difference between a VM and a physical machine.
The problem with virtualizing a DBMS goes to the very purpose of virtualization – attempting to reduce resources in order to reduce costs. The main retort from both Microsoft and VMWare about getting around reducing resources is that they have built in the ability to “share” resources – sharing CPU, sharing memory, sharing disk. Herein is the problem for databases. They don’t play nicely in the sandbox. They don’t share well. They want their own resources.
So, what do you do? Well, first understand the limits of virtualization and choose your virtualization instances wisely. Remember, there is no absolute solution to virtualizing SQL Server. The best you can hope for is a compromise. And the best way to compromise is to continue to try to isolate SQL Server instances. Over-allocating resources (CPU, memory, disk) in a contentious situation will make an already bad situation worse, so don’t over allocate. In short, don’t fall for “shared resources.”