Month: January 2019

Understanding the basics of SQL Licensing

Ever find yourself confused about how SQL licensing? If you have, welcome to the club! There are so many components to it that it can get crazy fast. The information in this article lays out some of the more important aspects of SQL licensing to be mindful of, as well as, situations where you may want to consider each. For this article, I am using the latest information from the SQL Server 2017 licensing guide. So any old timers out there that are still on a grandfathered plan then you will need to work with your rep.

SQL 2017 Licensing Guide

I highly recommend working with Microsoft or a 3rd party re-seller to obtain licenses and talk with them about your plan. Additionally, I also recommend getting any information they give you in writing. Unfortunately people make mistakes on this topic and things can get miscommunicated and you do not want that.  There are tons of horror stories where someone built there licensing structure on something that turned out to be wrong.

Disclaimer: I do not work for Microsoft or any 3rd party approved re-seller. I am just a guy who has spent a lot of time working on this subject sharing information I have learned with you.

Starting from the beginning let’s look at the primary editions of SQL and the differences between them. It is important to make sure that you are picking the correct one when installing SQL due to the licensing implications.

There are 5 primary editions of SQL Server that are currently available

    • Enterprise ($$$$) – This is the full version with no limitations. Should only be used when Standard does not meet the requirements for what you need
        • Cost: MSRP for a single Enterprise license (which covers 2 cores) is $14,256. The cost could be lower with your Microsoft enterprise agreement. Check with your licensing manager for exact costs
    • Standard ($) – Some enterprise functionality not available although will work for most stuff
        • Cost: MSRP for a single Standard license (which covers 2 cores) is $3,717. The cost could be lower with your Microsoft enterprise agreement. Check with your licensing manager for exact costs.
    • Web ($) – This version is somewhere between Standard and Express in terms of features. This is used for web hosters and Web VAPs and is only availible under the Microsoft Services Provider License (SPLA)
        • Cost: Speak to your rep about the costs here
    • Express (free) – A free version of SQL that has several limitations
        • Cost: Free
    • Developer – This is the full version of SQL, but should exclusively be used in non-prod. Starting in SQL 2014, Microsoft made this free. If you are running earlier versions you may be covered under a Visual Studio or MSDN subscription otherwise you need to speak to your licensing rep to see if there is any costs here. I will create a separate post specific to this subject.

Ways to license 

When looking at how you can license each of these are a handful of models to be familiar with for SQL. While this article does not specifically apply to Azure, a lot of this information does apply, although, there are additional options in Azure.

There are 4 ways that you can license a production SQL Instance

    1. License the Physical Hosts for virtual environment by physical cores (Limited to Enterprise edition) – This means that you license all physical cores on each server in a virtual cluster
    2. License a Physical server by physical cores (non-virtual) – This means that you all license all physical cores on the physical server for the version of SQL that is running on it.
    3. License the individual VM’s by virtual cores – In a virtual environment, you can license each individual VM with the version of SQL that you are running.
    4. License using server + CAL (limited to Standard edition) – This means that you must assign a license to the server running SQL Server and acquire a CAL for each user or device that accesses the server

There are a few other caveats to SQL licensing that you also need to be aware of.

Other important notes about licenses

    1. 1 license equals 2 physical cores. On a VM, 1 license equals 2 virtual cores.
    2. There is a 4 core minimum per physical processor. This means that there is a 2 license minimum per physical core. For a VM, you license the virtual cores with a 4 core minimum.

Software Assurance

In addition to the licensing you apply, there is also software assurance to consider. Software assurance is typically around 30% the cost of the license and is paid yearly. Although this is more of a starting point and can be lower, you need to work with your rep on this. Also, be aware that if you have this and drop it, then it cannot be added back a later time. To reclaim software assurance you need to re-buy the licenses.

Here are some of the benefits\reasons of why you want to consider getting SA on all licensing purchases.

Benefits of Software Assurance (SA)

    • Upgrade – Gives you the ability to upgrade SQL to any version (up to the latest).
        • Without SA you are limited to the latest version of SQL released when your SA expired
    • Virtualization – Have the ability to move servers around a virtual environment without needing to license the hosts
        • You cannot have a Virtual environment without SA unless you license all physical hosts
    • High Availability and Disaster Recovery – For high availability you can now have multiple passive (local, DR, and in the cloud) without additional licenses needed. Previously, you were limited to 1 passive per paid active. The standby nodes do have to truly passive and cannot be used for any type of production workload.
    • License Mobility – Ability to transfer licenses
    • Support benefits 
    • Training and deployment planning services (sometimes)

Looking at each of the Licensing models deeper

Here is a deeper explanation of each of the licensing models and the pros\cons of each.

