FIRST_CLUSTER_LOCK_PV

[Ronald Cogen]

I'm setting up service guard on a two-node cluster. The volume group that forms the package is made up of several (striped) disks. What value must I enter for the FIRST_CLUSTER_LOCK_PV parameter?
Here are the disks in the volume group:
--- Physical volume groups ---
PVG Name /dev/pvgpdb1
PV Name /dev/dsk/c4t6d0
PV Name /dev/dsk/c4t6d2
PV Name /dev/dsk/c11t6d2
PV Name /dev/dsk/c11t6d0
PV Name /dev/dsk/c11t6d1
PV Name /dev/dsk/c4t6d1

What exactly is the function of this parameter?
Cheers,
Ron

[John Poff]

Hi,

You can actually use any of the PVs. The information written to the cluster lock disk goes into the header area used by LVM and doesn't mess with your data area. The cluster lock disk is used by ServiceGuard when there is a problem with the cluster and the cluster needs to reform. The nodes will try to lock the cluster lock disk. The winner forms a new cluster, and the losing node does a TOC. It should only happen if you lose your heartbeat.

JP

[John Poff]

I forgot to add that the cluster lock PV needs to be the same disk for both nodes.

JP

[steven Burgess_2]

Ronald

Have a look at the below

http://www5.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000062686663

and

http://www4.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&admit=-938907319+1033566807050+28353475&docId=200000062922233

HTH

Steve

[Joaquin Gil de Vergara]

the cmgetconf command chooses one by you when you run it to obtain the cluster template config file

leave this value

Cluster Lock is used to choose a cluster master between cluster members in cluster reformations

[Ashwani Kashyap]

YOu can enter any PV name . It is immaterial whether the PV holds data or just an empty PV . THe only thing to remember is that the VG where the cluster lock PV belongs to must be cluster aware and shared by both the nodes .

Cluster lock PV is used to break up the tie in case of cluster failure . When exactly 50% of nodes try to reform the cluster , the node which grabs the clustr lock PV first forms the cluster .

For eg . in you two node cluster , say there is a complete heartbeat failure , only hear beat failure nothing else . In this case both the nodes will think that the other node has died and both of them will try to reform the cluster . Here the cluster is exactly split in 50% . To resolv this , the cluster lock PV comes in the picture . Here the node which grabs the cluster lock PV first , will be able to reform the cluster , while the other node will TOC .

Note that in a two node cluster , a cluster lock PV is an absolute must .

Usually the disk with the fastest access time is used for the lock disk . IF you run cmcheckconf or amscancl , it will suggest you which disk to use . But as I said earlier , you can use any disk .

[Ronald Cogen]

Thanks to all of you so far. If I run the procedure that creates the ascii file I get the following parameter:
FIRST_CLUSTER_LOCK_PV /dev/dsk/c??t0d0

Surely I have to replace this value or is it some kind of dynamic parameter?

Ron

[Joaquin Gil de Vergara]

leave it

MC/SG Admin manual says that run

# pvchange -t 0

after run the cmapplyconf command

regards

[Ronald Cogen]

I forgot to mention that my two node cluster is not really a cluster in the strict sense. One of the nodes functions as a test environment for the production. That means that this test environment will take over the package from the production but not the other way around. Also, if the production node crashes we start the package manually! I haven't set up the heartbeat yet. That is also another question. Do I need the heartbeat in such a scenario?

[John Poff]

Ron,

You'll have to set that parameter in your config file to a specific PV. Just pick one that is common to both nodes and put that in the entry. For example:

FIRST_CLUSTER_LOCK_PV /dev/dsk/c4t6d0

If you decide to use that disk. Just pick a disk and go for it.


JP

[John Poff]

Ron,

You'll definitely need a heartbeat. You can use your regular data LAN for the heartbeat, but I strongly suggest setting up a separate LAN just for the heartbeat in case your data LAN gets saturated or goes down. Most all the HP servers come with a built in LAN card that works great for the heartbeat LAN if you aren't already using it. What kind of hardware are your systems?

JP

[Dietmar Konermann]

Ron,
do you really get /dev/dsk/c??t0d0... I mean, do you really get the question marks?

