Terms, conditions, and license calculation
How to navigate SQL Server licensing: basic terminology, how to license, the number of executable instances, and license calculation..
SQL Server is a reletional DBMS (Database Management System) developed by Microsoft and is used to manage databases of a wide variety of sizes and structuresAlong with Oracle Database and MySQL, it is one of the most widely used database platforms in the world because of its features and functionality for storing, processing, analyzing, and securing data.
It can be used for various purposes, such as application development, running Web sites, hosting data warehouses, or supporting business intelligence solutions. Among MS products, it is often considered the most "hostile" because of its non-simple and ever-changing licensing rules.
Before we delve into licensing for SQL Server, let us keep in mind that each version and edition of SQL has specific licensing terms, rights and features.
Let's take a closer look at the differences between edition and version and the functional features.
Almost always within multi-license contracts and CSPs you can take advantage of downgrade right, i.e., you have the right to use previously released versions without having to purchase them: for example, if you purchase the SQL Server 2022 product through MPSA today, you can downgrade your instance to any of the previous editions.
Let's take a closer look at the main ones, dividing them into free and commercial:
Free Options
Commercial options
The Standard, in fact, is best suited for simple projects where advanced data analysis, security and management features are not required; it is a cost-effective choice for deployments with moderate performance and scalability requirements.
The Enterprise Edition, on the other hand, includes all the basic features of the Standard Edition plus other tools typical of high-end databases with lightning-fast performance, unlimited virtualization, end-to-end business intelligence elements for the purpose of "enabling high service levels for crucial workloads and end-user access to detailed data information."
With regard to downgrading editions, there is a basic rule: If you assign a SQL Server Enterprise license to a host, you can run both a SQL Server Enterprise instance and a SQL Server Standard instance within it..
The reverse is not possible, however, because SQL Server Standard is an edition considered "smaller" and therefore cannot contain SQL Server Enterprise. The only exception to when just written is the AHB (Azure Hybrid Use Benefit) where it is possible to cover Enterprise instances with Standard licenses by applying a multiplier of 4 to the cores used (i.e., it takes 4 Standard cores to cover 1 Enterprise core).
The first and most important difference in terms of licensing between SQL Server Standard and SQL Enterprise is the licensing model. With the Standard edition, you can choose either the Server+CAL or per-core licensing model, while SQL Server Enterprise is available only through the per-core licensing model*.
Caution: the fact that SQL Server Standard Core and Enterprise Core licenses are sold in dual core packages can be confusing. If Microsoft is told that you want 88 licenses, considering that they are sold in dual core packages (and therefore two licenses), you may be buying twice as many.
As we anticipated earlier, licenses can be granted in two ways:
Currently, only SQL Server Standard has this licensing model.
Those who purchased SQL Server Enterprise licenses with the Server+CAL model before April 1, 2012 can still renew, regardless of whether or not the Software Assurance (SA) has been renewed, but they cannot purchase new licenses.
SQL licensing under the Client Access Licenses (CAL) model , as specified in the product's user rights, equires that each instance of SQL (virtual or physical) be covered by a single SQL Server license and that each user and/or device directly or indirectly accessing a licensed SQL Server must have a SQL Server CAL (user/ device CAL ) of the same or newer version. For example, to access a SQL Server 2019 Standard Edition server, a user will need a CAL of SQL Server 2019 or 2022.
Remember to consider the rule of multiplexing: technology insertion between DBMS and consumer never reduces the number of licenses required: this is in the case, for example, of a user or device accessing a SQL-supported SharePoint server (thus not directly) where a SQL CAL is needed.
It should be noted that CALs for SQL server are never bundled with other CALs and have no equivalent: this implies that they must be purchased explicitly as SQL Server CALs (e.g., Office 365 does not include them and so do the Core CAL and Enterprise CAL packages).
Another important aspect is that there are no external connectors: if you have more than 20 users per core or they are not quantifiable because accessing the server is the entire Internet with Internet/Extranet workloads or systems that integrate with external workloads, you need (but also cheaper) the core license where you do not need to count the users and devices accessing the server. Which with CALs must be done instead, with the count kept individually.
So the rule of thumb is to look critically at how many users and devices you have in your assets indirectly accessing the SQL server and whether this number will grow in the next period.
N.B. Software Assurance (SA) notice: if a feature requires SA on the SQL Server instance license, it is likely that it will also require SA for the CALs. For example, SQL Failover requires SA for both the instance and the CALs."
This model provides customers with a more accurate measure of computing power , followed by more consistent licensing metrics , regardless of whether solutions are deployed on physical on-premises servers or in virtual or cloud environments.
Unlike the Server+CAL model, it does not require client access licensing, but instead of licensing SQL per server, it does so per server core running SQL Server. There are specific formulas and caveats for calculating the required number of SQL server core licenses.
To license SQL Server with this model, you must count the total number of server cores and purchase the appropriate number of licenses per core (sold in packs of two).
When you assign the SQL Server license to a SQL instance what you do is essentially assign it to the operating system in which SQL Server runs, which can be physical or virtual (see concept of virtualization: VMs, which are "dummy PCs" that contain virtual operating systems, can run inside a physical operating system, called a "host" because it hosts VMs).
Two considerations about this model:
1) licensing an instance (a copy of the server executable file executed as an OS service) does not differ depending on whether the OS is in a VM or physical
2) Containers or containers, which group and isolate applications together with the files needed for execution in a sort of "bubble," can run either within a physical operating system but can also be nested in virtual machines. In this model, however, each container is treated as a separate virtual operating system environment (OSE) (and not as another virtual machine as in pre-2022 editions).
In the Standard edition, a single SQL license assigned to an OSE allows you to run an unlimited number of SQL Server Standard instances within the same OSE. If you have four applications with similar requirements (e.g., they all require SQL Server Standard 2019), you can install SQL server four times in the same OSE under a single license which is a significant cost savings.
As for the Enterprise edition, remember that it can no longer be purchased under the Server+CAL model but there are organizations with existing licenses and continuous renewals (with or without SA).
Regardless of whether or not you have renewed the SA, with an Enterprise Edition with this licensing model, there are constraints:
1) you can run an unlimited number of instances in up to four operating system environments (virtual machines or containers)
2) there are HW limitations: up to a maximum of 20 cores in case of physical OSE and up to 20 hardware threads in case of virtual OSE
1) if you license physical cores, this covers all instances within the physical OS. Containers are not included, as they are considered VMs
2) the same license cannot be assigned to VMs and containers (this was possible in previous SQL Server 2019, 2017, 2016, 2014, 2012 versions). Concession per VM or per container is provided only in case you have SA (or CSP subscription which is the equivalent).
So in the case of SQL Server Standard with SA you have unlimited instances within the physical OS, but you also have VMs and containers within the virtual OS. In the other model the containers were treated as separate VMs and therefore require a separate set of licenses so in case of heavily containerized environments licenses with active SA are a concrete savings option because you no longer need to count them.
If you have SQL Server Enterprise with SA, you can license each core in the physical host and run an unlimited number of virtual machines and containers on itThis is the best option for entities that want unlimited virtualization and have heavily containerized environments.
without SA, infact, there are limisthe number of virtual machines and containers to follow cannot be more than the number of licenses assigned to the host (e.g., if a host has 12 cores, the number of virtual machines is limited to 24). If you assign SQL Server Enterprise without SA to containers you have to be careful: in this case they are managed as separate virtual machines.
Quando si esegue SQL Server in un OSE fisicoWhen running SQL Server in a physical OSE , all physical cores in the server must be licensed. In this case, a minimum of four core licenses is required for each physical processor in the server. So you look at the CPU characteristics, count the physical cores of a CPU, and assign at least four licenses per CPU.
You must remember that core licenses are sold in packs of two, so you must divide the number of licenses required by two to determine the actual number of license SKUs to order.
In this case, the situation is slightly different: virtual cores (vCPUs) must be counted , remembering that the number of required licenses has a minimum of 4. Consequently, if the virtual OSE has 2 vCPUs it must still be licensed at four.
N.B. If vCPUs are supported by multiple HW threads the latter should be counted, but this is an infrequent situation: usually popular hypervisors such as VMware or HyperV, once rebooted to enable hyperthreading, will have all vCPUs mapped to a single thread.
The topic of SQL licensing is very broad, and there are several topics to consider. We briefly mention a few of them:
Hosts can be combined in multiple clusters and this is for the simple reason that if one host fails the virtual machines can be moved to another host. But the situation could arise whereby virtual machines move but the assigned licenses cannot: when this right is provided we speak of license mobilitythat is, the ability of the license to move along with the virtual machine.
The licensing of a virtual instance requires an SA if the virtual server moves between hosts more than once every 90 days. This benefit is called License Mobility between Server Farms.
This is an important issue in the case of audits, with vendor verification of compliance: in the case of virtual machine moves, one must ensure that the licenses also cover the move.
One of the most sought-after benefits of SA is the ability to implement High Availability e Disaster Recovery: in anticipation of failover events, it is possible to install and run passive instances in OSE or separate servers on-premises or in Azure for disaster recovery. Regarding the need to fire nodes, keep in mind that:
The various functions of SQL can be separated across multiple servers.Some of these functions do not require licenses, but others do. The following are the components of SQL that are subject to licensing:
1) SQL Server Analysis Services SQL
2) Server Reporting Services SQL
3) Server Integrations Services
Each server with a licensable SQL function requires its own SQL license, even though all servers even though they all work on the same database. Consequently, if a database is running on one server, analysis services on a second server, and reporting services on a third server, all three servers require separate licenses.
At WEGG we are experienced Microsoft licensing consultants (including SQL Server), so if you need support in performing the required licensing calculation, verifying compliance position, and optimizing costs related to SQL Server spending contact us for a consultation!
Insights
OUR OFFICES
OUR OFFICES
PADUA
Via Arnaldo Fusinato 42, 35137
MILAN
Viale Enrico Forlanini 23, 20134
ROME
Viale Giorgio Ribotta 11, 00144
Copyright © 2022 WEGG S.r.l. • P.I 03447430285 • C.F. 02371140233 • REA 311023
Certified company ISO 9001:2015