License using server + CAL

CAL licenses can be purchased for servers running Standard edition only. It is usually used when the number of clients (user or device) is pre-determined. To license for this you have to pay a server license plus a fee for each Device or User CAL. Check with you licensing manager for cost.

License a Physical server by physical cores (non-virtual)

This one is pretty self-explanatory. If you are running SQL on physical servers you will need to license the physical cores of the servers they are running on. If you are running a passive\standby physical node then that would be covered under SA or have licenses applied if you do not have SA.

    • Be aware there is a 4 core minimum per physical processor.
    • You do not have to license for hyper-threading just the actual physical cores. Be sure to double check this. The value that SQL Server is not always right because it will include hyper-threading so be sure to check to see the actual physical core count.

Licensing the Physical Hosts for virtual environment by physical cores

Pros:

    • Easier to manage since you apply the licenses to the hosts. You can build whatever you want on it without needing to track as much
    • This model “can” function without software assurance (though could affect other things)
        • If you have a lot of licenses that do not have SA then you may want to look at using this as an interim solution
    • You can “potentially” save money by using hyper-threading, private cloud scenarios with VM density and using dynamic provisioning and de-provisioning of VM resources

Other Considerations:

    • This model can function without Software assurance as long as the number of VM’s do not exceed the physical core count. For example, if you have 40 physical cores then you can only run 40 virtual machines. If you go over the limit then a Enterprise license is required for each additional Virtual machine you are over
    • With software assurance, you can run as many Virtual machines as you like without limit
    • This option is oftentimes more difficult to quantify costs for projects\budgets. It is more difficult to communicate the cost for an application requiring SQL since it is shared by many things. This comes into play when you need to determine who is responsible for paying for what or whose budget it comes out of
    • You may end up paying for licenses then you are using. To come out ahead you have to have more licensed number of cores on the VM’s then you have on the hosts.
    • Must have a well-managed\well-designed infrastructure to maintain compliance.
        • You probably want to segregate SQL servers in your environment to dedicated virtual hosts to minimize your footprint. This requires consideration to be taken in the design stages of your infrastructure. Additionally, if you have some licenses that go up to SQL 2012 and others that go up to SQL 2014, then you may have to create dedicated Virtual clusters to host certain versions of SQL.
    • Limited opportunities to reduce licensing footprint. You cannot tune\consolidate a SQL Server and reduce the core count on it and affect the licensing, because you still have to license all of the hosts in the virtual cluster despite what is allocated to the VM’s.
    • Potential for more hardware needed to support this licensing model. If you have to create several different virtual clusters to contain different SQL versions you could end up requiring more hardware then what you need.

Recommendation: Do not select this option by default. I have worked with and seen several companies choose this option and cost themselves a significant amount of money that did not need to be spent. In fact, I think this is one the biggest mistakes I have seen in terms of licensing. There are situations where it makes sense, but not for everything. If you are unsure, perform an exercise to look at the math and see if it makes sense. Check yourself!

License the individual VM’s by virtual cores

Pros:

    • Usually the lowest cost option and the better option from what I have seen. The reason being is it’s less common to see more licensable cores being allocated to the VM’s then what the hosts have. Additionally, it is likely that you may be running multiple editions of SQL (Standard\Enterprise) on the same cluster.
    • Cost is more easily determined for budgeting\spending. It is easy to communicate the cost to the business when a new SQL VM gets built since you know exactly how many licenses it needs.
    • You are only playing for what you need.
    • Grants immediate opportunity to reduce licensing. You can tune\optimize as much as you can and reduce cores. As you reduce the cores, you can reduce the licenses needing to be allocated to it.

Other Considerations:

    • Licenses have to be managed per VM to remain in compliance. This requires you to keep track of your inventory to understand how many licenses are allocated. There is a little more management here over licensing the hosts. You cannot just build something anytime you want and expect to be in compliance.
    • Software assurance is required if the virtual server can move around on hosts.
        • You can license per VM without SA, but you can only failover that server once every 90 days to remain compliant (excluding permanent hardware failure)

If are unsure the best model for you, CHECK!

In my experience it is almost always a cheaper option to license per individual VM then it is to license the host. However, if you are unsure I would encourage you to do an exercise where you look at how many licenses you would need for the host vs how many you would need to license the VM and determine your cost difference.

Future Topics:

  1. What does building an inventory look like and how can you accomplish this? What tools are available?
  2. Advanced scenarios with licensing where you do not have software assurance
  3. Specifics to licensing a non-production environment
  4. Licensing for Analytic Platform System (Parallel Data Warehouse)
  5. Further licensing considerations with High Availibility
  6. SQL licensing in Azure
  7. Tools that you can use to better manage your licensing