May 25, 2016 at 12:11 pm
Here's the setup: Server A is primary 1 on a cross-data center 4 node cluster. It fails over to Server B in DC1. Server C is primary 2 on the same cluster, it fails over to Server D.
Servers B & D have standalone SQL instances installed, but are only on the cluster as failover nodes (no clustered instance here).
After we installed the standalone instance, we had a bit of trouble with the alias names (another thread on this forum) but managed to resolve it with the addition of a CNAME record for the B & D instances. Unfortunately, that caused another issue. Servers A & C refused to fail over to servers B & D after the troubleshooting my coworker did. Every time we tried to fail over, the servers either bounced back to the primary nodes or we got errors.
The SQL Server (SvrA) service terminated with the following service-specific error: An attempt was made to access a socket in a way forbidden by its access permissions.
Cluster resource 'SQL Server (SvrA)' of type 'SQL Server' in clustered role 'SvrA' 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 Cluster service failed to bring clustered role 'SvrA' completely online or offline. One or more resources may be in a failed state. This may impact the availability of the clustered role.
All the research I did on the socket error indicated the problem was two resources trying to use the same port. Which makes sense. When the coworker set up the aliases in config manager, he forced all of them (SvrA and SvrB, SvrC and SvrD) to use port 1433 by putting the port number on the aliases and in the TCP/IP protocol (Properties->IP Addresses->IPAll-> TCP Port). TCP/IP on both servers were set up to use dynamic ports, BTW, before this point.
I tried to tell him and my boss that the issue was both instances trying to use the same port number and they disagreed saying that since the instances are both named, it shouldn't matter that they're both using 1433. So I went into the server and changed SvrB's aliases and TCP/IP property to be port 1435 as a test and lookie-here, the cluster node suddenly fails over just fine. But now we can't connect to SrvB remotely using "SvrB". It has to be Server\SvrB or SvrB,1435.
I need two things. The first is: Am I correct about the shared port number being the reason why the clustered instance isn't failing over to the server with the standalone instance (which is named, not default)? If I'm wrong about this, then what would be the reason for the failover working when I changed the port numbers on SvrB?
The second thing is: Is there a way to create an alias for SvrB so that I only have to use SvrB remotely instead of specifying the port number or the server name? I know the alias works if I use port 1433 for the alias, but again, that's causing issues with the failover instance.
Any other thoughts on this situation that could help me?
May 25, 2016 at 12:27 pm
Looking around Google, I think I've answered my own question about port 1433. Which is, it cannot be used for multiple instances the way they think it can be used. But then I found this article about adding another IP address[/url].
Has anyone tried doing it this way yet? If so, how well did it work for you?
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply