[Pacemaker] symmetric (anti-)collocation

Andrew Beekhof andrew at beekhof.net
Wed Jan 19 03:41:51 EST 2011


On Tue, Dec 21, 2010 at 11:08 AM, Zrin Žiborski
<zrin+pacemaker at ziborski.net> wrote:
> Hi there,
>
> I've experimented a bit with pacemaker and as far as I can tell (without
> looking
> into the source code enough to distinguish a feature from a potential
> problem),
> the effect of
>     colocation X-Y <score>: X Y
> is (sometimes something) like
> "X gets <score> (added) for running together with Y", while Y "gets
> nothing".

Technically Y[node] should get the score from X[node] multiplied by -1.
Unless this prevents Y from running at all in which case you are
correct and Y gets nothing from X.

Remember that your constraint means "find a place for Y, then pick
somewhere for X based on <score>"

>
> When the scores are summed up it is irrelevant which resource seems to "get"
> the score, but it makes an important difference when pacemaker is searching
> for a solution step by step.
>
> Example: ("testres" is a test-RA, Dummy modified to include failure and
> logging):
> lower depends on starter, but starter should run only when lower is running.
>
> node fo1 attributes standby="off"
> node fo2 attributes standby="off"
>
> primitive lower ocf:custom:testres op monitor interval="10" meta
> is-managed="true"
> primitive starter ocf:custom:testres op monitor interval="10" meta
> is-managed="true"
>
> location starter_fo1 starter rule $id="starter-fo1-rule" -5: #uname eq fo1
> location starter_fo2 starter rule $id="starter-fo2-rule" -5: #uname eq fo2
>
> colocation lower_starter 20: starter lower
>
> order o_starter_lower inf: starter lower symmetrical=true
>
> property $id="cib-bootstrap-options" \
>         dc-version="1.0.9-unknown" \
>         cluster-infrastructure="openais" \
>         expected-quorum-votes="2" \
>         no-quorum-policy="ignore" \
>         stonith-enabled="false" \
>         symmetric-cluster="true" \
>         last-lrm-refresh="1292600052" \
>         default-resource-stickiness="3"
>
> - starter wouldn't run (score -5), but lower "pulls it up", starter gets
> score -5+20=15

I suspect this might be a bug.  Do you get the same behavior with
1.0.10 or 1.1.4?

> - when lower is stopped, starter gets score location+stickiness = -5+3 = -2
> and stops
>
> Now if the order in the colocation rule is changed to "lower starter",
> starter won't start, because "it won't get any score from the colocation
> rule,"
> or this solution is too far to be found ("before end of the universe?" :)
>
> I'll publish the whole example after a bit more testing - it seems that
> there are some
> problems to be solved, like weak dependency behaving like mandatory
> (positive order score
> less than inf behaving same as order score inf) or like resources getting
> allocation score
> greater then infinity...
>
> native_color: lower allocation score on fo1: 31000000
> native_color: lower allocation score on fo2: -3
>
> Best regards,
> Zrin
>
> zrin on #linux-cluster
> zrinjz on skype
>
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs:
> http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>
>




More information about the Pacemaker mailing list