<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">To be more specific:<div><br></div><div>I've tried following the example on page 25/26 of this document to the teeth: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a></div><div><br></div><div><a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf"></a>And it does work as advertised. When I stop corosync, the resource goes to the other node. I start corosync and it remains there as it should.</div><div><br></div><div>However, if I simply unplug the ethernet connection, let the resource migrate, then plug it back in, it will fail back to the original node. Is this the intended behavior? It seems a bad NIC could wreck havoc on such a setup.</div><div><br></div><div>Thanks!</div><div><br></div><div>Daniel</div><div><br></div><div><div>On May 16, 2011, at 5:33 PM, Daniel Bozeman wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>For the life of me, I cannot prevent auto-failback from occurring in a master-slave setup I have in virtual machines. I have a very simple configuration:<br><br>node $id="4fe75075-333c-4614-8a8a-87149c7c9fbb" ha2 \<br>        attributes standby="off"<br>node $id="70718968-41b5-4aee-ace1-431b5b65fd52" ha1 \<br>        attributes standby="off"<br>primitive FAILOVER-IP ocf:heartbeat:IPaddr \<br>        params ip="192.168.1.79" \<br>        op monitor interval="10s"<br>primitive PGPOOL lsb:pgpool2 \<br>        op monitor interval="10s"<br>group PGPOOL-AND-IP FAILOVER-IP PGPOOL<br>colocation IP-WITH-PGPOOL inf: FAILOVER-IP PGPOOL<br>property $id="cib-bootstrap-options" \<br>        dc-version="1.0.8-042548a451fce8400660f6031f4da6f0223dd5dd" \<br>        cluster-infrastructure="Heartbeat" \<br>        stonith-enabled="false" \<br>        no-quorum-policy="ignore"<br>rsc_defaults $id="rsc-options" \<br>        resource-stickiness="1000"<br><br>No matter what I do with resource stickiness, I cannot prevent fail-back. I usually don't have a problem with failback when I restart the current master, but when I disable network connectivity to the master, everything fails over fine. Then I enable the network adapter and everything jumps back to the original "failed" node. I've done some "watch ptest -Ls"ing, and the scores seem to signify that failback should not occur. I'm also seeing resources bounce more times than necessary when a node is added (~3 times each) and resources seem to bounce when a node returns to the cluster even if it isn't necessary for them to do so. I also had an order directive in my configuration at one time, and often the second resource would start, then stop, then allow the first resource to start, then start itself. Quite weird. Any nods in the right direction would be greatly appreciated. I've scoured Google and read the official documentation to no avail. I suppose I should mention I am using heartbeat as well. My LSB resource implements start/stop/status properly without error.<br><br>I've been testing this with a floating IP + Postgres as well with the same issues. One thing I notice is that my "group" resources have no score. Is this normal? There doesn't seem to be any way to assign a stickiness to a group, and default stickiness has no effect.<br><br>Thanks!<br><br>Daniel Bozeman<br></div></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Daniel Bozeman<br>American Roamer<br>Systems Administrator<br><a href="mailto:daniel.bozeman@americanroamer.com">daniel.bozeman@americanroamer.com</a></span>
</div>
<br></body></html>