Cluster formation upon reboot

[John Meissner]

durring SG cluster re-formation you can set the timeout for each box when rebooting. we have our boxes set for 10 minutes. this way as long as each box comes up withing 10 minutes of each other ... everything is fine.

[Shahril M]

Melvyn,
What case are you referring to, when you write "All nodes in a cluster MUST be available to autostart the cluster in htis case."
I ask because Elif wrote ">50%".

From what I understand from your last para, all nodes must be in "starting" status together, in order for the cluster to autostart.
In other words, no one node must be in an "unknown" or "down" status.
Am I right?


John, Elif, Melvyn & others,
/sbin/init.d/cmcluster has a symbolic link /sbin/rc3.d/S800cmcluster.
In this file, there is the following extract:

# Continue trying to join the cluster for up to 10 minutes
while (( ret!=0 && timed_out==0 && error==0 ))
do
...
...
# Check if we've exceeded our time limit
if (( ( SECONDS - start_time ) > 600 ))
then
(( timed_out = 1 ))
fi

done

Now, I had changed the value of AUTO_START_TIMEOUT, ran cmcheckconf and cmapplyconf.

But /sbin/init.d/cmcluster remains unchanged. Is this expected? If so, how would /sbin/rc3.d/S800cmcluster fall into the scheme of things?


Oleg & others,
I did the above while the cluster is down. Would that be a problem? The process completed without any errors.

[melvyn burnard]

Exactly what I say.
For an automaticcluster start to be succesfull, ALL nodes in hte cluster must be available tp start the daemons within the AUTO_START_TIMEOUT time.

Making changes to hte cluster config has NO EFFECT on the files in /sbin/init.d/cmcluster or any of those you refer to. These are nOT meant to be changed other than changing /etc/rc.config.d/cmcluster to a 1 or 0 depending on whehter you want the node to attempt to join a cluster or not.

As for changing the AUTO_START_TIMEOUT parameter, Oleg is incorrect, and you have done it the correct way, i.e. the cluster must NOT be running when changing any timing parameters.

I would recommend you take a read of:
http://docs.hp.com/hpux/onlinedocs/B3936-90065/B3936-90065.html

[Shahril M]

Hi Melvin & others,

One last point I need clarification:
If changing AUTO_START_TIMEOUT does not affect /sbin/init.d/cmcluster, then would not there be an inconsistency between the new value for AUTO_START_TIMEOUT for, say 30sec, compared to the default 10sec in /sbin/init.d/cmcluster?


Rgds,
Shahril

[melvyn burnard]

As per my previous response:
Making changes to the cluster config has NO EFFECT on the files in sbin/init.d/cmcluster or any of those you refer to. These are NOT meant to be changed other than changing /etc/rc.config.d/cmcluster to a 1 or 0 depending on whether you want the node to attempt to join a cluster or not.

[Shahril M]

Hi Melvyn,

Sorry, but I think you missed my point. You have already taught me in your previous post that /sbin/init.d/cmcluster will not be changed when the cluster config is modified.

Now, when the server goes to run level 3, it will execute /sbin/rc.3/cmcluster, which is a symbolic link to /sbin/init.d/cmcluster, with the start parameter.

At this juncture, does it enter into the join_cluster() function? If so, wouldn't it then go throught the loop which times out in 600sec? (which is hard-coded; refer to extract in my earlier post)

I am pretty sure that the AUTO_START_TIMEOUT will somehow take effect, overriding this 600sec, but what I want to learn is, at which point, and how? I am facing 2 conflicting configurations and I am confused!


TIA,
Shahril

[melvyn burnard]

The parameter that takes effect is that which you specify in the cluster ascii file, and which gets compiled in the cmclconfig binary .

Do not worry what is in the /sbin/init.d/cmcluster file

[Stephen Doud]

Hello Shahril,

Have a look at this document:
UXSGLVKBAN00000009
TITLE: ServiceGuard Cluster Formation at Boot Time

Concise information about the topic.

-s.