How does Service Guard deactivate/reactivate shared volume groups.

[Ash Holzheimer]

Can anyone help me with this question. If there are 2 nodes in a SG cluster and one fails, say it loses power. Say the node that failed was running some package. As I understand it, the other node will go for the lock disk and get it. It will then have control of the cluster. The volume group for the SG package (say vg01) was activated in exclusive mode on the failed node but wouldn't have been deactivated and the file systems would't have been unmounted and had their superblocks flagged as clean.

Is the cmlvmd responsible for the mode of vg activation? ie. because that node has failed, the cmlvmd on the active node can then activate vg01 exclusively, even though it hasn't been deactivated from the failed node. If this is the case, I presume that the file system/s for the package will then have to be remounted on the new node and the fsck'd. Is this the case?

TIA,
Ash.

[Robin Wakefield]

Hi Ash,

The logic for this should be in your control script, to be found in /etc/cmcluster/{package-name}/{control-script-name}. Towards the bottom you should see something like:

if [[ $1 = "start" ]]
then
print "\n\t########### Node \"$(hostname)\": Starting package at $(date) ###########"

activate_volume_group

check_and_mount

add_ip_address

get_ownership_dtc

customer_defined_run_cmds

start_services


# Check exit value

if (( $exit_value == 1 ))
then
print "\n\t########### Node \"$(hostname)\": Package start failed at $(date) ###########"
exit 1
else
print "\n\t########### Node \"$(hostname)\": Package start completed at $(date) ###########"
exit 0
fi

Rgds, Robin

[melvyn burnard]

>Is the cmlvmd responsible for the mode of vg activation? ie. because that node has failed, the cmlvmd on the active node can then activate vg01 exclusively, even though it hasn't been deactivated from the failed node. If this is the case, I presume that the file system/s for the package will then have to be remounted on the new node and the fsck'd. <

Correct, the package manager on the surviving node starts up the package on this node, and part of the activation is to try to activate the vg exclusively. As the other node is not available, it does not have the VG, so this gets activated, and any fs with the dirty bit set gets fscked as part of the start up script.

[John Waller]

Ash,

I believe the main trick is when you create the cluster, the Volume Groups which are configured to be controlled by ServiceGuard are marked as cluster aware (vgchange -c y. I would think that this has some form of special function to allow a VG to be activated without being deavtivated on an alternate node.

[Sanjay_6]

Hi Ash,

Take a Look at the thread below,

http://docs.hp.com/hpux/onlinedocs/B3936-90053/B3936-90053.html

Look for the section "Understanding MC/ServiceGuard Software Components"

You can also look at "How Package Control Scripts Work".

Hope this helps.

Regds