<div dir="ltr">HI Ulrich,<div><br></div><div>It's not that it is not working for me, it is that to make it, at least appear, to work for me, I've had to modify dlm.conf -- which I have found zero mention of this being necessary in any of the tutorials or walk throughs I've read.  I was curious what ramifications I would encounter by setting 'enable_fencing=0' in dlm.conf.   <br><br>From what I can tell, my config is sane with regard to interleave, colo, and ordering.   <br><br>SBD is a possibility we're considering, but haven't fully embraced, as of yet.  </div><div><br></div><div>I'm still planning on testing 'enable_startup_fencing=0' instead of 'enable_fencing=0' in dlm.conf and will report back (in case anyone is interested).  </div><div><br></div><div>Best,</div><div>-Pat</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 2, 2018 at 2:25 AM Ulrich Windl <<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-regensburg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<br>
I'm sorry that DLM/cLVM does not work for you. Did you double-check the configuration (meta interleave=true, colocation and ordering), especially the clones?<br>
Also as you have shared storage, why don't you use SBD for fencing?<br>
<br>
Regards,<br>
Ulrich<br>
<br>
<br>
>>> Patrick Whitney <<a href="mailto:pwhitney@luminoso.com" target="_blank">pwhitney@luminoso.com</a>> schrieb am 01.10.2018 um 22:01 in<br>
Nachricht<br>
<<a href="mailto:CAE0zLk_Va6gtHz9tG3woEcua2RidaehaOQ8ieQdZ4MeOkcy0nQ@mail.gmail.com" target="_blank">CAE0zLk_Va6gtHz9tG3woEcua2RidaehaOQ8ieQdZ4MeOkcy0nQ@mail.gmail.com</a>>:<br>
> Hi Ulrich,<br>
> <br>
> When I first encountered this issue, I posted this:<br>
> <br>
> <a href="https://lists.clusterlabs.org/pipermail/users/2018-September/015637.html" rel="noreferrer" target="_blank">https://lists.clusterlabs.org/pipermail/users/2018-September/015637.html</a> <br>
> <br>
> ... I was using resource fencing in this example, but, as I've mentioned<br>
> before, the issue would come about, not when fencing occurred, but when the<br>
> fenced node was shutdown (we were using resource fencing).<br>
> <br>
> During that discussion, yourself and others suggested that power fencing<br>
> was the only way DLM was going to cooperate and one suggestion of using<br>
> meatware was proposed.<br>
> <br>
> Unfortunately, I found out later that meatware was no longer available (<br>
> <a href="https://lists.clusterlabs.org/pipermail/users/2018-September/015715.html" rel="noreferrer" target="_blank">https://lists.clusterlabs.org/pipermail/users/2018-September/015715.html</a>),<br>
> so we were lucky enough our test environment is a KVM/libvirt environment,<br>
> so I used fence_virsh.  Again, I had the same problem... when the "bad"<br>
> node was fenced, dlm_controld would issue (what appears to be) a fence_all,<br>
> and I would receive messages that that the dlm clone was down on all<br>
> members and would have a log message that the clvm lockspace was<br>
> abandoned.<br>
> <br>
> It was only when I disabled fencing for dlm (enable_fencing=0 in dlm.conf;<br>
> but kept fencing enabled in pcmk) did things begin to work as expected.<br>
> <br>
> One suggestion earlier in this thread suggests trying the dlm configuration<br>
> of  disabling startup fencing (enable_startup_fencing=0), which sounds like<br>
> a plausible solution after looking over the logs, but I haven't tested<br>
> yet.<br>
> <br>
> The conclusion I'm coming to is:<br>
> 1. The reason DLM cannot handle resource fencing is because it keeps its<br>
> own "heartbeat/control" channel (for lack of a better term) via the<br>
> network, and pcmk cannot instruct DLM "Don't worry about that guy over<br>
> there" which means we must use power fencing, but;<br>
> 2. DLM does not like to see one of its members disappear; when that does<br>
> happen, DLM does "something" which causes the lockspace to disappear...<br>
> unless you disable fencing for DLM.<br>
> <br>
> I am now speculating that DLM restarts when the communications fail, and<br>
> the theory that disabling startup fencing for DLM<br>
> (enable_startup_fencing=0) may be the solution to my problem (reverting my<br>
> enable_fencing=0 DLM config).<br>
> <br>
> Best,<br>
> -Pat<br>
> <br>
> On Mon, Oct 1, 2018 at 3:38 PM Ulrich Windl <<br>
> <a href="mailto:Ulrich.Windl@rz.uni-regensburg.de" target="_blank">Ulrich.Windl@rz.uni-regensburg.de</a>> wrote:<br>
> <br>
>> Hi!<br>
>><br>
>> It would be much more helpful, if you could provide logs around the<br>
>> problem events. Personally I think you _must_ implement proper fencing. In<br>
>> addition, DLM seems to do its own fencing when there is a communication<br>
>> problem.<br>
>><br>
>> Regards,<br>
>> Ulrich<br>
>><br>
>><br>
>> >>> Patrick Whitney <<a href="mailto:pwhitney@luminoso.com" target="_blank">pwhitney@luminoso.com</a>> 01.10.18 16.25 Uhr >>><br>
>> Hi Everyone,<br>
>><br>
>> I wanted to solicit input on my configuration.<br>
>><br>
>> I have a two node (test) cluster running corosync/pacemaker with DLM and<br>
>> CLVM.<br>
>><br>
>> I was running into an issue where when one node failed, the remaining node<br>
>> would appear to do the right thing, from the pcmk perspective, that is.<br>
>>  It would  create a new cluster (of one) and fence the other node, but<br>
>> then, rather surprisingly, DLM would see the other node offline, and it<br>
>> would go offline itself, abandoning the lockspace.<br>
>><br>
>> I changed my DLM settings to "enable_fencing=0", disabling DLM fencing, and<br>
>> our tests are now working as expected.<br>
>><br>
>> I'm a little concern I have masked an issue by doing this, as in all of the<br>
>> tutorials and docs I've read, there is no mention of having to configure<br>
>> DLM whatsoever.<br>
>><br>
>> Is anyone else running a similar stack and can comment?<br>
>><br>
>> Best,<br>
>> -Pat<br>
>> --<br>
>> Patrick Whitney<br>
>> DevOps Engineer -- Tools<br>
>><br>
>> _______________________________________________<br>
>> Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank">Users@clusterlabs.org</a> <br>
>> <a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.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>
> -- <br>
> Patrick Whitney<br>
> DevOps Engineer -- Tools<br>
<br>
<br>
<br>
_______________________________________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank">Users@clusterlabs.org</a><br>
<a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.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 clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Patrick Whitney<div>DevOps Engineer -- Tools</div></div></div>