There are many ways to setup High Availability and Disaster Recovery, most of which are focused on SQL Server Enterprise edition. However, the licensing for Enterprise edition gets costly fast. One less talked about approach to building a cost-effective HA/DR solution is building a failover cluster instance using SQL Server Standard with SIOS Datakeeper.
SQL Server Standard edition over SQL Server Enterprise edition
Not every application and database need all the features of SQL Enterprise edition so why pay for those features if you aren’t using them. SQL Server Standard edition is a powerful database management system that costs almost one quarter the cost of SQL Server Enterprise edition. If your application and database can run within the confines of SQL Server Standard edition there are some significant cost savings that can be made. Straight Path has even helped customers migrate from Enterprise to Standard edition with no impact to performance. This saved the customer money in license fees and in some cases created a better HA/DR configuration.
As you can see in the table below the cost savings between Enterprise and Standard is about $20,000 on a 4-core server. For argument’s sake, if you currently have a Failover cluster with SQL Server Enterprise and you wanted to migrate to SQL Server Standard with SIOS; all told you’re saving about $15000. I have yet to come across an accountant that doesn’t want to save money. You may even be able to talk your boss into throwing you 1-2% of those savings so you can take the family out for a nice dinner.
| CPU Count | Enterprise | Standard | SIOS License | |
| NodeA | 4 | $27,496 | $7,172 | $2500 |
| NodeB | 4 | $0* | $0* | $2500 |
SIOS Datakeeper
Now let’s talk about SIOS Datakeeper and what it does. SIOS Datakeeper is a third-party tool that is installed on your SQL Server and is responsible for keeping the drives on your secondary server in sync with the drives on your primary server. SIOS does this by locking the drives on the secondary server and using storage level replication from your primary server over to your secondary server to keep the drives in sync. This way your secondary server is always ready to become the primary server to host your instance of SQL Server.
Failover clustering with SQL Server and SIOS DataKeeper
One key part of this configuration is your SQL Servers are part of a Failover Cluster install. SQL Server Standard edition can be used in a failover cluster with the main limitation being that you can only have 2 nodes in the SQL cluster. Most configurations are perfectly fine having only 2 nodes because the second server is there in case something happens to the primary server, or you want minimal down time for server patching.
For the purposes of this article, I will skip over all the details of building a Windows cluster and installing SQL Server. Instead, I will highlight the important differences when using SIOS Datakeeper.
- Each server in the cluster needs it own set of drives.
- When you are adding the servers into the cluster you do not want to add all available storage. SIOS will handle adding the storage into the cluster during the install and configuration.
- After the Windows servers are clustered is when you want to install and configure SIOS. This is important because when installing a failover cluster instance of SQL it needs drives that are part of the cluster.
One point I really want to emphasize is that each server needs its own drives. This is an important detail because it allows you to have a failover cluster that does not have a shared storage component. The traditional failover cluster requires that the servers have access to the same storage volumes. With SIOS Datakeeper the shared storage requirement is removed, and this allows you to enhance your disaster recovery plans. One key benefit of not needing shared storage is you can build a failover cluster in the cloud.
Bringing it all together
Here is an example of how we can put these two technologies together. For a moment pretend your primary datacenter is in an area that is prone to tornadoes. If you have a traditional failover cluster configured in your datacenter what happens if the datacenter loses power? Or worse, what if the datacenter is in the path of destruction? If both servers are in the same physical location because they need access to shared storage, the redundancy of a failover cluster isn’t very helpful. If I were in this scenario, I would be doing regular testing of the companies restore strategy because eventually you’re going to need it. An alternative scenario is you have a second server in a datacenter which is 50+ miles away that is being kept in sync with SIOS Datakeeper. The likelihood of both datacenters being hit by the same storm is dramatically reduced because they are geographically disbursed. Now, I’m not advocating working during a tornado because if you live in an area that is frequented by tornados you should be taking shelter with your loved ones. But, if you were out of the storms path and you had connectivity into your datacenter you could fail the cluster over and your company’s data would be out of harms way.
There are many ways in which you can build a reliable HA/DR configuration; for example you could do something similar with Availability Groups and SQL Server Enterprise edition. The problem is not everyone wants to, or can, pay for SQL Server Enterprise edition and more importantly not everyone needs Enterprise. What everyone does need though is a rock solid disaster recovery plan. Using SQL Server Standard edition with SIOS is one of the ways we help our clients to: save money, build a highly available environment, and have a rock solid disaster recovery plan.
