October 28, 2014 at 7:48 am
Good morning experts,
Let me preface by saying that clustering is not my strong suit. That being said, here is the scenario:
We have 2 physical servers configured as a SQL 2008 R2 active/active cluster.
There are two sql instances on each side. All four can reside on one side if necessary.
Out network team is switching the core routers tonight and we will certainly have some network blips and could be down as long as
10 minutes. We are afraid that the cluster could get confused??. We are a hospital, so we need to minimize any issues.
Any ideas on what we should do to protect ourselves.
Thanks in advance.
Mike
“I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant.”...Robert McCloskey
___________________________________________________________________
October 28, 2014 at 10:41 am
mbricker-600840 (10/28/2014)
We are a hospital, so we need to minimize any issues.Any ideas on what we should do to protect ourselves.
Thanks in advance.
Ensure that any disconnections to the clusters public network are made during a scheduled outage\downtime.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
October 28, 2014 at 10:46 am
Yes we have a 5 hour downtime window, but needto stay up as long as possible. We are thinking of pausing the nodes so nothing can move, but we are not sure if that will accomplish what we want (leave the things up on the A side and the others up on the B side).
We just don't want anything to try to move.
Mike
“I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant.”...Robert McCloskey
___________________________________________________________________
October 28, 2014 at 11:06 am
mbricker-600840 (10/28/2014)
Yes we have a 5 hour downtime window, but needto stay up as long as possible. We are thinking of pausing the nodes so nothing can move, but we are not sure if that will accomplish what we want (leave the things up on the A side and the others up on the B side).We just don't want anything to try to move.
It would make sense to fail all instances to node A and mess with the network for node B. Then move all to Node B and mess with the network for node A. Move instances back to preferred nodes when finished, this way all you'll encounter is a brief failover or 2.
Interrupting the public network will initiate a failover, all other networks not used for client communications will usually not affect the cluster
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
October 28, 2014 at 11:14 am
In this case the entire netwrok may go down.
Mike
“I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant.”...Robert McCloskey
___________________________________________________________________
October 28, 2014 at 11:59 am
mbricker-600840 (10/28/2014)
In this case the entire netwrok may go down.
Take the instances offline during this period then and keep the downtime short.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
November 3, 2014 at 12:26 pm
Perry Whittle (10/28/2014)
mbricker-600840 (10/28/2014)
In this case the entire netwrok may go down.Take the instances offline during this period then and keep the downtime short.
+1
November 3, 2014 at 3:05 pm
We ended up pausing both nodes. We resumed them after the downtime possibilities were passed.
Mike
“I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant.”...Robert McCloskey
___________________________________________________________________
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply