Like This Blog 0

Added by Don Jones May 21, 2013

Can SQL Server live inside a virtual machine?

Yes and no. There are certainly reasons to do so, such as the ease of constructing high-availability databases that don’t involve the complexity and expense of Windows Clustering (for example, using virtualization-based availability technologies from companies such as VMware and Marathon Technologies). Virtualization is the Great Consolidator when SQL Server Sprawl has gotten out of hand in your organization. Virtualization is also a great way to add business agility: With a well-designed infrastructure, you can move a busy SQL Server virtual machine to a host that has more free capacity, increasing SQL Server’s performance on the fly. Need to add a processor to SQL Server? Just shut down the virtual machine, add a virtual proc, and start it back up again. Easy.

But can virtualization handle SQL Server?

In the bad old days, no. At least not well. But today’s hypervisors are not only better, they’re running, in most cases, on top of hardware that’s been specifically designed to handle virtualization. All of the latest Intel and AMD server-class processors have virtualization extensions built right in, enabling them to do a very credible job of running SQL Server inside a virtual machine. It also helps that server memory is insanely cheap these days, making it pretty affordable to configure a server with 128GB of memory.

You do have to be careful, though. For example, memory overcommit capabilities let a virtualization host satisfy SQL Server’s thirst for RAM when SQL Server’s busy, and dynamically re-allocate that physical RAM to another virtual machine when SQL Server is a bit idle. At least, that’s the theory: In reality, SQL Server will tend to use as much memory as your virtual machine has, and performance will suffer if there’s not an exact, dedicated amount of physical memory to back up that virtual configuration. Not overcommitting memory where SQL Server is concerned is one of the little “tricks of the trade” that let SQL Server hum within a virtual machine.

Getting access to multiple processors is also a huge deal. Start using a fault tolerance platform like VMware’s vSphere FT, for example, and you lose multi-processor capabilities (FT can only sync one processor per virtual machine). All the rules for configuring a physical SQL Server computer apply to virtual machines, and “multiple processors” is one of the big rules.

You can also look for the “low hanging fruit” in your SQL Server lineup when it comes to virtualizing servers. For example, many DBAs start by virtualizing the sprawl-related SQL Server instances that they wish they didn’t have in the environment, anyway: The one someone installed to support some log-archival application, for example, or the SQL Server Express instance that’s running somebody’s project database. Those databases don’t need “big iron,” and they’ll live quite happily within a virtual machine. Start from the bottom, workload-wise, and work your way up. Test and monitor as you go, and you’ll find the balance between which SQL Server machines can be virtualized, and which ones legitimately need an entire physical server to themselves.

Enjoy,

Don Jones
PowerShell and SQL Instructor – Interface Technical Training
Phoenix, AZ