On 11/07/11 23:14, Ulrich Windl wrote:
>>>> Florian Haas<[email protected]> schrieb am 11.07.2011 um 14:12 in
> Nachricht<[email protected]>:
>> On 2011-07-11 13:40, Ulrich Windl wrote:
>>> Hi!
>>>
>>> I think I misunderstood "colocation": I thought a colocation means if two
>> resources are running, the should be (or not) on the same node.
>>> In practive however, there seems to be more:
>>> I have two resources, say A and B. A has highter priority than B, and an
>> ordering that B should be started after A. As B depends on resources provided
>> by A, I also added a infnity colocation for A and B.
>>> Now I'm surprised that when I tell CRM to stop B, B is stopped, but A also.
>>
>> It would be helpful if you shared your configuration, rather than
>> paraphrased it. That way we could have figured out if your configuration
>> actually matches the blurb you posted.
>
> OK:
> primitive prm_rksapr00_ping ocf:pacemaker:ping \
> params ... \
> op monitor interval="300s" timeout="60" \
> op start interval="0" timeout="60" \
> utilization utl_cpu="1" utl_ram="1" \
> meta priority="2050" target-role="Started"
> group grp_rksapr00 prm_rksapr00_ip_1 ... \
> meta priority="2000" resource-stickiness="100000"
> target-role="Started"
> order ord_rksapr00_ping_after_saprouter inf: grp_rksapr00 prm_rksapr00_ping
> colocation col_rksapr00_saprouter_ping inf: grp_rksapr00 prm_rksapr00_ping
You probably want to flip the colocation constraint:
colocation col_rksapr00_saprouter_ping inf: \
prm_rksapr00_ping grp_rksapr00
The prose version of your config would then be "start grp_rksapr00 then
prm_rksapr00_ping, and put prm_rksapr00_ping on whatever node
grp_rksapr00 is on".
>
>>
>> It is non-obvious, from your description, how you set a "higher
>> priority" for one resource over another, whether your order constraint
>> is advisory or mandatory, how you placed your colocation constraint, etc.
>>
>>> I wanted B to be more independent of A compared to putting A and B into one
>> group.
>>>
>>> What did I misunderstand?
>>
>> You probably (I'm guessing) missed the fact that colocation constraints
>> are directional. They are not reversible at will.
>>
>> If you have a colocation constraint like
>>
>> inf: foo bar
>>
>> ... then verbalize this as "foo on bar". foo must always run "on bar",
>> that is to say, on whichever node is currently managing bar. What this
>> implies is that if bar isn't running anywhere, foo can't run, either. By
>> contrast if foo can't run anywhere, then bar is unaffected.
>
> OK, so it seems you implemented a strange kind of c "colocation" that is part
> of co-location, and part of "depends_on". I'd like to have clean and separate
> implementations:
>
> For co-location: If "A is near B", obviously "B is near A", so co-location is
> symmetric by nature.
>
> For "depends_on": if "A depends_on B" it makes not much sense if "B
> depends_on A" (is this antisymmetric?)
>
> Your implementation mixed both, a symmetric and a non-symmetric relation.
> Naturally this causes problems.
Have a look at
http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/s-resource-colocation.html
and the following few pages. Also Colocation Explained at
http://clusterlabs.org/wiki/Documentation.
The key point being "you can't place A relative to B unless you know
where B is", so colocation with Pacemaker necessarily involves a
dependency. AIUI implementing fully "symmetric colocation" would mean
Pacemaker may need a semi-infinite amount of time to figure out WTF a
given colocation constraint means. This is undesirable.
HTH,
Tim
--
Tim Serong <[email protected]>
Senior Clustering Engineer, OPS Engineering, Novell Inc.
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
