query about lock disk

[Md. Minhaz Khan]

Dear concern
In my new company i have found volume group "vg_billing_data" is defined as lock disk for MC/Service guard cluster. But this volume group is used for oracle database and this was visible from both nodes(node1 and node2) using vgchange -a s vg_billing_data.

My query is if cluster heartbeat messages fail between two nodes then what happen in this situation?

As far as i know lock disk should be disable from both nodes using "vgchange -a n" command and only aware by cluster using "vgchange -c y"

So my new company cluster configuration for lock disk is right or wrong??
Pls see the attached file with this thred.

[johnsonpk]

Hi Minhaz,

>>>In my new company i have found volume group "vg_billing_data" is defined as lock disk for MC/Service guard cluster. But this volume group is used for oracle database and this was visible from both nodes(node1 and node2) using vgchange -a s vg_billing_data.

The VG_billing_data would be the Cluster lock vg not lock disk.

One of the disk from vg_billing_data can be a cluster lock_disk

there is no problem for activating a cluster_vg in shared mode (using vgchange -a s )

During spilt brain condition ,service guard only try to hold the cluster lock_pv not the vg .

As far I know service guard need the cluster lock_vg to be activated only during cluster creation.(if you are not using the cluster_lock_vg in any of your package..then you may not find this as activated in any of your node even when your cluster is running)


Thanks!!
Johnson


Thanks!!
Johnson

[Matti_Kurkela]

The cluster lock uses a small space in the VG header. Access to that space is not controlled by "vgchange -a" or "vgchange -c".

If the cluster heartbeat messages fail, that is a straightforward ServiceGuard split-brain avoidance situation: both nodes will attempt to write "their" sign in the cluster lock area. The first successful node gets to "be" the cluster and continue the service: the other node will have to stop using any shared resources ASAP, so that node will execute an TOC.

MK

[Md. Minhaz Khan]

Thanks a lot. Please also see the cluster configuration file. There FIRST_CLUSTER_LOCK_VG parameter is /dev/vg_billing_data.

from my previous experience i just use as follows after creation cluster:

#vgchange -a n lock_vg (Both nodes)
#vgchange -c y lock_vg (Both nodes)

Only lock volume group should be know by the cluster but not by nodes(May be i am wrong, if wrong please correct me)

[Sajjad Sahir]

Dear Minhaz

The vgchange command with the -a option activates or deactivates one or more volume groups.

The vgchange command with the -c option controls the membership of one or more volume groups in a high availability cluster. The vgchange command with the -c and -S options control the membership of a volume group and mark it sharable

s:
Activate each specified volume group and all associated physical and logical volume for shared read-write access. The volume group must be marked as part of a high availability cluster and marked sharable; otherwise, the volume group is not activated.

vghange -a n /dev/vgname it will deactivate the volume group
vgchange -a y /dev/vgname it will activate the volume group

thanks and regards

Sajjad Sahir

[Sajjad Sahir]

Please see this one also
Set up volume group /dev/vg03 for use in a high availability cluster:

vgchange -a n /dev/vg03 # Deactivate volume group
vgchange -c y /dev/vg03 # Enable volume group for HA cluster
vgchange -c y -S y /dev/vg03 # Enable volume group for HA cluster
and mark as sharable
vgchange -a e /dev/vg03 # Activate volume group in exclusive mode
vgchange -a s /dev/vg03 # Activate volume group in shared mode


thanks and regards

Sajjad Sahir

[johnsonpk]

Hi

Minhaz>>>Only lock volume group should be know by the cluster but not by nodes

Could you please elaborate that question?


Johnson

[Md. Minhaz Khan]

>Only lock volume group should be know by the cluster but not by nodes

Actually i want to know , in cluster environment lock volume group(for ex:vglock)
should deactive status or active status?

That is after creation cluster did we deactive lock volume group by the command "vgchange -a n vglock" or keep it active status that we activate using "vgchange -a y vglock" before cluster creation

Thnaks
Minhaz

[johnsonpk]

Hi Minhaz,

>>in cluster environment lock volume group(for ex:vglock)
should deactive status or active status?

scenario 1: You are planning to use the cluster_lock_vg in your package :

Deacivate the lock_vg and use it in your package this will inturn activate the lock_vg in appropriate mode (exclusive/shared) depending up on your packge ctl file

scenario 2:you will leave the cluster lock vg as unused.

You can deactivate lock vg to prohibit any accedental use by any one.even though you havent deactivate ,the next node reboot will take care of that since the vg activation process wont activate the vgs that are marked as cluster aware.


Bottomline: The cluster_lock vg need not be activated in any of the node

Thanks !!
Johnson

[Stephen Doud]

Though the cluster lock disk must be associated with an LVM VG, when Serviceguard needs to use the cluster lock structure on the disk, it does NOT use LVM commands but rather ioctl commands to directly address the cluster lock structure on the disk. Therefore, it doesn't matter whether the VG is activated or not.

[Md. Minhaz Khan]

Thanks a lot to everybody to help me.

Thanks
Minhaz