Welcome to the second, and final, installment of this blog series. Part One laid the foundation of SQL Server licensing. In this blog post, you will learn about licensing an entire ESXi host, how availability affects licensing, and more about Software Assurance.
Licensing an ESXi Host
At some point, licensing is a combination of a math problem, the underlying architecture, and how you want to pay for SQL Server. Licensing a virtualization host is only possible with Enterprise Edition. There are two main scenarios: very large VMs and many SQL Server VMs. Even if you are using a lot of Standard Edition, it may make more sense to license hosts using Enterprise.
If you use very large VMs with SQL Server inside, they are often the only thing running on the ESXi host. It may be simpler and effective to license the whole host.
If you deploy quite a bit of VMs with SQL Server, it may make sense if you add up the per VM licensing to see if it would be better to license the hypervisor host(s). This assumes that the VMs are running on dedicated hosts in an ESXi cluster that may or may not be dedicated just for SQL Server. DRS affinity rules allow you to designate specific hosts for VMs running SQL Server within an ESXi cluster that runs other workloads besides SQL Server. An example of how to configure a “must” enforcement in DRS is shown below.
When a license is purchased for an entire ESXi host, you license all cores. If licensing per host, Microsoft does not care if you disable cores; all cores must be licensed. If you do not want to pay for a core, it physically cannot exist in the server.
When licensing per host, if you use Enterprise Edition without SA and the server has 56 cores, you get 56 core licenses. For host-based licensing, Microsoft counts VMs that are running SQL Server. This means you can run up to 56 VMs with SQL Server on a single host. Those VMs can have any number of vCPUs. If a 57th VM is created, additional core-based licenses are required.
SA adds the additional benefit of unlimited virtualization when licensing per host. This means you can deploy as many VMs with SQL Server as you want on a single ESXi host. For both host-based scenarios, just because you can deploy many VMs on a single virtualization host does not mean you should as performance could potentially suffer in guest. Deploy wisely.
With host-based licensing. If a VM running SQL Server on a fully licensed host is moved to another ESXi host that does not have enough SQL Server cores licensed (or is not licensed at the host level at all), you will need to acquire the proper licensing for that VM to run on that other host. However, if that VM is part of an availability architecture, it may be accounted for. Availability is discussed in the next section.
It is recommended that when licensing per host, you have a method (log, document, etc.) to keep track of vMotion and when VMs are started/stopped to prove compliance if necessary.
Availability Architectures and Licensing
One of the biggest changes Microsoft made to licensing SQL Server with SQL Server 2019 is around availability. For in-guest based availability solutions using SQL Server features, Microsoft no longer requires a license for servers that are considered passive, or not running an active SQL Server workload. This benefit is only valid if you have SA. If you do not, each VM running SQL Server requires a license.
For example, if you have three replicas (one primary, two secondary) in an Always On Availability Group (AG) configuration, the primary which has the read/write copy of the database needs a license, but the two secondary replicas would not if you have SA. Without SA, all three would require a license. For more examples, see the Channel 9 videos and blog linked in “For More Information”. One caveat: if you are choosing per-host licensing, the primary and D/R hosts can have the same or less cores. If the D/R server has more cores, you need to have the same number of cores licensed on the primary. For example, the primary host has 56 cores and D/R has 64. The primary host would need 8 more cores of licensing.
There is also the case of partial licensing. If the primary has 56 cores, you cannot split that up and apply 28 to the one free D/R host covered by SA and 28 to another D/R host elsewhere in the topology. That example would be considered invalid.
Microsoft relaxed the rules for availability in two other ways. With Enterprise Edition, secondary replicas in an AG can be used for DBCCs, seeding log shipping, and generating backups without requiring a license. Those tasks are no longer considered active use. This new SQL Server 2019 benefit applies to any release if the cores are covered with SA. Without SA, you must pay for all HA and D/R replicas in an AG configuration.
With SA, disaster recovery (D/R) can now be tested once every 90 days with the D/R VMs live for a brief amount of time. Microsoft does not define brief. If you are using Site Recovery Manager, the D/R side can be running during the exercise and not need to incur a cost if the test is run every 90 days or more.
SA provides a lot of flexibility, but only to a point. Secondary replicas used for read-only queries must still be licensed. If you have more than one D/R server, even with SA, those must be licensed. If they are accounted for as part of host-based licensing, this may not be an issue.
Do You Need Software Assurance?
You can deploy SQL Server using VMs using vSphere without purchasing SA. SA comes into play if you use certain features (in-guest or vSphere/host level) or have specific architectures, some of which has been discussed already. SA may even save you money. As with most things related to SQL Server, purchasing SA is “it depends”.
The biggest consideration for vSphere is the SA benefit known as license mobility which comes in two flavors: within a server farm and through SA. The “within a server farm” variant allows you to reassign SQL Server licenses within a server farm more than once every 90 days. The “through SA” variant allows you to reassign licenses to third party shared servers, for example VMware Cloud on AWS.
The server farm variant is the most important for on premises vSphere customers as it has implications for vMotion within an ESXi cluster. Without SA, you cannot rehost a VM more than once every 90 days. If your company relies heavily on vMotion and moves VMs around all the time (or more than once every 90 days), you will need to purchase SA. Remember that the new host for the VM must have enough licenses on that host to cover the VM if using host-based licensing.
The other variant covers shared hardware in a public cloud or a host provider’s data center where you may not be running your own implementation of vSphere. The provider must be listed as an Authorized Mobility Partner of Microsoft. If you were using vSphere but do not own the hardware or hypervisor, this variant is what applies to you whether it is on premises or in the cloud.
Over the course this two part blog series, I hope you understand licensing SQL Server better for when deploying vSphere 7 on premises. There are a few enhancements to licensing SQL Server as of SQL Server 2019 that should hopefully assist many of you.
Even though what is in this blog is accurate at the time of writing, Microsoft licensing terms can change and more importantly, licensing is subject to interpretation by the person authoring your licensing contract or auditing what you have (or have not) licensed. The only source of truth as it relates to what you must pay Microsoft for SQL Server is the executed licensing agreement.
This is a guest post by Allan Hirt. Consultant, trainer, author, business continuity expert, and SQLHA, LLC founder Allan Hirt has been working with both SQL Server since 1992 when it was still a Sybase product as well as clustering in Windows Server since the late 1990s when it was called Wolfpack. He has been using VMware’s products for virtualizing workloads for nearly 20 years. Currently a dual Microsoft MVP (Data Platform; Cloud and Datacenter Management) as well as a VMware vExpert, Allan works with customers of all sizes around the world to deliver mission critical projects whether they are on premises, in the cloud, or hybrid. You can follow him on Twitter at @SQLHA, read his latest blog posts and see upcoming speaking engagements and classes at sqlha.com, and get his free video content on the SQLHA YouTube Channel.
Further information not already linked in the two blog posts:
Microsoft Blog – New high availability and disaster recovery benefits for SQL Server
VMware SQL Server Guide – SQL Server on VMware Best Practices Guide