Hi, 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. Alain
De : Maloja01 <maloj...@arcor.de> A : linux-ha@lists.linux-ha.org Date : 05/08/2011 11:02 Objet : Re: [Linux-HA] Antw: Re: location and orders : Question about a behavior ... Envoyé par : linux-ha-boun...@lists.linux-ha.org 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 _______________________________________________ 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