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