Configure a Dedicated Network Adapter for SQL Server Always On Distributed Avail ...

By:Edwin Sarmiento | Last Updated: 2018-11-30 || Related Tips:More > Availability Groups

Problem

We are exploring SQL Server Always On Distributed Availability Group as our disaster recovery (DR) strategy. We have multiple network connections to our DR data center and would like to utilize one of them specifically for the SQL Server Always On Availability Group data replication traffic. Our network engineers would like to guarantee Quality of Service (QoS) so it doesn’t get affected by other traffic in the network. How do I configure a dedicated network adapter for SQL Server Always On Distributed Availability Groups data replication traffic?

Solution

In a previous tip on Configuring a Dedicated Network for SQL Server Always On Availability Groups Data Replication Traffic , you have seen how to configure a windows Server Failover Cluster (WSFC) with dedicated network adapters that can be used for SQL Server Always On Availability Group data replication traffic. You’ve also seen in a previous tip on Setup and Implement SQL Server 2016 Always On Distributed Availability Groups that they involve two (2) WSFCs.

However, configuring a dedicated network adapter for SQL Server Always On Distributed Availability Groups data replication traffic is a bit challenging. That’s because, most of the time, the dedicated network subnets are not exposed to other network services such as the DNS. Inthe previous tip, an Availability Group listener name that leverages the DNS service was used to direct data replication traffic from the primary Availability Group to the secondary Availability Group. For dedicated network subnets, network engineers either need to add a static route to the routing tables of network devices to properly route traffic in the network or deploy a dedicated DNS server specifically just for that subnet. Both approaches require additional management and operations overhead that your network engineers will not be happy about. The goal is to minimize the amount of changes done on the network side for ease of management and troubleshooting in the future.

Configure a Dedicated Network Adapter for SQL Server Always On Distributed Availability Groups Data Replication Traffic

A network diagram is provided below to better describe the architecture.

There are two WSFCs, each one hosts a traditional Availability Group. Only the public network adapters have access to the DNS service. The private network subnets (10.0.0.0/8 and 10.0.1.0/16) will be used for the SQL Server Always On Distributed Availability Groups data replication traffic. Below are the TCP/IP configuration of the servers.

Production DR WSFC OS: Windows Server 2016 OS: Windows Server 2016 NODE 1 TDPRDAG01 TDDRAG01 IP Address (Public) 172.16.0.11/16 192.168.0.11/24 IP Address (Private) 10.0.0.11/8 10.0.1.11/16 NODE 2 TDPRDAG02 TDDRAG02 IP Address (Public) 172.16.0.12/16 192.168.0.12/24 IP Address (Private) 10.0.0.12/8 10.0.1.12/16 Cluster Name Object TDPRDAG10 TDDRAG10 SQL Server service account TESTDOMAIN\sqlservice TESTDOMAIN\sqlservice Availability Group Name: AG_DC1 Name: AG_DC2 Listener: AG_DC1_LISTENER Listener: AG_DC2_LISTENER Listener IP: 172.16.0.13/16 Listener IP: 192.168.0.13/24 Endpoint (NODE 1) = IP address: port number 10.0.0.11:5022 10.0.1.11:5022 Endpoint (NODE 2) = IP address: port number 10.0.0.12:5022 10.0.1.12:5022 Virtual IP Address for Availability Group Data Replication Traffic 10.0.0.13 10.0.1.13 Distributed Availability Group Name: DistAG_DC1_DC2

Here’s a high-level overview of the steps for your reference.

Create the endpoints on the replicas of the primary Availability Group Create the primary Availability Group (AG_DC1) with a corresponding listener name (AG_DC1_LISTENER) Create the endpoints on the replicas of the secondary Availability Group Create the secondary Availability Group (AG_DC2) with a corresponding listener name (AG_DC2_LISTENER) Create the Virtual IP Addresses for Distributed Availability Group Data Replication Traffic Create Distributed Availability Group (DistAG_DC1_DC2) on the primary Availability Group (AG_DC1) Join the secondary Availability Group (AG_DC2) to the Distributed Availability Group

Before proceeding with the configuration, make sure that each server can access the other servers on all network subnets. A simple PING and TELNET tests can be used for verification.

NOTE:Use SQLCMD mode when running the T-SQL scripts to make sure you are connected to the correct SQL Server instance.

Step #1: Create endpoint on all the replicas in the primary Availability Group

Use the T-SQL script below to create the endpoint on all of the replicas in the primary Availability Group and to grant CONNECT permissions to the SQL Server service account. Be sure that the endpoint is listening on all IP addresses.

--Create endpoint on all Availability Group replicas
--Run this on the primary replica of the primary Availability Group
:CONNECT TDPRDAG01
USE [master]
GO
CREATE ENDPOINT [Hadr_endpoint]
STATE=STARTED
AS TCP (LISTENER_PORT = 5022, <strong>LISTENER_IP = ALL</strong>)
FOR DATA_MIRRORING (ROLE = ALL, AUTHENTICATION = WINDOWS NEGOTIATE
, ENCRYPTION = REQUIRED ALGORITHM AES)
GO
--Run this on the secondary replica of the primary Availability Group
:CONNECT TDPRDAG02
USE [master]
GO
CREATE ENDPOINT [Hadr_endpoint]
STATE=STARTED
AS TCP (LISTENER_PORT = 5022, <strong>LISTENER_IP = ALL</strong>)
FOR DATA_MIRRORING (ROLE = ALL, AUTHENTICATION = WINDOWS NEGOTIATE
, ENCRYPTION = REQUIRED ALGORITHM AES)
GO
:CONNECT TDPRDAG01
--Create login and grant CONNECT permissions to the SQL Server service account
USE master
GO
CREATE LOGIN [TESTDOMAIN\sqlservice] FROM WINDOWS;
GO
GRANT CONNECT ON ENDPOINT::Hadr_endpoint
TO [TESTDOMAIN\sqlservice];
GO
:CONNECT TDPRDAG02
--Create login and grant CONNECT permissions to the SQL Server service account
USE master
GO
CREATE LOGIN [TESTDOMAIN\sqlservice] FROM WINDOWS;
GO
GRANT CONNECT ON ENDPOINT::Hadr_endpoint
TO [TESTDOMAIN\sqlservice];
GO Unlike inthis previous tip where a specific IP address was used in the L