Those of you who follow me on Twitter have probably seen me say this a few times – 2012 will be the year of SQL virtualization, specifically SQL on vSphere. I figured it was about time to back that up with some facts and some opinions on just why I am so adamant about that statement.
I spend a lot of time talking to organizations and helping them virtualize their mission critical applications. In the last few years, many organizations have had success virtualizing Exchange 2010. A big reason why is due to the architectural changes in Exchange that have reduced I/O requirements as well as introduced new availability features. Combine that with the fact that Microsoft has relaxed their support policies around virtualizing Exchange and it is no surprise that many organizations have chosen to virtualize 100% of their Exchange 2010 environment.
I think that it is now Microsoft SQL that will be the next big mission critical applications that organizations will choose to virtualize. I’ve already spoken with many large organizations myself this year alone who are interested in taking on large scale SQL virtualization and consolidation projects, and others which are looking to build SQL as a Service platforms as well.
Here are a few of the reasons why I think this is the year of SQL virtualization.
With the release of SQL 2012, Microsoft has introduced new features that will make it much easier to virtualize SQL while still maintaining high availability. Specifically, the new SQL 2012 AlwaysOn Availability Groups (AAGs) can provide nearly the same level of availability as a traditional SQL cluster without the strict requirements for virtualizing a traditional Windows Failover Cluster (MSCS). AAGs can also have multiple passive copies (previously not possible with database mirroring), and the passive nodes can actually be used for read requests to offload processing from the active node.
So you get the availability of a cluster, along with multiple passive copies of the database, but you don’t have to go through the difficulties of virtualizing a cluster. Despite the fact that Microsoft changed to a per-core licensing model for SQL 2012 I still see this as a big driver for organizations to move to virtualize their SQL 2012 environment.
Even with the move to per-core licensing in SQL 2012, organizations can still save a lot of money by virtualizing SQL. That is because when organizations move to the per-core model and license SQL 2012 Enterprise Edition, they can virtualize an unlimited number of SQL 2012 (or lower) instances on those cores. I’ve personally worked with a number of organizations that either use the older Server+CAL licensing model or have a large number of CPU licenses that they can move into the virtual infrastructure and see significant savings.
There’s a lot more to the licensing story that I won’t get into here, but you can read my previous post on the subject.
Underutilized SQL servers
VMware has a large collection of data on production servers from its Capacity Planner data warehouse. This data shows that the vast majority of SQL servers are actually very underutilized and require very little CPU, memory, or disk I/O. Many people assume that SQL is difficult to virtualize because of the heavy performance requirements, but VMware’s data (in addition to my own observations at many customers) has shown that not to be the case.
Combine under-utilized SQL servers with advantageous licensing if you heavily consolidate your SQL workloads, and it is no surprise that many organizations are eager to virtualize SQL. There may be heavy hitting SQL servers in your environment and those can be virtualized too, but it is likely that many of them are actually pretty light.
VMware is getting serious about mission critical apps
Earlier this year, VMware released a new competency for their partners called the Virtualizing Business Critical Applications (VBCA) competency. VMware partners can go to Partner Central and receive free training and education to help them be successful with virtualizing business critical applications like SQL and Exchange. If you work for a VMware partner and have not yet seen the training and information available for the VBCA competency, log on to Partner Central and go check it out (after you finish reading this post, of course).
VMware clearly sees the value in helping their partners be successful with virtualizing mission critical applications like SQL. With VMware helping their partners to deliver successful projects, it can only help drive adoption of virtualized SQL (and Exchange, etc.) even higher.
Combine all of those things together with the scalability of vSphere 5, and you have a recipe for SQL virtualization. Many organizations have already started down this path and others are just starting, and I believe that this year will be the year that more organizations choose to virtualize SQL than before. And I believe it’s about time….
After seeing a discussion in the vExpert forums and in my own experience in talking to customers, I came to the conclusion that many people aren’t aware of some of the support restrictions around virtualizing tier-1 Microsoft applications.
The one support requirement that many folks aren’t aware of is the use of virtual machine snapshots on Microsoft applications, particularly Exchange or SQL. For both applications, Microsoft is explicit in stating that virtual machine snapshots of any kind are not supported.
Why does this matter? Many popular virtual machine backup products (purposely not naming any) rely on snapshots to take clean backups of running VMs. That means using these products to backup Exchange or SQL VMs may be unsupported.
Here are the official Microsoft support statements for Exchange and SQL:
Some hypervisors include features for taking snapshots of virtual machines. Virtual machine snapshots capture the state of a virtual machine while it's running. This feature enables you to take multiple snapshots of a virtual machine and then revert the virtual machine to any of the previous states by applying a snapshot to the virtual machine. However, virtual machine snapshots aren't application aware, and using them can have unintended and unexpected consequences for a server application that maintains state data, such as Exchange. As a result, making virtual machine snapshots of an Exchange guest virtual machine isn't supported.
Support policy for SQL Server running in a hardware virtualization environment (covers all versions):
Virtualization Snapshots for Hyper-V or for any virtualization vendor are not supported to use with SQL Server in a virtual machine. It is possible that you may not encounter any problems when using snapshots and SQL Server, but Microsoft will not provide technical support to SQL Server customers for a virtual machine that was restored from a snapshot.
Pretty clear, right? The SQL policy actually explains this the best. They’re saying that you may not have any trouble using virtual machine snapshots, but if you restore a VM using a backup product that relies on snapshots then they will not support any issues with that restore.
What about virtual machine backup products that use an application aware VSS writer? I’ve spoken to Microsoft about this in particular and the answer I got back matches what their policy states. That is, if you’re using a virtual machine backup product that relies on snapshots, that solution is unsupported and you may be redirected to the backup vendor for support. This is true whether or not the virtual machine backup uses an application aware VSS writer, as some popular backup products do.
When you are virtualizing your mission critical applications like Exchange or SQL, support is extremely important. So what are your options?
1) If you have a Microsoft Premier support agreement, then Microsoft will make reasonable efforts to support you even if you run in unsupported configurations. If your organization has a Premier support agreement then you’ll most likely get support if you use a backup product that relies on virtual machine snapshots. Always confirm with your Microsoft rep in advance to ensure they will support the configuration.
2) Talk to your Microsoft representative and try to get the support statement clarified. Show them your configuration and get confirmation that it is or is not supported.
3) Rely on the backup vendor for first level support if your restored VM is having issues.
4) Use a different type of backup product for Exchange or SQL virtual machines.
As I said, mission critical applications have more strict requirements for support and I believe that you should make all attempts to follow these requirements. These applications are usually too important to an organization to risk a lengthy outage due to a miscommunication or disagreement about what is or is not supported.
Last week Microsoft released their updated licensing scheme for SQL Server 2012, which is due to be released next year. Though there are a number of changes to the product and to how it is licensed, in my mind the biggest change is that Microsoft has moved to a per core licensing model for SQL. The Server + CAL model still exists as well but for this post I’ll focus on the per core licensing and changes that affect those that want to virtualize SQL Server 2012.
You can read more about the new licensing for SQL 2012 by going to SQL 2012 Licensing Overview page. Here are some of the highlights:
- The Datacenter Edition from SQL 2008 R2, which was previously licensed per socket/CPU, has been discontinued.
- The top tier license is now Enterprise Edition (EE), which is licensed per core. It requires a minimum of 4 core licenses per processor. If all cores in a host are licensed, you retain the unlimited virtualization rights previously available in SQL 2008 R2 Datacenter Edition.
- The cost per core of SQL 2012 Enterprise will be $6,874/core not including Software Assurance (SA).
- Software Assurance is required in order to use license mobility (i.e. vMotion/Live Migration) more than once every 90 days.
- Instead of licensing an entire server, you can also license the virtual cores of individual SQL virtual machines.
- Core licenses are sold in 2 core packs.
- There is a limitation of 20 cores per server maximum for EE. (Note: this has been clarified - see below)
- If you are current on SA and have SQL 2008 R2 Enterprise you will receive a minimum of four SQL 2012 EE core licenses per CPU or the actual number of cores in use.
- If you are current on SA and have SQL 2008 R2 Datacenter you will receive a minimum of eight SQL 2012 EE core licenses per CPU or the actual number of cores in use.
Per Core Licensing
It really shouldn’t come as a surprise to anyone that Microsoft is moving from a per socket/processor model to a per-core model for licensing SQL Server. After all, processors are shipping with more and more cores per CPU and are capable of higher consolidation ratios. Combine that with the fact that the majority of SQL Server workloads are actually very light use (based on VMware Capacity Planner data) and you can see that Microsoft couldn’t continue with per socket licensing.
The only potential issue I see is the minimum of 4 cores licenses per processor. If organizations are still using older hardware that only has 2 cores/processor then they are paying for cores they don’t have. I would suspect that in 2012 this isn’t likely to affect a large number of organizations. Update 11/19/2012: Microsoft has included a core multiplication factor that will account for older systems that have fewer than 4 cores per processor.
The actual cost for EE is roughly the same as if you licensed 2 sockets of SQL 2008 R2 Enterprise Edition as long as it had 4 cores per CPU. The cost goes up as soon as you start using 6 core processors and above. The prevalence of 4 core processors means this likely won’t change much for many organizations.
Compared to SQL 2008 R2 Datacenter, however, there is a large cost difference. Datacenter costs $54,990 per processor or over $100,000 to license a 2 CPU system. You can now essentially get the benefits of Datacenter Edition (unlimited virtualization rights, etc.) for half the cost you would pay in SQL 2008 R2.
Even with this new licensing model there are still huge cost savings to be had by licensing all cores of a server and virtualizing your SQL 2012 workloads. It’s hard to argue with unlimited virtualization rights especially for those lightly loaded SQL workloads.
There may be situations where Server + CAL licensing actually makes more sense. If you’re worried about the higher per core costs that may be something to consider. Server + CAL licensing requires a lot more administrative overhead and is usually only beneficial for situations where there are a small amount of users/devices that are easily accounted for.
Licensing per VM
Instead of licensing all of the cores in a server, you can instead simply license the cores you use in your SQL virtual machines. Sounds easy, right? Unfortunately you are still required to license four cores per VM. Since the majority of SQL workloads are underutilized and can likely get by with 1-2 vCPUs, you’re essentially paying for core licenses you won’t use. I can’t imagine many organizations will go down this road unless they have a small number of larger SQL servers.
Update 11/19/2012: Another aspect of per VM licensing that may be undesirable is the requirement to purchase extra licenses if you use Intel processors with hyper-threading enabled. See this post for more details.
20 Core Limitation
I have to admit I’m scratching my head a bit on this one. Knowing that 10 and 12 core processors are available today and 16 core processors are on the horizon, why put a limit at just 20 cores per server? What happens if you already own 12 core processors, or you have a 4 socket system that exceeds 20 cores in total? The only thing the SQL 2012 Licensing Guide says is to “contact your Microsoft representative for help transitioning to the new licensing model.” It’s not uncommon for organizations to scale up and have ESX/ESXi hosts with greater than 20 cores (even easier today with 8 and 10 core processors), so I would hope there is a reasonable solution here.
Update 12/19/2011: On December 1st, Microsoft released an updated copy of their licensing datasheet for SQL 2012. In this updated version, they clarify the language around the 20 core limit and make it clear that it only applies to SQL 2012 EE licenses that were upgraded from SQL 2008 licenses in the Server + CAL model. For EE licenses that are purchased new, or that were upgraded from SQL 2008 that used the per CPU licensing model, you are not limited to just 20 cores. See this post for more information.
If you already have SA on your SQL 2008 R2 licenses, you’re probably in better shape than you think. Note the italics above regarding “actual number of cores in use.” If you use per processor licensing in SQL now and your processors have more than 4/8 cores, work with Microsoft to get core licenses for what you’re actually using rather than simply accepting the default trade-in value. Those that bought into higher core CPUs should not be penalized by upgrading to SQL 2012.
Software Assurance also gives you the right to full virtual machine mobility. In other words, the rights to use vMotion/DRS in vSphere to move your SQL workloads more than once per 90 days. You still need the appropriate Windows license to allow that mobility, but again this is another reason why Software Assurance is becoming mandatory.
Anyone still reading? I realize this is a large post so I’ll keep my final thoughts brief. In short, I think that the move to per-core based licensing was an inevitable change that I would expect to see other vendors take up as well. The bright side is that the cost to have unlimited virtualization rights for SQL has essentially been cut in half depending on whether or not you already owned the SQL 2008 Datacenter license.
Anything that promotes the virtualization of mission critical applications like SQL is good in my book. I look forward to talking to customers about this change and helping them move towards virtualizing their SQL deployments.