The most successful deployments of virtual SQL Servers have a few things in common. When a company is doing all of these things, odds are they’re going to be very happy with their virtual SQL Servers:
10. Use vSphere 4.1, not earlier versions. vSphere 4.1 introduced major improvements in multi-CPU scheduling that vastly improve performance. SQL Server will break queries out across multiple virtual CPUs, and it expects all of those vCPUs to perform identically. vSphere 4.1 helps make that happen. You can read more about the vSphere CPU scheduler here.
9. When using blades, avoid overcommitting switch uplinks. Virtualization works great with blades – but only when the SAN and network teams monitor utilization rates between the blade chassis switches and the rest of the networks. All too frequently, the SQL Server is thrown into a blade chassis with dozens of other servers all competing for the same small amount of storage and network bandwidth leaving the blade chassis. Everyone looks at their monitoring systems and can’t understand why the backups, big queries, and maintenance jobs run so slow, and the culprit is the hidden small uplink.
8. Avoid 1Gb iSCSI for storage. While this cheap and easy-to-use storage works great for most servers, it doesn’t work as well for SQL Server. If you’re happy with the speed of SQL Server running on local storage, you can be in for a rude surprise with 1Gb iSCSI.
7. Test storage performance before deployment. I’m partial to SQLIO, which might be the worst-named tool in history. It has absolutely nothing to do with SQL Server – it doesn’t require SQL Server, and it doesn’t mimic SQL Server. It just flat out hammers IO using whatever parameters you pass in. Using a test file of the same size as the expected database, the storage should consistently exceed 100MB/sec whether it’s random or sequential, reads or writes. Higher numbers than that may be required due to the application design or end user expectations, but that’s a good foot-in-the-door number.
6. Compensate for slow storage with memory. If you can’t get the storage performance you need, you can help by caching as much of the database as possible in memory. If the projected database size is 50GB but the virtual server only has 16GB of memory, then it’s not going to be able to cache the entire database. Perhaps the users won’t be querying old data, in which case you might be able to get by with less.
5. Ensure CPU power saving is turned off. While Intel’s latest Xeon processors provide impressive power savings, they won’t ramp up to full processor speed unless the CPU is under heavy load. SQL Server will rarely push the processors that hard, which means they stay slow – sounds good in theory, but in reality, every query takes 70-100% longer than it did pre-virtualization. If you care about query performance, turn this setting off in the hardware BIOS. You can read more about the power-saving CPU issue here.
4. Coordinate VMware reservations and shares with SQL Server settings. VMware vSphere has a great set of options to ensure that a guest OS gets the right amount of resources for its needs. These settings need to be set in concert with SQL Server’s min and max memory settings. There’s plenty of bad advice out on the web saying things like, “Just disable the balloon driver and give SQL Server all the memory” – that’s not right either. There’s a happy medium in letting SQL Server and VMware cooperate to balance resources across multiple guests, but it only works when these settings are aware of each other.
3. Use Resource Pools to track SQL Server licensing. Microsoft’s virtualization licensing for SQL Server is notoriously complex. Starting with SQL Server 2008R2, only Datacenter Edition ($60k/cpu socket) provides unlimited virtualization rights. Enterprise Edition ($30k/cpu socket) provides just four VMs. Tracking these closely with VMware Resource Pools can result in huge cost savings. If SQL Servers are allowed to move to any host in the VMware cluster, then a licensing audit can produce staggering costs.
2. Use VMware HA for high availability. If your users can tolerate a SQL Server outage of 2-3 minutes, VMware HA is much easier to manage than a SQL Server cluster. If your users require less than 30 seconds of downtime, consider implementing a physical SQL Server cluster instead. SQL Server clusters are tricky enough to manage on their own, and doing them inside VMware adds an impractical level of management on servers that can’t be down for more than 30 seconds.
1. Virtualize small SQL Servers first. Start by gaining experience with 1-2 vCPU servers with under 16GB of memory. As the company’s sysadmins grow accustomed to how SQL Server uses CPU and memory in a virtual environment, they’ll be more confident virtualizing larger servers. If the DBAs and sysadmins don’t get along when trying to pin down performance problems on smaller servers, they’re going to be very adversarial when dealing with larger servers.
Wow – That’s a Demanding List!
I know what you’re thinking: “This outside consultant is greedy and expects everybody to dump tons of money into their SQL Servers. He’s asking for the moon. Nobody does this in real life.”
Let’s rewind back to the beginning of the recommendations where I said, “When a company is doing all of these things, odds are they’re going to be very happy with their virtual SQL Servers.” You can certainly skimp on some of these items and still stand a pretty good chance of being happy with your SQL Server performance.
The more items you skimp on, the worse your chances become. If you implement a virtual SQL Server with 32GB of memory trying to cache 250GB of databases on RAID 5 storage, hooked up via 1GB iSCSI, with no prior experience virtualizing SQL Servers of that size, odds are you’re going to be miserable. Users will scream and complain, and you’ll bring in an outsider who will track the problems back to these types of recommendations. Keep my contact info handy.
