Hi, Robinson, Eric wrote: > FYI -- additional info. > > 1. I did an 'unmove' for resources g_clust04 and g_clust05, which > removed the 'location cli-prefer' statements from the crm config. The > resources stayed where they were. > > 2. I changed resource-stickiness to 200. > > 3. I performed the power plug pull test on node ha07b again. Its > resources failed over to node ha07c as expected. > > 4. I plugged the power back into node ha07b. The resources did not fail > back, which means the resource-stickiness worked. > > 5. I did a 'move' to manually failback resource g_clust05 to node ha07b. > The resource moved successfully and drbd looked good afterwards. > > After all that, my crm config had the following additional line: > > > location cli-prefer-g_clust05 g_clust05 \ > > rule $id="cli-prefer-rule-g_clust05" inf: #uname eq > ha07b.mycharts.md > > 6. I did an 'crm resource unmove g_clust05'. The localtion-cli-prefer > line went away but the resource stayed where it was on node ha07b. > > Do I conclude from this that 'move' is the wrong way to manually > failback a resource? Or should I just remember to always do an 'unmove' > on the resource as well, which seems a bit counterintuitive? > There are a number of ways to failover/failback a resource/group of resources, they basically have to do with changing the scores of the resources, location and ordering constraints. One way to do it is through the "crm resource move res/group", another way is to set a location constraint based on a cloned ping resource and block icmp traffic to the node you wish to failover via iptables, another way is to set a time based constraint on the node you wish to failover and to reference the current time ... you catch my drift, there are many ways of achieving the same goal.
One of the simplest ways is to use the move command, however, the move command sets a -inf: location constraint, which if you forget, the node doesn't failback. The same is true if you set a location constraint based on ping, you block icmp traffic and forget to unblock it. So it's really up to the method used, you know, wax on, wax off. What is interesting to know is why do the 2 different notations appear, "cli-prefer-*" and "cli-standby-*"? Regards, Dan > Final crm config: > > node $id="6080642c-bad3-4bb8-80ba-db6b1f7a0735" ha07b.mycharts.md \ > attributes standby="off" > node $id="740538ba-ded5-43b1-95c0-ef898dc72581" ha07a.mycharts.md \ > attributes standby="off" > node $id="b3b4bec2-19e2-4096-8914-febddc5ae42a" ha07c.mycharts.md \ > attributes standby="off" > primitive p_drbd0 ocf:linbit:drbd \ > params drbd_resource="ha01_mysql" \ > op monitor interval="15s" > primitive p_drbd1 ocf:linbit:drbd \ > params drbd_resource="ha02_mysql" \ > op monitor interval="15s" > primitive p_fs_clust04 ocf:heartbeat:Filesystem \ > params device="/dev/drbd0" directory="/ha01_mysql" fstype="ext3" > primitive p_fs_clust05 ocf:heartbeat:Filesystem \ > params device="/dev/drbd1" directory="/ha02_mysql" fstype="ext3" > primitive p_vip_clust04 ocf:heartbeat:IPaddr2 \ > params ip="192.168.10.206" cidr_netmask="32" \ > op monitor interval="15s" > primitive p_vip_clust05 ocf:heartbeat:IPaddr2 \ > params ip="192.168.10.207" cidr_netmask="32" \ > op monitor interval="15s" > group g_clust04 p_fs_clust04 p_vip_clust04 > group g_clust05 p_fs_clust05 p_vip_clust05 > ms ms_drbd0 p_drbd0 \ > meta master-max="1" master-node-max="1" clone-max="2" > clone-node-max="1" notify="true" > ms ms_drbd1 p_drbd1 \ > meta master-max="1" master-node-max="1" clone-max="2" > clone-node-max="1" notify="true" > location loc1 g_clust04 50: ha07a.mycharts.md > location loc2 g_clust04 0: ha07c.mycharts.md > location loc3 g_clust05 50: ha07b.mycharts.md > location loc4 g_clust05 0: ha07c.mycharts.md > colocation c_clust04 inf: g_clust04 ms_drbd0:Master > colocation c_clust05 inf: g_clust05 ms_drbd1:Master > order o1 inf: ms_drbd0:promote g_clust04:start > order o2 inf: ms_drbd1:promote g_clust05:start > property $id="cib-bootstrap-options" \ > dc-version="1.0.9-89bd754939df5150de7cd76835f98fe90851b677" \ > cluster-infrastructure="Heartbeat" \ > stonith-enabled="false" \ > no-quorum-policy="ignore" \ > symmetric-cluster="true" > rsc_defaults $id="rsc-options" \ > resource-stickiness="200" > > -- > Eric Robinson > > > Disclaimer - November 25, 2010 > This email and any files transmitted with it are confidential and intended > solely for General Linux-HA mailing list. If you are not the named addressee > you should not disseminate, distribute, copy or alter this email. Any views > or opinions presented in this email are solely those of the author and might > not represent those of Physicians' Managed Care or Physician Select > Management. Warning: Although Physicians' Managed Care or Physician Select > Management has taken reasonable precautions to ensure no viruses are present > in this email, the company cannot accept responsibility for any loss or > damage arising from the use of this email or attachments. > This disclaimer was added by Policy Patrol: http://www.policypatrol.com/ > _______________________________________________ > Linux-HA mailing list > Linux-HA@lists.linux-ha.org > 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 Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
