Failover Clustering and Always On Availability Groups (SQL Server)
Published: May 13, 2016
Updated: May 17, 2016
THIS TOPIC APPLIES TO: SQL Server (starting with 2016)Azure SQL DatabaseAzure SQL Data Warehouse Parallel Data Warehouse
Always On Availability Groups, the high availability and disaster recovery solution introduced in SQL Server 2016, requires Windows Server Failover Clustering (WSFC). Also, though Always On Availability Groups is not dependent upon SQL Server Failover Clustering, you can use a failover clustering instance (FCI) to host an availability replica for an availability group. It is important to know the role of each clustering technology, and to know what considerations are necessary as you design your Always On Availability Groups environment.
In This Topic:
Deploying Always On Availability Groups requires a Windows Server Failover Clustering (WSFC) cluster. To be enabled for Always On Availability Groups, an instance of SQL Server must reside on a WSFC node, and the WSFC cluster and node must be online. Furthermore, each availability replica of a given availability group must reside on a different node of the same WSFC cluster. The only exception is that while being migrated to another WSFC cluster, an availability group can temporarily straddle two clusters.
Always On Availability Groups relies on the Windows Failover Clustering (WSFC) cluster to monitor and manage the current roles of the availability replicas that belong to a given availability group and to determine how a failover event affects the availability replicas. A WSFC resource group is created for every availability group that you create. The WSFC cluster monitors this resource group to evaluate the health of the primary replica.
The quorum for Always On Availability Groups is based on all nodes in the WSFC cluster regardless of whether a given cluster node hosts any availability replicas. In contrast to database mirroring, there is no witness role in Always On Availability Groups.
The overall health of a WSFC cluster is determined by the votes of quorum of nodes in the cluster. If the WSFC cluster goes offline because of an unplanned disaster, or due to a persistent hardware or communications failure, manual administrative intervention is required. A Windows Server or WSFC cluster administrator will need to force a quorum and then bring the surviving cluster nodes back online in a non-fault-tolerant configuration.
For information about running SQL Server on Windows Server Failover Clustering (WSFC) nodes and about WSFC quorum, see Windows Server Failover Clustering (WSFC) with SQL Server.
Beginning with SQL Server 2012 SP1, Always On Availability Groups supports cross-cluster migration of availability groups for deployments to a new Windows Server Failover Clustering (WSFC) cluster. A cross-cluster migration moves one availability group or a batch of availability groups to the new, destination WSFC cluster with minimal downtime. The cross-cluster migration process enables you to maintain your service level agreements (SLAs) when upgrading to a Windows Server 2012 cluster. SQL Server 2012 SP1 (or a later version) must be installed and enabled for Always On on the destination WSFC cluster. The success of a cross-cluster migration depends on thorough planning and preparation of the destination WSFC cluster.
For more information, see Cross-Cluster Migration of Always On Availability Groups for OS Upgrade.
You can set up a second layer of failover at the server-instance level by implementing SQL Server failover clustering together with the WSFC cluster. An availability replica can be hosted by either a standalone instance of SQL Server or an FCI instance. Only one FCI partner can host a replica for a given availability group. When an availability replica is running on an FCI, the possible owners list for the availability group will contain only the active FCI node.
Always On Availability Groups does not depend on any form of shared storage. However, if you use a SQL Server failover cluster instance (FCI) to host one or more availability replicas, each of those FCIs will require shared storage as per standard SQL Server failover cluster instance installation.
For more information about additional prerequisites, see the "Prerequisites and Restrictions for Using a SQL Server Failover Cluster Instance (FCI) to Host an Availability Replica" section of Prerequisites, Restrictions, and Recommendations for Always On Availability Groups (SQL Server).
Regardless of the number of nodes in the FCI, an entire FCI hosts a single replica within an availability group. The following table describes the distinctions in concepts between nodes in an FCI and replicas within an availability group.
|Nodes within an FCI||Replicas within an availability group|
|Uses WSFC cluster||Yes||Yes|
While the replicas in an availability group do not share storage, a replica that is hosted by an FCI uses a shared storage solution as required by that FCI. The storage solution is shared only by nodes within the FCI and not between replicas of the availability group.
|Storage solutions||Direct attached, SAN, mount points, SMB||Depends on node type|
|Applicable failover policy settings||WSFC quorum|
Availability group settings**
Availability group settings
|Failed-over resources||Server, instance, and database||Database only|
*Whereas synchronous secondary replicas in an availability group are always running on their respective SQL Server instances, secondary nodes in an FCI actually have not started their respective SQL Server instances and are therefore not readable. In an FCI, a secondary node starts its SQL Server instance only when the resource group ownership is transferred to it during an FCI failover. However, on the active FCI node, when an FCI-hosted database belongs to an availability group, if the local availability replica is running as a readable secondary replica, the database is readable.
**Failover policy settings for the availability group apply to all replicas, whether it is hosted in a standalone instance or an FCI instance.
SQL Server Failover Cluster Instances (FCIs) do not support automatic failover by availability groups, so any availability replica that is hosted by an FCI can only be configured for manual failover.
You might need to configure a Windows Server Failover Clustering (WSFC) cluster to include shared disks that are not available on all nodes. For example, consider a WSFC cluster across two data centers with three nodes. Two of the nodes host a SQL Server failover clustering instance (FCI) in the primary data center and have access to the same shared disks. The third node hosts a stand-alone instance of SQL Server in a different data center and does not have access to the shared disks from the primary data center. This WSFC cluster configuration supports the deployment of an availability group if the FCI hosts the primary replica and the stand-alone instance hosts the secondary replica.
When choosing an FCI to host an availability replica for a given availability group, ensure that an FCI failover could not potentially cause a single WSFC node to attempt to host two availability replicas for the same availability group.
The following example scenario illustrates how this configuration could lead to problems:
Marcel configures two a WSFC cluster with two nodes,
NODE02. He installs a SQL Server failover cluster instance,
fciInstance1, on both
NODE01 is the current owner for
NODE02, Marcel installs another instance of SQL Server,
Instance3, which is a stand-alone instance.
NODE01, Marcel enables fciInstance1 for Always On Availability Groups. On
NODE02, he enables
Instance3 for Always On Availability Groups. Then he sets up an availability group for which
fciInstance1 hosts the primary replica, and
Instance3 hosts the secondary replica.
At some point
fciInstance1 becomes unavailable on
NODE01, and the WSFC cluster causes a failover of
NODE02. After the failover,
fciInstance1 is a Always On Availability Groups-enabled instance running under the primary role on
Instance3 now resides on the same WSFC node as
fciInstance1. This violates the Always On Availability Groups constraint.
To correct the problem that this scenario presents, the stand-alone instance,
Instance3, must reside on another node in the same WSFC cluster as
For more information about SQL Server failover clustering, see Always On Failover Cluster Instances (SQL Server).
Do not use the Failover Cluster Manager to manipulate availability groups, for example:
Do not add or remove resources in the clustered service (resource group) for the availability group.
Do not change any availability group properties, such as the possible owners and preferred owners. These properties are set automatically by the availability group.
Do not use the Failover Cluster Manager to move availability groups to different nodes or to fail over availability groups. The Failover Cluster Manager is not aware of the synchronization status of the availability replicas, and doing so can lead to extended downtime. You must use Transact-SQL or SQL Server Management Studio.
Overview of Always On Availability Groups (SQL Server)
Enable and Disable Always On Availability Groups (SQL Server)
Monitor Availability Groups (Transact-SQL)
Always On Failover Cluster Instances (SQL Server)