Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Applies to: 
SQL Server on Azure VM
On Azure Virtual Machines (VMs), the distributed network name (DNN) routes traffic to the appropriate clustered resource. It provides an easier way to connect to the SQL Server failover cluster instance (FCI) than the virtual network name (VNN), without the need for an Azure Load Balancer.
This article teaches you to configure a DNN resource to route traffic to your failover cluster instance with SQL Server on Azure VMs for high availability and disaster recovery (HADR).
For an alternative connectivity option, consider a Virtual network name (VNN) and Azure Load Balancer instead.
Overview
The distributed network name (DNN) replaces the virtual network name (VNN) as the connection point when used with an Always On failover cluster instance on SQL Server VMs. Configuring a DNN negates the need for an Azure Load Balancer routing traffic to the VNN, simplifying deployment, maintenance, and improving failover.
With an FCI deployment, the VNN still exists, but the client connects to the DNN DNS name instead of the VNN name.
Tip
Simplify your deployment and eliminate the need for an Azure Load Balancer or distributed network name (DNN) for your failover cluster instance by creating your SQL Server virtual machines (VMs) in multiple subnets within the same Azure virtual network.
Prerequisites
Before you complete the steps in this article, you should already have:
- SQL Server starting with either SQL Server 2019 CU8 and later, SQL Server 2017 CU25 and later, or SQL Server 2016 SP3 and later on Windows Server 2016 and later.
- Decided that the distributed network name is the appropriate connectivity option for your HADR solution.
- Configured your Failover cluster instances.
- Installed the latest version of PowerShell.
Note
Each availability group or failover cluster instance on the same cluster needs its own independent connection point, whether it's a VNN listener or a DNN listener.
Create DNN resource
The DNN resource is created in the same cluster group as the SQL Server FCI. Use PowerShell to create the DNN resource inside the FCI cluster group.
The following PowerShell command adds a DNN resource to the SQL Server FCI cluster group with a resource name of <dnnResourceName>. The resource name is used to uniquely identify a resource. Use one that makes sense to you and is unique across the cluster. The resource type must be Distributed Network Name.
The -Group value must be the name of the cluster group that corresponds to the SQL Server FCI where you want to add the distributed network name. For a default instance, the typical format is SQL Server (MSSQLSERVER).
Add-ClusterResource -Name <dnnResourceName> `
-ResourceType "Distributed Network Name" -Group "<WSFC role of SQL Server instance>"
For example, to create your DNN resource dnn-demo for a default SQL Server FCI, use the following PowerShell command:
Add-ClusterResource -Name dnn-demo `
-ResourceType "Distributed Network Name" -Group "SQL Server (MSSQLSERVER)"
Set cluster DNN DNS name
Set the domain name system (DNS) name for the DNN resource in the cluster. The cluster then uses this value to route traffic to the node that's currently hosting the SQL Server FCI.
Clients use the DNS name to connect to the SQL Server FCI. You can choose a unique value. Or, if you already have an existing FCI and don't want to update client connection strings. You can configure the DNN to use the current VNN that clients are already using. To do so, you need to rename the VNN before setting the DNN in DNS.
Use this command to set the DNS name for your DNN:
Get-ClusterResource -Name <dnnResourceName> | `
Set-ClusterParameter -Name DnsName -Value <DNSName>
The DNSName value is what clients use to connect to the SQL Server FCI. For example, for clients to connect to FCIDNN, use the following PowerShell command:
Get-ClusterResource -Name dnn-demo | `
Set-ClusterParameter -Name DnsName -Value FCIDNN
Clients must now enter FCIDNN into their connection string when connecting to the SQL Server FCI.
Warning
Don't delete the current virtual network name (VNN) as it's a necessary component of the FCI infrastructure.
Rename the VNN
If you have an existing virtual network name and you want clients to continue using this value to connect to the SQL Server FCI, you must rename the current VNN to a placeholder value. After the current VNN is renamed, you can set the DNS name value for the DNN to the VNN. If using the current VNN isn't necessary for your business, skip this section.
Some restrictions apply for renaming the VNN. For more information, see Renaming an FCI.
After you rename the VNN, then set the cluster DNN DNS name.
Set DNN resource online
After your DNN resource is appropriately named, and you set the DNS name value in the cluster, use PowerShell to set the DNN resource online in the cluster:
Start-ClusterResource -Name <dnnResourceName>
For example, to start your DNN resource dnn-demo, use the following PowerShell command:
Start-ClusterResource -Name dnn-demo
Configure possible owners
By default, the cluster binds the DNN DNS name to all the nodes in the cluster. However, nodes in the cluster that aren't part of the SQL Server FCI should be excluded from the list of DNN possible owners.
To update possible owners, follow these steps:
Go to your DNN resource in Failover Cluster Manager.
Right-click the DNN resource and select Properties.
Clear the check box for any nodes that don't participate in the failover cluster instance. The list of possible owners for the DNN resource should match the list of possible owners for the SQL Server instance resource. For example, assuming that Data3 doesn't participate in the FCI, the following image is an example of removing Data3 from the list of possible owners for the DNN resource:
Select OK to save your settings.
Restart SQL Server instance
Use Failover Cluster Manager to restart the SQL Server instance. Follow these steps:
- Go to your SQL Server resource in Failover Cluster Manager.
- Right-click the SQL Server resource, and take it offline.
- Wait until all associated resources are offline. Then right-click the SQL Server resource and bring it online again.
Update connection string
Update the connection string of any application connecting to the SQL Server FCI DNN, and include MultiSubnetFailover=True in the connection string. If your client doesn't support the MultiSubnetFailover parameter, it isn't compatible with a DNN.
The following is an example connection string for a SQL FCI DNN with the DNS name of FCIDNN:
Data Source=FCIDNN, MultiSubnetFailover=True
Additionally, if the DNN isn't using the original VNN, SQL clients that connect to the SQL Server FCI need to update their connection string to the DNN DNS name. To avoid this requirement, you can update the DNS name value to be the name of the VNN. But you need to replace the existing VNN with a placeholder first.
Test failover
Test failover of the clustered resource to validate cluster functionality.
To test failover, follow these steps:
- Connect to one of the SQL Server cluster nodes by using Bastion.
- Open Failover Cluster Manager. Select Roles. Notice which node owns the SQL Server FCI role.
- Right-click the SQL Server FCI role.
- Select Move, and then select Best Possible Node.
Failover Cluster Manager shows the role, and its resources go offline. The resources then move and come back online in the other node.
Test connectivity
To test connectivity, sign in to another virtual machine in the same virtual network. Open SQL Server Management Studio and connect to the SQL Server FCI by using the DNN DNS name.
If you need to, you can download SQL Server Management Studio.
Avoid IP conflict
You can take this optional step to prevent the virtual IP (VIP) address used by the FCI resource from being assigned to another resource in Azure.
Although your customers now use the DNN to connect to the SQL Server FCI, you can't delete the virtual network name (VNN) and virtual IP because they're necessary components of the FCI infrastructure. However, there's no longer a load balancer reserving the virtual IP address in Azure. So, there's a risk that another resource on the virtual network could be assigned the same IP address as the virtual IP address used by the FCI. This situation can potentially lead to a duplicate IP conflict issue.
Configure an APIPA address or a dedicated network adapter to reserve the IP address.
APIPA address
To avoid using duplicate IP addresses, configure an APIPA address (also known as a link-local address). To do so, run the following command:
Get-ClusterResource "virtual IP address" | Set-ClusterParameter
–Multiple @{"Address"="169.254.1.1";"SubnetMask"="255.255.0.0";"OverrideAddressMatch"=1;"EnableDhcp"=0}
In this command, "virtual IP address" is the name of the clustered VIP address resource, and "169.254.1.1" is the APIPA address chosen for the VIP address. Choose the address that best suits your business. Set OverrideAddressMatch=1 to allow the IP address to be on any network, including the APIPA address space.
Dedicated network adapter
Alternatively, you can configure a network adapter in Azure to reserve the IP address used by the virtual IP address resource. However, this configuration consumes the address in the subnet address space, and requires the added overhead of ensuring the network adapter isn't used for any other purpose.
Limitations
- The client connecting to the DNN listener must support the
MultiSubnetFailover=Trueparameter in the connection string. - There might be more considerations when you're working with other SQL Server features and an FCI with a DNN. For more information, see FCI with DNN interoperability.