<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'> <br><div><pre>> > > > > > }<br>> > > > > > handlers {<br>> > > > > > fence-peer "/usr/lib/drbd/rhcs_fence";<br>> > > > > > }<br>> > > > > > }<br>> > > > > ><br>> > > > > ><br>> > > > > rhcs_fence is wrong fence-peer utility. You should use<br>> > > > > /usr/lib/drbd/crm-fence-peer.sh and<br>> > > > > /usr/lib/drbd/crm-unfence-peer.sh instead.<br>> > > ><br>> > > > But my understanging (probably wrong) was that the fence-peer handler is<br>> > > > meant to be called for STONITH, not for "usual" promotions/demotions<br>> > > > to/from Primary/Secondary.<br>> > > ><br>> > > > If I use the aforementioned pair of handlers (crm-*.sh) for<br>> > > > fence/unfence, do I still get STONITH behavior for "split brain cases"?<br>> > > ><br>> > > <br>> > > Correct. The 'rhcs_fence' handler passes fence calls on to cman, which <br>> > > you have set to redirect on to pacemaker. This isn't what it was <br>> > > designed for, and hasn't been tested. It was meant to be an updated <br>> > > replacement for obliterate-peer.sh in cman+rgmanager clusters directly <br>> > > (no pacemaker).<br>> > <br>> > Well, since it is a CMAN cluster after all and rhcs_fence relies only (besides /proc/drbd) on cman_tool and fence_node (which should be correctly working), I thought it would be the correct fence script choice, but I will obviously accept your suggestion and use the crm-* scripts instead.<br>> > <br>> > Anyway, I'm afraid that the real problem lurks elsewhere, since, as I stated before, a simple master/slave promotion/demotion should not lead to fencing, I suppose.<br>> > <br>> > As suggested by Nikita Staroverov , I pasted relevant (I hope) excerpts from logs on first node (the one surviving the stonith) at the time of one "stonith fest" :) just after committing a CIB update with new resources.<br>> > <br>> > <a href="http://pastebin.com/0eQqsftb" target="_blank">http://pastebin.com/0eQqsftb</a><br>> > <br>> > I can recall that seconds before being shot, the second node "lost contact" with cluster (I was issuing "pcs status" and "crm_mon -Arf1" from an SSH session and suddenly it went "cluster not connected" or something like that).<br>> <br>> Yep, thats consistent with:<br>> <br>> Jul 2 21:32:38 cluster1 pengine[16342]: warning: pe_fence_node: Node cluster2.verolengo.privatelan will be fenced because the node is no longer part of the cluster<br>> <br>> > <br>> > Maybe (apart from the aforementioned improper use of rhcs_fence) there are issues with some timeout settings on cluster/DRBD operations and almost certainly the nodes have problems with their clock (still finding a reasonable/reachable NTP source), but I do not know if these can be relevant issues.<br>> <br>> Or, its _because_ of the improper use of rhcs_fence... depending on how it works it could be telling corosync/cman on cluster2 to disappear.<br><br>I can confirm that changing handler scripts to the suggested crm-*.sh has resolved all the problems.<br><br>I still think that at least this page:<br><br><a href="http://www.drbd.org/users-guide-8.4/s-fence-peer.html#idp68019024" target="_blank">http://www.drbd.org/users-guide-8.4/s-fence-peer.html#idp68019024</a><br><br>clearly states that no fence-peer handler should be invoked under regular operations, but this is more of a documentation (and drbd-users list) affair.<br><br>Many thanks again to you all for the assistance!<br><br>Regards,<br>Giuseppe<br></pre></div> </div></body>
</html>