SQL Server Licensing Strategies for SPLA
Licensing Microsoft server products in any environment can be a challenging undertaking, given the complexity of some of Microsoft’s licensing rules. However, licensing Microsoft products for commercial hosting environments under a Services Provider License Agreement (SPLA) can be especially daunting, due to the different use rights and license metrics available under that model. Licensing SQL Server is perhaps the best example.
Subscriber Access License Licensing SQL Server with SALs is not a viable option unless either (1) the service provider will be able to maintain exclusive administrative control over the credentialing of new users, or (2) all new users will be credentialed and tracked exclusively through a console or other tool that is delivered by the service provider and tied to the provider’s internal reporting tools. Outside of those scenarios, it can be very difficult to track and count users for monthly reporting purposes. Similarly, it also can be difficult to track and count users in the event of an audit, which means that the provider could be exposing itself to significant, unexpected and unnecessary licensing and legal expenses. SALs therefore may make sense for discrete, hosted solutions that are licensed per user, but typically not for cloud hosts or other IaaS providers. (NOTE: It also is important to keep in mind the fact that SQL Server Enterprise edition currently is licensable only per core under SPLA, not per SAL.)
Per Core, by Virtual Server If a service provider cannot satisfy the per-SAL licensing requirements suggested above, then it will need to decide whether it wants to license SQL Server by processor core either according to the processor resources allocated to individual virtual servers or according to the processor resources of physical hosting infrastructure. The former option may make sense if there are a limited number of virtual servers running SQL Server, relative to the total number of virtual servers residing on the physical host server. The reason is the fact that Microsoft requires a minimum of four core licenses per virtual server, regardless of the virtual cores allocated to that virtual server. Therefore, the requirements for licensing individual virtual servers can quickly outstrip the requirements for licensing the physical host, especially if any of the virtual cores in question are mapped to more than one hardware thread, which increases the licensing obligations. In addition, if the service provider is delivering an IaaS solution that allows the customer to create new virtual servers without input from the service provider, this also can be a difficult model to track from month to month and in the event of an audit. (NOTE: This is, in many cases, the only practical option for licensing SQL Server Standard or Web editions by core, since licensing physical servers for those editions per core will only support installations of SQL Server in a physical operating system environment, not on any virtual servers.)
Per Core, by Physical Host The easiest licensing model from an administrative perspective is to license SQL Server Enterprise edition based on the number of physical cores running on the host infrastructure, multiplied by a core factor assigned by Microsoft (to find the current core factors, try an Internet search for: “sql core factor”), for each physical server where any edition of SQL Server may be running. This model will allow an unlimited number of SQL Servers (any edition) to be deployed on the host infrastructure. However, in many cases, this model will be very expensive from month to month, and it may make sense only if the number of virtual servers running SQL Server is – or could be – relatively high (or if the service provider cannot satisfy the conditions suggested above for the other licensing models).
SQL Server licensing is a challenging undertaking that forces a business to weigh the administrative burdens associated with some options against the licensing costs associated with others. In addition, there are other rules associated with SQL Server under SPLA that are not within the scope of the information presented above. When in doubt, consult with counsel or with a knowledgeable and independent licensing consultant.
