Question

I have an Azure AO AG which consists of three servers (all WS-2019 & SQL-2019 CU8):

  • A - Subnet 1 - Principal Server (Sync)
  • B - Subnet 1 - Secondary Server (Sync)
  • C - Subnet 2 - Secondary Server (Async)

I have created a DNN Listener on the resource which looks to be up an running but when I connect to the Listener it resolves to server C. I have confirmed that in the cluster and AG, server A is the principal. I have tried failing over to server B which seems to work fine but the listener still only resolves to Server C.

I pulled out the Cluster Logs and I have a warning that jumped out to me that does not seem to appear on google:

2020/11/12-15:27:48.720 WARN [RES] Distributed Network Name <6789>: Configuration: Obtaining exclude networks failed with error 2.

No correct solution

OTHER TIPS

A Distributed Network Name is like an AG Listener in a Multi-Subnet Failover cluster. It's registered in DNS with multiple IP addresses.

Clients resolving the name from DNS will receive a list of IP addresses, and it requires client-side logic to select the correct one. The SQL Server client drivers do this with the MultiSubnetFailover connection string and the Transparent Network IP Resolution Feature as a fallback. And the logic is simple. The client will connect to one of the IP addresses that has the target port open. And so the DNN must use a port that no SQL Server (or other process) in the cluster is listening on.

If you test with something like ping.exe, or telnet, or test-netconnection it will just connect to the first IP address returned from DNS, which may not be the primary node.

Default 1433 SQL port is not supported by DNN listener if SQL server uses this port.
Additionally, In case there are multiple AGs with DNN listeners in scope of single cluster, every DNN listener should be configured using unique custom port. The custom port should be added to firewall exceptions on all AG nodes. When connecting using SSMS, it is necessary to specify custom port that was configured for DNN listener in format: , It is also better to explicitly specify AG database in SSMS connection properties and MultiSubnetFailover=True in Additional Connection parameters. That worked for me.

Sergei

Availability Group DNN listeners aren't supported until CU8 so you may need to upgrade?

https://support.microsoft.com/en-us/help/4578579/kb4578579-improvement-availability-group-listener-without-the-load-bal

Rhys

Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top