August 7, 2013 at 6:21 am
I have two Windows 2012/SQL 2012 failover clusters that seem to go to sleep at night. I can connect to then with no issues all day long, but when I try in the morning I can not connect to them remotely. If I RDP to the server and run SSMS, they are fine, but from my desktop I get a "did not respond in a timely manor" I simply fail the instances to another node and then they are fine. There is nothing in the system logs that indicate any issues. We have the firewalls turned off. Any ideas?
August 7, 2013 at 6:29 am
can you elaborate please
August 7, 2013 at 6:33 am
What questions do you have? I am not sure what you would like to know.
August 7, 2013 at 7:04 am
if you are able to connect through RDP from one system, why cant you with the other. It should work in the similar way right?
do you have any connection time out, if so please increase the time, that may help a little.
I am not sure whether i am guiding you in the right way or not, just trying to remind you abt what you know already.
August 7, 2013 at 7:53 am
MichaelDep (8/7/2013)
I have two Windows 2012/SQL 2012 failover clusters that seem to go to sleep at night. I can connect to then with no issues all day long, but when I try in the morning I can not connect to them remotely. If I RDP to the server and run SSMS, they are fine, but from my desktop I get a "did not respond in a timely manor" I simply fail the instances to another node and then they are fine. There is nothing in the system logs that indicate any issues. We have the firewalls turned off. Any ideas?
How are you connecing in SSMS with name or ip and ( of what sysname or cluster name)
Regards
Durai Nagarajan
August 7, 2013 at 10:42 am
I am connectiing the sam way both on the server and from my workstation. I am using the virtual server name\instance name. When I cannot connect from my workstation I can RDP to the virtual server name and connect to the databases. As soon as I fail to the other node, I can then connect remotely.
Dep
August 10, 2013 at 11:39 am
I don't consider myself an expert, but I think durai asks the key question here. If you are connecting by name, this could be as simple as a DNS resolution issue, and that would be the first possibility I would want to eliminate. Have you tried connecting using the IP address? There are many network conditions that could interfere with timely name resolution and cause this failure.
August 12, 2013 at 6:12 am
MichaelDep (8/7/2013)
I am connectiing the sam way both on the server and from my workstation. I am using the virtual server name\instance name. When I cannot connect from my workstation I can RDP to the virtual server name and connect to the databases. As soon as I fail to the other node, I can then connect remotely.Dep
looks like you are connecting to one of the node's name or IP , can you check the node IP and cluster ip once again with the comments after faiover you can able to connect.
Regards
Durai Nagarajan
August 15, 2013 at 10:13 am
I am definitely connecting to the virtual Server Name address, but further research has shown that for some reason that address has stopped talking on the network (Ping gives me no response) until I restart that instances role. But no cluster events show in the log that indicate this issue and in Failover cluster Manager the resource shows on-line. It appears the cluster doesn't even realize the interface is non-functional.
August 16, 2013 at 3:11 am
what is happending if you do manual fail over?.
Regards
Durai Nagarajan
August 16, 2013 at 4:54 am
Are the clusters on the same network segment as your computer?
August 16, 2013 at 5:43 am
Same data center, but different subnets.
August 16, 2013 at 5:44 am
All services are available if I do a manual fail-over
August 16, 2013 at 5:47 am
and when you manually failover again is it going back to the previous master.
Regards
Durai Nagarajan
August 16, 2013 at 5:47 am
I've had a similar thing before but with a site to site VPN between our office and the data centre where the tunnel to the subnet that the SQL Servers were on kept closing due to lack of activity, and trying to connect to the SQL Server via SSMS didn't re-establish the connection, but the RDP session to the server would, and it was weird. I had one of our firewall guys investigate and he managed to resolve it in the end. But if you're saying that your computer and the SQL Server are on the same physical network but different subnets, I can't see it being anything like that, unless there is a firewall between subnets and that's dropping traffic somehow?
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply