On 08/05/2011 08:30 AM, Ulrich Windl wrote:
>>>> Maloja01 <maloj...@arcor.de> schrieb am 04.08.2011 um 18:49 in Nachricht
> <4e3acd86.1020...@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).
>
> Hi!
>
> 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).
Kind regards
Fabian
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.
>
> Regards,
> Ulrich
>
>>
>> Regards
>> Fabian
>>
>> On 08/04/2011 03:10 PM, Ulrich Windl wrote:
>>>>>> Maloja01 <maloj...@arcor.de> schrieb am 04.08.2011 um 12:58 in Nachricht
>>> <4e3a7b5c.1030...@arcor.de>:
>>>> On 08/04/2011 08:28 AM, Ulrich Windl wrote:
>>>>> Hi!
>>>>>
>>>>> Isn't the stickyness effectively based on the failcount? We have one
>>>> resource
>>>>> that has a location constraint for one node with a weight of 500000 and a
>>>>> sticky ness of 100000. The resource runs on a different node and shows no
>>>>> 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) and
>>>> the failcount for (RUNNING or non-running ressources).
>>>>
>>>> If you ever had a on-start-failure of a resource on a node the failcount
>>>> is set to infinity which means, the resource could not be started at
>>>> this node.
>>>
>>> fabian,
>>>
>>> I know that, and the errors were removed by "crm_resource -C". Still the
>> 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 uses
>>>> the location/antcolocation/cololaction constraints, failcounts,
>>>> stickiness and maybe some other scores to evaluate WHERE to run a resource.
>>>>
>>>> So in my opinion the stiness does exactly what you are asking for.
>>>
>>> Unfortunately someone did a manual migrate yesterday, so I cannot show the
>> scores that lead to the problem.
>>>
>>> Regards,
>>> Ulrich
>>>
>>>
>>> _______________________________________________
>>> Linux-HA mailing list
>>> Linux-HA@lists.linux-ha.org
>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>>> See also: http://linux-ha.org/ReportingProblems
>>
>> _______________________________________________
>> Linux-HA mailing list
>> Linux-HA@lists.linux-ha.org
>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>> See also: http://linux-ha.org/ReportingProblems
>>
>
>
>
>
> _______________________________________________
> Linux-HA mailing list
> Linux-HA@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
