[Pacemaker] Anticolocation problem
Andrew Beekhof
andrew at beekhof.net
Thu Feb 2 21:50:32 EST 2012
The latest code appears to behave ok, so perhaps the problem was since fixed.
Can you send me the output from cibadmin -Ql when the cluster is in
this state so I can confirm?
On Mon, Jan 30, 2012 at 11:38 PM, agutxi Agustin <agutxisol at gmail.com> wrote:
> Hi guys,
> I'm trying to setup some anticolocation rules, but I'm finding some
> strange behaviour and not getting the desired effect, so I wonder if
> I'm missing something or there is really some problem with my
> setting.If you could lend me a hand that would be great.
>
> The scenario: 3 Dummy resources running based on utilization (1 core
> for each resource running) on 2 nodes, each with 2 cores capacity.
> Plus: Anticolocation rules: No 2 resources can run in the same node (I
> know in this case I could limit this with utilization, but this is
> just a test case from a bigger scenario where I detected the problem)
> Configuration:
> _______________________________________________________________________________
> crm(live)# configure show
> node vmHost1 \
> utilization cores="2"
> node vmHost2 \
> utilization cores="2"
> primitive DummyVM1 ocf:pacemaker:Dummy \
> op monitor interval="60s" timeout="60s" \
> op start on-fail="restart" interval="0" \
> op stop on-fail="ignore" interval="0" \
> utilization cores="1" \
> meta is-managed="true" migration-threshold="2" target-role="Started"
> primitive DummyVM2 ocf:pacemaker:Dummy \
> op monitor interval="60s" timeout="60s" \
> op start on-fail="restart" interval="0" \
> op stop on-fail="ignore" interval="0" \
> utilization cores="1" \
> meta is-managed="true" migration-threshold="2" target-role="Started"
> primitive DummyVM3 ocf:pacemaker:Dummy \
> op monitor interval="60s" timeout="60s" \
> op start on-fail="restart" interval="0" \
> op stop on-fail="ignore" interval="0" \
> utilization cores="1" \
> meta is-managed="true" migration-threshold="2" target-role="Stopped"
> colocation antidummy12 -INF: DummyVM1 DummyVM2
> colocation antidummy13 -INF: DummyVM1 DummyVM3
> colocation antidummy23 -INF: DummyVM2 DummyVM3
> property $id="cib-bootstrap-options" \
> dc-version="1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c" \
> cluster-infrastructure="openais" \
> expected-quorum-votes="2" \
> stonith-enabled="false" \
> stop-all-resources="false" \
> placement-strategy="utilization" \
> no-quorum-policy="ignore" \
> cluster-infrastructure="openais" \
> stop-orphan-resources="true" \
> stop-orphan-actions="true" \
> symmetric-cluster="true" \
> last-lrm-refresh="1326975274"
> rsc_defaults $id="rsc-options" \
> resource-stickiness="INFINITY"
> _______________________________________________________________________________
>
> Looking around for symmetric anti-collocation information, I found a
> message where Andrew Beekhof stated:
>
>>>>> colocation X-Y -2: X Y
>>>>> colocation Y-X -2: Y X
>>>>>
>>>> the second one is implied by the first and is therefore redundant
>>>>
>>> If only that were true!
>>>
>>
>> It is. I know exactly how my code works in this regard.
>> More than likely a score of -2 is simply too low to have any effect.
>
> so I was expecting my resources to prevent another resource from
> running on the same node.
>
> Test: I start 2 resources: DummyVM1 & DUmmyVM2: they correctly start
> on vmHost1 and vmHost2, as expected (I don't care about location)
> _______________________________________________________________________________
> crm(live)# status
> ============
> Last updated: Mon Jan 30 13:33:19 2012
> Last change: Mon Jan 30 13:30:21 2012 via cibadmin on vmHost1
> Current DC: vmHost2 - partition with quorum
> Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c
> 2 Nodes configured, 2 expected votes
> 3 Resources configured.
> ============
>
> Online: [ vmHost1 vmHost2 ]
>
> DummyVM1 (ocf::pacemaker:Dummy): Started vmHost1
> DummyVM2 (ocf::pacemaker:Dummy): Started vmHost2
> _______________________________________________________________________________
>
> Then, I start the DummyVM3 resource:
>
> _______________________________________________________________________________
> crm(live)# resource start DummyVM3
> crm(live)# status
> ============
> Last updated: Mon Jan 30 13:33:52 2012
> Last change: Mon Jan 30 13:33:50 2012 via cibadmin on vmHost1
> Current DC: vmHost2 - partition with quorum
> Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c
> 2 Nodes configured, 2 expected votes
> 3 Resources configured.
> ============
>
> Online: [ vmHost1 vmHost2 ]
>
> DummyVM1 (ocf::pacemaker:Dummy): Started vmHost1
> DummyVM2 (ocf::pacemaker:Dummy): Started vmHost2
> DummyVM3 (ocf::pacemaker:Dummy): Started vmHost1
> _______________________________________________________________________________
>
> and immediately DummyVM3 is started on vmHost1, though from my
> understanding it shouldnt (anticolocation with -INF score).
> I think the colocation scores are being ignored, is this possible?.
> I checked with "ptest -saL" and it is not showing -INFINITY for my
> colocation rules:
>
> root at vmHost1:~# ptest -saL
> Allocation scores:
> native_color: DummyVM3 allocation score on vmHost1: INFINITY
> native_color: DummyVM3 allocation score on vmHost2: 0
> native_color: DummyVM2 allocation score on vmHost1: 0
> native_color: DummyVM2 allocation score on vmHost2: INFINITY
> native_color: DummyVM1 allocation score on vmHost1: INFINITY
> native_color: DummyVM1 allocation score on vmHost2: 0
>
> Can someone give me any hints as for what I am doing wrong?
> Thank you guys,
>
> Agustín
>
> "Death: Human beings make life so interesting. Do you know, that in a
> universe so full of wonders, they have managed to invent boredom." --
> Terry Pratchett
>
> _______________________________________________
> 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://bugs.clusterlabs.org
More information about the Pacemaker
mailing list