On Tue, Mar 23, 2010 at 7:11 PM, Eric Blau <[email protected]> wrote:
> 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.

That I would probably still expect - for allocation we dont
differentiate between the different states.

> If I start up server 3, none of the resources are started on that server.

That I do find strange.  Can you file a bug for that please?

>
> 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
>
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

Reply via email to