Although there are still some people who think that SQL Server can’t be virtualized, most people have realized that the vast majority of SQL Server instances can be virtualized just like Microsoft Exchange Server and many other enterprise workloads. There are several reasons to virtualize SQL Server. Certainly, in today’s tough economic climate, cost savings is a primary factor. Virtualization lets you run more server workloads on less hardware. Another reason behind the move to virtualize is power savings and improved hardware ROI. Consolidating workloads from multiple servers onto a single server drives up the hardware utilization rate, which for most single purpose servers account for only about 15 percent of utilization. This also reduces the number of physical servers and the overall power consumption. Having fewer servers also makes IT administration easier.
Related: Optimizing SQL Server Performance in a Virtual Environment
All of these are certainly valid reasons to virtualize, but the main advantage that virtualization offers is improved availability. That might seem odd at first because when you virtualize servers, you’re running more servers on a single hardware platform, and therefore potentially have a single point of failure. Downtime on the virtual server can affect all of the virtual machines (VMs) that run on that server. However, in reality that’s actually a much smaller risk than a user or software error, which can bring down the SQL Server instance in the VM itself. User error and software failure are more common than hardware failure.
Additionally, all of the major virtualization platforms offer technologies that let you mitigate the risk of a hardware failure on your virtualization platform. Microsoft provides Windows Failover Clustering and VMware provides its High Availability clustering feature, both of which can automatically move protected resources to a backup server in the event of a server failure. That covers the single point of failure exposure. The real availability enhancements stem from the fact that virtualization lets you abstract the server workload from the underlying hardware that it runs on. This provides huge improvements for availability and disaster recovery.
Learn more: SQL Server in a Microsoft Private Cloud
In the event of a disaster, restoring a VM backup is much faster than getting a bare metal restore off the ground, and it can also be faster than having a warm backup. Technologies such as Hyper-V’s Live Migration let you move VMs and SQL Server instances to different virtual hosts so that you can perform planned maintenance on that host. Although most businesses might not be here yet, virtualization and Live Migration or VMware’s VMotion can also lay the foundation for the dynamic IT infrastructure and the private cloud, where policy-driven automation moves workloads in response to resource utilization and power consumption.
Performance can be another important reason to move SQL Server to a virtualized environment. Sure, there’s some overhead when running VMs, and it’s also true that a SQL Server instance running on a VM won’t be able to achieve the same performance as the same SQL Server instance running on native hardware. The difference is small and becoming smaller all the time. The typical rule of thumb these days is to account for about five percent overhead for virtualization.
That said, there are still many times when the move to virtualization can actually result in overall performance gains. How is that possible? Well it can happen because a lot of SQL Server instances, particularly departmental instances and other SQL Server Express instances, are running on underpowered and outdated hardware. In these cases, moving the SQL Server workload to new high-powered, multi-core, Second Level Address Translation (SLAT) lets hardware provide significant increases in performance, even when it’s running a VM.
Of course, it’s true that not every instance of SQL Server is suitable for virtualization. When should SQL Server not be virtualized? Today, the problem lies in those high-end, scale-up implementations that require more resources than today’s VMs can provide. Of course, the virtualization platform makes a big difference. VMware’s vSphere 5 Enterprise Plus Edition provides better scalability than Hyper-V 2.0, with up to 32 vCPUs and 96GB of RAM. Hyper-V lags a bit behind VMware, with support for up to 4 vCPUs and 64GB of RAM per VM. Microsoft plans to even the odds with the upcoming release of Windows Server 8 and Hyper-V 3.0, which will support up to 32 virtual CPUs and 512GB RAM per VM. With this kind of scalability, it won’t be long before all workloads will be candidates for virtualization.
