As anyone who has ever worked with any Microsoft Enterprise-Class software can tell you, Microsoft Licensing can be complicated. Add in Software Assurance, Enterprise Agreements, Multiplexing, Virtualization, and HA Technologies and it gets even worse. Sometimes you can even get experts from Microsoft that cannot clear it up for you. I have found that the best way to address Microsoft Licensing is on a case-by-case basis. However, there are a few cases that are both broad enough and common enough, as to warrant some decent documentation. I believe my recent experience qualifies as one of those cases.
We have been planning to add a new node to our primary SQL cluster. This particular cluster has grown over the last few years at a fairly steady clip. It started out as an Active-Passive Cluster, covered by a single Enterprise Per-Proc license. As time went on, I realized that we needed to start splitting some of that load onto two nodes, so that would mean bringing that Passive node into active duty, which, of course, would require the purchase of an additional Enterprise Per-Proc license. No big deal, we had budgeted for it and we were ready to go in no time. Shortly after that, I added a single node at our DR site, which was the SQL Mirroring Failover Partner for the cluster. This provided the hardware redundancy we wanted at the primary site (because a single node could handle the load of the entire cluster, if needed) and the logical redundancy we needed at the DR site. All was well, and everything was legal.
Well, now it is time for a third node. We still have enough horsepower and RAM to support all of the instances on the two nodes for quite a while, but the database requirements have grown enough that I wouldn’t feel comfortable if the entire workload had to perform on a single node, should the other node fail. So, I need to add a passive node. Additionally, this would require turning that one DR node into a two-node cluster at the DR site. This is where I had a lesson to learn.
Due to several documents I had read, from Microsoft (including the 2008 SQL Licensing Overview document), I had come to the conclusion that the passive node in an Active/Active/Passive cluster did not require its own license (which is true) and that a passive mirror did not require its own license (which is also true). However, I had misunderstood the actual meaning of the PUR‘s statement, “”. It turns out that each licensed node can only ever cover a single passive node (either a cluster node or a mirror, not both). This is quite clearly delineated in the Microsoft Software License Terms for Microsoft SQL Server 2008 R2 Enterprise, Section 4, paragraph e, which states:
Fail-over Server. 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. If you have licensed the server software under the Per Processor licensing model, the number of processors used in that separate operating system environment must not exceed the number of processors used in the corresponding operating system environment in which the active instances are running. You may run the passive fail-over instances on a server other than the licensed server.
Meaning, If you have a total of only two Enterprise Per-Proc licenses, you cannot have more than two total servers acting as some form of failover against those licenses.
So, to help visualize this:
My solution was to go ahead and bite the bullet on buying the third license and using my production cluster in an Active/Active/Active setup, in which any two of the nodes could support the load of all three. In some shops, however, this may be a reason to hold off buying another node for your cluster, depending, of course, on your specific needs.
