Cluster lock disk!!

[astra]

Hello all,

We have a two node serviceguard cluster. It is recommended by HP to use single lock disk as FIRST_CLUSTER_LOCK. If due to any reason the lock disk fails what would be the behavior of cluster. And how to evade this event to occur??

Thanks,
Amit

[Ganesan R]

Hi Astra,

Nothing will happen untill cluster is healthy and running. Cluster lock disk will come into picture and referred only when cluster nodes break the communication and trying to form the individual cluster.

As long as both nodes are running fine and able to communicate, lock disk will not play any role at all.

You can replace the lock disk any time and restore the lock informations.

[Ivan Krastev · Accepted solution]

Lock disk is used only when you have a problem with nodes - failed node, communication problems to form a new cluster with the available nodes. In case of lock disk failure you can replace the lock disk.

regards,
ivan

[astra]

Hello,

Thanks for your reply,

Yes, exactly, if cluster lock disk fails and one node rebooted, then what would be the behaviour and its preventive steps??

Regards,
Amit

[Ganesan R]

Hi,

>>if cluster lock disk fails and one node rebooted, then what would be the behaviour and its preventive steps??<<

In this situation, clustor will not come up since no node can acquire the lock. Preventive step is to make available the cluster lock.

This is the reason why cluster lock is must for 2 node cluster. Because there is high possiblity of cluster breaking equal.

[Eric SAUBIGNAC]

"Yes, exactly, if cluster lock disk fails and one node rebooted, then what would be the behaviour "

It depends on how the node as rebooted :

- gracefully, that is with a shutdown. In this case the node leaves the cluster, the other node acknowledge this situation and when the rebooted node comes back, it joins back the cluster. Every thing is clean and cluster lock disk, though it is failed, has no role in the situation.

- the node is rebooted not gracefully (outage, reset through MP, hardware failure, ...). In this case the other node is not advertised that a member has leaved. So it will try to communicate with it, and after NODE_TIMEOUT it will try to acquire the lock disk. Because the lock disk is not available in your scenario, the second node will TOC. If you are lucky, both nodes will reboot together and join before AUTO_START_TIMEOUT and will form a new cluster. More chance that no (because in fact 1st node is KO), and you will have to start the cluster manually on one node.

Eric

[astra]

Hi Ganeshan,

Thanks for your quick and valuable respopnse.

My cluster lock disk is mirrored. Is there any option available for second cluster lock disk in configuration file. So that if FIRST lock disk fails then second disk could come into play without any loss of functionality.

Regards,
Amit

[Eric SAUBIGNAC]

Astra,

DON'T use this option. There is a potential split-brain situation where both node will start the package :-( It is a beat long to explain there. In a few words suppose you have 1 node and one SAN array in one room and an other node and an other SAN array in another room. Suppose that the SAN connections and etherned connection between the 2 rooms are lost at the same moment. Here is the split-brian situation.

Eric

[Eric SAUBIGNAC]

astra,

Take time to read "Arbitration For Data Integrity in Serviceguard Clusters" at http://docs.hp.com/en/B3936-90078

Eric

[Ganesan R]

Hi Astra,

YES. It is possible. I also read somewhere that this is not recommanded. Maybe the reason could be what Eric explained.

But you can define SECOND_CLUSTER_LOCK_VG and SECOND_CLUSTER_LOCK_PV in cluster ascii file.

See the HP explanations about this.

FIRST_CLUSTER_LOCK_VG, SECOND_CLUSTER_LOCK_VG
---------------------------------------------
The volume group containing the physical disk volume on which a cluster lock is written. Identifying a cluster lock volume group is essential in a two-node cluster. If
you are creating two cluster locks, enter the volume group name or names for both locks. This parameter is only used when you employ a lock disk for tie-breaking
services in the cluster.
Use FIRST_CLUSTER_LOCK_VG for the first lock volume
group. If there is a second lock volume group, the parameter SECOND_CLUSTER_LOCK_VG is included in the file on a separate line.

Lock volume groups must also be defined in
VOLUME_GROUP parameters in the cluster ASCII
configuration file.

FIRST_CLUSTER_LOCK_PV, SECOND_CLUSTER_LOCK_PV
---------------------------------------------
The name of the physical volume within the Lock Volume Group that will have the cluster lock written on it. This parameter is FIRST_CLUSTER_LOCK_PV for the first physical lock volume and SECOND_CLUSTER_LOCK_PV for the second physical lock volume. If there is a second physical lock volume, the
parameter SECOND_CLUSTER_LOCK_PV is included in the file on a separate line. These parameters are only used when you employ a lock disk for tie-breaking services in the cluster.

Enter the physical volume name as it appears on both
nodes in the cluster (the same physical volume may
have a different name on each node). If you are
creating two cluster locks, enter the physical volume
names for both locks. The physical volume group
identifier can contain up to 39 characters.

Hope this clarify you..

[astra]

Hello Eric,

Thanks for your response,

Yes, i was going thru that document.

Regards,
Amit

[Stephen Doud]

A cluster will form regardless of availability of the cluster lock disk.

The cluster lock disk is only queried when all HB networks fail AND an equal number of nodes are separated from one another, as in 2 and 4 node clusters. If this should occur, all nodes would seek the cluster lock disk, would fail to arbitrate, and all nodes will TOC (crash and save a memory dump).

However, if redundant heartbeat networks are configured and use different external networks, the likelihood of the cluster needing cluster lock arbitration falls significantly.

Previous recommendations indicated that dual-lock disks not be configured due to possibility of split-brain. The manual discusses the scenarios where a dual-lock disk may be preferrable over a possible total total outage.

Cluster lock disks are not used (supported) in clusters larger than 4 nodes, limited by SCSI addressing constraints. The quorum server is recommended for larger clusters.

[astra]

Thanks all of you for your valuable informations.