dbTalk Databases Forums  

Cluster IP address change and delay

comp.databases.ms-sqlserver comp.databases.ms-sqlserver


Discuss Cluster IP address change and delay in the comp.databases.ms-sqlserver forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
aleu@vp.pl
 
Posts: n/a

Default Cluster IP address change and delay - 05-24-2007 , 03:20 PM






Hi all,

I have recently changed IP addresses on my MS SQL cluster (the new IP
addresses belongs to a different network). Both physical node's IP
addresses and resource's IP addresses have been changed.

Everything seems to work fine. The cluster is up and responding
normally. The resources failover to another node when needed correctly.
However, I have noticed that the time it takes for the resource to
failover to another node is much longer than in the past (before IP
addresses change). I have noticed that "Network Name" is the resource
type that causes the delay. Could you please advise if there is
something that I overlooked and needs to be changed.updated as well, so
that groups fail over faster?

Thanks,
Aleu

Reply With Quote
  #2  
Old   
John Bell
 
Posts: n/a

Default Re: Cluster IP address change and delay - 05-27-2007 , 03:45 AM






Hi

<aleu (AT) vp (DOT) pl> wrote

Quote:
Hi all,

I have recently changed IP addresses on my MS SQL cluster (the new IP
addresses belongs to a different network). Both physical node's IP
addresses and resource's IP addresses have been changed.

Everything seems to work fine. The cluster is up and responding normally.
The resources failover to another node when needed correctly. However, I
have noticed that the time it takes for the resource to failover to
another node is much longer than in the past (before IP addresses change).
I have noticed that "Network Name" is the resource type that causes the
delay. Could you please advise if there is something that I overlooked and
needs to be changed.updated as well, so that groups fail over faster?

Thanks,
Aleu
I assume that you have followed http://support.microsoft.com/kb/244980 or
http://msdn2.microsoft.com/en-us/library/ms190460.aspx? Which version of SQL
Server is this?

When did you test the failover as it will take time to propogate the IP
address change. Have you tried to ping each of the servers or resolve the
names in the DNS?

John




Reply With Quote
  #3  
Old   
aleu@vp.pl
 
Posts: n/a

Default Re: Cluster IP address change and delay - 05-28-2007 , 08:17 AM



John Bell wrote:
Quote:
I assume that you have followed http://support.microsoft.com/kb/244980 or
http://msdn2.microsoft.com/en-us/library/ms190460.aspx? Which version of SQL
Server is this?
John, thanks for your response. Yes I did follow MS knowledge base
articles. I have MS SQL server 2005 x64.

Quote:
When did you test the failover as it will take time to propogate the IP
address change. Have you tried to ping each of the servers or resolve the
names in the DNS?
I did the ping commands. Well, I have tested the failover many hours
after that...

Any idea why this is so slow?

Thanks,
Aleu


Reply With Quote
  #4  
Old   
John Bell
 
Posts: n/a

Default Re: Cluster IP address change and delay - 05-28-2007 , 08:59 AM



Hi

On May 28, 2:17 pm, "a... (AT) vp (DOT) pl" <a... (AT) vp (DOT) pl> wrote:
Quote:
John Bell wrote:
I assume that you have followedhttp://support.microsoft.com/kb/244980or
http://msdn2.microsoft.com/en-us/lib...460.aspx?Which version of SQL
Server is this?

John, thanks for your response. Yes I did follow MS knowledge base
articles. I have MS SQL server 2005 x64.

When did you test the failover as it will take time to propogate the IP
address change. Have you tried to ping each of the servers or resolve the
names in the DNS?

I did the ping commands. Well, I have tested the failover many hours
after that...

Any idea why this is so slow?

Thanks,
Aleu
I can't think of any other reasons why this should be an issue if your
DNS and routing are working fine. You may want to try changing it back
and seeing if the time improves.

John



Reply With Quote
  #5  
Old   
aleu@vp.pl
 
Posts: n/a

Default Re: Cluster IP address change and delay - 05-28-2007 , 11:55 AM



John Bell wrote:
Quote:
I can't think of any other reasons why this should be an issue if your
DNS and routing are working fine. You may want to try changing it back
and seeing if the time improves.
Unfortunately, I cannot change it back. Not only the IP addresses of
cluster resources have changed but also, cluster node's IP addresses
(moved to a different network). The "SQL IP address 1" becomes active
very fast (in around 6 seconds), however, "SQL Network Name" takes a few
good minutes (3-4) to change status from "online pending" to "online".

I have checked system logs and found few relevant things:

1. The configuration of the AdminConnection\TCP protocol in the SQL
instance VALIDATION is not valid.

2. Database mirroring connection error 4 'An error occurred while
receiving data: '10053(An established connection was aborted by the
software in your host machine.)'.' for 'TCP://hostname.x.x:2343'.

3. Database mirroring connection error 4 'An error occurred while
receiving data: '64(The specified network name is no longer available.)'.'

4. Configuration option 'Agent XPs' changed from 1 to 0. Run the
RECONFIGURE statement to install.

I do not know whether they are of any use, but (1) seems to be relevant.
What does it mean? Where can I check/change settings of
AdminConnection\TCP protocol?

What is the best place to look for the error logs? Does MS SQL server
store its error logs in some specific files? If so, what is the filename
and it's location?

Sorry for many questions but I am still newbie in this thing.

Thanks,
Aleu


Reply With Quote
  #6  
Old   
John Bell
 
Posts: n/a

Default Re: Cluster IP address change and delay - 05-29-2007 , 01:57 AM



Hi Aleu

On May 28, 5:55 pm, "a... (AT) vp (DOT) pl" <a... (AT) vp (DOT) pl> wrote:
Quote:
John Bell wrote:

I can't think of any other reasons why this should be an issue if your
DNS and routing are working fine. You may want to try changing it back
and seeing if the time improves.

Unfortunately, I cannot change it back. Not only the IP addresses of
cluster resources have changed but also, cluster node's IP addresses
(moved to a different network). The "SQL IP address 1" becomes active
very fast (in around 6 seconds), however, "SQL Network Name" takes a few
good minutes (3-4) to change status from "online pending" to "online".

I have checked system logs and found few relevant things:

1. The configuration of theAdminConnection\TCPprotocol in the SQL
instance VALIDATION is not valid.

2. Database mirroring connection error 4 'An error occurred while
receiving data: '10053(An established connection was aborted by the
software in your host machine.)'.' for 'TCP://hostname.x.x:2343'.

3. Database mirroring connection error 4 'An error occurred while
receiving data: '64(The specified network name is no longer available.)'.'

4. Configuration option 'Agent XPs' changed from 1 to 0. Run the
RECONFIGURE statement to install.

I do not know whether they are of any use, but (1) seems to be relevant.
What does it mean? Where can I check/change settings ofAdminConnection\TCPprotocol?

What is the best place to look for the error logs? Does MS SQL server
store its error logs in some specific files? If so, what is the filename
and it's location?

Sorry for many questions but I am still newbie in this thing.

Thanks,
Aleu
There are quite a few posts if you look for "AdminConnection\TCP"
http://groups.google.com/groups/sear...ction%5CTCP%22
they seems to suggest networking issues (incorrect aliases, firewall
issues etc) or possibly service account permissions.

I assume that the error messages regarding mirroring are related to
the period when you are switching, therefore may be expected.

John



Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.