On Tue, Mar 23, 2010 at 13:17, Andrew Beekhof <[email protected]> wrote:
> On Tue, Mar 23, 2010 at 6:01 PM, Eric Blau <[email protected]> wrote: > > Hi everyone, > > > > I'm working with a test configuration containing 128 resources using the > > Stateful example resource agent supplied with Linux HA. I'm trying to > > figure out how to get resource colocation constraints working > efficiently. > > > > I have 128 master/slave Stateful resources with a configuration for each > > that looks like this: > > > > <master id="ms_stateful_1"> > > <primitive id="stateful1" class="ocf" provider="pacemaker" > > type="Stateful"/> > > <instance_attributes id="params-stateful1"> > > <nvpair id="stateful1-clone-max" name="clone-max" value="2"/> > > <nvpair id="stateful1-clone-node-max" name="clone-node-max" > > value="1"/> > > <nvpair id="stateful1-master-max" name="master-max" value="1"/> > > <nvpair id="stateful1-master-node-max" name="master-node-max" > > value="1"/> > > <nvpair id="stateful1-resource-stickiness" > > name="resource-stickiness" value="10"/> > > </instance_attributes> > > </master> > > > > I then have a default score of 10000 assigned to each resource by using a > > resource location constraint like this: > > > > <rsc_location id="stateful1_default-score1" rsc="ms_stateful_1"> > > <rule id="stateful1_default-score2" score="10000"> > > <expression id="stateful1_default_expr" attribute="#uname" > > operation="defined"/> > > </rule> > > </rsc_location> > > > > I would then like to specify a resource colocation constraint that would > > spread out the master and slave resources among cluster nodes as much as > is > > possible. > > It should do this normally though. > Did it not do so without the colocation constraints? > No, it does not do so without the colocation constraints. For example, if I configure 128 resources with 1 server in the cluster, all 128 resources are started as master on that server. If I start up server 2, all 128 resources are started as slaves on that server. If I start up server 3, none of the resources are started on that server. I would like for the resources to be redistributed. So with 2 servers I would have 64 masters and 64 slaves on each of the two servers. With 3 servers I would have 42 or 43 masters on each server and 42 or 43 slaves on each server. With the colocation constraints, this works with a small number of resources, but cannot scale to 128 resources. > > > I have figured out that this is possible to do by creating rules > > like this with negative scores: > > > > <rsc_colocation id="stateful1_2" rsc="ms_stateful_1" > > with-rsc="ms_stateful_2" score="-7"/> > > <rsc_colocation id="stateful1_2_ms" rsc="ms_stateful_1" > > with-rsc="ms_stateful_2" with-rsc-role="Master" score="-7"/> > > > > This causes resources to prefer to be placed on nodes where the fewest > > number of resources are running to spread them out to the largest extent > > possible. > > > > These resource colocation constraints work well for a small number of > > resources, but it requires defining colocation constraints for all > > permutations of resources. For 5 resources this is manageble, I define > > colocation constraints between resources like this: > > > > 1->2 > > 1->3 > > 1->4 > > 1->5 > > 2->3 > > 2->4 > > 2->5 > > etc. > > > > but for large numbers of resources (like 128) this simply is not > scalable. > > > > Is there a more efficient way to define the colocation constraints > instead > > of requiring an explicit constraint for each combination of resources? > > > > Thanks in advance for your help! > > > > Regards, > > Eric Blau > > _______________________________________________ > > Linux-HA mailing list > > [email protected] > > http://lists.linux-ha.org/mailman/listinfo/linux-ha > > See also: http://linux-ha.org/ReportingProblems > > > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems > _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
