https://www.sqldbachamps.

com Praveen Madupu +91 98661 30093

Sr SQL Server DBA, Dubai
praveensqldba12@gmail.com

In SQL Server, Always On Availability Groups (AG) provide high availability and disaster recovery solutions.

A common implementation of AGs involves creating multiple availability groups to support different subnets,
typically in a multi-subnet or multi-site deployment. This can be especially useful for geographically distributed
applications where you want to ensure high availability and resilience across data centers.

Key Concepts of Multiple Subnet Availability Groups in SQL Server

1. Availability Groups (AG):

○ A set of databases that fail over together as a single unit.
○ AGs are part of the Always On Availability Groups feature, introduced in SQL Server 2012
Enterprise Edition.
2. Multi-Subnet Deployment:
○ Involves placing replicas of the availability group in different subnets, often across geographically
dispersed data centers.
○ This helps ensure that the system remains operational even if an entire data center (or a subnet)
goes down.
3. Listener:
○ The Availability Group Listener is a virtual network name that acts as a connection point for
client applications, providing automatic redirection to the active replica.
○ In multi-subnet environments, the listener needs to be configured with multiple IP addresses, one

https://www.sqldbachamps.com
for each subnet.
4. Replicas:
○ SQL Server replicas are instances of SQL Server that host a copy of the databases in the AG.
○ In multi-subnet scenarios, replicas can reside in different subnets, typically in different locations or
data centers.
5. Auto-Failover:
○ One of the benefits of Always On AGs is automatic failover between replicas, which can be
cross-subnet (even across data centers).
○ This failover process requires careful configuration to handle differences in network latency and
ensure that client applications can quickly reconnect to a new primary replica.

Configuration of Multi-Subnet AGs in SQL Server

To set up a multi-subnet availability group, several steps must be followed. Here’s an outline:

1. Prerequisites

● SQL Server 2012 Enterprise Edition or higher (Always On AGs).

● A Windows Server Failover Cluster (WSFC) configured with at least two nodes.
● A multi-subnet network environment where subnets are available for each data center or region.
● DNS configured to support multi-subnet configurations (e.g., with multiple IPs for the Availability Group
Listener).
https://www.sqldbachamps.com Praveen Madupu +91 98661 30093
Sr SQL Server DBA, Dubai
praveensqldba12@gmail.com
2. Setting Up the Availability Group

● You first create an Availability Group with multiple replicas. This can be done using SQL Server
Management Studio (SSMS) or via Transact-SQL (T-SQL).

-- Example: Creating the Availability Group

CREATE AVAILABILITY GROUP [AG_MultiSubnet]

FOR DATABASE [MyDatabase]

REPLICA ON

N'SQLNode1' WITH (ENDPOINT_URL = 'TCP://SQLNode1.domain.com:5022', AVAILABILITY_MODE =

SYNCHRONOUS_COMMIT, FAILOVER_MODE = AUTOMATIC),

N'SQLNode2' WITH (ENDPOINT_URL = 'TCP://SQLNode2.domain.com:5022', AVAILABILITY_MODE =

SYNCHRONOUS_COMMIT, FAILOVER_MODE = AUTOMATIC);

● When configuring the replicas, ensure each replica is located in a different subnet.

3. Configuring the Listener for Multi-Subnet

● Multi-Subnet Listener: For a multi-subnet environment, configure the Availability Group Listener to

https://www.sqldbachamps.com
support multiple subnets. The listener will have a DNS name, but it will be associated with multiple IP
addresses—one for each subnet.
● You need to set up multiple IP addresses for the listener, typically via DNS and SQL Server’s
configuration.
○ Example of listener configuration:
■ Listener DNS name: AGListener.domain.com
■ Listener IP addresses:
■ IP for Subnet 1: 10.0.0.100
■ IP for Subnet 2: 10.1.0.100
● In SQL Server, when creating the availability group listener, you specify these IPs:

-- Create the Availability Group Listener for multi-subnet

ALTER AVAILABILITY GROUP [AG_MultiSubnet]

ADD LISTENER 'AGListener.domain.com'

(WITH IP ((10.0.0.100, 255.255.255.0), (10.1.0.100, 255.255.255.0)),

PORT = 1433);
https://www.sqldbachamps.com Praveen Madupu +91 98661 30093
Sr SQL Server DBA, Dubai
praveensqldba12@gmail.com

● DNS and Routing: Configure the DNS records so that the listener resolves to the correct IP based on the
client’s location. This often involves setting up DNS round-robin or geo-DNS to resolve to the appropriate
IP address based on the client’s subnet.

4. Considerations for Multi-Subnet Availability Groups

● Health Detection: Ensure that the health detection of the Availability Group is appropriately configured,
especially since network latency and split-brain scenarios can occur across subnets. SQL Server uses
quorum votes from the WSFC (Windows Server Failover Cluster) to make failover decisions.
● Latency and Network Considerations: When you deploy across multiple subnets or data centers,
consider the network latency between the replicas. Higher latency can increase the time required for
failover and impact the performance of synchronous commit mode (if used).
● Quorum Settings: In a multi-subnet configuration, it’s important to set quorum appropriately to avoid
split-brain scenarios. The cluster’s quorum configuration determines how the nodes in the cluster
communicate to make decisions when network connectivity is lost.
● Failover Mode:
○ Automatic Failover: You can configure automatic failover between replicas, but automatic failover
requires that all replicas are synchronous and that the primary replica and its mirrored secondary
replica can communicate reliably.
○ Manual Failover: For multi-subnet environments, you may choose to use manual failover when

https://www.sqldbachamps.com
you want more control over the failover process, especially in cases where network latencies or
transient issues may impact failover behavior.

5. Testing and Monitoring

● Regularly test the failover process to ensure that the application can automatically reconnect to the new
primary replica if the current primary goes down.
● Monitor the AG using Extended Events, SQL Server Management Studio (SSMS), or Dynamic
Management Views (DMVs) to ensure that the replication health is maintained and that failovers occur as
expected.

6. Backup and Disaster Recovery

● Since the replicas are spread across subnets (and possibly different data centers), backup strategies
should be tailored to handle geographical distribution.
● Leverage SQL Server’s Backup to URL or Cloud Storage if necessary for off-site disaster recovery.
https://www.sqldbachamps.com Praveen Madupu +91 98661 30093
Sr SQL Server DBA, Dubai
praveensqldba12@gmail.com
Example of Monitoring AG Status:

You can use the following DMV to check the status of the Always On Availability Groups:

SELECT

ag.name AS AGName,

ar.replica_server_name AS ReplicaServerName,

ar.availability_mode_desc AS AvailabilityMode,

ar.failover_mode_desc AS FailoverMode,

drs.database_state_desc AS DatabaseState,

drs.synchronization_state_desc AS SyncState

FROM sys.availability_groups ag

JOIN sys.availability_replicas ar ON ag.group_id = ar.group_id

JOIN sys.dm_hadr_database_replica_states drs ON ar.replica_id = drs.replica_id;

https://www.sqldbachamps.com
Summary

Implementing a multi-subnet Always On Availability Group in SQL Server provides high availability and disaster
recovery in geographically dispersed environments.

However, it requires careful network, DNS, and quorum configuration to ensure that failovers are smooth and that
applications can reliably connect to the active replica.

Always consider network latency, DNS resolution, and failover mechanisms to optimize the performance and
reliability of your multi-subnet AG setup.