Is quorum disk mandatory for gfs sharing ?

[Jean-Yves Picard]

Hello,

short version: Do I need a quorum disk for a gfs shared among two host ?

long version:

I have two redhat 5.3 hosts, and I need to have a shared ressource between them.
SAN ressource is shared, I have setup cluster with
-two node option
-no quorum disk
-no fence command

If I bring down a lan interface, remaining host can no longer acces gfs data until failed host is rebooted.
I know I can setup fence to automatically reboot other host, but if one node is down due to real hardware failure, my data won't be accessible until problem is fixed.

How can I access data with two nodes if they are up, and the remaining node if one is down ?
That sound simple, I thought gfs would do the job, but obviously it doesn't ...

Jean-Yves Picard

[Steven E. Protter]

Shalom,

Quorom disk, last I read is not mandatory, but it is quite useful. It improves reliability of the cluster and fail over.

You should be able to live without it if you have reliable fencing.

SEP

[Serviceguard for Linux]

Just as Steven says, you need a fence command.

When a node is detected as failed, the other node cannot continue until the fence command completes. The reason: the system cannot differentiate a hang from a failure. Since a node can come out of a hang, that could cause a corruption. Fencing protects against this.

[Matti_Kurkela · Accepted solution]

> If I bring down a lan interface, remaining host can no longer acces gfs data until failed host is rebooted.

This is slightly incorrect.

When the RedHat Cluster/GFS is properly set up, it should work like this:
if you bring down a LAN interface, the remaining node stops accessing GFS until it gets a confirmation that the failing node has been successfully fenced out of the cluster.

Once the fencing has been confirmed, the remaining node should resume accessing GFS.

If the fence operation causes the failing node to reboot, it can automatically re-join the cluster once its reboot is complete, if it has the necessary network connectivity to access the cluster-wide GFS locks (managed by the cluster DLM infrastructure).

If the failed-and-rebooted node does not have network connectivity, the rejoin operation will time out and the cluster will remain in single-node operation until the sysadmin fixes the network problem and manually re-joins the node to the cluster.

If the fencing operation is not conclusively successful, the state of the failed node is unknown to the rest of the cluster.
To recover from a node failure (e.g. by transitioning to a single-node operation), the state of all nodes must be known. This can be achieved by either the failed node rebooting on its own and rejoining the cluster (announcing that it's up again), or by the fencing system confirming that the failing node is now definitely down.

MK

[Jean-Yves Picard]

Hello,

thanks for all replies,

I've setup fencing on hosts and waiting for more test to be done.

Matti and Serviceguard (Is that your name ?), you gave me some understanding of Redhat philosphy.

Il'll be back once test are done.

Jean-Yves

[Serviceguard for Linux]

Obviously "serviceguard" is not my name. :))

My name is Rick. I've been dealing with SGLX for years. This list seems to be slowly migrating to a general Linux HA list since SGLX has been discontinued.

[Jean-Yves Picard]

Hello,

thanks all for your help, I add a fence command, and now it worked as expected.

one more cluster mecanics learned !! (HA-CMP, Tru64, ServiceGuard HP-UX, and now GFS ... what next ? )

Jean-Yves

[Jean-Yves Picard]

quorum is not mandatory, fence is