[Linux-HA] Antw: Re: location and orders : Question about a behavior ...
alain.moulle at bull.net
alain.moulle at bull.net
Fri Aug 5 03:26:02 MDT 2011
I was the guy who intiate this thread with a simple question, but
this thread has been re-oriented with other similar questions ...
so I don't know who is answering to anybody else ... please Fabian,
if you can just reopen my first msg in this thread, it would be nice
for me ...
Thanks a lot anyway.
De : Maloja01 <maloja01 at arcor.de>
A : linux-ha at lists.linux-ha.org
Date : 05/08/2011 11:02
Objet : Re: [Linux-HA] Antw: Re: location and orders : Question about a
Envoyé par : linux-ha-bounces at lists.linux-ha.org
On 08/05/2011 08:30 AM, Ulrich Windl wrote:
>>>> Maloja01 <maloja01 at arcor.de> schrieb am 04.08.2011 um 18:49 in
> <4E3ACD86.1020104 at arcor.de>:
>> Hi Ulrich,
>> I did not folow the complete thread, just jumped in - sorry. Is the
>> resource inside a resource group? In this case the stickiness is
>> multiplied. And sofor the stickiness could be greater than the location
>> role (score).
> Yes, a group with about 20 resources has a resource-stickiness="100000"
In this case - if I remeber that correctly the scores for a RUNNING
group is 20*100000 -> 2000000 > 500000.
Can you describe your problem, what are you missing?
a) You want to have a RUNNING group NOT to do a fallback -> Stickiness
should do that here: 2M ("active" node) >500K (preferred node) [if
activenode <> preferred node ;-)]
b) You want to have a STOPPED group to be placed on a specific node (to
have an "ordered" administartion at least at the start-point -> location
score should help here 500K (preferred node) >0 (not preferred node)
I miss the point where you argumented, that stickiness is not
implemented as you expected it would be implemented. Could you explain,
whats missing or wrong? Maybe we can try it in a state description like
status-before (f.e. group on node1), change in the cluster (either event
or admin based) and status-after (here the current implemented one and
the one that you expected how it should work).
and a "location loc_grp_cbw grp_cbw 500000: node". As the group is
somewhat indivisible, assigning varying stickinesses to individual
resources just makes things unreadable and complicated. I feel that a
group stickyness should override individual resource stickynesses, and
not be used a a default stickyness for every resource in the group.
>> On 08/04/2011 03:10 PM, Ulrich Windl wrote:
>>>>>> Maloja01 <maloja01 at arcor.de> schrieb am 04.08.2011 um 12:58 in
>>> <4E3A7B5C.1030900 at arcor.de>:
>>>> On 08/04/2011 08:28 AM, Ulrich Windl wrote:
>>>>> Isn't the stickyness effectively based on the failcount? We have one
>>>>> that has a location constraint for one node with a weight of 500000
>>>>> sticky ness of 100000. The resource runs on a different node and
>>>>> tendency of moving back (not even after restarts).
>>>> No stickiness has nothing to do with the failcount. The policy engine
>>>> could take both into account the stickiness (for RUNNING resources)
>>>> the failcount for (RUNNING or non-running ressources).
>>>> If you ever had a on-start-failure of a resource on a node the
>>>> is set to infinity which means, the resource could not be started at
>>>> this node.
>>> I know that, and the errors were removed by "crm_resource -C". Still
>> resource is happy where it is, and doesn't want to move away.
>>>> If the policy engine needs to evaluate where to run a resource it
>>>> the location/antcolocation/cololaction constraints, failcounts,
>>>> stickiness and maybe some other scores to evaluate WHERE to run a
>>>> So in my opinion the stiness does exactly what you are asking for.
>>> Unfortunately someone did a manual migrate yesterday, so I cannot show
>> scores that lead to the problem.
>>> Linux-HA mailing list
>>> Linux-HA at lists.linux-ha.org
>>> See also: http://linux-ha.org/ReportingProblems
>> Linux-HA mailing list
>> Linux-HA at lists.linux-ha.org
>> See also: http://linux-ha.org/ReportingProblems
> Linux-HA mailing list
> Linux-HA at lists.linux-ha.org
> See also: http://linux-ha.org/ReportingProblems
Linux-HA mailing list
Linux-HA at lists.linux-ha.org
See also: http://linux-ha.org/ReportingProblems
More information about the Linux-HA