Published on

April 22, 2017

Understanding SQL Server AlwaysOn Multi-Subnet Listener

One of the key features of SQL Server AlwaysOn Availability Groups is the ability to configure a multi-subnet listener. This allows clients to connect to the availability group even if it spans multiple subnets. However, there are certain considerations and potential issues that need to be addressed when implementing a multi-subnet listener.

Recently, one of my clients encountered an issue with their multi-subnet listener. They were unable to bring the listener online on a newly added node. Upon investigation, we found the following error messages in the event logs:

Log Name: System
Source: Microsoft-Windows-FailoverClustering
Event ID: 1045
Level: Warning
Source: IP Address Resource
Description: IP Address Resource NT AUTHORITY\SYSTEM No matching network interface found for resource ‘Cluster IP Address’ IP address ‘10.10.10.10’ (return code was ‘5035’). If your cluster nodes span different subnets, this may be normal.

Log Name: System
Source: Microsoft-Windows-FailoverClustering
Event ID: 1069
Level: Error
Source: Resource Control Manager
Description: Cluster resource ‘Cluster IP Address’ of type ‘IP Address’ in clustered role ‘Cluster Group’ failed. Based on the failure policies for the resource and role, the cluster service may try to bring the resource online on this node or move the group to another node of the cluster and then restart it. Check the resource and group state using Failover Cluster Manager or the Get-ClusterResource Windows PowerShell cmdlet.

The return code 5035 indicates that a cluster network is not available for the operation. This is expected behavior in multi-site clusters where each subnet requires a dedicated network for proper management of IP addresses.

To resolve this issue and ensure failover functionality, it is necessary to have two IP addresses – one for each subnet. This applies to both the Windows Cluster IP and the AlwaysOn listener IP address.

By setting up a network for each subnet at each site, the cluster can effectively manage bringing IP addresses online and offline based on the available networks for the cluster node being moved to.

Implementing a multi-subnet listener in SQL Server AlwaysOn Availability Groups provides flexibility and high availability across multiple subnets. However, it is crucial to ensure proper network configuration to avoid issues like the one described above.

By following the recommended solution and workaround, you can successfully configure and manage a multi-subnet listener in your SQL Server AlwaysOn environment.

Click to rate this post!
[Total: 0 Average: 0]

Let's work together

Send us a message or book free introductory meeting with us using button below.