
dejanmm at fastmail
Dec 6, 2011, 9:20 AM
Post #6 of 6
(390 views)
Permalink
|
|
Re: disconnecting network of any node cause both nodes fenced
[In reply to]
|
|
Hi, On Tue, Dec 06, 2011 at 05:36:09PM +0100, Lars Marowsky-Bree wrote: > On 2011-12-05T22:37:03, Andreas Kurz <andreas [at] hastexo> wrote: > > > Did you clone the sbd resource? If yes, don't do that. Start it as a > > primitive, so in case of a split brain at least one node needs to start > > the stonith resource which should give the other node an advantage ... > > adding a start-delay should further increase that advantage. > > start-delay=20s or so is a recommended setting here, yes. A patch to > the external.c plugin to actually relay the "start" to the external/* The agent (and external.c) never sees the start action. What would need to be patched in the first place is stonithd. And, of course, we'd need to introduce a new operation for that which would need to be implemented then in all agents. Or, alternatively, stonithd could perhaps learn about supported methods from the agent. Thanks, Dejan > agent would be helpful, or perhaps just adding a 20s delay there > directly ... That'd auto-fix this for all users of sbd. > > > >> * use a quorum node > > > i.e I should add another node(quorum node) in this two node cluster. > > Yes ... you can add a node in permanent standby mode or starting > > corosync without pacemaker should also work fine. > > The latter is probably the better choice, otherwise the node will > participate in the DC elections. > > Alternatively, with the more recent sbd versions, you could also have a > redundant network quorum device via iSCSI; that would prevent the node > which loses network connectivity from fencing the other, since it would > have committed suicide. > > > Regards, > Lars > > -- > Architect Storage/HA > SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) > "Experience is the name everyone gives to their mistakes." -- Oscar Wilde > > _______________________________________________ > Linux-HA mailing list > Linux-HA [at] lists > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list Linux-HA [at] lists http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
|