If yes, pls tell me SG revision and patch level... :)

Regards...
Dietmar.

[Ronald Cogen]

This one is for Dietmar.
I'm not sure whether that parameter was generated or whether one of my collegues put that there to remind me of something.

In any event, the SG version is A.11.14.
I'm not sure what you mean by 'patch level' so I took the Quality Pack version from the 'swlist -l bundle' output.

Do you mean, I shouldn't get the parameter with question marks?

[Ronald Cogen]

The Quality Patch Level is B.11.00.51.01

I forgot to put that in in my last replay ....

[Dietmar Konermann]

Hi, Ron!

Correct. You need to enter the real path to the disk... no wildcards.

And ServiceGuard's cmquerycl should NOT generate a template containing theses wildcards... instead it should pick one of your disks as cluster lock device.

With the term patch-level I meant the installed ServiceGuard patch.

Regards...
Dietmar.

[Ronald Cogen]

Dietmar,

How do I get the software patch level specifically for service guard?

[Dietmar Konermann]

E.g.
swlist -l product |grep -i serviceguard

If no patch is listed then you have vanilla 11.14 and should install PHSS_27246 anyway.

But until now we still don't know who put that "??" in the file...

Regards...
Dietmar.

[Ronald Cogen]

Dietmar,

Did you look at the response from Joaquin. If I read him correctly, it implies that cmapplyconf would generate the information automatically. Is this correct?

[Ashwani Kashyap]

Hi Ron ,
These errors mean that the PV's are not recognised by LVM yet . Did you do a pvcreate on the disks ?

[melvyn burnard]

First, I need to correct a few answers you have received.
1. from Joaquin. This is not correct at all, it will not help you. If the vg is configured and set up correctly on both nodes, it should automatically fill in hte relevant PV

2. from Ashwani. The first set of messages are NOT errors, but Warnings indicating discs have not been prepared. A CDROM is good example of this. The second set which are errors, indicate there is a conflict in the VG/PV set up for the discs specified.

Now to carry on, it appears your shared VG is not correctly set up on both nodes. Do you have the same minor number for the shared vg on both systems? do they have the same number of PV's listed in /etc/lvmtab?
Did you have the VG activated when you did the cmquerycl to create the ascii file?

Finally, the patch bundle you have will NOT have any SG patches available, htese are not part of a standard bundle. You will need ot load the lates patch for the version of SG you are using, obtainable form htis site.

[Ronald Cogen]

Fistly, I'd like to thank everyone at this point for all the helpful responses. But, I am still not clear on a few points.

Melvyn: At the moment the cluster is not running. The VG is mounted normally (i.e. not via service guard). I don't know what you mean by 'shared VG'. This is a one-way cluster, because we're using a test server as the backup, so the disks are transparent from only one side.

[melvyn burnard]

Ah, I am confused here. You stated:

I'm setting up service guard on a two-node cluster.

So is this a single node or a two node cluster?
If a single node, then you do NOT need a cluster lock disc. simply comment out or delete the lines referring t the cluster lock VG/PV
If it is a two node cluster, you MUST have a cluster lock disc, and hence you MUST share a vg, as per te manual Managing MC/ServiceGuard viewable at http://docs.hp.com/hpux/ha

[Animesh Chakraborty]

Lock Disk Parameters: Use the FIRST_CLUSTER_LOCK_VG and
FIRST_CLUSTER_LOCK_PV parameters to define a lock disk.
The FIRST_CLUSTER_LOCK_VG is the LVM volume group that
holds the cluster lock. This volume group should not be
used by any other cluster as a cluster lock device.

The disk must be seen from both the nodes to work in cluster.
I would suggest you to read the mcsg document first to avoid further confusion.

Thanks
Animesh

[Ronald Cogen]

Melvyn,

Thanks for continuing this. I'm finding out how much I still don't know about sg.
Anyway, I guess you could call it a two-server 'cluster' with one server serving as a failover for the other. Accordingly, it is probably not a 'cluster' in the strict sense.
Well, what would you call this configuration?

Thanks to everybody for the useful comments.

Ron