On Wed, Nov 7, 2012 at 10:51 PM, Ulrich Windl <[email protected]> wrote: >>>> Dejan Muhamedagic <[email protected]> schrieb am 07.11.2012 um 11:28 in > Nachricht <[email protected]>: >> Hi, >> >> On Wed, Nov 07, 2012 at 06:01:51PM +0900, Josh Bowling wrote: >> > Nevermind, I think I got it. >> > Basically, I just made sure to unplug the NIC used for STONITH while >> > keeping the corosync NIC plugged in when I started the victim server back >> > up. >> > I then made sure that they both saw eachother correctly with `crm status` >> > and then plugged the STONITH NIC back in. No problem. >> >> Normally, you shouldn't have to do this. It sounds like startup >> fencing, but that should happen only in case the other node is >> not "seen" for a while after corosync/pacemaker started. > > Hi! > > I agree that one shouldn't have to do it, but I've seen cases (two node > cluster with quorum-policy=ignore) where one node was down while the > "cluster" wanted to fence both nodes. So when the other node goes up, nodes > will shoot each other.
There is only one case that this is normal... if there is a network malfunction that is preventing the two nodes from talking to each other. Ok, that and if you have a resource that is failing to stop on both node. Anything else is a bug that needs to be squashed ASAP. You reported one for this? > My expectation was that the "cluster" would see that the other node is down > and hasn't to be shot. Likewise it looks stupid if the remaining node insists > of being shot, but refuses to shoot itself. > > So in practice you'll have to interfere more often that you would wish. > > Strange enough that many consultants still recommend two-node clusters. My > guess is they never tried a bigger one... ;-) > > Regards, > Ulrich > >> >> Thanks, >> >> Dejan >> >> > I've tested this method with all of my data and KVMs and it's working >> > without a hitch. >> > >> > Thanks again for all the help. >> > I'll try and return the favor down the road. >> > _______________________________________________ >> > 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 >> > > > > > _______________________________________________ > 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
