[Pacemaker] Load Balancing, Node Scores and Stickiness

[Andrew Beekhof]

On Thu, Oct 22, 2009 at 11:55 AM, Colin <colin.hch at gmail.com> wrote:
> On Thu, Oct 22, 2009 at 11:40 AM, Andrew Beekhof <andrew at beekhof.net> wrote:
>> On Wed, Oct 21, 2009 at 2:06 PM, Colin <colin.hch at gmail.com> wrote:
>>>
>>> it seems from the documentation that Pacemaker has some inherent
>>> tendency to to load-balancing, in the sense of, given equal choice,
>>> not starting all resources on a single node...
>>>
>>> Now, I would like to be able to choose freely on a scale between
>>> "always move everything to achieve good load balancing" and "don't
>>> gratuitously migrate resources", and would therefore like to
>>> understand the algorithms in Pacemaker better.
>>>
>>> Given a bunch of nodes and resources with a simple setup, i.e. no
>>> resource colocation constraints, no groups etc., I understand that a
>>> global score is calculated for each resource and each node, where
>>>
>>> score( resource, node ) = sum of all rsc_location constraints for that
>>> resource and node + if the resource is already running on this node,
>>> the stickiness (the stickiness of the resource or the global default
>>> stickiness)
>>>
>>> How does the assignment of nodes proceed? My guess is something like:
>>>
>>> for every resource in order of resource priority
>>>   choose node with highest score for that resource
>>
>>     if multiple nodes exist with the same score, pick one with the
>> least allocated resources
>
> That's easy enough to understand ... and I can't do any fine-tuning,
> i.e. suppose that 4 nodes of my 10 node cluster fail, and then come up
> again. If all resources have equal score on all nodes (without
> counting stickiness), then (a) if stickiness is greater than 0 all
> resources will stay put, and (b) if stickiness is 0 then the cluster
> will move around resources to distribute them evenly?

yep

and if you have any colocation constraints the stickiness is additive.
so three colocated resources would prefer their existing host 3 times
as much as a single, uncolocated one.

>
> (Come to think of it, any kind of fine-tuning taking into account
> multiple resource weights and more complicated migration resistance
> scores would probably be algorithmically really really horrible and
> complex (in the complexity theoretic sense, too)...)
>

exactly :-)