The DNN Listener: Guide to Distributed Network Names (DNNs) for SQL Server VMs

Introduction

This comprehensive guide explores Distributed Network Names (DNNs), an essential concept for managing AlwaysOn Availability Groups on Azure SQL Server VMs. It delineates the differences between DNNs and Virtual Network Names (VNNs), outlines the advantages of using DNNs, and provides a detailed walkthrough for setting them up using PowerShell.

Understanding DNNs and Their Role

What is a DNN?

A DNN, or Distributed Network Name, is a specialized listener designed for AlwaysOn Availability Groups deployed on SQL Server VMs in Azure. It serves as a unified entry point for client applications, facilitating connection to the availability group regardless of the primary replica. This feature simplifies client configurations by obviating the need to manage individual IP addresses or DNS entries for each replica.

DNN vs. VNN: Key Differences

While both DNNs and Virtual Network Names (VNNs) facilitate connections to AlwaysOn Availability Groups, their methodologies differ:

• VNN: A Virtual Network Name is associated with a specific IP address within a subnet, requiring clients to connect using this IP. This traditional approach necessitates managing DNS entries, which must be updated during failovers to reflect the new primary replica.
• DNN: Unlike a VNN, a DNN does not require a dedicated IP address. Clients connect directly using the DNN, which automatically routes connections to the current primary replica, eliminating the need for managing DNS updates or individual IP addresses.

Benefits of DNN Listeners

• Simplified Configuration: Reduced Dependencies: By eliminating the need for Cluster Network Names (CNO) and VNNs, DNNs streamline the setup and maintenance of AlwaysOn Availability Groups.
• Streamlined Networking: DNNs operate without dedicated IP addresses, simplifying network configuration and reducing error potentials.
• Enhanced Flexibility: Multi-Subnet Support: DNNs are ideal for hybrid and cloud deployments across multiple subnets, requiring no additional client connectivity configurations.
• Containerized Environments: The simplicity of DNNs makes them suitable for environments like Kubernetes, where traditional configurations may be cumbersome.
• Improved Availability: Seamless Failover: DNNs enhance failover smoothness by eliminating dependencies on DNS and IP updates, which can delay reconnections.
• Load Balancing Integration: Although not load balancers themselves, DNNs work seamlessly with SQL Server’s read-only routing and secondary replica read capabilities, facilitating connections to read-scale replicas without complex configurations.

Setting Up a DNN: A Step-by-Step Guide

Prerequisites:

• Supported SQL Server Versions: SQL Server 2019 CU8 or later, SQL Server 2017 CU25 or later, or SQL Server 2016 SP3 and later on Windows Server 2016 or subsequent versions.
• HA/DR Suitability: Confirm that a DNN aligns with your High Availability Disaster Recovery (HADR) strategy.
• Configured Availability Group: Ensure your AlwaysOn Availability Group is already set up.
• PowerShell Installation: Have the latest version of PowerShell installed on your system.
• Unique Listener Port: Designate a unique port specifically for your DNN listener, ensuring it is not shared across your availability group replicas or failover cluster instance.

Configuration Steps:

1. Open a text editor, such as Notepad.

2. Copy and paste the following script:

param ( [Parameter(Mandatory=$true)][string]$Ag, [Parameter(Mandatory=$true)][string]$Dns, [Parameter(Mandatory=$true)][string]$Port ) Write-Host “Add a DNN listener for availability group $Ag with DNS name $Dns and port $Port“ $ErrorActionPreference = “Stop”

# create the DNN resource with the port as the resource name Add-ClusterResource -Name $Port -ResourceType “Distributed Network Name” -Group $Ag

# set the DNS name of the DNN resource Get-ClusterResource -Name $Port | Set-ClusterParameter -Name DnsName -Value $Dns

# start the DNN resource Start-ClusterResource -Name $Port $Dep = Get-ClusterResourceDependency -Resource $Ag if ( $Dep.DependencyExpression -match ‘\s*\((.*)\)\s*’ ) { $DepStr = “$($Matches.1) or [$Port]” } else { $DepStr = “[$Port]” } Write-Host “$DepStr“

# add the Dependency from availability group resource to the DNN resource Set-ClusterResourceDependency -Resource $Ag -Dependency “$DepStr“ #bounce the AG resource Stop-ClusterResource -Name $Ag Start-ClusterResource -Name $Ag

1. Save the script as a .ps1 file, such as add_dnn_listener.ps1.

2. execute c:\Documents> .\add_dnn_listener.ps1 ag1 dnnlsnr 6789

Verifying DNN Creation:

Check the creation of your DNN listener with which should return details about the listener including its name and port number.

select * from sys.availability_group_listeners

Conclusion

Distributed Network Names offer a robust solution for managing AlwaysOn Availability Groups in Azure SQL Server VMs. By leveraging DNNs, DBAs can optimize their setups for better scalability, simplified network management, and enhanced overall availability, making them a pivotal tool in modern cloud environments.

Further Reading:
Configure DNN listener for availability group – SQL Server on Azure VMs | Microsoft Learn
The Art of Resolving HADR_SYNC_COMMIT Waits in SQL Server – SQL Table Talk