vgchange with ServiceGuard

[kenken_3]

Hi,

Our system has SG running and the two nodes shared the disk storage.

Recently there is a network issue happen to the heartbeat. After it is resolved, all the mount points on the shared disk storage dispper.

They told me I have to shutdown the cluster, then need to run
vgchange -c n
vgchange -a y
then have to manully mount all the mount points. After that, everything is back to normal.

Can somone explains to me why need to run this vgchange?

[RAC_1]

If you can, just restart cluster and that should take care of it.

[rariasn]

Hi kenken,

-c cluster Control the membership of volume groups in a high availability cluster. cluster can have one of the following values:

y Mark each specified volume group as
a member of the high availability
cluster. The high availability
software must be running;
otherwise, the volume group is not
marked. Needs to be done on one
node only.

n Remove each specified volume group
from membership in the high
availability cluster. The high
availability software does not need
to be running.

The volume group must be deactivated with the -a n option before a -c y|n option can be
executed.


man vgchange

rgs,

ran

[nanan]

Hi! kenken
I have a question
who are they ??

and of cause you can do that to mount cluster volumes without regrading clutser lvm deamon.

But as RAC stated, you have to have a reason why need to hadling the volums like that, because it may make a big problem in your data.
So you'd batter use cluster package to mount the cluster volumes with cmrunpkg

Regards
nanan

[Rita C Workman]

Why ?..............Because the person who told you this either doesn't know MC/SG or is trying to get around it by removing the disks from cluster control.

Whoever 'they' are....you need to learn more about MC/SG for yourself, so you don't need to ask 'them' for help, cause you are being steered down a slippery slope.

Rgrds,
Rita

[Stephen Doud]

Perhaps the network outage caused stale NFS mounts, or a package halted (unmounting the file systems) because the package had a subnet dependency and the subnet was considered down.

If you care to investigate further, look at the /var/adm/syslog/syslog.log at the time of the failure, and see what Serviceguard daemons (they begin with the letters 'cm') have to report.

Take the HP Education Center Serviceguard class, read the Managing Serviceguard manual (http://docs.hp.com/en/ha.html#Serviceguard) and keep using the forum to get accurate information about the product.