This is a guest post from a Microsoft SQL Server expert, Allan Hirt, Managing Partner at SQLHA.
Microsoft SQL Server is a common backend for many applications, whether it is for relational database needs to business intelligence and beyond. Traditional, on premises-based VMware vSphere is one way to deploy SQL Server, but now there is another option for virtualizing SQL Server deployments: VMware Cloud on AWS.
VMware Cloud on AWS is VMware’s offering to deploy virtualized servers, or virtual machines (VMs), in the public cloud. The public cloud in this case is Amazon’s AWS. In addition to using vSphere, the solution also includes vSAN and NSX. Everything together ensures that VMware Cloud on AWS is a solution which fits into the concept of the software defined data center (SDDC). To see the details of the VMware Cloud in the AWS Cloud base cluster configuration, read this white paper, as well as in the VMware Cloud on AWS FAQs. An FAQ for third party software considerations can be found at the link Third Party Technology Solutions.
VMware Cloud on AWS can either be used to extend existing on premises deployments to create a hybrid configuration with on premises vSphere or used on its own to deploy new VMs running SQL Server where you are only deployed on VMware Cloud on AWS.
This blog post will cover the considerations for licensing SQL Server when using VMware Cloud on AWS, including hybrid scenarios which also have an on premises footprint. The goal for any deployment is to not only be properly licensed, but also have one that is supported by all vendors and has the right performance and availability. Where applicable, supportability and its effect on licensing will be addressed.
Licensing the Operating System
With SQL Server, there are two components you must license: the underlying operating system (if applicable) as well as SQL Server itself. SQL Server is supported on Windows Server, Red Hat Enterprise Linux, SUSE Linux Enterprise Server (SLES), and Ubuntu. Click on each of the links for the relevant licensing information for each respective OS.
Licensing SQL Server – The Basics
When it comes to SQL Server, the first place to look is the licensing guide that is published by Microsoft. Microsoft also publishes a shorter data sheet. These are always the basis for any conversation with a Microsoft licensing professional.
The rest of this section assumes the following:
- For purposes of licensing in context of this post, a VM and a container will be considered the same. SQL Server can be deployed in a container as well as in a traditional VM.
- SQL Server Enterprise Edition or Standard Edition
- SQL Server just refers to the relational database engine in context of this post. There are other components such as Analysis Services, Integration Services, and Reporting Services which may also require a separate license from SQL Server if they are running independently of the database engine. Those will not be addressed.
- There are tools under the SQL Server umbrella. Some, but not all, are free. An example of a free tool is SQL Server Management Studio. An example of tools that are not free are the ones for Business Intelligence.
- If the goal is to deploy an older version of SQL Server, the license purchased and licensing terms are for the latest version of SQL Server and you get rights to deploy the target version. For example, as of the writing of this post, the current version of SQL Server is SQL Server 2017. If you deploy SQL Server 2014, you will be buying a SQL Server 2017 license enabling you to deploy SQL Server 2014.
- The VMware Cloud on AWS configuration is not shared by multiple customers (i.e. all VMs are for a single company)
SQL Server is generally licensed per core. Cores are sold in packs of two. Each VM can be licensed individually, or entire hosts can be licensed. Licensing an entire host requires Enterprise Edition of SQL Server. Which method you choose depends on how much SQL Server that will be deployed.
If you only have a few deployments of SQL Server where licensing entire hosts does not makes sense, each VM running SQL Server should be individually licensed. If you are using SQL Server Standard Edition, you can only license per VM.
If you plan on deploying many SQL Server VMs, even if a hypervisor host is not dedicated just for SQL Server VMs, it may make more sense from a cost perspective to license all cores on each host instead of licensing per VM.
A single VM can be assigned up to 128 virtual CPUs (vCPUs). From a licensing perspective, you license what the operating system (OS) inside the VM can see. If the OS (referred to as an operating system environment, or OSE, in the Microsoft licensing documentation) can see eight cores, you need to account for eight cores worth of SQL Server licensing.
If a VM is configured with less than four vCPUs, SQL Server has a minimum core count for licensing of four. For example, if a VM is allocated two vCPUs, that equates to two cores. The VM must meet the minimum of four cores for licensing. Therefore, a two-vCPU VM requires the purchase of 2x two-core packs. Those additional two cores purchased cannot be assigned to or used by another VM.
For both Standard and Enterprise Edition, a core-based license for a single VM allows deployment of multiple instances of SQL Server inside the VM. Whether you deploy one instance per VM or more than one depends on many factors outside the scope of this blog.
Standard Edition can also be licensed using the Server + Client Access License (CAL) model. You would purchase a server license for the VM, and then a CAL for each user or device that would access SQL Server within that VM. Server + CAL is not an option for Enterprise Edition.
For VMware Cloud on AWS, Software Assurance (SA) may be required whether licensing per VM or entire hosts. You need to consider your usage of SQL Server to make the right decision with regards to SA. There are quite a few benefits to SA, one of which will be covered in the next section.
If licensing per host, each host in an ESXi cluster must have all cores licensed for SQL Server and have enough spare licensed cores to be able to run a VM from another host if it is moved using DRS/vMotion. This means that you are manually keeping track of licenses and how many cores are available.
For example, if you have a server with 32 cores with each core assigned a SQL Server Enterprise Edition license, you can deploy any legal combination of SQL Server VMs that totals up to the 32 cores available as long as you do not exceed the 32 licensed cores. If you vMotion a VM where all the cores will be in use or the VMs running on that server will exceed the number of licensed cores (for example, you have 32 licensed cores for SQL Server, but moving the VM brings you up to 36), you will need to buy the appropriate amount of two packs to cover those cores. There is one way to cover you in this case: SA.
SA allows you to overcommit vCPU resources, SA has a benefit called Unlimited Virtualization which allows you to exceed the number of physical processors and deploy unlimited VMs with unlimited vCPUs and not have to worry about things like minimum core counts or how a vCPU or vCore is presented behind the scenes at the hypervisor. What is meant by this?
The Unlimited Virtualization benefit of SA also matters if hyperthreading is used. For physical implementations of SQL Server, hyperthreading does not affect the number core licenses. This is not true for virtualized SQL Server deployments. As Microsoft states “For licensing purposes, a v-core maps to a hardware thread.” Microsoft requires additional licenses when a single hardware thread is supporting multiple virtual cores or multiple hardware threads are supporting a single virtual core at the same time. Unlimited covers all of this, and thus, SA should be considered in these cases.
There is a benefit of SA called License Mobility within a Server Farm. If you are licensing per VM, this allows that VM to be moved and reassigned to another host more frequently than once every 90 days. A VM that is licensed on its own can be moved from Host A to B with vMotion, but if you do it more frequently than 90 days, you will need this benefit of SA. License Mobility within a Server Farm is required for VMware Cloud on AWS due to the way maintenance is handled as well as its use of vMotion. See the example in the next section for more information on maintenance.
Availability Configurations and VMware Cloud on AWS
Microsoft has specific rules around how SQL Server is licensed for availability. Couple that with some of the requirements to deploy Always On Availability Groups (AGs) or Always On Failover Cluster Instances (FCIs) from both Microsoft and VMware, everything factors into what does (or does not) get licensed. As mentioned in the previous section, Software Assurance is not only recommended, but in some cases, may be required depending on your scenario with regards to SQL Server availability.
If deploying highly available SQL Server architectures, SA has a specific benefit: the Failover Server and Disaster Recovery benefits are important. This allows one of the VMs functioning as a standby server in a particular AG or FCI configuration that also has no active use to not require a license.
This SA benefit does not apply to hybrid configurations that span on premises and VMWare Cloud on AWS. This means that If you have an existing on premises vSphere deployment but want to extend it to VMWare Cloud on AWS for disaster recovery, all VMs (or possibly hosts) participating in that configuration would need to be licensed.
SQL Server Licensing Examples
This section will show some examples of licensing SQL Server for VMware Cloud on AWS.
IMPORTANT There is a difference between what is technically possible to deploy and what is supported. All examples in this section are based on supported configurations of SQL Server on any VMware deployment – on premises or in the cloud.
Example One – Always On Availability Group Fully in VMware Cloud on AWS
One way to deploy a supported AG using VMware Cloud on AWS is to have the replicas split up among the different regions. This is shown in Figure 1.
Figure 1. Example of an AG in VMWare Cloud on AWS
One of the requirements for deploying AGs and FCIs for availability configurations is the use of anti-affinity on the VMs participating in the AG or FCI. As of the writing of this post, it is not possible to configure anti-affinity for VMs deployed on VMware Cloud on AWS. This means that AG and FCI scenarios are affected, and thus, has an influence on licensing. If anti-affinity is added in the future to VMware Cloud on AWS, this blog post will be updated accordingly.
In this scenario, these would be most likely licensed per VM if they were the only SQL Server VMs hosted in VMware Cloud for AWS. SA would benefit the deployment because of the aforementioned benefits to allow the VM in Region 2 to function as a standby with no additional licensing cost if the VMs are all located in the same Server Farm. Microsoft’s definition of a Server Farm is as follows:
Server Farm means a single data center or two data centers each physically located either in time zones not more than four hours apart, or within the EU or EFTA.
The other instance must not be running any live workloads. Microsoft considers a live workload tasks such as using a replica for readable queries, backing up from an AG secondary replica, and running database consistency checks to be a live workload. No active use also means there are no other databases receiving requests and outside of receiving transactions from one or more AGs, nothing else is happening.
If SA is not purchased, both VMs would always need to be fully licensed for SQL Server even though the one in Region 2 has no live production use.
In the case of Figure 1, the SA benefit would apply if the zones were US East 1 and US West 2 if the VM that is the secondary replica was not actively in use for any reason other than a secondary replica in the AG. The SA benefit would not apply if it was US West 2 and EU Central 1. In the case of the latter, even if SA has been purchased, both VMs would need to be licensed no matter what the usage (or not) is of the secondary replica.
Example Two – Hybrid Always On Availability Group
Figure 2 is a hybrid configuration where you have two AG replicas on premises and one up in the VMWare Cloud on AWS for disaster recovery purposes. There is no SA benefit when spanning on premises and VMware Cloud on AWS, so at a minimum, the primary replica on premises and the secondary replica in the cloud must be fully licensed. The SA benefit may or may not apply to the secondary replica on premises depending on if it has active use or not, such as for readable queries.
IMPORTANT The lack of the SA benefit for the standby server is true in all hybrid scenarios, even if the cloud’s data center is within four hours.
Figure 2. Hybrid AG configuration
Example Three – VMware Cloud on AWS and the Maintenance Node
Figure 4 shows VMware Cloud on AWS which includes a maintenance node. Assume that there is enough SQL Server usage that per-host is the most cost-effective licensing scheme. In this example, all five hosts including the maintenance node would need to be licensed. Why?
The maintenance node comes into play when a host is designated for updates. Behind the scenes, another host will be added to the vSphere cluster and VMs from the host will automatically be moved via vMotion to that new host or one of the others in the VMware Cloud on AWS configuration.
This creates a zero-downtime scenario for the hosts which is a big benefit. However, there are two challenges:
- There is currently no mechanism to control where a VM is hosted; and
- There is no way to control when the maintenance will occur
Figure 3. Per-host licensing with SQL Server Enterprise Edition
Example Four – Testing Disaster Recovery with VMware Site Recovery Manager
One of the nice benefits of VMware Site Recovery Manager is that it allows you to bring up VMs configured for disaster recovery without taking down or directly affecting the current production site. Assume in this example that VMware Cloud on AWS is the disaster recovery site. Similar to the previous example with the maintenance node, if the disaster recovery is brought live, that VM needs to be licensed. It also would be considered a hybrid configuration since it spans on premises and the public cloud.
The Bottom Line
With the planning and care you would give an on-premises deployment of SQL Server with vSphere, you can also deploy on VMware Cloud on AWS. Part of the puzzle is ensuring that SQL Server is licensed properly for the intended configuration(s). Using the examples here along with the linked Microsoft documentation, work with a Microsoft licensing professional to ensure your company’s usage of SQL Server is properly licensed when using VMware Cloud on AWS.