Summary
When it comes to cost-efficiency in managing SQL Server licensing, there's a method that ranks second most effective. And, bizarrely, it's not common knowledge.
Licensing Multiple Instances in a Single OS Environment
Imagine one SQL Server instance configured in a particular way and another instance configured differently, each with its unique collation orders, master databases, and schemas. The trick is to deploy these disparate instances within a single operating system environment.
This approach significantly simplifies licensing requirements because, in this scenario, you only need a single SQL license to cover all the multiple instances serving multiple purposes and applications.
The licensing process involves identifying the highest version and edition across all instances in one OSE. For example, if you're running SQL Server 2012 Enterprise alongside SQL Server 2019 Standard, your licensing should be based on the higher version and edition - in this case, SQL Server 2019 Enterprise.
This strategy can be applied to both physical and virtual operating systems. However, remember, it doesn't extend to the host level in virtual environments, as each virtual machine is considered a separate operating system.
Specialised Hardware Clusters: A Game Changer
I've worked with customers who have taken this concept further by building specialised, high-power hardware clusters. This approach is distinct from deploying typical virtual clusters with multiple virtual machines. These specialised clusters house just one operating system but can run multiple SQL Server instances. Optimised for disaster recovery and high availability, such a configuration can include up to four nodes dedicated to SQL Server.
The primary advantage here is licensing efficiency, especially when only two nodes are active. You can even leverage SQL Server Enterprise or Standard licenses in some configurations without needing Software Assurance. This translates into substantial cost reductions, particularly for setups utilising exclusively SQL Server Standard instances.
Maintenance and Security Considerations
From my years as a Database Administrator (DBA), I've observed that maintaining such a setup has complexities. For example, when upgrading or altering one database, you might impact the entire cluster. I don't mean breaking it. It's more about the downtime required to maintain a node.
Another critical aspect to consider is security. Depending on the setup, it might be prudent to run sensitive databases, like payroll, separately.
Performance and Cost Benefits
Performance-wise, these specialised clusters often outperform their virtualised counterparts due to the lack of virtualisation overhead, like hypervisors.
We validated this through tests conducted with a client in the UK, where the hardware cluster setup not only delivered better performance but also led to significant licensing cost savings.
Containerisation and Licensing: A Common Misconception
A common misconception I've encountered involves the use of containerisation technologies like Docker. Some believe that isolating SQL Server instances within different containers in the same operating system environment allows them to be licensed as a single entity. However, this is not the case.
Microsoft's licensing terms clearly state that each container, when used to isolate SQL Server, is treated as a separate operating system environment for licensing purposes. Each container, therefore, requires its own license. This detail is critical and has been a part of Microsoft Product Terms for several years.
Ending on a High Note
While these strategies offer significant benefits in terms of licensing cost reduction and operational efficiency, they require careful consideration and a thorough understanding of SQL Server licensing rules.
By adopting such approaches and being mindful of Microsoft's licensing stipulations, you can optimise your SQL Server environments both financially and functionally.
If you'd like to discuss it further, please message me using this form: