Hi, On Tue, Dec 15, 2009 at 03:00:55PM +0100, Alain.Moulle wrote: > Hi, > > I'm trying to clearly evaluate the risk of split brain and the risk of > dual-fencing with pacemaker/openais in > the case I can't chose anything else but having only *one* network for
Oops. > totem protocol : > > Let's say we have a two-nodes cluster with stonith resources : > - if there is a problem on one node (not a network pb) : > the other will became DC (if not yet) and fence the node > in failure. > - if there is a network failure between one node and the eth switch : > each node does not get any token anymore from the other > node, but only the > DC has the right to take a decision in the cluster and > specifically the decision to fence the > other node, so the DC node should fence the other. > The only problem I can see here is if the "not-DC" node > declares itself as new DC before to > be fenced, and therefore will also decide to fence the other > node, which could lead to a > dual-fencing situation. So the fence request from the > initial DC node should happen before the > DC Deadtime value (default 60s) to eliminate any risk of > dual-fencing. Have you ever tried this? If that indeed makes the non-DC node wait with fencing, then that may help. > In any cases, we can't have a split-brain situation if a fence does not > complete successfully. Am I right ? No. It is a split-brain situation as soon as nodes can't communicate. > And if we have a more than two-nodes cluster, it seems similar for me ... No, because the partition without quorum can't fence nodes. That makes things simpler and more predictable. > Am I right about all this ? or did I miss something somewhere ? I'm not sure if my response helps at all. You should test this thoroughly. For instance, we have one bugzilla open for external/ipmi where nodes did shoot each other on split brain. Thanks, Dejan > Thanks for you response. > Alain Moullé > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
