The evolution of SQL failover licensing to drive SA

Many organisations adopt failover technologies to re-assign workloads from a primary server to a secondary standby server when a production server fails.

Under the legacy product specific licensing terms for SQL server 2008, a standby server that is considered ‘passive’ (and not running any active workloads or reports) would generally not require a license to be assigned under Microsoft licensing. This includes back-up and restore related tasks under the passive designation.

This ‘passive failover rule’  would commonly support situations when a primary server suffers a hardware or software failure (or is taken offline for routine maintenance or patch management) and requires the secondary ‘passive’ server to take over completely for ‘temporary’ support.

A secondary server, that would be utilized solely to maintain a copy of the database and will never take over from the primary does also fall under the ‘passive’ designation. However, the passive failover server rule will only support a single designated passive server under the allowance for each primary licensed server.

The SQL server ‘passive failover rule’ is an important licensing exception, and a principle driver of cost reduction in SQL licensing, but as Microsoft sought to evolve their commercial licensing model to drive revenue growth, and customer purchasing behaviours to secure ongoing predictable revenue through their ‘Software Assurance’ maintenance model, the licensing has evolved incrementally since 2008. This article charts the evolution of SA and the curtailment of the failover benefit to drive that revenue growth and respond to emerging technologies.

The Product Use Rights for SQL Server 2008

As an extract below, from the Product Use Rights (published in July 2010, Page 63 of 136) (the first PUR document after SQL server 2008 R2 general availability) explained the passive failover licensing exception as follows:

“Fail-over Servers. For any operating system environment in which you run instances of the server software, you may run up to the same number of passive fail-over instances in a separate operating system environment for temporary support […]  You may run the passive fail-over instances on a server other than the licensed server.”).

Similarly, illustrated in an extract below, (published in January 2012, Page 58 of 147) the last archived product use rights document for SQL server 2008 R2 before general availability (GA) of SQL server 2012, used almost identical wording and explains the exception as follows:

“For any OSE in which you run instances of the server software, you may run up to the same number of passive fail-over instances in a separate OSE for temporary support […] You may run the passive fail-over instances on a server other than the licensed server.”

The principle licensing tenet established that a licensed primary instance could be supported by an unlicensed passive instance.

This approach was similarly maintained upon general availability of SQL server 2012, and did not appear to explicitly indicate a change in the passive failover server rule.

“Fail-Over Rights […] For any OSE in which you use Running Instances of the server software, you may use up to the same number of passive fail-over Running Instances in a separate OSE on any Server for temporary support.“

[Ref: Product Use Rights, January 2014, Page 37]

Microsoft Published Guidance for SQL Server 2008

Microsoft provided a guidance document, originally published way back in July 2008,  that provided a good insight into the principle logic of server ‘failover rights’, with an extract here as follows:

“When doing failover support, a server is designated as the passive server. The purpose of the passive server is to absorb the data and information held in another server that fails. A passive server does not need a license, provided that the number of processors in the passive server is equal or less than those of the active server. The passive server can take the duties of the active server for 30 days. Afterward, it must be licensed accordingly

[Ref: SQL Server 2008 Pricing and Licensing, July 2008, Page 2 of 5]

The wording of the Product Use Rights and prior published guidance, (published in July 2008),  support interpretation of  the passive failover server rule as actually two separate but ultimately connected allowances under the primary perpetual license.

  1. A right to have running instances which are classified as passive instances in a separate OSE.
  2. The passive instances can be used ‘for temporary support’, (with restrictions)

Operational Logic for SQL Server 2008

Accordingly, the following general principles were established when assessing licensing requirements for passive failover:

  1. There can only one unlicensed passive node for every active node, the licenses assigned to the primary must be sufficient to cover the secondary.
  2. Passive servers do not require licenses to be assigned, but are unable to run any production workloads, but backup and restore related tasks are an important exception.
  3. When database mirroring, the secondary server cannot provide reporting functions.
  4. The backup server can take over during a failure or system maintenance, i.e. hardware or software failure, or routine system maintenance.
  5. The duration of the failover event is for ‘temporary support’, this is commonly interpreted as 30 days.
  6. The server cannot be sequestered for short-term transaction load-balancing.
  7. The passive node must takeover completely, no production workloads must remain, (so all databases must move together for database mirroring or log shipping), both active and passive nodes cannot be in an active production capacity.

The incremental expansion of Software Assurance for SQL Server 2012

Microsoft Volume Licensing eventually communicated a change of how the operational logic of a failover event is conceptually approached, this was later addressed in non-binding advisory guidance 16 months after general availability, this was first presented via the popular TechNet  blog; under the following statement:

