Skip to content

failover-clustering-and-always-on-availability-groups-sql-server.md

Latest commit

 

History

History
125 lines (85 loc) · 13.6 KB

failover-clustering-and-always-on-availability-groups-sql-server.md

File metadata and controls

125 lines (85 loc) · 13.6 KB
title Failover Cluster Instance with Availability Groups
description Enhance your high availability and disaster recoverability by combining the features of a SQL Server failover cluster instance and an Always On availability group.
author MashaMSFT
ms.author mathoma
ms.date 08/21/2025
ms.update-cycle 1825-days
ms.service sql
ms.subservice availability-groups
ms.topic conceptual
helpviewer_keywords
clustering [SQL Server]
Availability Groups [SQL Server], WSFC clusters
Failover Cluster Instances [SQL Server], see failover clustering [SQL Server]
quorum [SQL Server]
failover clustering [SQL Server], AlwaysOn Availability Groups
failover clustering [SQL Server], Always On Availability Groups
Availability Groups [SQL Server], Failover Cluster Instances
monikerRange >=sql-server-2016

Failover Clustering and Always On availability groups (SQL Server)

[!INCLUDE sql windows only]

[!INCLUDE ssHADR], the high availability and disaster recovery solution introduced in [!INCLUDE sssql11], requires Windows Server Failover Clustering (WSFC). Also, though [!INCLUDE ssHADR] isn't dependent upon [!INCLUDE ssNoVersion] failover clustering, you can use a failover clustering instance (FCI) to host an availability replica for an availability group. It's important to know the role of each clustering technology, and to know what considerations are necessary as you design your [!INCLUDE ssHADR] environment.

Note

For information about [!INCLUDE ssHADR] concepts, see What is an Always On availability group?

Windows Server Failover Clustering and availability groups

Deploying [!INCLUDE ssHADR] requires a Windows Server Failover Cluster (WSFC). To be enabled for [!INCLUDE ssHADR], an instance of [!INCLUDE ssNoVersion] must reside on a WSFC node, and the WSFC and node must be online. Furthermore, each availability replica of a given availability group must reside on a different node of the same WSFC. The only exception is that while being migrated to another WSFC, an availability group can temporarily straddle two clusters.

[!INCLUDE ssHADR] relies on the Windows Server Failover Cluster (WSFC) 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 monitors this resource group to evaluate the health of the primary replica.

The quorum for [!INCLUDE ssHADR] is based on all nodes in the WSFC regardless of whether a given cluster node hosts any availability replicas. In contrast to database mirroring, there's no witness role in [!INCLUDE ssHADR].

The overall health of a WSFC is determined by the votes of quorum of nodes in the cluster. If the WSFC 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 administrator will need to force a quorum and then bring the surviving cluster nodes back online in a non-fault-tolerant configuration.

Important

[!INCLUDE ssHADR] registry keys are subkeys of the WSFC. If you delete and re-create a WSFC, you must disable and re-enable the [!INCLUDE ssHADR] feature on each instance of [!INCLUDE ssNoVersion] that hosted an availability replica on the original WSFC.

For information about running [!INCLUDE ssNoVersion] on WSFC nodes and about WSFC quorum, see Windows Server Failover Clustering with SQL Server.

SQL Server failover cluster instances (FCIs) and availability groups

You can set up a second layer of failover at the server-instance level by implementing [!INCLUDE ssNoVersion] and FCI together with the WSFC. Either a standalone instance of [!INCLUDE ssNoVersion] or an FCI instance can host an availability replica. 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.

[!INCLUDE ssHADR] doesn't depend on any form of shared storage. However, if you use a [!INCLUDE ssNoVersion] 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 Prerequisites, restrictions, and recommendations for Always On availability groups (SQL Server).

Comparison of failover cluster instances and availability groups

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 Yes Yes
Protection level Instance Database
Storage type Shared Non-shared

Although the replicas in an availability group don't share storage, a replica that's 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
Readable secondaries No* Yes
Applicable failover policy settings WSFC quorum

FCI-specific

Availability group settings**		 WSFC quorum

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 [!INCLUDE ssNoVersion] instances, secondary nodes in an FCI actually haven't started their respective [!INCLUDE ssNoVersion] instances and are therefore not readable. In an FCI, a secondary node starts its [!INCLUDE ssNoVersion] 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, the database is readable if the local availability replica is running as a readable secondary replica.

**Failover policy settings for the availability group apply to all replicas, whether it's hosted in a standalone instance or an FCI instance.

Considerations for hosting an availability replica on an FCI

Important

If you plan to host an availability replica on a SQL Server failover cluster instance (FCI), ensure that the Windows Server 2008 host nodes meet the Always On prerequisites and restrictions for Failover Cluster Instances (FCIs). For more information, see Prerequisites, Restrictions, and Recommendations for Always On Availability Groups (SQL Server).

[!INCLUDE ssNoVersion] Failover Cluster Instances (FCIs) don't support automatic failover by availability groups, so any availability replica that an FCI hosts can only be configured for manual failover.

You might need to configure a WSFC to include shared disks that aren't available on all nodes. For example, consider a WSFC across two data centers with three nodes. Two of the nodes host a SQL Server FCI in the primary data center and have access to the same shared disks. The third node hosts a standalone instance of SQL Server in a different data center and doesn't have access to the shared disks from the primary data center. This WSFC configuration supports deploying an availability group if the FCI hosts the primary replica and the standalone instance hosts the secondary replica.

When choosing an FCI to host an availability replica for a given availability group, ensure that an FCI failover couldn't 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:

  • You configure a WSFC with two nodes, NODE01 and NODE02.
  • You install a [!INCLUDE ssNoVersion] failover cluster instance, fciInstance1, on both NODE01 and NODE02 where NODE01 is the current owner for fciInstance1.
  • On NODE02, you install another instance of [!INCLUDE ssNoVersion], Instance3, which is a standalone instance.
  • On NODE01, you enable fciInstance1 for [!INCLUDE ssHADR]. On NODE02, you enable Instance3 for [!INCLUDE ssHADR]. Then you set 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 causes a failover of fciInstance1 to NODE02. After the failover, fciInstance1 is a [!INCLUDE ssHADR]-enabled instance running under the primary role on NODE02. However, Instance3 now resides on the same WSFC node as fciInstance1. This violates the [!INCLUDE ssHADR] constraint.

To correct the problem that this scenario presents, the standalone instance, Instance3, must reside on another node in the same WSFC as NODE01 and NODE02.

For more information about [!INCLUDE ssNoVersion] FCIs, see Always On failover cluster instances (SQL Server).

Restrictions on using the WSFC Manager with availability groups

Don't use the Failover Cluster Manager to manipulate availability groups. For example:

  • Don't add or remove resources in the clustered service (resource group) for the availability group.

  • Don't change any availability group properties, such as the possible owners and preferred owners. These properties are set automatically by the availability group.

  • Don't use the Failover Cluster Manager to move availability groups to different nodes or to fail over availability groups. The Failover Cluster Manager isn't aware of the synchronization status of the availability replicas, and doing so can lead to extended downtime. You must use [!INCLUDE tsql] or [!INCLUDE ssManStudioFull].

Warning

Using the Failover Cluster Manager to move a failover cluster instance hosting an availability group to a node that's already hosting a replica of the same availability group can result in losing the availability group replica, preventing it from being brought online on the target node. A single node of a failover cluster can't host more than one replica for the same availability group. For more information on how this occurs and how to recover, see the blog Replica unexpectedly dropped in availability group.

Related content