On Fri, Aug 19, 2011 at 01:08:31PM +0200, Dejan Muhamedagic wrote:
> Hi,
> 
> On Fri, Aug 19, 2011 at 11:45:24AM +0200, Maloja01 wrote:
> > On 08/18/2011 12:19 PM, Ulrich Windl wrote:
> > > Hi!
> > > 
> > > Reading the docs, I learned that pacemaker understands more complex 
> > > dependencies than "group" where resources are strictly sequential. For 
> > > example one could start a set of resources in parallel, then wait until 
> > > all are done, then start another set of resources, etc.
> > > 
> > > Now I wonder:
> > > 1) Can such a thing (i.e. parallelism) be configured with crm shell? If 
> > > so, what is the syntax like?
> > 
> > If you have two resources like primitives and they do not have any order
> > constraints (neither explizit by a order constraint nor implizit by
> > membership in group) such resources are assumed be
> > "startable"/"stopable" in parallel and the cluster will do not have any
> > peferences about the order.
> 
> I guess that he meant resource sets. There's a slight confusion
> regarding those and they were to be reimplemented/redefined in
> CRM. Don't know what's the current status.
> 
> > > 2) In some resource groups, not all resources are really required. For 
> > > example in a RAID1, only one of both legs is really required to start up 
> > > the RAID (assuming I need to activate some extra resource for each leg of 
> > > the RAID). Can such a dependency be expressed in CRM? If so, how do you 
> > > do it?
> > 
> > Beside the fact that I do not see the both legs/ 2 x single leg
> > ressources for RAID1 I would say yes that possible but will increase
> > the complexity of the cluster and the most important idea behind
> > clustering is: "keep it simple". In your case the critical point could
> > be the "OR" in the oredring of costraints.
> > 
> > All resouces after your 2 legs solution could be started, if Leg1 OR
> > Leg2 is up. Maybe that has to be described via ordering constraints.
> 
> That cannot be described currently, i.e. start B if at least one
> of A1 and A2 are running.

You can "work around" that, though:

You would need to express your condition via (volatile) node attributes,
similar to ping scores.

monitor and start action, and maybe post-start notification, of the
"legs", could check and add some score to the "raid can run here"
attribute.
If that score attribute is <= 0 or not defined, raid can not run there.
If "enough" legs are available, it can.

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

Reply via email to