| title | SQL Server Multi-Subnet Clustering | ||||||
|---|---|---|---|---|---|---|---|
| description | Learn about configuring a SQL Server failover cluster instance in a multi-subnet environment, which provides disaster recovery in addition to high availability. | ||||||
| author | MashaMSFT | ||||||
| ms.author | mathoma | ||||||
| ms.date | 08/25/2025 | ||||||
| ms.service | sql | ||||||
| ms.subservice | failover-cluster-instance | ||||||
| ms.topic | concept-article | ||||||
| ms.custom |
|
||||||
| helpviewer_keywords |
|
[!INCLUDE SQL Server]
A [!INCLUDEssNoVersion] multi-subnet failover cluster is a configuration in which each failover cluster node is connected to a different subnet or a different set of subnets. These subnets can be in the same location or in geographically dispersed sites. Clusters in geographically dispersed sites are sometimes referred to as stretch clusters. Because there's no shared storage that all the nodes can access, data should be replicated between the data storage on the multiple subnets. When you replicate data, there's more than one copy of the data available. Therefore, a multi-subnet failover cluster provides a disaster recovery solution in addition to high availability.
The following illustration represents a two-node, two-subnet failover cluster instance (FCI) in [!INCLUDE ssnoversion].
:::image type="content" source="../../../sql-server/failover-clusters/windows/media/multi-subnet-architecture-withmultisubnetfailoverparam.png" alt-text="Diagram that shows a multi-subnet architecture with MultiSubnetFailover.":::
Following are some examples of [!INCLUDE ssNoVersion] FCIs that use multiple subnets:
-
[!INCLUDE ssNoVersion] FCI SQLCLUST1 includes Node1 and Node2. Node1 is connected to Subnet1. Node2 is connected to Subnet2. [!INCLUDE ssNoVersion] Setup sees this configuration as a multi-subnet cluster and sets the IP address resource dependency to
OR. -
[!INCLUDE ssNoVersion] FCI SQLCLUST2 includes Node1, Node2, and Node3. Node1 and Node2 are connected to Subnet1. Node 3 is connected to Subnet2. [!INCLUDE ssNoVersion] Setup sees this configuration as a multi-subnet cluster and sets the IP address resource dependency to
OR. Because Node1 and Node2 are on the same subnet, this configuration provides additional local high availability. -
[!INCLUDE ssNoVersion] FCI SQLCLUST3 includes Node1 and Node2. Node1 is on Subnet1. Node2 is on Subnet1 and Subnet2. [!INCLUDE ssNoVersion] Setup sees this configuration as a multi-subnet cluster and sets the IP address resource dependency to
OR. -
[!INCLUDE ssNoVersion] FCI SQLCLUST4 includes Node1 and Node2. Node1 is connected to Subnet1 and Subnet2. Node2 is also connected to Subnet1 and Subnet2. [!INCLUDE ssNoVersion] Setup sets the IP address resource dependency to
AND.[!NOTE]
This configuration isn't considered a multi-subnet failover cluster configuration because the clustered nodes are on the same set of subnets.
In a multi-subnet failover cluster configuration, the IP addresses aren't owned by all the nodes in the failover cluster, and they might not all be online during [!INCLUDE ssNoVersion] startup. Starting in [!INCLUDE ssSQL11], you can set the IP address resource dependency to OR. Doing so enables [!INCLUDE ssNoVersion] to be online when there's at least one valid IP address that it can bind to.
Note
In [!INCLUDE ssNoVersion] versions earlier than [!INCLUDE ssSQL11], a stretch V-LAN technology was used in multi-site cluster configurations to expose a single IP address for failover across sites. Now that SQL Server can cluster nodes across different subnets, you can configure [!INCLUDE ssNoVersion] failover clusters across multiple sites without implementing the stretch V-LAN technology.
You might want to consider the following failover behavior if you set the IP address resource dependency to OR:
-
When there's a failure of one of the IP addresses on the node that currently owns the [!INCLUDE ssNoVersion] cluster resource group, a failover isn't triggered automatically until all the IP addresses valid on that node fail.
-
When a failover occurs, [!INCLUDE ssNoVersion] comes online if it can bind to at least one IP address that's valid on the current node. The IP addresses that didn't bind to [!INCLUDE ssNoVersion] at startup will be listed in the error log.
When a [!INCLUDE ssNoVersion] FCI is installed side-by-side with a standalone instance of the [!INCLUDE ssDEnoversion], be careful to avoid TCP port number conflicts on the IP addresses. Conflicts usually occur when two instances of the [!INCLUDE ssDE] are configured to use the default TCP port (1433). To avoid conflicts, configure one instance to use a nondefault fixed port. Configuring a fixed port is usually easier on the standalone instance. Configuring the [!INCLUDE ssDE] to use different ports prevents an unexpected IP address / TCP port conflict that blocks an instance startup when a [!INCLUDE ssNoVersion] FCI fails to the standby node.
By default, a multi-subnet FCI enables the RegisterAllProvidersIP cluster resource for its network name. In a multi-subnet configuration, the online and offline IP addresses of the network name are both registered at the DNS server. The client application then retrieves all registered IP addresses from the DNS server and attempts to connect to the addresses, either in order or in parallel. This means that client recovery time in multi-subnet failovers no longer depends on DNS update latencies. By default, the client tries the IP addresses in order. When the client uses the optional MultiSubnetFailover=True parameter in its connection string, it instead tries the IP addresses simultaneously and connects to the first server that responds. This configuration can help minimize the client recovery latency when failovers occur. For more information, see Always On client connectivity (SQL Server) and Create or configure an availability group listener (SQL Server).
With legacy client libraries or non-Microsoft data providers, you can't use the MultiSubnetFailover parameter in your connection string. To help ensure that your client application works optimally with multi-subnet FCI in [!INCLUDE ssnoversion], try to adjust the connection timeout in the client connection string by 21 seconds for each additional IP address. This configuration ensures that the client's reconnection attempt doesn't time out before it can cycle through all IP addresses in your multi-subnet FCI.
The default client connection timeout period for [!INCLUDE ssNoVersion] Management Studio and sqlcmd is 15 seconds.
Note
If you're using multiple subnets and have a static DNS, you need to have a process in place to update the DNS record associated with the listener before you perform a failover. Otherwise the network name won't come online.
| Description | Article |
|---|---|
| Install a SQL Server failover cluster | Create a new SQL Server failover cluster (Setup) |
| In-place upgrade of your existing SQL Server failover cluster | Upgrade a SQL Server failover cluster instance (Setup) |
| Maintain your SQL Server failover cluster | Add or remove nodes in a SQL Server failover cluster (Setup) |
| Use the Failover Cluster Management snap-in to view Windows Server Failover Cluster events and logs | View events and logs for a failover cluster |
| Use Windows PowerShell to create a log file for all nodes (or a specific node) in a Windows Server failover cluster | Get-ClusterLog failover cluster cmdlet |