[Linux-HA] resource group design question (2)

Andrew Beekhof beekhof at gmail.com
Mon Oct 15 03:35:35 MDT 2007

On 10/13/07, Daniel X Moore <dxm at sgi.com> wrote:
> Andrew Beekhof wrote:
> \
> >> Also, there's no way for the program which makes the change to
> >> synchronize against the plugin starting/stopping the sub-resource. eg:
> >> you add a sub-resource, but there's no way to ask HB when that change
> >> has actually taken effect.
> > why ask HB? - you're the one starting it... wouldn't you know when its done?
> The controlling app asks HB to change the value in the CIB. The CIB
> change happens, triggering the call to the RA to stop/start or reload.

That sounds incredibly messy.

> But that change happens asynchronously (I think), some time after the
> CIB change, and perhaps on another node. AFAICT, there's no reliable way
> for the controlling app to detect that the change has taken effect. If
> the resource isn't currently running, no change actions are even required.
> > fancyRAstart() {
> > for subrsc in rsclist; do
> >    phase1start
> > done
> >
> > for subrsc in rsclist; do
> >    phase2start
> > done
> >
> > ...
> >
> > }
> you got it.
> >
> >
> > and presumably the reverse for stop.  no?
> yep.
> >>>> Hope this explains it!
> >>> not really - but maybe i'm thick
> >> more likely, I'm not explaining it properly. It'd be easy with a
> >> white-board.
> >
> > ok... draw me a couple of gifs or powerpoint slides :-)
> See attached. We have one or more HB groups ("ga"...) with multiple HB
> RAs within ("ra"...). Each RA does things in several phases ("sa"...).
> RAs can be added, removed or reloaded independently.

started and stopped independently as well?
does any other resource ever need to know which start phase a given child is in?

> BUT when we start a group, we want to reorder the phases for the
> resources in the group so that the whole group starts up efficiently and
> correctly. Ditto for stop.
> The best idea for an extension I've come up with is to allow a group to
> specify a controlling RA which intercepts any action destined for one or
> more RAs in the group. That RA could deal with actions as it sees fit
> (perhaps by dispatching them to the other RAs in the group).

Here is the problem... you're trying to create a cluster with two
brains which can't ever end well.

Your RA is only going to get one action at a time from the CRM - which
I doubt is going to be enough information on which to make an
intelligent decision.

Maybe we're saying stop because the resource should stop, maybe
because it should be restarted after a failure or maybe we're moving
it to another node... only the PE knows.

An improvement would be to make the group completely opaque to the CRM
and for the RA to interact with the lrmd directly (via lrmadmin) when
starting/stopping/monitoring its children (at least the actions would
be synchronous) but thats still going to be non-optimal for the same
stop/retart/move reasons above.

Lars suggested containers but even that is not going to help if you
want the RA to dynamically decide what the "correct" order events is.

Can you give us some concrete example of the re-ordering you'd have the RA do?

What would happen if you added an extra child resource to the start?
middle? end?
Will it always behave like that or does it depend on what the resource does?
If "it depends", is there a finite set of possibilities?

> The key is that the group RA would need to know which RAs an action
> applied (ie a specific RA or all RAs in the group).
> --
> -------------------------------------------------------------------
>   Daniel Moore                              dxm at sgi.com
>   Engineering Manager: AppMan + HA          Phone:  +61-3-9963-1957
>   SGI Australian Software Group             Mobile: +61-4-1360-4720
> -------------------------------------------------------------------
> _______________________________________________
> Linux-HA mailing list
> Linux-HA at lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems

More information about the Linux-HA mailing list