I talked about why sysadmins want to virtualize servers, and today it’s time to talk about why you as a DBA or developer might want to virtualize some of your SQL Servers.
Virtualization Means Cheap High Availability
In a perfect world, every SQL Server would be a cluster on a SAN with instant failover. This isn’t a perfect world, and we can’t afford to implement that level of protection for every server in the shop.
Virtual SQL Servers provide a level of high availability without the expense and hassle of clustering. In my last post, I explained that sysadmins love virtualization because they can easily move guest servers around from one piece of hardware to another. As a DBA, I love it for that same reason: suddenly, if the underlying hardware fails, I’m not sweating bullets. If the RAID card fails, if the motherboard fails, if the memory fails, if the network card blows chunks, you name it, it’s not my problem. The sysadmin simply boots up my SQL Server on another virtual host, and I don’t have to deal with screaming users.
I especially like this option for development and QA servers. Management is rarely willing to implement expensive high-availability setups for development environments, but when the dev server goes down, the developers and project managers are kicking my door down. The PM’s scream about how there’s so many expensive developers sitting around idle waiting for the server to come back up. Virtualization avoids this problem altogether.
Virtual SQL Servers can React Quickly to Changing Needs
Capacity planning is hard work. How much speed do we really need for a new application? What happens if our estimates are wrong, and we suddenly need a whole lot more oomph? What happens if we overbought, and we’ve got all this expensive hardware sitting around idle because the application never caught on with end users?
Virtual servers can be easily scaled up or scaled down. Simply shut the virtual machine down, change the number of CPUs and memory it has with a few mouse clicks, and boot it back up again. Presto change-o.
We can even move storage around. Say we initially decided to put the server’s data on a cheap RAID 5 SATA array, and now our users have fallen in love with the application and they’re adopting it like crazy. We can shut it down, move the virtual hard drives over to a faster RAID 10 SAS array, and boot it back up again. Presto change-o, rapid storage performance improvements without long downtime windows to backup/restore.
I loved this approach because it let me keep old SQL Servers around as long as necessary. For example, we decommissioned an old help desk database server, but I told the help desk folks they could keep it around as long as they wanted. It hardly used any resources at all, because nobody queried it unless they had a question about an old help desk ticket that didn’t get transitioned correctly to the new system. I set the server up with one virtual CPU, 1gb of memory, and put it on cheap RAID 5 SATA. The end users loved me because I could provide the service for no cost.
Virtual Server Performance Isn’t That Bad
Virtualization has a really bad reputation because in the beginning, the software really did suck and admins didn’t understand how to use it. Raise your hand if you installed VMware Workstation on your desktop years ago, and you tried to run multiple operating systems on a machine that barely had the horsepower to run Internet Explorer. I was there, and I know how it was.
Things have changed: the software’s gotten much better, memory became absurdly cheap, and there’s resources to help use it better.
The 2008 book Oracle on VMware by Bert Scalzo is a good example. Bert’s one of the Oracle experts at Quest, and he wrote this to help DBAs understand how to implement database servers in a virtual environment. It does a good job of explaining enough about virtualization to make a DBA comfortable with the technology and avoid some common pitfalls. Years ago, books like this weren’t available because the technology was changing so fast that best practices were wrong as fast as they were written.
You can still get really bad performance with virtualization, just as you can get really bad performance with SQL Server on native hardware. But follow a few basic guidelines like avoiding oversubscription, properly configuring networking & storage, and using the right OS configurations, and you can get perfectly acceptable performance. Yes, you’re still going to lose a few percent of overhead – but with today’s redonkulously fast CPUs and memory, I’m more concerned about optimizing T-SQL code than I’m concerned with losing 5% of my CPU speed due to virtualization. It’s all about priorities, and that small performance loss is just one piece of the picture.
Virtualization is All About Give and Take
The economy has gone down the toilet. Virtualizing non-mission-critical SQL Servers gives us the chance to cut costs without cutting service levels, and furthermore, gives us the chance to show management that we’ve got skin in the game. If we insist that every single SQL Server is too important to be virtualized, and that there’s no way we can save money, then management just might look at us as part of the problem. Be part of the solution: be proactive, find SQL Servers with low utilization levels, and offer them up as the first phase.
My approach was to start with the SQL Servers that I frankly didn’t really want to survive on their own anyway. I had one particular application that had always demanded its own standalone SQL Server with no other applications on it. The server was barely used, and it was a completely out-of-date and unsupported version of SQL Server. The application manager wouldn’t allow me to patch it, wouldn’t upgrade to a newer version, and didn’t have the budget to move to newer hardware.
Virtualization administrators have slick tools like VMware Converter and Vizioncore vConverter to automate the physical-to-virtual (P2V) process. These solutions take a backup of the physical server and clone it into a brand-new virtual server. When the virtual server starts up, the new virtualization drivers are installed automatically, and the server is up and running smoothly without time-intensive application reinstalls. I’ve blogged about virtualizing SQL Servers with P2V and I’ve performed it many a time – it’s a great way to get rid of hardware dinosaurs.
Even better, this whole process doesn’t require work from the DBA. The time and effort is all put in by the virtualization administrator. If your sysadmin is dying to try virtualizing a SQL Server, you can point them at your newly chosen dinosaur and tell ‘em to have at it – you don’t have to be involved. That’s the best of both worlds: management will see you as a part of the solution, but you won’t actually have to do any work.