Thanks for your help, Andrew! On Tue, Feb 23, 2010 at 04:36, Andrew Beekhof <[email protected]> wrote:
> On Mon, Feb 15, 2010 at 8:49 PM, Eric Blau <[email protected]> wrote: > > Hello all, > > > > > > > > I have some questions about resource location and colocation constraints. > > I'm trying to set up a proof of concept configuration with some > multistate > > resources using the Stateful RA. I'm currently using Linux HA 2.1.4. > > If you're not a SLES customer, please upgrade to Pacemaker 1.0.7 > You'll be much happier. > Ok. I'm working on upgrading to Pacemaker 1.0.7 now and have ported my configuration to Pacemaker 1.0.7 with heartbeat 3.0.2. > > > > > > > > > The behavior I'd like to have is to for say, 5 servers to run 5 resources > > with each resource consisting of 2 clones, one of which is master and the > > other is slave (left in the started state). I'd like for these resources > to > > be distributed among nodes in a cluster to the best extent possible > meaning > > that each node should run the fewest number of resources possible while > > always running 2 clones of each resource. I'd also like resources to be > > redistributed when a server goes offline and comes back. > > > > > > > > One more thing. I'd like for the CRM to promote a slave to a master and > > reassign the slave role to another node in the event of a failure. > > > > > > > > I've run into 3 problems: > > > > > > > > 1. I tried setting resource colocation constraints with negative > > scores so that the CRM attempts to distribute resources among all the > > servers. The problem is that the base weight score for each resource is > 0 > > so when the negative score is applied, many of the resources cannot run > > anywhere. > > I've been meaning to add the ability to set a different default score, > but until then you can use (in crm shell syntax): > > crm configure location ms_stateful_1-default ms_stateful_1 \ > rule 5000: defined #uname > Thanks, I'll try that. > > > > 2. If a node running the master instance of a given resource dies, > CRM > > picks another server and starts the master resource on that server > instead > > of promoting the slave to be master and picking a new slave. > > the master scores (set with crm_master by the script) determine who is > promoted. > make sure the old slave sets a higher score than the instance that was > just started > Ok. This behavior is probably just a side effect of the Stateful resource I'm using for testing then. "crm_master 5" is invoked from the RA when it is started or demoted and "crm_master 10" is invoked when it is promoted. This would cause a "started" and a demoted/slave resource from having the same score. > > > > > 3. If a node goes offline and comes back, the CRM does not > > redistribute resources to that server, despite setting > resource_stickiness > > to 0 on all of the resources. > > Where is "back"? And why would it be better? > > If each resource really does prefer specific hosts, you need to > specify location constraints, eg: > > crm configure location ms_stateful_1-best ms_stateful_1 \ > rule 10000: #uname eq best_node > > crm configure location ms_stateful_1-second_best ms_stateful_1 \ > rule 6000: #uname eq second_best_node > I was hoping that having colocation constraints with negative scores would tell CRM to prefer to spread out resources among all servers in the cluster. If a server dies and comes back, I would expect the colocation constraints to force at least one of the resources to be started or and/or promoted on the server that recovers. > > > > > > > > > Can you help me with these issues? Thanks in advance! > > > > > > > > Here is my configuration: > > > > > > > > <resources> > > > > <master_slave id="ms_stateful_1"> > > > > <primitive id="stateful1" class="ocf" provider="heartbeat" > > type="Stateful"/> > > > > <instance_attributes id="params-stateful1"> > > > > <attributes> > > > > <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="0"/> > > > > </attributes> > > > > </instance_attributes> > > > > </master_slave> > > > > <master_slave id="ms_stateful_2"> > > > > <primitive id="stateful2" class="ocf" provider="heartbeat" > > type="Stateful"/> > > > > <instance_attributes id="params-stateful2"> > > > > <attributes> > > > > <nvpair id="stateful2-clone-max" name="clone_max" value="2"/> > > > > <nvpair id="stateful2-clone-node-max" name="clone_node_max" > > value="1"/> > > > > <nvpair id="stateful2-master-max" name="master_max" value="1"/> > > > > <nvpair id="stateful2-master-node-max" name="master_node_max" > > value="1"/> > > > > <nvpair id="stateful2-resource-stickiness" > > name="resource_stickiness" value="0"/> > > > > </attributes> > > > > </instance_attributes> > > > > </master_slave> > > > > <master_slave id="ms_stateful_3"> > > > > <primitive id="stateful3" class="ocf" provider="heartbeat" > > type="Stateful"/> > > > > <instance_attributes id="params-stateful3"> > > > > <attributes> > > > > <nvpair id="stateful3-clone-max" name="clone_max" value="2"/> > > > > <nvpair id="stateful3-clone-node-max" name="clone_node_max" > > value="1"/> > > > > <nvpair id="stateful3-master-max" name="master_max" value="1"/> > > > > <nvpair id="stateful3-master-node-max" name="master_node_max" > > value="1"/> > > > > <nvpair id="stateful3-resource-stickiness" > > name="resource_stickiness" value="0"/> > > > > </attributes> > > > > </instance_attributes> > > > > </master_slave> > > > > <master_slave id="ms_stateful_4"> > > > > <primitive id="stateful4" class="ocf" provider="heartbeat" > > type="Stateful"/> > > > > <instance_attributes id="params-stateful4"> > > > > <attributes> > > > > <nvpair id="stateful4-clone-max" name="clone_max" value="2"/> > > > > <nvpair id="stateful4-clone-node-max" name="clone_node_max" > > value="1"/> > > > > <nvpair id="stateful4-master-max" name="master_max" value="1"/> > > > > <nvpair id="stateful4-master-node-max" name="master_node_max" > > value="1"/> > > > > <nvpair id="stateful4-resource-stickiness" > > name="resource_stickiness" value="0"/> > > > > </attributes> > > > > </instance_attributes> > > > > </master_slave> > > > > <master_slave id="ms_stateful_5"> > > > > <primitive id="stateful5" class="ocf" provider="heartbeat" > > type="Stateful"/> > > > > <instance_attributes id="params-stateful5"> > > > > <attributes> > > > > <nvpair id="stateful5-clone-max" name="clone_max" value="2"/> > > > > <nvpair id="stateful5-clone-node-max" name="clone_node_max" > > value="1"/> > > > > <nvpair id="stateful5-master-max" name="master_max" value="1"/> > > > > <nvpair id="stateful5-master-node-max" name="master_node_max" > > value="1"/> > > > > <nvpair id="stateful5-resource-stickiness" > > name="resource_stickiness" value="0"/> > > > > </attributes> > > > > </instance_attributes> > > > > </master_slave> > > > > </resources> > > > > > > > > <constraints> > > > > <rsc_colocation id="stateful1_2" from="ms_stateful_1" > to="ms_stateful_2" > > score="-1000"/> > > > > <rsc_colocation id="stateful1_3" from="ms_stateful_1" > to="ms_stateful_3" > > score="-1000"/> > > > > <rsc_colocation id="stateful1_4" from="ms_stateful_1" > to="ms_stateful_4" > > score="-1000"/> > > > > <rsc_colocation id="stateful1_5" from="ms_stateful_1" > to="ms_stateful_5" > > score="-1000"/> > > > > <rsc_colocation id="stateful2_1" from="ms_stateful_2" > to="ms_stateful_1" > > score="-1000"/> > > > > <rsc_colocation id="stateful2_3" from="ms_stateful_2" > to="ms_stateful_3" > > score="-1000"/> > > > > <rsc_colocation id="stateful2_4" from="ms_stateful_2" > to="ms_stateful_4" > > score="-1000"/> > > > > <rsc_colocation id="stateful2_5" from="ms_stateful_2" > to="ms_stateful_5" > > score="-1000"/> > > > > <rsc_colocation id="stateful3_1" from="ms_stateful_3" > to="ms_stateful_1" > > score="-1000"/> > > > > <rsc_colocation id="stateful3_2" from="ms_stateful_3" > to="ms_stateful_2" > > score="-1000"/> > > > > <rsc_colocation id="stateful3_4" from="ms_stateful_3" > to="ms_stateful_4" > > score="-1000"/> > > > > <rsc_colocation id="stateful3_5" from="ms_stateful_3" > to="ms_stateful_5" > > score="-1000"/> > > > > <rsc_colocation id="stateful4_1" from="ms_stateful_4" > to="ms_stateful_1" > > score="-1000"/> > > > > <rsc_colocation id="stateful4_2" from="ms_stateful_4" > to="ms_stateful_2" > > score="-1000"/> > > > > <rsc_colocation id="stateful4_3" from="ms_stateful_4" > to="ms_stateful_3" > > score="-1000"/> > > > > <rsc_colocation id="stateful4_5" from="ms_stateful_4" > to="ms_stateful_5" > > score="-1000"/> > > > > <rsc_colocation id="stateful5_1" from="ms_stateful_5" > to="ms_stateful_1" > > score="-1000"/> > > > > <rsc_colocation id="stateful5_2" from="ms_stateful_5" > to="ms_stateful_2" > > score="-1000"/> > > > > <rsc_colocation id="stateful5_3" from="ms_stateful_5" > to="ms_stateful_3" > > score="-1000"/> > > > > <rsc_colocation id="stateful5_4" from="ms_stateful_5" > to="ms_stateful_4" > > score="-1000"/> > > > > </constraints> > > > > _______________________________________________ > > 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
