Hi, On Thu, Feb 21, 2008 at 09:00:35PM +0100, Johan Hoeke wrote: > Dejan Muhamedagic wrote: > > Hi, > > > > On Thu, Feb 21, 2008 at 04:09:19PM +0100, Johan Hoeke wrote: > >> Dejan Muhamedagic wrote: > >>> Hi, > >>> > >>> On Thu, Feb 21, 2008 at 01:26:12PM +0100, Johan Hoeke wrote: > >>>> Dejan Muhamedagic wrote: > >>>>> On Thu, Feb 21, 2008 at 12:19:55AM +0100, Johan Hoeke wrote: > >>>>> Oops. So there's an on_fail=fence for this monitor operation. Is > >>>>> that necessary? > >>>> We want the cluster to failover if oracle breaks for whatever reason. > >>>> At least I think we do ;) > >>> But failing over is not the same as fencing. Why would you fence > >>> a cooperating node. > >> Hi Dejan, > >> > >> We're using fibre channel attached storage. I want to fence to protect > >> the data on the SAN. > > > > That's a good cause, but why do you think that the data is > > jeopardized. I mean, if the node is healthy and if it says that > > it doesn't have the disks mounted I suppose that you could > > trust it. That's why fencing is by default done only in case a > > resource can't be stopped. Of course, it is another matter if you > > think that the resource agents may lie or that something else in > > the setup can't be trusted. > > > > Thanks, > > > > Dejan > > > > OK, I understand. I'll change from monitor on_fail=fence to stop > on_fail=fence and test,test,test.
on_fail=fence is default for stop operations as those failures are dangerous. > I have to be super careful that the > SAN filesystem doesn't get corrupted again. That happened the other day > by accident when a wrong ipfilter config was pushed by mistake. The > heartbeat interface was filtered out, a split brain situation occurred > and the SAN filesystem was corrupted. Stonith didn't save us for > whatever reason. You have to have a reliable stonith device. Do you think that on_fail=fence in the monitor op would have made the situation better? > The application managers don't have much confidence in > heartbeat since then. :( That's a shame. Thanks, Dejan > regards, > > Johan > > _______________________________________________ > 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
