This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
3. - SQL Server virtualization best practices: Read more in this section
- Considerations for virtualizing SQL Server
- Facts and myths about virtualizing SQL Server
- Strategies for maintaining high availability of virtual machines
Explore other sections in this guide:
Can SQL Server live inside a virtual machine?
Yes and no. There are certainly reasons for virtualizing SQL Server. One is that you can easily construct high-availability databases that don’t involve the complexity and expense of Windows Clustering. So you’ll be ready for virtualization-based availability technologies from companies such as VMware and Marathon Technologies.
SQL Server virtualization is the Great Consolidator when SQL Server sprawl has gotten out of hand in your organization. And it’s 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 128 GB of memory.
You have to be careful, though. For example, memory overcommit capabilities let a SQL Server virtualization host satisfy the database’s thirst for RAM when SQL Server’s busy, and dynamically reallocate that physical RAM to another virtual machine when SQL Server is a 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 tricks of the trade that let SQL Server hum within a virtual machine.
Getting access to multiple processors is also a huge deal when virtualizing SQL Server. Start using a fault tolerance platform like VMware’s vSphere FT, for example, and you lose multiprocessor 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 lineup when it comes to virtualizing SQL Server. For example, many database administrators start by virtualizing the sprawl-related SQL Server instances 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.
ABOUT THE AUTHOR
Don Jones is a senior partner and principal technologist at strategic consulting firm Concentrated Technology. Contact him via www.ConcentratedTech.com.