[Linux-HA] master slave colocation question

[Andrew Beekhof]

On Nov 13, 2007, at 10:17 AM, Cousin Marc wrote:

> Le Monday 12 November 2007 17:41:18, vous avez écrit :
>> On Nov 12, 2007, at 5:13 PM, Cousin Marc wrote:
>>> Le Monday 12 November 2007 16:13:45 Andrew Beekhof, vous avez  
>>> écrit :
>>>> On Nov 12, 2007, at 2:29 PM, Cousin Marc wrote:
>>>>> Hi,
>>>>> I'm trying to figure out the actual behaviour of heartbeat (I'm
>>>>> using
>>>>> 2.1.2+hg.11310.702e4f418ca8-2, as provided for debian sid)
>>>>>
>>>>> I'm sorry if it's a bit long and complicated, don't hesitate to  
>>>>> ask
>>>>> me to
>>>>> clarify some parts ...
>>>>>
>>>>>
>>>>> I've detailed the steps I'm following, as I've found several  
>>>>> docs in
>>>>> the wiki
>>>>> contradicting each other.
>>>>>
>>>>> I'm trying for my tests to build a 3 node cluster (drbdtest1, 2  
>>>>> and
>>>>> 3), with 2
>>>>> nodes hosting a drbd device, and one resource group having to be
>>>>> collocated
>>>>> with the master drbd resource.
>>>>>
>>>>> First, I create a drbd resource ...
>>>>>
>>>>> No problem here. Without constraints, it's running anywhere.
>>>>>
>>>>> I'm adding a location constraint telling heartbeat not to run on
>>>>> drbdtest3 ...
>>>>>
>>>>> cibadmin -o constraints -C -X '
>>>>> <rsc_location id="place_r0" rsc="cloner0">
>>>>>        <rule id="prefered_place_r0" score="-INFINITY">
>>>>>          <expression attribute="#uname" id="colocr0_1"
>>>>> operation="eq"
>>>>> value="drbdtest3"/>
>>>>>        </rule>'
>>>>
>>>> that will work, but you're better off with a rsc_colcation  
>>>> constraint
>>>> (also set the score=-INFINITY)
>>>>
>>>>> It's OK, now it's not running on the third node. It's activating a
>>>>> master on
>>>>> drbdtest1.
>>>>>
>>>>> Then I create my resource group ('applisr0'), with no constraints
>>>>> for now.
>>>>>
>>>>> It's OK, but of course, with no constraints, it's not running  
>>>>> where
>>>>> it should.
>>>>> In fact, it's running on the third node.
>>>>>
>>>>> Then I put a constraint telling it not to run on a stopped node.
>>>>>
>>>>> cibadmin -o constraints -C -X '<rsc_colocation
>>>>> id="r0_et_applis_stopped"
>>>>> from="applisr0" to="cloner0" to_role="stopped" score="-INFINITY"/>
>>>>>
>>>>> It's not working. The group is still trying to start on the third
>>>>> node.
>>>>
>>>> Instead of a double negative, just go with a positive:
>>>>
>>>> cibadmin -o constraints -C -X '<rsc_colocation id="r0_et_applis"
>>>> from="applisr0" to="cloner0" score="INFINITY"/>
>>>>
>>>>> I've tried a lot of other configurations. I think that 'stopped'  
>>>>> is
>>>>> not
>>>>> working...
>>>>>
>>>>> The most obvious way to verify it is this :
>>>>>
>>>>> if I replace the previous constraint with :
>>>>> cibadmin -o constraints -U -X '<rsc_colocation
>>>>> id="r0_et_applis_stopped"
>>>>> from="applisr0" to="cloner0" to_role="stopped" score="+INFINITY"/ 
>>>>> >'
>>>>>
>>>>> the resource isn't running anywhere. I think it means that every
>>>>> node is
>>>>> considered to be in the stopped role.
>>>>>
>>>>>
>>>>> I can make it work this way :
>>>>>
>>>>> cibadmin -o constraints -C -X '<rsc_colocation
>>>>> id="r0_et_applis_master"
>>>>> from="applisr0" to="cloner0" to_role="master" score="+INFINITY"/>'
>>>>>
>>>>>
>>>>> So, to sum it up, it seems to me that the stopped role is seen as
>>>>> true on
>>>>> every node...
>>>>>
>>>>> Am I right ?
>>>>
>>>> For clones, this may be correct.
>>>> Most people find the regular way sufficient but there's no argument
>>>> that the double negative should also work.
>>>>
>>>> If you'd like to log a bug in bugzilla I will make sure it gets
>>>> fixed.
>>>
>>> Okay, but I still don't get it completely :
>>>
>>> <rsc_colocation id="r0_et_applis_stopped" from="applisr0"  
>>> to="cloner0"
>>> to_role="stopped" score="-INFINITY"/>
>>>
>>> And
>>> <rsc_colocation id="r0_et_applis_master" from="applisr0"  
>>> to="cloner0"
>>> to_role="master" score="+INFINITY"/>'
>>
>> I didn't include to_role="master" in the inverse constraint
>
> So I get it even less :)
>
>
> Doesn't it mean that we would just tell heartbeat that we want to  
> start
> applisr0 anywhere where cloner0 is started ?

yes, that's what

<rsc_colocation id="r0_et_applis_stopped" from="applisr0" to="cloner0"
to_role="stopped" score="-INFINITY"/>

does too.

so i assumed thats what you wanted.

>
> I want it to applisr0 run anywhere where cloner0 is master.

then you only need the second one

<rsc_colocation id="r0_et_applis_master" from="applisr0" to="cloner0"
to_role="master" score="+INFINITY"/>'

> The idea behind what I was doing was that I would put -INFINITY  
> anywhere I
> wouldn't want applisr0 to run (stopped and slave), and a small score
> (something like 100) where I would rather have it to run (my  
> preferred node
> for applisr0).

sure, in theory that should also work (though you've demonstrated that  
it doesn't and i need to fix that)

> If I put +INFINITY as a score for colocation, wouldn't hearbeat  
> consider that
> as long as cloner0 and applisr0 are at the same place, the score is
> +INFINITY, wherever it can make both of them run ?

no, your +100 preference would still take effect... it would determine  
which clone instance we decided to colocate it with