A couple of weeks ago, one of my colleagues and I were discussing some solutions for High Availability and Disaster Recovery in Microsoft SQL Server. However, it seems there was some misunderstanding about Proof of Concepts (POC) among Window Failover Clustering (WSFC), SQL Server Failover Cluster Instances (FCIs) and AlwaysOn Availability Groups.
In this article, I would like to provide basic concepts that can help everyone distinguish what they are and when we should use those concepts effectively.
Windows Server Failover Clustering (WSFC)
WSFC Cluster is a group of independent servers that work together to increase the availability of applications or services. Each server is called a node in a WSFC cluster and if an application fails or services that were hosted on that node crash, then they are automatically (or manually) transferred to another node in the WSFC cluster in a process named Failover.
Before creating a WSFC cluster, we must enable WSFC on our server that provides infrastructure features that support high-availability and disaster recovery scenarios of hosted server applications or services such as SQL Server or Microsoft Exchange. This feature is turned off by default when installing the Windows Server Operating System, so to learn how to enable this feature, click here.
SQL Server Failover Cluster Instances (FCIs) or AlwaysOn Failover Cluster Instances
An FCI is high-availability and disaster recovery solution at SQL Server Instance level, it means SQL Server instance installed across nodes in a WSFC cluster. It leverages WSFC feature to provide local high availability through redundancy at server-instance level.
AlwaysOn Availability Groups
This feature provides high-availability and disaster recovery solution at user-database level. It is similar to the combination between Database Mirroring and WSFC solution. It requires that SQL Server Instance of user-databases resides on WSFC nodes.
Recommended Solution
Both FCI and AlwaysOn Availability Groups require enabled WSFC on nodes in a WSFC cluster, they leverage WSFC functionality. The question when we use FCI and when we use AlwaysOn Availability Groups or when we can combine FCI + AlwaysOn Availability Groups
SQL Server Failover Instances (FCIs) |
AlwaysOn Availability Groups |
|
Required WSFC |
Yes |
Yes |
Protection Data Level |
Instance |
Database |
Storage Type |
Shared |
Non-Shared |
Storage Solution |
Direct Attached, SAN, mount point, SMB |
Depend on node type |
Readable Secondaries |
No |
Yes |
Failed-Over resources |
Server, Instance and Database |
Database Only |
Applicable fail-over for policy settings |
WSFC Quorum FCI-specific Availability group settings |
WSFC Quorum Availability group settings |
The key points are what I highlighted in the table, it is a reference table when we consider using FCIs or AlwaysOn Availability Groups. For example, my customer needs High Availability and Disaster Recovery solution and they are also able to query data on secondaries so I proposed WSFC + AlwaysOn Availability Groups on EC2 of AWS platform.
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.
Comments (0)