Microsoft SQL Server Licensing For Dummies.. 

Don’t let the above title fool you!  Have you been confused on the Microsoft SQL Server Licensing requirements?  Per Processor, Per CAL, Per Core, Per Socket, Per Node – Per haps (space intended :-), we should revisit the issue again, and try to offer some assistance as you go forward in making your purchasing decisions.  While I would like nothing more than clarity to prevail, I can’t offer guarantees - just some links and discussions that may help in most scenarios.

At the end of this article, you may have even more questions, and some lasting vagueness, but don’t feel too bad - even the folks from Microsoft aren’t 100% sure what the right licensing requirements are for your implementation!  And, that’s after Microsoft said not too long ago, that we’re making the license requirements easier to understand. 

OK, maybe we’ll have some answers for some straightforward installations, but in certain failover scenarios, the debate rages on about how many licenses we actually need. 

To quote one potential Microsoft customer who was searching for answers in planning for his highly available failover infrastructure “We had the conversation with Microsoft [and], never really got a definitive answer to it. One rep said we needed more licensing; the other didn't, then change their minds.”

Let’s focus on the latest publicly available versions, SQL Server 2008 and SQL Server 2008 R2.  So, to be fair, Microsoft did implement what’s called per processor, or processor-based licensing model.  According to Microsoft’s 2008 Pricing and Licensing Sheet, they offer a processor-based licensing model to help alleviate complexity. Processor licenses can be used for any type of application (not limited to Web-based scenarios).  The official definition of this type of licensing is offered below:

Processor License. A Processor License is required for each processor installed on each operating system environment running SQL Server or any of its components (for example, Analysis Services). It includes access for an unlimited number of users or devices to connect from either inside or outside the firewall. Customers do not need to purchase additional client access licenses (CALs) when licensed under the per processor model.

Processor licenses are available in Enterprise, Standard, Web and Workgroup editions and offer more simplicity for certain scenarios.

As you can see in the paragraphs above, I highlighted some key words: “alleviate complexity” and “more simplicity”. Reminds me of oxymorons like “jumbo shrimp” and “preheat oven” Well, even under the processor-based licensing, we need to know what the definition of a “processor” is.  Of course, we know “processor” is interchangeable with “CPU”.  Now we have Dual Core, Quad Core/Multi-Core, Hyper threading, and what about Virtual Machines (VM) as well?  Have a headache yet?  Well, it gets more fun! J

Hyper threading (if enabled), allows multiple threads to execute on a single physical CPU appearing as two logical processors.  Dual Core is where a single CPU socket that has more than 1 core appearing as multiple logical CPUs.  Extrapolate this for a 2 Quad Cores, we have a single CPU socket with 4 logical CPUs x 2 + (hyper threading on) x 2 = 16.  Visually, we have 16 logical processors showing up in task manager.   Now, take an exact hardware replica of this configuration and create an Active/Passive failover cluster.  We have two nodes (so far 🙂 and 32 logical processors in the mix.

So, in this first scenario, how many licenses do we need here?  First, we need to know that regardless of the number of cores that a CPU has, Microsoft will only charge you for the number of physical CPU/sockets.  Maybe we ought to call it per socket licensing.  Therefore, as in the scenario above, we would only need to licenses based on 2 physical processors per server.  (ie: 2x$the price of a license)  You may also want to check out the upper limit of what your intended edition supports.  Here is a good explanation on licensing a SQL Server Standard Edition, which supports up to 4 CPUs.

But, wait a minute, are you responsible for licensing BOTH the Active and the Passive nodes?  I mean, all my passive node is doing, is waiting around collecting dust, and we hope we never have to failover to that box.  Isn’t that a great cost to incur for such a large paper weight that generates cooling and energy costs of its own?  And what if I throw in a couple of other servers, and implement Log Shipping and Database Mirroring for good measure.  How much is this going to cost?

Think it’s redundant? Well, that’s the length’s many will go to ensure high availability, failover and business continuity, and just another term for redundancy anyway.

Microsoft has a section designated for PASSIVE SERVERS / FAILOVER SUPPORT, defined as:

Two or more servers, each running SQL Server, can be configured such that if one server fails, its processing will be picked-up, recovered and continued by the other. SQL Server 2008 offers 3 types of failover support:  1) Database Mirroring; 2) Failover Clustering; 3) Backup Log Shipping.

Let’s first examine the instance of licensing an Active/Passive Failover Cluster.  For SQL Server 2008 R2 Small Business, SQL Server 2008 R2 Enterprise, SQL Server 2008 R2 Standard and SQL Server 2008 R2 Workgroup failover rights are defined as:

