Introduction
Microsoft SQL Server 2016 has a pretty decent feature set to achieve cost-effective high availability for your environment and build a reliable disaster recovery solution. Basic Availability Groups (BAGs) and Failover Cluster Instances (FCI) are included in SQL Server 2016 Standard Edition and serve to implement high redundancy level for business-critical databases. In this article, I would like to discuss some differences between these solutions and open the curtain on how it can be done with Software-Defined Storage like Storage Spaces Direct (S2D) and VSAN from StarWind (StarWind VSAN).
Problem
Basic Availability Groups and Failover Cluster Instances features both have their own pros and cons. We will cover some of them.
As you may know, Basic Availability Group does not need shared storage and could be built by utilizing local storage. However, FCI needs shared storage to build a highly available solution. Each Availability Group replica has its own copy of system databases, while FCI utilizes the same shared storage, which can become a single point of failure. Another restriction is a license. You can only protect one database in Basic Availability Group and so if you have more than one database, you need to upgrade the license up to Enterprise Edition. Particular companies have strict requirements to have multiple copies of databases. Thus, the important thing to be noted is that FCI has only one copy of databases and Availability Groups have multiple database copies. Also, when it comes to FCI failover, the additional license may be required in some cases. The main difference in protection context is that Basic Availability Group keeps only database protection while Failover Cluster Instance ensures the overall instance protection.
Solution
Let’s get closer to the Failover Cluster Instance and see how we can overcome its essential problems. As far as you can see from the table above, FCI has two major obstacles:
- Non-usage of local storage
- Having only one local database copy
After applying SDS solution
Storage Spaces Direct and StarWind VSAN can assist us in solving these issues. Both solutions have the same mechanism to clout it by simply creating shared storage from the local repository. In other words, you only need to create a shared storage with S2D or StarWind, deploy a Failover Cluster feature, build the SQL Server Failover Cluster Instance and split it over your nodes. Ultimately, you will have a few instance copies with their own system databases, user databases, all user and administrator logins, resource allocations, etc. Despite all its benefits, Storage Spaces Direct historically has all the features and a proper resiliency staring only from four and up to 64 nodes. In addition, S2D requires expensive Datacenter license which is not so useful for such deployments. On the other hand, StarWind delivers all the cache levels, data locality, multiprotocol, deduplication, and maximum possible IOPS out of the existing setup, with starting configuration just of two nodes.
Conclusion
We can easily set FCI problems aside with the help of modern Software-Defines Storage solutions including such known representatives of this class as Storage Spaces Direct and StarWind VSAN. Both solutions allow us creating Failover Cluster Instance based on the local storage with a few high-available instance copies. The main concerns in Storage Spaces Direct are license and resilience when deployed on small configurations. On the other side, StarWind can be applied starting from a two-node scenario with all the features included, but the decision is yours.
