February 3, 2017 at 4:29 am
Hi, I'm hoping someone can offer some suggestions on what to look at here as we're getting a little stumped.
Currently we have a SQL AlwaysOn AG with boxes called sql1,sql3 and sqlFC
1 and 3 are standard boxes, 1 is the primary , 3 is asynch - we had a sql2 which was synch also but have decommissioned it
FC is a failover cluster or 2 boxes, joined to the AG synchronously
All of our connections strings connect to server 'SQLBox' which is an AName record pointing to the listener
Whenever we did failovers between 1 and 2 we had no issues, everything worked fine, but when we attempted a failover to the FC box it failed over fine, but nothing could connect to it via 'SQLBox' so we had to fail back to 1
if we RDP to SQLBox it took us to the SQLFC server so it was pointing correctly.
All boxes have the same instance name, all have an alias in sql configuration for sqlbox to point to themseleves (sql1, sqlfc etc)
This is obviously causing us a little concern and ideally we'd like to de-com sql1 soon so we need our applications to continue working after a failover, reconfiguring all the apps to point to sqlFC isn't feasible due to code sprawl.
Any ideas on what else we need to look at?
February 6, 2017 at 10:19 am
can you supply a little more detail around the setup?
The nodes with the FCI installed are part of the same WSFC as the other 2 nodes?
The AG has a listener created, correct?
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
February 6, 2017 at 1:26 pm
Are sql1, sql3 and sqlFC in the same subnet, different subnets?
Joie Andrew
"Since 1982"
February 7, 2017 at 1:57 am
Nodes of the FCI are part of the same wsfc
AG has a listener created called HAListener, listening on the default port 1433
SQL1,3,FC are all on the same subnet - they are dynamic ports on the sql server
Tried failing over again yesterday, same issue but also attempted to connect to the listener rather than the dns name that points at the listener ip, that failed also, but then tried listener and port, 1433 and it connected ok.
February 7, 2017 at 10:21 am
andrew 13724 - Tuesday, February 7, 2017 1:57 AMNodes of the FCI are part of the same wsfc
AG has a listener created called HAListener, listening on the default port 1433
SQL1,3,FC are all on the same subnet - they are dynamic ports on the sql server
Tried failing over again yesterday, same issue but also attempted to connect to the listener rather than the dns name that points at the listener ip, that failed also, but then tried listener and port, 1433 and it connected ok.
So, you've created an AG spanning 2 separate clusters, correct?
If so, this is not supported except for migration purposes, resources from one WSFC cannot failover to another WSFC, all nodes must be part of the same WSFC.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
February 15, 2017 at 2:26 am
Hi Andrew.
If I've understood well, you're having trouble whenever you don't specify the port, and this could lead into problems with SQL Browser's protocol (UDP 1434).
It seems to me a problem I had in a client with wsfc.
Are your connections crossing any firewall? If so you should:
1) configure static ports for SQL Server instances, not dynamic.
2) be aware your firewalls permit UDP connections in BOTH directions: UDP connections from clients ports (1024-65535) into dns name port 1434, and UDP connections from 1434 port in your SERVERS (not dns name nor listener) into your clients ports (1024-65535).
I hope this will help you.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply