Clusterlock and multipath

[Albert Pauw]

For the installation of a 2-machine HP-UX cluster I am going to use two SANs, located in two different rooms. Since every HP-UX machine is connected via fibrechannel to two fabrics using two HBAs I will see the disk space on every SAN twice. Putting the two disks (or actually two FC paths) in a VG gives me the multipath faulttolerance.

The idea is to have two clusterlock volumes, on each SAN one. So having the two SANs faulttolerant. How do I configure this?
All other network requirements are met (heartbeat etc).

For the two cluster lock parameters: FIRST_CLUSTER_LOCK_VG and SECOND_CLUSTER_LOCK_VG I can use the two volumegroups on both SANs.

What I am puzzled about is how to set the FIRST_CLUSTER_LOCK_PV en SECOND_CLUSTER_LOCK_PV parameters with the two paths to each SAN volume.

Thanks,

Albert

[Stephen Doud]

Concepts of dual cluster locks are discussed in this document - http://docs.hp.com/en/B3936-90095/B3936-90095.pdf
--- pg 72.
It is important that you understand the principles and drawbacks of a second cluster lock volume group.

The cluster ASCII configuration file can accommodate only one path for each cluster lock device.

The parameters appear as:
FIRST_CLUSTER_LOCK_VG
SECOND_CLUSTER_LOCK_VG (add manually)
and in each nodes' descriptive section:
FIRST_CLUSTER_LOCK_PV
SECOND_CLUSTER_LOCK_PV (add manually)

Even though it is not possible to list both paths to the cluster lock device, Serviceguard will be able to start a cluster in the absence of a lock device if necessary.
The lock device is only used to arbitrate a cluster reformation that occurs when heartbeat transmission completely ceases between two equally split subclusters.

== Cluster Reformation Protocol ==
When heartbeat transmission/reception entirely ceases unexpectedly for whatever reason, each remaining node attempts to reform a cluster with any other contactable nodes. The cluster reformation process involves a voting period and assessment of remaining members.

When the number of remaining members in contact with each other is a majority of the original members (up to every original member - ie. transistory HB xmission failure), Serviceguard automatically grants a cluster reformation. After reformation, Serviceguard assesses unowned packages (see the next paragraph) and attempts to start them on active cluster members if so configured and enabled.

When the number of remaining members in contact with each other is a minority of the original members (less than half), Serviceguard automatically forces these nodes to TOC (reboot). This because a 'majority' subcluster may have reformed and taken over packages originally running on this minority subcluster of nodes.
The minority node does not have the time to halt the package when it is forced to TOC.

When the number of remaining members is equal to half of the original members, Serviceguard seeks authorization from the cluster arbitration device to form the new cluster. Losing the arbitration or failure to contact the arbitration device induces a TOC, but only when such arbitration is required to resolve a split-brain condition.