Like most Microsoft products, sometimes the licensing can be more difficult to figure out than the technical aspects of the product, and SQL Server is no different. Each SQL Server edition has a different licensing model and some have more than one. There are multiple different license types. And if that’s not enough there are considerations for AlwaysOn Availability Groups, virtualized SQL Server instance and even which Windows Server edition you’re running on. While the entire ins and outs of licensing would take a small book to cover here are some of the most important things you need to know about SQL Server 2014 licensing.
Server vs Core Licensing
Beginning with SQL Server 2012 Microsoft changed the way that SQL Server was licensed and began using core licensing. Before that you had the option of licensing on a Server + CAL basis or according to the physical processors (sockets) that were on the server. With the explosion of server cores in modern CPUs Microsoft followed Oracle’s lead and switched from a processor licensing model to a core licensing model. The different editions of SQL Server 2014 offer the following licensing options:
- SQL Server Standard Edition: Server + CAL or Core licensing
- SQL Server Business Edition: Server + CAL licensing
- SQL Server Enterprise Edition: Core licensing
When licensing SQL Server using the traditional Server + CAL model you need to purchase a server license for each server, and client access licenses (CALs) for each device or user that accesses SQL Server. This model is appropriate for on-premise implementations where you know the number of users and devices that will connect to the server.
With the Core licensing model, each server running SQL Server 2014 or any of its components like Analysis Service, Reporting Services or Integration Services must be assigned some number of SQL Server 2014 core licenses. The number of core licenses needed depends on whether customers are licensing the physical server or SQL Server instances running in virtual machines. The Core model allows access for an unlimited number of users or devices to connect which makes it appropriate for Internet and cloud implementations. You don’t need to purchase CALs to access SQL Server instances that are licensed using the Core model. If you are running SQL Server on a physical server then all of the cores in the server must be licensed. If you are running in a virtual environment then you need to license the number of virtual CPUs that you are using. There is a minimum of four core licenses required per virtual machine. I’ll cover more about virtualization and licensing in the SQL Server and Virtualization section.
SQL Server Components
Once you know about the basic SQL Server licensing models you need to know how this applies to the way that you might install SQL Server. For instance, in larger implementations it’s common to install different SQL Server components on different servers. You might put Reporting Services or Analysis Services on different servers than the SQL Server Database Engine. In this case you need to be aware that the different software components cannot be licensed separately. If you install any of these components on another server then an additional SQL Server license is required for each system where they they are installed.
SQL Server and Virtualization
Virtualization always throws in a few twists and turns when it comes to licensing. When deploying SQL Server 2014 software in virtualized environments you can choose to license either individual virtual machines or to license for maximum virtualization on the server.
To use the Server + CAL model in a virtual environment you simply purchase one server license for each virtual machine running SQL Server. You don’t need to worry about the number of virtual processors used in the virtual machine. To use the Core model in a virtual environment all the virtual CPUs in the virtual machines that are running instances of SQL Server 2014 software must be licensed.
To use the maximum virtualization license you need to use the SQL Server Enterprise Edition and license all the cores in the physical server and add Software Assurance (SA) to those licenses. This allows you to run a number of SQL Server 2014 instances equal to the number of core licenses assigned to the server. For example, a two processor server with four cores per processor licensed with eight core licenses can run SQL Server software in up to eight VMs — no matter how many virtual cores are in each VM. More virtual SQL Server instances can be run by purchasing additional core licenses for the licensed server.
AlwaysOn Availability Groups and Failover Clustering: Passive SQL Server Instances and Readable Secondaries
AlwaysOn Availability Groups and AlwaysOn Failover Clustering Instances are SQL Server 2014’s primary availability technologies. Both of these technologies enable you to have passive servers that are only used in the event of a failover. These are called passive SQL Server instances – essentially SQL Server instances that are not serving data to clients or running active workloads. Passive fail-over rights allow you to have a passive instances of SQL Server without requiring the passive server to have a license for SQL Server.
With SQL Server 2012 the ability to have a passive server was included with the base SQL Server license. When a failover happens the passive server becomes active and must be licensed. Then you can reassign the license from the former active server to the new active server. However, this scenario had licensing restrictions. Without SA SQL Server license reassignment cannot take place more frequently than 90 days. Therefore to comply with licensing without SA you needed to run on the failover server for at least 90 days. With SA you had mobility rights to reassign the license as frequently as you needed. With SQL Server 2014 passive fail-over rights are no longer part of the SQL Server license. They require SA on your passive servers and there is no time restrictions for license reassignment.
The key point with passive SQL Server instances is that the SQL Server instance must not be running a workload. So how does this work if you’re using AlwaysOn Availability Groups and you’re taking advantage of readable secondaries for backups or queries? In that case, the SQL Server instance on the readable secondary is running a workload and it needs the appropriate SQL Server license – it is not considered a passive SQL Server instance. For more details on SQL Server 2014 licensing you can refer to Microsoft Volume Licensing and SQL Server 2014 Licensing Guide.
Leave a Reply