Hi, On Wed, Jan 30, 2008 at 04:05:41PM +0100, Andreas Mock wrote: > > -----Urspr?ngliche Nachricht----- > > Von: General Linux-HA mailing list <[email protected]> > > Gesendet: 30.01.08 13:44:53 > > An: General Linux-HA mailing list <[email protected]> > > co-incidentally, i've been thinking about such a feature recently... > > i'm inclined to think that this functionality should be in the LRM > > (ie. its a threshold for escalating to the CRM). > > > > thoughts? > > My thoughts if anyone is interested: > > The result of the monitor action should be: > a) Resource is running. > b) Resource is not running. > > But does it imply that it is running healthy? As the result of > the monitor action determines what happens to the resource, > I would say "YES".
Right. > So the question is: > Does the resource run in a way able to fulfill it's service? (Yes/No) > But IMHO this question implies that the RA tries/should try to do as much > as necessary to test the service-ability. This can be pretty much. > Sometimes too much if the service is doing what it should: Working hard! That's why multiple levels of monitoring are available. > Timeout means: Nothing, no answer. That's equivalent to no service. We can't say why though. > What shall I do with this information? As I said before: Shall I assume > that something is wrong or everything is o.k. > Is everything o.k. if a service is producing so much load that I'm not even > able to get the output of 'ps -ax'? > > What is the difference between aksing once with long timeout and multiple > times with short timeout. (If I measure the time, I could know in both cases > that the RA need (too) long to get an answer). > > IMHO not the timeout of the monitor action is the big problem, but the > possible > chain reaction you get after this: > monitor timeout because of heavy (regulsr) load => stop action triggered => > stop action times out (RAs try to do a graceful shutdown) because of heavy > load => > MESS (node fencing or resource in unmanaged state). > > My proposal: Make the timeout for monitor long enough. If timeout occures > assume > that there is really something wrong because a "simple" monitor action does > not work. > => Stop resource. Implement a two-step stop action (probably in the RA > itself): > 1) Try a graceful stop of resource. (e.d. db shutdown) > 2) After inner timeout stop/kill resoure brutal (if possible) > 3) If this doesn't work, signal timeout to upper instance which results in > known behaviour. The higher instance (LRM) has timeouts too. The RA should try to stop the resource at any cost. Reasonable exceptions allowed. If it can't stop the resource then it should let CRM deal with that which typically results in a STONITH operation. > What would someone win: Kill one resource brutally with the hope all other > resources > still remain intact. > > Of course interested to hear other aspects. :-) There's still certain set of resources which are (unfortunately) unreliable and can occasionaly timeout. I can recall some STONITH devices which would timeout once out of a hundred times or so. For those, a monitor failure could be considered transient. Perhaps a database with occasional high load too. Under some circumstances, i.e. if the software runs as it should and the high load is not result of a flaw, it would be preferable not to failover but to wait. Thanks, Dejan > > Best regards > Andreas Mock > > _____________________________________________________________________ > Unbegrenzter Speicherplatz f?r Ihr E-Mail Postfach? Jetzt aktivieren! > http://www.digitaledienste.web.de/freemail/club/lp/?lp=7 > > _______________________________________________ > 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
