SQL Server License Allocation

Microsoft offers multiple licensing vehicles for the Windows Server, SQL Server and System Center product families that provide end users with the exact same features and capabilities but differing in one key way: virtualization rights. 

These virtualization rights directly impact the number of licenses required.  For example, a single Windows Standard license allows the user to run one instance of Windows Server on a physical host in addition to two virtual instances on that host.  If the user wants to run more than two virtual Windows Servers on that host, then they can assign additional Windows Server Standard licenses to it, often referred to as “stacking.”  Alternatively, the user could assign a Windows Datacenter license to the host, which is based upon the number of cores installed in the host, allowing the user to run an unlimited number of virtual Windows Servers on that host. 

The assignment of SQL Server licenses is similar to the assignment of Windows Servers licenses in several respects, including:

• Groupings (hypervisor clusters, physical and unlinked)
• Unlimited virtualization when licensing SQL at the host level
• Cluster and host specifics including:
  • Cluster name
  • Total hosts per cluster
  • Cluster and host processor and core counts
• A ‘Summary Table’ view in the SQL Server section of the Movere portal to confirm that all active SQL Servers have been assigned a license.

The key differences between Windows and SQL Server licensing assignments include:

• The ability to assign SQL Server licenses at the host or guest level,
• High Availability features that impact licensing counts, including: clustering, log shipping, mirroring and availability groups; and  License mobility.

Host or Guest Level Licensing:

This is only applicable to SQL Servers that have been linked to at least one physical hypervisor host.  When licensing SQL Server at the host level, you can only assign SQL Enterprise edition licenses coupled with Software Assurance (SA), to the hosts in the cluster you want to license for unlimited SQL virtualization.

When licensing SQL at the host level do NOT assign licenses to the guests on those hosts. If there are SQL Servers in the cluster that you want to license at the guest level, then assign a license at the guest level to these devices first.  You will no longer be able to assign a SQL Server license to the host(s) within the cluster that the guest level licensed SQL Servers have run on.  Using this approach, we can assign a SQL Server license to a subset of the hosts within a cluster and license the SQL Servers not on those hosts individually.  If a SQL Server you are licensing at the guest level has touched a host that you want to assign a SQL Server license to, then assign a license to the host first, then assign a license to the guest:

In the screenshot above, a SQL Enterprise license with SA has been assigned to the two physical hosts in the hypervisor cluster.  A SQL Server license does not need to be assigned to the virtual SQL Server guests running on these hosts as they have been licensed for unlimited SQL Server virtualization.

High Availability (HA) Features:

SQL Server’s HA features include clustering, log shipping, mirroring and availability groups; these features impact SQL Server licensing requirements.  For example, the secondary ‘passive’ node in a SQL availability group does not require its own SQL Server license as long as it is only functioning in a secondary role and does not allow secondary connections.  If Movere is able to query each SQL Servers ‘master’ and ‘msdb’ tables, then it can capture all four HA configurations, but it will not incorporate these settings into the license allocation table:

In the screenshot above, SQL Servers ‘SQLAG2’ and ‘SQLAG3’ are both functioning in secondary roles, and both allow secondary connections.  In this configuration, a SQL Server license would need to be assigned to both devices.  In addition to the licensing requirement, we can also see that the copy of the ‘SAGDB’ database on ‘SQLAG2’ is not in a healthy synchronization state.  If the synchronization health is returned to healthy and the SQL Server rescanned with Movere then this view will update to reflect the change:

In this configuration, these servers would no longer require a SQL server license and the synchronization state has been returned to healthy.

For SQL clusters we refer to the SQL ‘Device-Instance’ view on the Movere portal.  It is not uncommon for SQL clusters to have multiple instances running on different nodes.  In the screenshot below instance ‘\SQL’ is running on server ‘SQL2K12N2’ while instance ‘SQL2’ is running on server ‘SQL2K12N1’.  In this configuration both nodes will require a SQL license:

If there was only one instance or all instances were running on the same node, then only one SQL Server would require a license and the other considered passive.

In both cases, if we need to exclude a SQL Server from the license count, we don’t use the ‘Excluded’ option from the Device Overrides page, as this would remove the entire server, all we want to do is remove the SQL Server license requirement.

To remove the license requirement from a SQL Server, go to the SQL Server License Allocation page and apply a license to the active node then check the ‘ISV’ button against the passive node.  From the screenshot below we can identify the ‘running’ node by the Database Engine  icon next to the SQL version and edition.  The same applies for other SQL Services including Analysis , Reporting  , and Integration .

NOTE: SQL Integration Services (SQL IS) displays as ‘\~(version)’, for example:  , as the instance name.  SQL IS is not bound to an instance, but does require a license.

For Log Shipping and Mirroring we refer to the SQL ‘Feature List’ view on the Movere portal. In the screenshot below we can see that the database count on each SQL Server is equal to the number of databases being either log shipped or mirrored.  These counts exclude ‘tempdb’ and when all databases on the SQL Server are being log shipped or mirrored then the SQL Server does not require a SQL license.  From the SQL License Allocation page, all three of these SQL Servers should be excluded from the SQL license count by having the ‘ISV’ button checked.

If the counts do not match, then we can refer to the SQL ‘Database List’ view on the Movere portal. In the screenshot below, all three databases are in a ‘RESTORING’ state which is consistent with the log shipping and mirroring settings above.

If the database count on any of these servers was 2 (or more) and the other databases have an ‘ONLINE’ state, then that server would require a SQL license.

License Mobility:

License Mobility through SA allows virtual Windows Servers running applications like SQL Server to move across multiple physical hosts as usage needs change.  The number of hosts a virtual device has run on appears as a count next to the virtual machines name.  In the screenshot below we can see that the first SQL Server has run on 2 hosts.  To see a host list, click on the movement count, in this case ‘2’:

NOTE:  When assigning a license to a guest that is moving across multiple hosts, the user will also need to assign SA to permit mobility. If SA is not assigned to that guest, Movere will include in the total license count the number of licenses required to license that guest on each host it has traversed while powered on. For example, a 4 core SQL Server that has run on 2 physical hosts will require 4 licenses with SA, but will require 8 licenses without SA (4 cores x 2 hosts). 

The SQL Server above requires 4 core licenses when assigned SA. If the SA option is not selected, then both of the hosts the SQL Server has run on will need to be assigned 4 SQL Server core licenses, bringing the total license count to 8 cores.