AWS and SQL Server fail-over ¦ PART 5
Is passive fail-over freely licensed for SQL Server?
The answer is it depends, because the rights granted have changed significantly and repeatedly over the last 12 years.
Previously, e.g for SQL Server 2008 and 2012, the primary license for the active instance automatically gave a (free) license to an equivalent passive fail-over instance on another server.
The rules have, over the years, changed for every edition. Now, to know the correct contractual position, regard needs to be had to both the original SQL Server rules for the particular edition when released and the applicable Product Use Rights or Product Terms, from release and now.
The latest edition is SQL Server 2019, with the licensing position  (as at November 2019) for this as follows:
Are passive instances automatically included?
In general, no passive instances may be assumed to be permitted, unless separately licensed.
No fail-over rights unless managed by SQL Server Parallel Data Warehouse;
However, with Software Assurance, fail-over rights are available for the following:
- Fail-Over servers for disaster recovery: Allows customers to install and run passive SQL Server 2019 instances in a separate OSE or server for disaster recovery in anticipation of a fail-over event
- Fail-Over servers for disaster recovery in Azure: Allows customers to install and run passive SQL Server 2019 instances in a separate OSE or server for disaster recovery in Azure in anticipation of a fail-over event
- Fail-Over servers for high availability: Allows customers to install and run passive SQL Server 2019 instances in a separate OSE or server for high availability in anticipation of a fail-over event
No distinction is drawn as to how the high availability is implemented, whether Log Shipping, Always On SQL Fail-Over Cluster Instances or Always On Availability Groups.
What is a ‘passive’ SQL Server replica?
Answer: ‘one that is not serving SQL Server data to clients or running active SQL Server workloads’.
The passive fail-over instances can run on a separate server. These may only be used to synchronize with the primary server and perform the following maintenance-related operations for the permitted passive fail-over Instances: Database consistency checks; Log Back-ups; Full Back-ups.’
Can shared servers be used?
Confusingly, the Product Terms elsewhere indicate that shared servers can it seems be used:
For Products that are also granted Fail-Over Rights, Customer may run passive fail-over Instances on the qualifying shared servers in anticipation of a fail-over event. The number of licenses that otherwise would be required to run the passive fail-over Instances must not exceed the number of licenses required to run the corresponding production Instances on the same partner’s shared servers.
However, it appears that this is intended to cover the scenario where the licenses are made available to a shared environment e.g within EC2 using License Mobility: Microsoft’s SQL Server 2017 Licensing Guide states this:
In the case where you are using License Mobility to license your primary database running on shared hardware in the cloud, you may run the same number of passive SQL Server instances in a separate OSE running in the cloud on shared hardware to support failover events.
Can you rely on the SQL Server Licensing Guide?
It must be noted that the SQL Server Licensing Guide is a guide only (stated as ‘This document is for informational purposes only’) and is not legally binding.
For the correct position, one must rely only on the Product Terms in place when the product was first acquired. This declares, fundamentally, that ‘If Customer complies with its volume licensing agreement, it may use the software as expressly permitted in the Product Terms’.
So, it is this document that is central to what a customer can do.
What are the use rights for SQL Server Enterprise?
For SQL Server Enterprise, the primary use right is this: ‘Customer may run any number of Instances of the server software in up to four OSEs on the Licensed Server at a time’.
The key here is ‘the Licensed Server’: one license only covers one server – so that covers the primary usage only: no additional fail-over or high availability instances are included.
The latest Product Terms (December 2019) however enlarges the rights for SQL Server 2019 where Software Assurance is in place:
4.2 SQL Server 2019 – Fail-over Rights
For each of its Primary Workloads, Customer is entitled to:
- One Fail-over OSE for any purpose, including high availability, on any Server dedicated to Customer’s use (subject to the Outsourcing Software Management clause); and
- Two Fail-over OSEs specifically for disaster recovery purposes:
- one on any Server dedicated to Customer’s use (subject to the Outsourcing Software Management clause) and
- one on Microsoft Azure servers
Customer may also run Primary Workloads and its disaster recovery Fail-over OSEs simultaneously for brief periods of disaster recovery testing every 90 days. Customer may perform the following maintenance-related operations for any permitted Fail-over OSE:
- Database consistency checks or Checkdb
- Log Back-ups
- Full Back-ups
- Monitoring resource usage data
The difference with Azure
So, a clear distinction is drawn between whether or not you utilise Azure. The Licensing Guide confirms this:
‘The secondary passive server can also be setup in Azure for Disaster recovery with no additional SQL Server licenses required. Customers will only have to cover for the compute costs for VM/server used for passive replica’.
What ‘fail-over’ is licensed?
The Product Terms also make it clear what limited fail-over is included.
Fail-over OSEs permitted for disaster recovery must be asynchronous and manual. Fail-over OSEs may not serve SQL Server data to users or devices or otherwise run active SQL Server workloads. The number of licenses that otherwise would be required for a Fail-over OSE must not exceed the number of licenses required for the corresponding Primary Workload. These fail-over rights require SA for both the Licensed Server and CALs, if any, and do not apply when Customer deploys SQL Software under License Mobility through SA.
The base right then is for one fail-over OSE on any server dedicated to the customer
By contrast, if Azure is utilised, then the right is for one fail-over OSE on dedicated server dedicated and, also, one Fail-over disaster recovery OSE on Microsoft Azure servers.
Can you use AWS for fail-over from on-premise?
There is no technical reason why AWS EC2 could not be the fail-over destination from your on-premise database/programs – provided it is to ‘a Server dedicated to Customer’s use’ (see the Cerno Guide on this ‘Moving Microsoft to AWS: the licensing issues Part 2’.
There are also diagrams showing (e.g on p.27 of the Microsoft SQL Server 2017 Licensing Guide and on p.29 of the 2019 Guide) indicating that a fail-over, passive in the cloud, simply needs the same number of licenses as the active primary server.
That guide (for Microsoft SQL Server 2017) declares that
‘The passive fail-over instances can run on a separate server. … The secondary server used for fail-over support does not need to be separately licensed for SQL Server as long as it is truly passive, and the primary SQL Server is covered with active SA…’
but not mentioning any restriction to on-premise backing to cloud.
For SQL Server 2019, the Licensing guide uses this wording:
The secondary passive server can also be setup in Azure for Disaster recovery with no additional SQL Server licenses required.
…but what is the position for use, outside of Azure e.g in AWS?
The guide states ‘All the three passive secondary replica benefits can be used simultaneously as long as the on-prem primary is covered with SA’ with the primary instance being shown as on-premise and the failover being shown as ‘Passive in the Cloud’.
Certainly the position is not clear but we cannot find any explicit wording, in the document or in the Product Terms regarding this prohibition.
What is permitted with a passive fail-over?
It is critical to understand the difference between being allowed to have running, in readiness, a passive fail-over instance, and the position when the passive instance then becomes active.
As described above, passive fail-overs are permitted, with no additional licensing, with software assurance. However what happens when that fail-over occurs? Under Microsoft’s general rules, the primary license can be (and indeed must be) assigned from the original to the fail-over provided that any switch does not occur more often than every 90 days (unless there is permanent hardware failure or loss).
If software assurance is in place, then more latitude is given (see Moving Microsoft to AWS: the licensing issues: PART 3: Shared Environments).
Here, license mobility is granted – the right to move licenses to a customer’s other licensed servers as often as needed:
‘License Mobility Across Server Farms: Under License Mobility Across Server Farms, Customer may reassign any of its Licenses which are designated as having License Mobility and for which it has SA to any of its Licensed Servers located within the same Server Farm as often as needed’.
It is still the case that reassigning the license does not mean that both original and new server can run in parallel. The license is assigned – not duplicated. The (former) passive node must take over completely and use of both for production purposes is not allowed unless of course additional licenses have been purchased.
It might be thought that a simple question as to whether fail-over is licensed for SQL Server might have one simple answer. But, as may be seen, much depends on the version used, the applicable product terms, whether software assurance is in place and whether if fail-over to the cloud, Azure is utilised.
Cerno Professional Services Ltd