Virtualizing SQL Server: Myth or reality?

Virtualizing SQL Server: Myth or reality?

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.

    Requires Free Membership to View

    Login

    By submitting your registration information to SearchSQLServer.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSQLServer.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

Premium Access

Register now for unlimited access to our premium content across our network of over 70 information Technology web sites.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in February 2011

For more on SQL Server virtualization

Learn whether BI systems are compatible with SQL Server virtualization

Read about 2011 market trends like SQL Server virtualization

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.

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.

    Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

    Back to top