[Linux-cluster] IP-based tie-breaker on a 2-node cluster?

[Harri.Paivaniemi at tietoenator.com]

What Gordan said is true,

but you could also just tune deadnode_timeout to be different on both nodes: this results the behaviour Gordan told - the node that has smaller deadnode_timeout would fence first.

-hjp



-----Original Message-----
From: linux-cluster-bounces at redhat.com on behalf of Andrew Lacey
Sent: Thu 4/17/2008 18:47
To: Linux-cluster at redhat.com
Subject: [Linux-cluster] IP-based tie-breaker on a 2-node cluster?
 
I am doing some testing on a 2-node, active/standby RHEL 4 cluster with
non-GFS shared storage. I am using HP iLO for fencing. I don't have a
quorum disk set up. Both cluster nodes are connected to the same switch,
and that network path is used for cluster communication as well as general
network communication (including access to iLO). I've found that when the
switch goes down and comes back up, the result is not desirable. As soon
as the switch loses power, each node starts trying to fence the other.
Since the iLO is not reachable, this is unsuccessful, but the nodes keep
retrying the fence. When the switch comes back online, the "OK Corral"
scenario takes place -- both nodes fence each other simultaneously and
bring down the cluster.

I have seen some references to the concept of IP-based tie-breakers on a
Red Hat cluster, but I'm not sure how to set this up. What I would like is
a configuration whereby a node that cannot ping the switch will just sit
there in its current state and not attempt to fence the other node.
Fencing would only occur when a node can reach the switch but cannot reach
the other node. Is this something that can be done? Can someone direct me
to documentation? I have a ticket in with Red Hat on this same question,
so we'll see who answers first :-) Thanks,

-Andrew L

--
Linux-cluster mailing list
Linux-cluster at redhat.com
https://www.redhat.com/mailman/listinfo/linux-cluster

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3678 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20080417/b0a1e6b0/attachment.bin>