2

I have a multi-subnet SQL Server 2012 failover cluster running on 2 Windows 2012 R2 nodes. The cluster is located on 192.168.1.10 when on NODE A and 192.168.5.10 when running on NODE B. When I look at DNS on the domain, I see 2 A records:

SQLCLUSTER - 192.168.1.10

SQLCLUSTER - 192.168.5.10

From what I've read when there's 2 A records with the same name, Windows clients should be smart enough to determine the live IP within 10 seconds, but I'm not getting that. If I fail the cluster over from NODE A to NODE B, many of the client machines (web and SSRS) will not pick up the new IP address.

So for example, if I'm on the SSRS machine and ping SQLCLUSTER, I'll see it reply from 192.168.1.10. If I fail the cluster over to NODE B and ping again, it's still trying to ping 192.168.1.10, not .5.10 as it should.

It seems to be the only way to make sure it works properly is to delete the DNS record of the offline node then do a flushdns/registerdns on the clients. Is there possibly something I missed here? Is it an issue that the DNS server is on the 192.168.1.x subnet and that may give precedence to the .1.x addresses?

I look at the event viewer and don't see any errors regarding writing the DNS records or reading them, so it's leading me to believe that I might just have something configured improperly.

  • 1
    Wouldn't the cluster use a VIP instead of a dedicated ip address, similar to the way NLB works in Windows? Doesn't the cluster have a cluster name and ip address that serves as the "access point" for clients and the cluster members manage which server the client connections are sent to? – joeqwerty May 25 '16 at 17:53
  • Yes, sorry I might not have communicated that properly. Those addresses are resources managed by the cluster service. They are assigned to the cluster when nodes are changed, they are not the IP's of the nodes. One IP is always Online and one is always Offline in the Cluster Manager. The cluster name is supposed to resolve to the online address, but it doesn't always do that. – edgesrazor May 25 '16 at 18:36
2

Ok, I think I found a workaround - it's not exactly pretty, but it does work.

From information found here: https://blogs.msdn.microsoft.com/sambetts/2014/02/04/multi-subnet-clustered-sql-registerallprovidersip-sharepoint-2013/

I set RegisterAllProvidersIP to 0 then set the HostRecordTTL to 300 and restarted the role.

This will force the cluster to only register 1 address in DNS and default its TTL to 5 minutes.

  • This worked great. And here's some sample PowerShell to do this using the FailoverClusters module: Get-ClusterResource| Where-Object {$_.Name -match "WhateverYourNetworkNameIs"} |Set-ClusterParameter RegisterAllProvidersIp 0; Get-ClusterResource| Where-Object {$_.Name -match "WhateverYourNetworkNameIs"} |Set-ClusterParameter HostRecordTTL 300 – KJH Aug 27 '19 at 12:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.