“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.”

That seems pretty straightforward. While there is some disagreement in some circles, about the above definition in having multiple passive instances, I am very confident that this is defined as a 1:1 relationship.  That is, if you have 1 Active instance, and 2 Passive nodes, only the first passive server is considered covered as a free license. 

Here is more info on Product Usage Rights (PUR) in this page on About Licensing, from Microsoft.

Therefore, as Microsoft answers in its 2008 licensing frequently asked questions section, failover support, where servers are clustered together and set to pick up processing duties if one computer should fail, keeping a passive server for failover purposes does not require a license as long as the passive server has the same or fewer processors than the active server (under the per processor scenario). In the event of a failover, a 30-day grace period is allowed to restore and run SQL Server on the original active server.  Failover support is available in Standard and Enterprise editions of SQL Server 2008.   So, for all intents and purposes, the short answer is “NO” - you do not need a license for the passive server.

But, what if we add log shipping?  In this scenario, we are log shipping from the Active node, as the primary, to the Passive node, as the standby.  The confusion here may lie in the terminology.  Most DBA’s are used to the term “passive” to indicate the non-active node on a failover cluster, but remember as defined above, “if one server fails, its processing will be picked-up, recovered and continued by the other”  So, “passive” can include the Log Shipping Standby, or the Database Mirrored Secondary server.

The question answered here is, if I am doing log shipping in an active/passive failover configuration, how should I license the backup server?  In this scenario, the passive server does not require a license, unless the passive server has more processors than the active server, and the active server is licensed under the per processor model.  Again, it seems that we only need to license the Active node in this case.  Here are some example failover configuration scenarios:

Some other questions, that are worthy of mentioning is support and licensing for multiple instances.  As we know that one physical server or node can host multiple instances, many still wonder how many need to be “licensed”.  If we’re keeping to the processor-based licensing, then you can run an unlimited number (as supported by the HW) of instances under this license scheme.   The FAQ does also talk about multi-instance licensing. “In SQL Server 2008, you can run multiple instances with the Workgroup, Standard, and Enterprise editions when they are licensed server/CAL or on a per-processor basis.  Please read the SQL Server 2008 Licensing Overview for more information.”

We asked earlier about deploying SQL Server in virtual environments.  Let’s take a look at the MS answer under the headline:  How do I license SQL Server 2008 for my virtual environments?

A: For Standard, Workgroup, and Enterprise, if you decide to license on a per processor basis, you must buy a SQL Server license for each virtual processor. For Enterprise Edition, you can also choose to license all physical processors in a box. This gives you rights to run SQL Server on any number of virtual processors running on the same physical server. If you use Server/CAL based licensing, for Standard and Workgroup editions, you must obtain SQL Server licenses for each Virtual Operating System Environment on which you run instances of SQL Server. However, for the Enterprise edition, if you have a Server license for the physical Server, you may run any number of SQL Server instances in any Virtual Operating System Environment that you run on that same physical serve

UPDATE: Virtual Licensing for SQL Server 2008 R2.  As many in the community were kind enought to point out, and I didn't originally include in this blog, is that there are some big and significant changes to the virtual licensing model in R2.  Important enough, that I decided to update this blog, so folks searching the net and hit this site, will have the latest and accurate info.  Even though I referenced it in the comments, it didn't seem enough.

In R2, unlimited virtualization of sql now requires the Datacenter Edition per processor. Apparently, Enterprise Edition only gets you 4 virtual machines, not unlimited.  There are also some changes around the per core and socket licensing.  For more info, there was this excellent article on InfoWorld.Com, entitled, "Microsoft changes SQL Server 2008 R2 virtualization licensing", that discusses this at length.

 ----------------

Hopefully, the above make sense, and the information is helpful in those different cases that might affect your deployment and purchasing strategy.  Clearly, there are more questions, and always varying implementations.  I tried to point out some of the standard and non-standard ones, as relates to failover scenarios and explain some of the definitions that will clarify what they’re talking about.  The recommendation is to contact your local MS representative and verify with them – although this proves that it’s better to contact two reps – and probably get three opinions. J 

Perhaps, the true test is to invite a licensing auditor into your shop, since they have the authority to say who is in compliance and who is not.  After all, in Baseball, if the ball gets lobbed into the stands, and the Umpire calls a strike, it’s officially a strike!  Since none of us will rush invite the auditor, hopefully this resource will serve as the best we have to answer most, if not all our licensing questions. 

Here is the official SQL Server 2008 Licensing Frequently Asked Questions.  I think this should enlighten most of you on the topic.

Robert Pearl