On Thu, Oct 22, 2009 at 11:55 AM, Colin <colin....@gmail.com> wrote: > On Thu, Oct 22, 2009 at 11:40 AM, Andrew Beekhof <and...@beekhof.net> wrote: >> On Wed, Oct 21, 2009 at 2:06 PM, Colin <colin....@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 :-) _______________________________________________ Pacemaker mailing list Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker
