vcs

[shiv124]

I have couple of following questions.

1.When we freeze a service group persistently(across reboots) if we dont dump the configuration after reboot the service groups would be in freeze state ?

2.when the service groups are freezed persistent.If that node reboots.The service groups would be in offline state after the node comes up Is that correct ?

3.when the service groups are freeze state  i see the resources are in disabled state .but i headr/read still the agents monitor the state of the resource.My understanding if the resource is in disabled state the agents must not monitor.

4.when ever we have complete network maintaince.if the network goes down (assumong all the links on the sam enetwork) the nodes gets fenced each other and all the node gets rebooted.

To avoid this i can do hastop -all -force .but i guess still fencing would happen here and i need to stop my gab fence and llt.What must be the procedure to avoid reboots ?  we want to do this not effecting the applications ?

[arangari]

Answers:

1. Short Answer: Yes. "Think RSM". If you dont dump the configuration, then for a boot-strap of cluster, you would not get the freeze state of group.  However if there is atleast one node still RUNNING, it will remember the information and send-back to rebooting node when it joins the cluster.  

2. Short Answer: Yes. The node when joins and completes the first probe of resources, if it returns the current state of the resources. If the applications under frozen service group are not started during system-up process, you should see the state as OFFLINE.

3. At freeze, the resources are turned into 'Monitor-Only' resources - hence the montior will continue. We do not disable resources.  Where do you see the disabled state?

4. Are you talking about LLT links?

[udas]

The best way is to never have all cluster interconnects in maintenace simultaneously. This ensures availability and business continuity accross the window. If that isn't feasible, is it possible for you to put a bound on the maintenance window duration? In that case, you could set the LLT timer "peerinact" to a value large enough to capture that. This must be done for each LLT link from each cluster node. The lltconfig manual page has the revelant documentation. Please understand that the timer needs to be set back to its original value post maintenance. This cannot be done automatically. Missing this step results in LLT not detecting node / link outages until the new timeout expires. It is imperative to perform this reset ASAP.

[shiv124]

HI Uds/Arangari ,

Thanks for ur replies.

I am talking about LLT Links.I would go ahead and read "UDS" recomenadtion on LLT peer inact.

what are the other  alternatives I hve  to avoid the nodes getting rebooted without effecting the service groups (i would freeze the service groups too) when my activity of all LLT  links going down on all nodes.

Thanks

Siva

[shiv124]

Any suggestions Please ?

[g_lee]

Regarding your query

"what are the other  alternatives I hve  to avoid the nodes getting rebooted without effecting the service groups (i would freeze the service groups too) when my activity of all LLT  links going down on all nodes."

If all your LLT links go down, it's expected the nodes will be fenced/rebooted - this is the intended behaviour.

LLT links should be configured on different networks for this reason (you mentioned in your original post "4.when ever we have complete network maintaince.if the network goes down (assumong all the links on the sam enetwork) the nodes gets fenced each other and all the node gets rebooted." - the links should not be on the same network in the first place)

If you only have 1 private network available, perhaps look at configuring a low-pri link on one of the public links (so as long as maintenance occurs one network at a time the heartbeat can still go over the available link)