>>> 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. 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
