<p dir="ltr">Thanks Ken.</p>
<p dir="ltr">It's weird. Because we did tests and that did not happen.</p>
<p dir="ltr">There is a node (named Z) without stonith/sbd resources assigned at all and but it was the node that sent the fencing request to a crashed node (X).</p>
<p dir="ltr">But this error appeared in its logs: "No route to host".</p>
<p dir="ltr">It's obvious for us that if SBD isn't running on Z, and there is no network access to that crashed node (X), then based on your answer, node Y which really had access to X via SBD had to initiate the fencing request. But this did not happen.</p>
<p dir="ltr">In addition to this answer, I wonder if I could tell the cluster to avoid sending fencing requests from specific nodes, or at the other side: Tell the cluster which nodes are authorized to send fencing requests.</p>
<p dir="ltr">Any idea?</p>
<div class="gmail_quote">On Jun 24, 2015 1:56 PM, "Ken Gaillot" <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 06/24/2015 12:20 PM, Jonathan Vargas wrote:<br>
> Hi there,<br>
><br>
> We have a 3-node cluster for OCFS2.<br>
><br>
> When one of the nodes fail, it should be fenced. I noticed sometimes one of<br>
> them is the one who sends the fencing message to the failing node, and<br>
> sometimes it's the another.<br>
><br>
> How the cluster decides which of the remaining active nodes will be the one<br>
> to tell the failed node to fence itself?<br>
><br>
> Thanks.<br>
<br>
Fencing resources are assigned to a node like any other resource, even<br>
though they don't really "run" anywhere. Assuming you've configured a<br>
recurring monitor operation on the resource, that node will monitor the<br>
device to ensure it's available.<br>
<br>
Because that node has "verified" (monitored) access to the device, the<br>
cluster will prefer that node to execute the fencing if possible. So<br>
it's just whatever node happened to be assigned the fencing resource.<br>
<br>
If for any reason the node with verified access can't do it, the cluster<br>
will fall back to any other capable node.<br>
<br>
> *Jonathan Vargas Rodríguez*<br>
> Founder and Solution Engineer<br>
> Alkaid <<a href="https://alkaid.cr/" rel="noreferrer" target="_blank">https://alkaid.cr/</a>> | Open Source Software<br>
><br>
> * mail *  <a href="mailto:jonathan.vargas@alkaid.cr">jonathan.vargas@alkaid.cr</a><br>
>  telf   <a href="tel:%2B506%204001%206259%20Ext.%2001" value="+50640016259">+506 4001 6259 Ext. 01</a><br>
>  mobi   <a href="tel:%2B506%204001%206259%20Ext.%2051" value="+50640016259">+506 4001 6259 Ext. 51</a><br>
><br>
> <<a href="http://linkedin.com/in/jonathanvargas/" rel="noreferrer" target="_blank">http://linkedin.com/in/jonathanvargas/</a>><br>
> <<a href="https://plus.google.com/+JonathanVargas/" rel="noreferrer" target="_blank">https://plus.google.com/+JonathanVargas/</a>><br>
> <<a href="https://www.facebook.com/alkaid.cr" rel="noreferrer" target="_blank">https://www.facebook.com/alkaid.cr</a>>       <<a href="https://twitter.com/alkaidcr" rel="noreferrer" target="_blank">https://twitter.com/alkaidcr</a>><br>
<br>
<br>
<br>
_______________________________________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
<a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/mailman/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/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>