“[…] You do not require SA for SQL Server Fail-over Rights, but once you activate the Passive Fail-Over server in a DR then that Passive Fail-over becomes the active server (during a fail-over event) and it must be fully licensed for SQL Server.  You can accomplish this by assigning new licenses to the (now active) passive server, or by reassigning existing licenses from the primary server to the backup server once the instances of SQL Server on the primary server are inactive and no longer performing SQL Server workloads.”

[Ref: This was originally published on the TechNet website, formerly available at: https://blogs.technet.microsoft.com/b/volume-licensing/archive/2013/08/22/licensing-how-to-sql-server-fail-over-vs-cold-disaster-recovery-rights.aspx]

Wherein, Microsoft once admitted “What this means is that your SQL Server 2012 licenses without SA may only be reassigned once every 90 days.  This may not fit your fail-over strategy very well.”

The non-binding advisory content published by Microsoft on the TechNet blog, indicated that under the software use terms for SQL server 2012, during a failover event the primary licensed server would need to have the license reassigned to the passive server at point of failover. The legacy approach, to license only the ‘active’ node of an active-passive SQL server cluster seems to have been curtailed as an extended use right, and would markedly depart from the license precedent of product-specific licensing terms for SQL server 2008 and 2008 R2.

The change in precedent was not explicitly referenced in the first non-binding advisory licensing guide document published two months after general availability in June 2012, and matched the operating logic of former releases:

“The secondary server used for failover support does not need to be separately licensed for SQL Server as long as it is truly passive. If it is serving data, such as reports to clients running active SQL Server workloads, or performing any “work” such as additional backups being made from secondary servers, then it must be licensed for SQL Server”.

“Primary server licenses include support for one secondary server only, and any additional secondary servers must be licensed for SQL Server. Note: The rights to run a passive instance of SQL Server for temporary support are not transferable to other licensed servers for purposes of providing multiple passive secondary servers to a single primary server.”

“When licensing SQL Server 2012 under the Per Core model, the number of core licenses must be based on the server that requires the higher number of licenses. This way, when the failover server takes over, it is adequately licensed. For a passive instance of SQL Server to be properly licensed, it cannot require more core licenses than the licensed primary system”

[Ref: SQL Server Licensing Guide, June 2012, Page 14 of 25]

To explore this nuanced change in wording a little further, in the non-binding published literature I have included the later amended SQL Licensing Guide, published in  March 1st 2013, with the Page 15 extract in full, which formally cemented the expansion of Software Assurance for SQL server 2012:

“Failover Basics / For each properly licensed instance of SQL Server, customers can run a supporting passive instance in a separate OSE for temporary support—that is, to synchronize with the primary server and otherwise maintain the passive database instance in a warm standby state in order to minimize downtime due to hardware or software failure.

A passive SQL Server instance is one that is not serving SQL Server data to clients or running active SQL Server workloads. This passive failover instance can run on a server other than the licensed server.

The secondary server used for failover support does not need to be separately licensed for SQL Server as long as it is truly passive. If it is serving data, such as reports to clients running active SQL Server workloads, or performing any “work” such as additional backups being made from secondary servers, then it must be licensed for SQL Server.

Primary server licenses include support for one secondary server only, and any additional secondary servers must be licensed for SQL Server.

•Note: The rights to run a passive instance of SQL Server for temporary support are not transferable to other licensed servers for purposes of providing multiple passive secondary servers to a single primary server.

•When licensing SQL Server 2012 under the Per Core model, the number of core licenses must be based on the server that requires the higher number of licenses. This way, when the failover server takes over, it is adequately licensed. For a passive instance of SQL Server to be properly licensed, it cannot require more core licenses than the licensed primary system.

•In the event that a passive instance of SQL Server becomes active for any reason, then it must be fully licensed accordingly. This can be accomplished by assigning new licenses to the (now active) secondary server, or by reassigning existing licenses from the primary server (once the primary instances are inactive and no longer performing SQL Server workloads). License Mobility, a Software Assurance (SA) benefit, may allow for more flexibility with license reassignment. For details on reassignment considerations without SA, refer to the Licensing SQL Server for Application Mobility section of this guide.”

[Ref: SQL Server 2012 Licensing Reference Guide, March 1st 2013, Page 15]

The evolution of Software Assurance

Any conflict in interpretation, and likely the crux of the matter, could likely be dependent on  the common interpretation of  the latter evolution of “fail-over rights” for SQL server 2012 as the following core operational logic delineated as follows:

  1. A right to have running instances which are classified as passive instances in a separate OSE.
  2. The passive instances can be used ‘for temporary support’ i.e. 30 days (with restrictions).
  3. At point of failover, the primary licensed server would need to have the license re-assigned to the passive server.

The emergence of the new wording would interpret the passive failover server rule as limited to an allowance under the primary licensed server to run a secondary passive failover server under the ‘passive’ designation, but importantly, at point of failover and the secondary passive failover taking over completely, the license on the assigned primary licensed server is required to be re-assigned.

This much later non-binding interpretation of fail-over rights in the published content, would later have a real impact for  organisations that adopt a 30 day patching cycle and would underwrite an even stronger case for maintaining active Software Assurance (SA) for organisations seeking to enable ‘license mobility within server farms’ to allow re-assignment of SQL Licenses ‘as often as needed’ outside of the restrictive ‘90 rule’.

“Customer may reassign a License to another device or user, but not less than 90 days since the last reassignment of that same License, unless the reassignment is due to (i) permanent hardware failure or loss”.

[Ref: Microsoft Product Terms, April 2019, Page 7 of 115]

The ’90 day rule’ is a license re-assignment restriction that will limit re-assignment of a server license under Volume Licensing more than once in a 90 day period. This will apply to Windows Server, but also will apply to SQL server. The operational logic of affecting license re-assignment at point-of-failover, was to orchestrate the application of the ’90 day rule’ to the passive ‘fail-over right’ for SQL server, and curtail customer’s from electing to have SA lapse, or omit SA at time of purchase.

This was compounded by the previous curtailment of SQL Enterprise Edition ‘license mobility’ in the updated 2012 licensing schema as requiring active Software Assurance to support dynamic re-assignment of a license, rather than enshrined within the perpetual license itself. The evolution of Software Assurance for SQL server as critical for dynamic high availability environments, and the evolution in the operational logic of the passive fail-over rule has had a material impact in creating customer ‘lock in’.

Cementing the role of Software Assurance with SQL Server 2014

Formerly, the SQL server license was assigned to the primary active server, and the primary instance would failover from the active to the passive secondary server for ‘temporary support’, without re-assigning the license from the active to the passive secondary server. Once the failed active server was restored,  the operating logic would support the customer to  switch back from the secondary to the restored active server at any time. It emerged, incrementally with SQL server 2012, that a customer would not need another license for the passive server, however under the 90 day re-assignment rule, the customer was not free to switch from the active primary to the passive sever, and back the restored primary within 90 days. It established the operating logic that a license is re-assigned at point of failover and that without active SA, it would limit ‘license mobility’ to re-assign the license again within 90 days and support dynamic virtual environments.

Later with the release of SQL server 2014, the curtailment of perpetual license rights to install and run the passive SQL server was granted through the new ‘Fail-over Server’ Software Assurance benefit.

Under the SQL server 2014 Product Use Rights, in order to utilize this benefit, you must comply with the following terms:

“Maintain Software Assurance coverage on the server licenses and core licenses under which you run your licensed software and for all CALs under which you access your licensed software.

Your right to run the passive fail-over instances ends when your Software Assurance coverage ends.

Fail-over server rights do not apply in the case of software moved to shared third party servers under License Mobility through Software Assurance.”

[Ref: Microsoft Product Use Rights, April 2014, Page 73]

This incremental evolution in wording was important, in that it enshrined the failover right as a benefit of Software Assurance and not of the perpetual license, with the following update to the operational logic:

  1. A right to have running instances which are classified as passive instances in a separate OSE.
  2. At point of failover, the primary licensed server would need to have the license re-assigned to the passive server.
  3. The passive instance is a benefit of Software Assurance.

SQL server 2014 also later established passive failover within the public cloud as a Software Assurance benefit.

Notably, it was later in December 2015, published in the Microsoft Product Terms, that Microsoft introduced fail-over rights for use on shared third party servers.”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“. [Ref: Microsoft Product Terms, December 2015, Page 82 of 91]. This wording would indicate that, if the licensed primary active instance is on  shared tenancy servers, the passive instance is also required to run on shared tenancy servers with he same provider. Similarly, If the licensed primary active instance is on a dedicated host, the passive instance is also required to run on dedicated hardware. Please be aware that Microsoft does not intend the failover use right to be used for on-premises to 3rdparty shared tenancy failover.

Microsoft positioned the licensing changes for SQL server 2014 as a positive evolution in the licensing model, combining it with ‘License Mobility within a Server Farm’ Software Assurance benefit, to enable their customers address the ‘big gap’ customers had with the 90 day license reassignment rule, wherein they had to maintain the secondary server for 90 days, before they could fail back to the primary active server after a failover event. However, as illustrated in this article, it is a fascinating orchestrated evolution of the commercial model over many years, underwriting double-digit growth and setting the foundation for Azure.

Setting the stage for Azure

The binding failover definition of the Product Terms does initially appear to provide Microsoft with a strong curtailment of the benefit for shared server environments:

Fail-Over Rights:  An SA benefit that allows Customer to run passive fail-over Instances of the Product in conjunction with software running on the Licensed Server, in anticipation of a fail-over event. Passive fail-over Instances may be run in either a separate OSE on the Licensed Server or on a different Server dedicated to Customer’s use. Fail-Over Rights apply only if the number of licenses that otherwise would be required to run the passive fail-over Instances does not exceed the number of licenses required to run the corresponding production Instances. This SA benefit requires SA for the License Server and access license, if any. [Ref: Microsoft Product Terms, April 2019, Page 71]

However, Microsoft did not limit the fail-over use right to only dedicated hardware alone, and ensured the failover benefit was also additive to the Azure Hybrid Benefit for SQL Server,  similar wording was maintained inclusive of ‘shared servers’, as illustrated below, and taken from the same document:

“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.” [Ref: Microsoft Product Terms, April 2019, Page 88]

This was echoed, in the SQL Server 2016 Licensing Guide, June 2016, that the “primary database running on shared hardware in the cloud, you may run the same number of passive SQL Server instances in a seperate OSE running in the cloud on shared hardware to support failover events” [Ref: SQL Server 2016 Licensing Guide, June 2016, Page 22 of 31].

  • Notably, Microsoft confer that , without Software Assurance, both active and passive servers within the cloud environment are licensed.
  • If Software Assurance is maintained, and the active primary is on dedicated hardware, the passive is required to be on dedicated hardware.
  • Similarly, if the active primary is on shared tenancy servers in a public cloud environment, the passive failover server is also required to be on shared tenancy servers with the same partner.
  • Microsoft curtail using the data center provider as the fail-over destination from on-premises.  You are restricted from deploying SQL Server with active SA on-premises to extend the passive fail-over to a third-party data center.

Fail-over under SPLA

For service providers that are licensing SQL server under a SPLA agreement, the binding document confers  support for the fail-over right.The  secondary failover instance can reside on a “Server dedicated to Customer’s use“. Notably, Microsoft confer that “Server means a physical hardware system capable of running server software”.

Accordingly, eligibility should be assessed carefully when the primary and passive fail-over instances are deployed in a multi-tenant shared server environment under SPLA.

“Fail-Over Rights: Permits Customer to run passive fail-over Instances of the Product in conjunction with software running on the Licensed Server, in anticipation of a fail-over event. Passive fail-over Instances may be run in either a separate OSE on the Licensed Server or on a different Server dedicated to Customer’s use. Fail-Over Rights apply only if the number of Licenses that otherwise would be required to run the passive fail-over Instances does not exceed the number of Licenses required to run the corresponding production Instances.”

[Ref: Service Provider Use Rights, April 2019, Page 31 of 33]

Further, the license re-assignment restriction under SPLA is further curtailed under the following wording of the Service Provider Use Rights (SPUR):

“Customer may reassign a License to another device or user, but not during the same calendar month, unless the reassignment is due to (i) permanent hardware failure or loss”

[Ref: Service Provider Use Rights, April 2019, Page 5 of 33]

Final Thoughts

The published guidance on the requirements for Software Assurance would be a subtle, but significant change to how the fail-over rights in the Product Use Rights were interpreted by Microsoft and its subsidiaries for many years. The incremental evolution of SQL server licensing reiterates my  strong recommendation to refer to all binding-documentation, rather than relying solely on non-binding advisory documentation (even Microsoft’s own websites and blogs). While the correct interpretation is commonly shared by experienced licensing professionals, trainers and Microsoft licensing executives, it is valuable to always look directly at all relevant binding (and non-binding) documentation to ascertain the true impact to how the license version, and the role of Software Assurance can impact architecture choices.

The SQL server ‘passive failover rule’ was, and remains, an important licensing exception, and still to some extent, a principle driver of cost reduction in SQL licensing, but as illustrated in this article, as Microsoft has sought to evolve their commercial licensing model to drive revenue growth, and customer purchasing behaviours to secure ongoing predictable revenue through maintaining customers in ‘Software Assurance’, the value of the perpetual licensing asset has been curtailed.

Thanks All


About

This website is a way to give back to the licensing community and as an information resource for all customers that work with Microsoft software and licensing. I hope you find it of value.

Tony Mackelworth is Head of Microsoft Advisory Services at SoftwareONE

If you would like to reach out for a coffee or a meeting under NDA, Email or connect via Twitter or LinkedIn

Copyright – Softspend Limited 2019. All Rights Reserved.