Hi Dan, Thanks so much for your explanation! I am wondering is there an easy way to change the default behavior? Can I set the score dynamically when the resource is going up(set the currently running node higher than other node)? I just don't want the resource to be migrated unnecessarily. The result I want is, when the resource is running in one node, regardless of other node status, and as long as currently node is up and running, the resouce shouldn't be migrated.
I don't know if I set the location constraints works, because what I want is some sort of dynamic feature, not restrict the resource to some permanent ones. Can you please suggest? Thanks. Bin On Fri, Dec 3, 2010 at 7:17 PM, Dan Frincu <[email protected]> wrote: > Hi Bin, > > Bin Chen(sunwen_ling) wrote: > > Hi Dan, > > > > Thanks for your reply. For me I didn't setup any complex rules, I just > set > > up a two nodes cluster, and configure a dummy resource to view the > behavior. > > I am wondering this behavior is by default if I didn't specify > anything(no > > resource constraints, no location constraints)? Why heartbeat wants to > > design like this because when M1 stop/start the resource will be migrated > > twice, which seems not necessary. I mean if I set "I prefer resource to > be > > running at M1" I can understand the behavior, but if I didn't set > anything > > it should treat M1 and M2 the same machine, right? > > > When you don't explicitly set anything on a resource, it takes the > default allocation score > > # ptest -Ls > Allocation scores: > native_color: test-binch allocation score on cluster1: 0 > native_color: test-binch allocation score on cluster2: 0 > > The question actually is, when having a resource with equal score on > both nodes, how does Pacemaker decide where to allocate that resource? > The answer is: it depends. > > If you have just one resource, it will choose the node with the lowest > uname when compared by strcmp() > > I've replicated your setup, but by using corosync, with a dummy resource > and it works the way you've described it. > > 1. 2 nodes, cluster1 and cluster2 and a resource Dummy > 2. cluster 1 and cluster 2 start, Dummy starts on cluster1 > 3. echo b > /proc/sysrq-trigger on cluster1, resource moves to cluster2 > 4. cluster1 comes back, resource moves to cluster1 > > This is the expected behavior, and if you're still wondering why it does > that, think of the actions and the order they occur in. > > First both nodes start, then you allocate a resource to the cluster > without specifying a location constraint or score. It automagically sets > the score to zero, but it also has to decide a location, being just one > resource, it chooses the node with the lowest uname (cluster1). Cluster1 > disappears, lowest uname node remaining is cluster2, resource moves. > Cluster1 comes back, lowest uname is now cluster1, resource moves back. > > I've also done another test. > > 1. Shutdown corosync on cluster1 (Dummy moves to cluster2) > 2. On cluster2, delete node cluster1 > 3. On cluster1, permanently change hostname to cluster3 (echo > "kernel.hostname = cluster3" >> /etc/sysctl.conf && sysctl -p) > 4. Start corosync on cluster3 (Dummy stays on cluster2, because it has > the lowest uname, score is still 0 on both nodes for resource Dummy) > 5. echo b > /proc/sysrq-trigger on cluster2 (resource Dummy moves to > cluster3, lowest uname) > 6. Cluster2 restarts (Dummy resource moves back to cluster2, lowest uname) > > So when it comes to one equal cost resource, the tiebreaker is the > lowest uname when compared by strcmp() and it preempts the location (by > comparison, the designated coordinator, DC, is not preempted, which is a > good thing, but that's another discussion). > > What happens when you have 2 resources of equal cost? Pacemaker tries to > spread the resources "evenly" across the available nodes. > > # ptest -Ls > Allocation scores: > native_color: test-binch allocation score on cluster2: 0 > native_color: test-binch allocation score on cluster3: 0 > native_color: test-binch-2 allocation score on cluster2: 0 > native_color: test-binch-2 allocation score on cluster3: 0 > > r...@cluster2:~# ptest -LsVVV 2>&1 | grep Leave > ptest[6460]: 2010/12/03_13:13:47 notice: LogActions: Leave resource > test-binch (Started cluster2) > ptest[6460]: 2010/12/03_13:13:47 notice: LogActions: Leave resource > test-binch-2 (Started cluster3) > > HTH, > Dan > > p.s.: imagine that I've said score wherever I said cost, it's an old > habit I've developed from saying "equal cost {routes,load balancing}" > too many times. > > Looking forward to your reply. > > > > Thanks. > > Bin > > > > The CIB: > > > > <?xml version="1.0" ?> > > <cib admin_epoch="0" crm_feature_set="3.0.1" > > dc-uuid="d111371b-51bd-41f0-a764-4e2f7616e47a" epoch="10" have-quorum="1" > > num_updates="313" validate-with="pacemaker-1.0"> > > <configuration> > > <crm_config> > > <cluster_property_set id="cib-bootstrap-options"> > > <nvpair id="cib-bootstrap-options-dc-version" name="dc-version" > > value="1.0.10-da7075976b5ff0bee71074385f8fd02f296ec8a3"/> > > <nvpair id="cib-bootstrap-options-cluster-infrastructure" > > name="cluster-infrastructure" value="Heartbeat"/> > > <nvpair id="cib-bootstrap-options-stonith-enabled" > > name="stonith-enabled" value="false"/> > > </cluster_property_set> > > </crm_config> > > <rsc_defaults/> > > <op_defaults/> > > <nodes> > > <node id="d111371b-51bd-41f0-a764-4e2f7616e47a" type="normal" > > uname="xcp-3"/> > > <node id="51fbafc2-2ca9-4123-b1e0-43927f6eccb6" type="normal" > > uname="xcp-1"/> > > </nodes> > > <resources> > > <primitive class="ocf" id="test-binch" provider="heartbeat" > > type="binch"> > > <operations> > > <op id="test-binch-monitor-3s" interval="3s" name="monitor"/> > > </operations> > > </primitive> > > </resources> > > <constraints/> > > </configuration> > > </cib> > > > > > > On Thu, Dec 2, 2010 at 8:03 PM, Dan Frincu <[email protected]> > wrote: > > > > > >> Hi, > >> > >> Bin Chen(sunwen_ling) wrote: > >> > >>> Hi guys, > >>> > >>> I have configured 2 machines, M1 and M2. The case is: > >>> > >>> 1) M1 starts, M2 starts, resource running on M1 > >>> 2) M1 poweroff, resource running on M2 > >>> 3) M1 poweron, resource migrated to M1 from M2 > >>> > >>> In step 3, for me I want to leave the resource running at M2, just make > >>> > >> the > >> > >>> M1 to be passive node. How to achieve that? > >>> > >>> > >> Set the default resource-stickiness or the individual resource > >> stickiness to a value higher than the location constraint. If the > >> resource is part of a group, set the resource-stickiness to a value > >> higher than the cumulated score of the group. > >> > >> Regards, > >> Dan > >> > >>> Thanks. > >>> Bin > >>> _______________________________________________ > >>> Linux-HA mailing list > >>> [email protected] > >>> http://lists.linux-ha.org/mailman/listinfo/linux-ha > >>> See also: http://linux-ha.org/ReportingProblems > >>> > >>> > >> -- > >> Dan FRINCU > >> Systems Engineer > >> CCNA, RHCE > >> Streamwide Romania > >> > >> _______________________________________________ > >> 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 > > > > -- > Dan FRINCU > Systems Engineer > CCNA, RHCE > Streamwide Romania > > _______________________________________________ > 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
