I performed a "power-plug-pull" test on my newest cluster and it failed
over as expected. However, when I restored power to the "failed" node,
the resources failed back. I don't understand why this happened since I
have resource stickiness set.
There are three nodes in the cluster. I pulled the plug in node ha07b
and resource g_clust05 failed over to node ha07c just like it should.
But when I restored power to ha07b, the resource failed back. (Well,
almost. DRBD did not successfully fail back and both nodes ended up in a
secondary / standalone state.)
Shouldn't the resource stickiness have kept the resource on the node
ha07c?
Here's my crm configuration:
node $id="6080642c-bad3-4bb8-80ba-db6b1f7a0735" ha07b.mydomain.com \
attributes standby="off"
node $id="740538ba-ded5-43b1-95c0-ef898dc72581" ha07a.mydomain.com \
attributes standby="off"
node $id="b3b4bec2-19e2-4096-8914-febddc5ae42a" ha07c.mydomain.com \
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 cli-prefer-g_clust04 g_clust04 \
rule $id="cli-prefer-rule-g_clust04" inf: #uname eq
ha07a.mydomain.com
location cli-prefer-g_clust05 g_clust05 \
rule $id="cli-prefer-rule-g_clust05" inf: #uname eq
ha07b.mydomain.com
location loc1 g_clust04 50: ha07a.mydomain.com
location loc2 g_clust04 0: ha07c.mydomain.com
location loc3 g_clust05 50: ha07b.mydomain.com
location loc4 g_clust05 0: ha07c.mydomain.com
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="100"
--
Eric Robinson
Disclaimer - November 24, 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
