[Pacemaker] Load Balancing, Node Scores and Stickiness

[Colin]

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?

(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)...)

Thanks, Colin