Dejan Muhamedagic wrote: > Hi, > > On Thu, Feb 21, 2008 at 12:19:55AM +0100, Johan Hoeke wrote: >> LS, >> >> Running a 2 node cluster, heartbeat-2.1.3-3 centos rpms, RH AS 4.6 >> >> While testing a "maintenance scenario" for the cluster I set all >> resources to is_managed is false, >> and proceeded to shut oracle by hand, oracle being one of the resources. >> >> Within minutes, the node was stonithed. The log shows that this was >> right after the monitor operation for the oracle resource came back with >> return code 7: >> >> Conclusion: the monitor operation was still running even though the >> resource was unmanaged, and it forced a fencing action. > > 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 ;) We're discussing exactly how we want the cluster to behave. This question is more about understanding why the cluster behaved this way. > >> I then made a script which in addition to changing the resources to >> is_managed = false also set the monitor operations to disabled=true. >> This worked, now I am able to shutdown oracle by hand without a fencing >> action starting up. >> >> Questions: >> >> It this expected behavior? Should monitor operations keep running even >> though the resources are set to is_managed=false? > > Yes. There was some discussion about it and the majority of > votes went this way, i.e. that monitoring should continue even > for the unmanaged resources. OK, thanks for the clarification Dejan! > >> Is explicitly setting >> the monitor operations to disable=true the "right way" to prevent >> unwanted fencing actions during cluster maintenance? > > I'd say yes. But note that I was also in favour of having > monitoring disabled by default. noted ;) and thanks again for your help. regards, Johan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
