<div dir="ltr"><div><div><div><div><div>Hi, thanks for the answers,<br><br></div>i've performed the test of shutting down both IPoIB interfaces on an OSS server<br>while a Lustre client writing a large file to the OST one that server, the umount still succeded,<br></div><div>and writing to the file continued after a short delay on the same OST mounted on the failed-over server.<br></div><div>I found however that if ones incorrectly formats Lustre OST (wrong index) then it fails to mount,<br></div>and STONITH is triggered. I may test the "exit $OCF_ERR_GENERIC" solution,<br></div>but I would like to go back now to the first question: how can one trigger STONITH<br></div>in case a server misses both IB interfaces? How to make it cooperate with the existing<br>Filesystem mount based STONITH? Is it a good idea at all? Any examples in the net?<br></div><div><br></div>Marcin<br><div><div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 20, 2015 at 9:00 AM, Andrei Borzenkov <span dir="ltr"><<a href="mailto:arvidjaar@gmail.com" target="_blank">arvidjaar@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">19.08.2015 13:31, Marcin Dulak пишет:<br>
<span class="">> However if instead both IPoIB interfaces go down on server-02,<br>
> the mdt is moved to server-01, but no STONITH is performed on server-02.<br>
> This is expected, because there is nothing in the configuration that<br>
> triggers<br>
> STONITH in case of IB connection loss.<br>
> Hovever if IPoIB is flapping this setup could lead to mdt moving<br>
> back and forth between server-01 and server-02.<br>
> Should I have STONITH shutting down a node that misses both IpoIB<br>
> (remember they are passively redundant, only one active at a time)<br>
> interfaces?<br>
<br>
</span>It is really up to the agent. Note that on-fail is triggered only if<br>
operation fails. So as long as stop invocation does not return error, no<br>
fencing happens.<br>
<span class=""><br>
> If so, how to achieve that?<br>
><br>
<br>
</span>If you really want to trigger fencing when access to block device<br>
fails you probably need to define it as separate resource with own<br>
agent and set on-fail=fence on monitor operation for this block<br>
device. Otherwise you cannot really distinguish fiesystem level error<br>
from block device level.<br>
<span class=""><br>
> The context for the second question: the configuration contains the<br>
> following Filesystem template:<br>
><br>
> rsc_template lustre-target-template ocf:heartbeat:Filesystem \<br>
> op monitor interval=120 timeout=60 OCF_CHECK_LEVEL=10 \<br>
> op start interval=0 timeout=300 on-fail=fence \<br>
> op stop interval=0 timeout=300 on-fail=fence<br>
><br>
> How can I make umount/mount of Filesystem fail in order to test STONITH<br>
> action in these cases?<br>
><br>
<br>
</span>Insert "exit $OCF_ERR_GENERIC" in stop method? :)<br>
<span class=""><br>
> Extra question: where can I find the documentation/source what<br>
> on-fail=fence is doing?<br>
<br>
</span>Pacemaker Explained has some description. It should initiate fencing<br>
of node where resource had been active.<br>
<span class=""><br>
> Or what does it mean on-fail=stop in the ethmonitor template below (what is<br>
> stopped?)?<br>
><br>
<br>
</span>on-fail=stop sets resource target role to stopped. So pacemaker tries<br>
to stop it and leave it stopped.<br>
<span class=""><br>
> rsc_template netmonitor-30sec ethmonitor \<br>
> params repeat_count=3 repeat_interval=10 \<br>
> op monitor interval=15s timeout=60s \<br>
> op start interval=0s timeout=60s on-fail=stop \<br>
><br>
> Marcin<br>
><br>
><br>
><br>
</span>> _______________________________________________<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>
><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><br></div>