<div dir="ltr">Thanks for your reply Digimer.<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 13, 2017 at 1:35 PM, Digimer <span dir="ltr">&lt;<a href="mailto:lists@alteeve.ca" target="_blank">lists@alteeve.ca</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 13/03/17 12:07 PM, Chris Walker wrote:<br>
&gt; Hello,<br>
&gt;<br>
&gt; On our two-node EL7 cluster (pacemaker: 1.1.15-11.el7_3.4; corosync:<br>
&gt; 2.4.0-4; libqb: 1.0-1),<br>
&gt; it looks like successful STONITH operations are not communicated from<br>
&gt; stonith-ng back to theinitiator (in this case, crmd) until the STONITHed<br>
&gt; node is removed from the cluster when<br>
&gt; Corosync notices that it&#39;s gone (i.e., after the token timeout).<br>
<br>
</span>Others might have more useful info, but my understanding of a lost node<br>
sequence is this;<br>
<br>
1. Node stops responding, corosync declares it lost after token timeout<br>
2. Corosync reforms the cluster with remaining node(s), checks if it is<br>
quorate (always true in 2-node)<br>
3. Corosync informs Pacemaker of the membership change.<br>
4. Pacemaker invokes stonith, waits for the fence agent to return<br>
&quot;success&quot; (exit code of the agent as per the FenceAgentAPI<br>
[<a href="https://docs.pagure.org/ClusterLabs.fence-agents/FenceAgentAPI.md%5D" rel="noreferrer" target="_blank">https://docs.pagure.org/Clust<wbr>erLabs.fence-agents/FenceAgent<wbr>API.md]</a>). If<br>
the method fails, it moves on to the next method. If all methods fail,<br>
it goes back to the first method and tries again, looping indefinitely.<br>
<div><div class="gmail-m_-2709524083496572569h5"><br></div></div></blockquote><div><br></div><div>That&#39;s roughly my understanding as well for the case when a node suddenly leaves the cluster (e.g., poweroff), and this case is working as expected for me.  I&#39;m seeing delays when a node is marked for STONITH while it&#39;s still up (e.g., after a stop operation fails).  In this case, what I expect to see is something like:</div><div>1.  crmd requests that stonith-ng fence the node</div><div>2.  stonith-ng (might be a different stonith-ng) fences the node and sends a message that it has succeeded</div><div>3.  stonith-ng (the original from step 1) receives this message and communicates back to crmd that the node has been fenced</div><div><br></div><div>but what I&#39;m seeing is</div><div>1.  crmd requests that stonith-ng fence the node</div><div>2.  stonith-ng fences the node and sends a message saying that it has succeeded</div><div>3.  nobody hears this message</div><div>4.  Corosync eventually realizes that the fenced node is no longer part of the config and broadcasts a config change</div><div>5.  stonith-ng finishes the STONITH operation that was started earlier and communicates back to crmd that the node has been STONITHed</div><div><br></div><div>I&#39;m less convinced that the sending of the STONITH notify in step 2 is at fault; it also seems possible that a callback is not being run when it should be.</div><div><br></div><div><br></div><div>The Pacemaker configuration is not important (I&#39;ve seen this happen on our production clusters and on a small sandbox), but the config is:</div><div><br></div><div><div>primitive bug0-stonith stonith:fence_ipmilan \</div><div>        params pcmk_host_list=bug0 ipaddr=bug0-ipmi action=off login=admin passwd=admin \</div><div>        meta target-role=Started</div><div>primitive bug1-stonith stonith:fence_ipmilan \</div><div>        params pcmk_host_list=bug1 ipaddr=bug1-ipmi action=off login=admin passwd=admin \</div><div>        meta target-role=Started</div><div>primitive prm-snmp-heartbeat snmptrap_heartbeat \</div><div>        params snmphost=bug0 community=public \</div><div>        op monitor interval=10 timeout=300 \</div><div>        op start timeout=300 interval=0 \</div><div>        op stop timeout=300 interval=0</div><div>clone cln-snmp-heartbeat prm-snmp-heartbeat \</div><div>        meta interleave=true globally-unique=false ordered=false notify=false</div><div>location bug0-stonith-loc bug0-stonith -inf: bug0</div><div>location bug1-stonith-loc bug1-stonith -inf: bug1</div></div><div><br></div><div>The corosync config might be more interesting:</div><div><br></div><div><div>totem {</div><div>    version: 2</div><div>    crypto_cipher: none</div><div>    crypto_hash: none</div><div>    secauth: off</div><div>    rrp_mode: passive</div><div>    transport: udpu</div><div>    token: 240000</div><div>    consensus: 1000</div><div><br></div><div>    interface {</div><div>        ringnumber 0</div><div>        bindnetaddr: 203.0.113.0</div><div>        mcastport: 5405</div><div>        ttl: 1</div><div>    }</div><div>}</div></div><div><div>nodelist {</div><div>        node {<br></div><div>                ring0_addr: 203.0.113.1</div><div>                nodeid: 1</div><div>        }</div><div>        node {</div><div>                ring0_addr: 203.0.113.2</div><div>                nodeid: 2</div><div>        }</div><div>}</div></div><div><div>quorum {</div><div>    provider: corosync_votequorum</div><div>    two_node: 1</div><div>}</div></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="gmail-m_-2709524083496572569h5">
&gt; In trace debug logs, I see the STONITH reply sent via the<br>
&gt; cpg_mcast_joined (libqb) function in crm_cs_flush<br>
&gt; (stonith_send_async_reply-&gt;sen<wbr>d_cluster_text-&gt;send_cluster_<wbr>text-&gt;send_cpg_iov-&gt;crm_cs_<wbr>flush-&gt;cpg_mcast_joined)<br>
&gt;<br>
&gt; Mar 13 07:18:22 [6466] bug0 stonith-ng: (  commands.c:1891  )   trace:<br>
&gt; stonith_send_async_reply:        Reply   &lt;st-reply st_origin=&quot;bug1&quot;<br>
&gt; t=&quot;stonith-ng&quot; st_op=&quot;st_fence&quot; st_device_id=&quot;ustonith:0&quot;<br>
&gt; st_remote_op=&quot;39b1f1e0-b76f-4d<wbr>25-bd15-77b956c914a0&quot;<br>
&gt; st_clientid=&quot;823e92da-8470-491<wbr>a-b662-215526cced22&quot;<br>
&gt; st_clientname=&quot;crmd.3973&quot; st_target=&quot;bug1&quot; st_device_action=&quot;st_fence&quot;<br>
&gt; st_callid=&quot;3&quot; st_callopt=&quot;0&quot; st_rc=&quot;0&quot; st_output=&quot;Chassis Power Control:<br>
&gt; Reset\nChassis Power Control: Down/Off\nChassis Power Control: Down/Off\nC<br>
&gt; Mar 13 07:18:22 [6466] bug0 stonith-ng: (       cpg.c:636   )   trace:<br>
&gt; send_cluster_text:       Queueing CPG message 9 to all (1041 bytes, 449<br>
&gt; bytes payload): &lt;st-reply st_origin=&quot;bug1&quot; t=&quot;stonith-ng&quot;<br>
&gt; st_op=&quot;st_notify&quot; st_device_id=&quot;ustonith:0&quot;<br>
&gt; st_remote_op=&quot;39b1f1e0-b76f-4d<wbr>25-bd15-77b956c914a0&quot;<br>
&gt; st_clientid=&quot;823e92da-8470-491<wbr>a-b662-215526cced22&quot; st_clientna<br>
&gt; Mar 13 07:18:22 [6466] bug0 stonith-ng: (       cpg.c:207   )   trace:<br>
&gt; send_cpg_iov:    Queueing CPG message 9 (1041 bytes)<br>
&gt; Mar 13 07:18:22 [6466] bug0 stonith-ng: (       cpg.c:170   )   trace:<br>
&gt; crm_cs_flush:    CPG message sent, size=1041<br>
&gt; Mar 13 07:18:22 [6466] bug0 stonith-ng: (       cpg.c:185   )   trace:<br>
&gt; crm_cs_flush:    Sent 1 CPG messages  (0 remaining, last=9): OK (1)<br>
&gt;<br>
&gt; But I see no further action from stonith-ng until minutes later;<br>
&gt; specifically, I don&#39;t see remote_op_done run, so the dead node is still<br>
&gt; an &#39;online (unclean)&#39; member of the array and no failover can take place.<br>
&gt;<br>
&gt; When the token expires (yes, we use a very long token), I see the following:<br>
&gt;<br>
&gt; Mar 13 07:22:11 [6466] bug0 stonith-ng: (membership.c:1018  )  notice:<br>
&gt; crm_update_peer_state_iter:      Node bug1 state is now lost | nodeid=2<br>
&gt; previous=member source=crm_update_peer_proc<br>
&gt; Mar 13 07:22:11 [6466] bug0 stonith-ng: (      main.c:1275  )   debug:<br>
&gt; st_peer_update_callback: Broadcasting our uname because of node 2<br>
&gt; Mar 13 07:22:11 [6466] bug0 stonith-ng: (       cpg.c:636   )   trace:<br>
&gt; send_cluster_text:       Queueing CPG message 10 to all (666 bytes, 74<br>
&gt; bytes payload): &lt;stonith_command __name__=&quot;stonith_command&quot;<br>
&gt; t=&quot;stonith-ng&quot; st_op=&quot;poke&quot;/&gt;<br>
&gt; ...<br>
&gt; Mar 13 07:22:11 [6466] bug0 stonith-ng: (  commands.c:2582  )   debug:<br>
&gt; stonith_command: Processing st_notify reply 0 from bug0 (               0)<br>
&gt; Mar 13 07:22:11 [6466] bug0 stonith-ng: (    remote.c:1945  )   debug:<br>
&gt; process_remote_stonith_exec:     Marking call to poweroff for bug1 on<br>
&gt; behalf of crmd.3973@39b1f1e0-b76f-4d25-b<wbr>d15-77b956c914a0.bug1: OK (0)<br>
&gt;<br>
&gt; and the STONITH command is finally communicated back to crmd as complete<br>
&gt; and failover commences.<br>
&gt;<br>
&gt; Is this delay a feature of the cpg_mcast_joined function?  If I<br>
&gt; understand correctly (unlikely), it looks like cpg_mcast_joined is not<br>
&gt; completing because one of the nodes in the group is missing, but I<br>
&gt; haven&#39;t looked at that code closely yet.  Is it advisable to have<br>
&gt; stonith-ng broadcast a membership change when it successfully fences a node?<br>
&gt;<br>
&gt; Attaching logs with PCMK_debug=stonith-ng<br>
&gt; and PCMK_trace_functions=stonith_s<wbr>end_async_reply,send_cluster_t<wbr>ext,send_cpg_iov,crm_cs_flush<br>
&gt;<br>
&gt; Thanks in advance,<br>
&gt; Chris<br>
<br>
</div></div>Can you share your full pacemaker config (please obfuscate passwords).<br>
<br>
--<br>
Digimer<br>
Papers and Projects: <a href="https://alteeve.com/w/" rel="noreferrer" target="_blank">https://alteeve.com/w/</a><br>
&quot;I am, somehow, less interested in the weight and convolutions of<br>
Einstein’s brain than in the near certainty that people of equal talent<br>
have lived and died in cotton fields and sweatshops.&quot; - Stephen Jay Gould<br>
<br>
______________________________<wbr>_________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank">Users@clusterlabs.org</a><br>
<a href="http://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.clusterlabs.org/m<wbr>ailman/listinfo/users</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/doc<wbr>/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
</blockquote></div><br></div></div>