<HTML>
<HEAD>
<TITLE>Re: How to prevent locked I/O using Pacemaker with Primary/Primary DRBD/OCFS2 (Ubuntu 10.10)</TITLE>
</HEAD>
<BODY>
<FONT SIZE="2"><FONT FACE="Consolas, Courier New, Courier"><SPAN STYLE='font-size:10pt'>Lars,<BR>
<BR>
Interesting, I will definitely continue in that direction then. Perhaps I misunderstood the requirements of STONITH. I understand it to be a form of “remote reboot/shut down” of sorts, and being that the box was already “shut down”, I assumed at this stage in my testing that it could not be related to STONITH since the box was confirmed to be down. Perhaps Pacemaker is just awaiting that confirmation as you suggest, so thank you, I will see if that is indeed the case. I’ve seen quite a few stonith operation options available, is there any one of them that is better suited for a simple two-node cluster (OCFS2)?<BR>
<BR>
<BR>
> Message: 1<BR>
> Date: Thu, 7 Apr 2011 02:50:09 +0200<BR>
> From: Lars Ellenberg <<a href="lars.ellenberg@linbit.com">lars.ellenberg@linbit.com</a>><BR>
> To: <a href="pacemaker@oss.clusterlabs.org">pacemaker@oss.clusterlabs.org</a><BR>
> Subject: Re: [Pacemaker] How to prevent locked I/O using Pacemaker<BR>
> with Primary/Primary DRBD/OCFS2 (Ubuntu 10.10)<BR>
> Message-ID: <<a href="20110407005009.GF3726@barkeeper1-xen.linbit">20110407005009.GF3726@barkeeper1-xen.linbit</a>><BR>
> Content-Type: text/plain; charset=iso-8859-1<BR>
> <BR>
> On Wed, Apr 06, 2011 at 10:26:24AM -0600, Reid, Mike wrote:<BR>
>> Lars,<BR>
>> <BR>
>> Thank you for your comments. I did confirm I was running 8.3.8.1, and I have <BR>
>> even upgraded to 8.3.10 but am still experiencing the same I/O lock issue. I <BR>
>> definitely agree with you, DRBD is behaving exactly as instructed, being <BR>
>> properly fenced, etc.<BR>
>> <BR>
>> I am quite new to DRBD (and OCFS2), learning a lot as I go. To your<BR>
>> question regarding copy/paste, yes, the configuration used was<BR>
>> culminated from a series of different tutorials, plus personal trial<BR>
>> and error related to this project. I have tried many variations of the<BR>
>> DRBD config (including resource-and-stonith)<BR>
> <BR>
>> but have not actually set up a functioning STONITH yet,<BR>
> <BR>
> And that's why your ocfs2 does not unblock.<BR>
> It waits for confirmation of a STONITH operation.<BR>
> <BR>
>> hence the<BR>
>> "resource-only". The Linbit<BR>
>> docs have been an amazing resource.<BR>
>> <BR>
>> Yes, I realize that a Secondary-node is not indicative of it's<BR>
>> data/synch state. The options I am testing here were referenced from<BR>
>> this page:<BR>
>> <BR>
>> <BR>
>> <BR>
>> <a href="http://www.drbd.org/users-guide/s-ocfs2-create-resource.html">http://www.drbd.org/users-guide/s-ocfs2-create-resource.html</a><BR>
>> <a href="http://www.drbd.org/users-guide/s-configure-split-brain-behavior.html#s-autom">http://www.drbd.org/users-guide/s-configure-split-brain-behavior.html#s-autom</a><BR>
>> atic-split-brain-recovery-configuration <BR>
>> <BR>
>> <BR>
>> <BR>
>> When you say "You do configure automatic data loss here", are you<BR>
>> suggesting that I am instructing DRBD survivor to perform a full<BR>
>> re-synch to it's peer?<BR>
> <BR>
> Nothing to do with full sync. Should usually be a bitmap based resync.<BR>
> <BR>
> But it may be a sync in an "unexpected" direction.<BR>
> <BR>
>> If so, that would make sense since I believe<BR>
>> this behavior was something I experienced prior to getting fencing<BR>
>> fully established. In my hard-boot testing, I did once notice the<BR>
>> "victim" was completely resynching, which sounds related to<BR>
>> "after-sb-1pri discard-secondary". <BR>
>> <BR>
>> DRBD aside, have you used OCFS2? I'm failing to realize why if DRBD is <BR>
>> fencing it's peer that OCFS2 remains in a locked-state, unable to run <BR>
>> standalone? To me, this issue does not seem related to DRBD or Pacemaker, but <BR>
>> rather a lower-level requirement of OCFS2 (DLM?), etc.<BR>
>> <BR>
>> To date, the ONLY way I can restore I/O to the remaining node is to bring the <BR>
>> other node back online, which unfortunately won't work in our Production <BR>
>> environment. On a separate ML, someone made a suggestion that "qdisk" might <BR>
>> be required to make this work, and while I have tried "qdisk", my high-level <BR>
>> research leads me to believe that is a legacy approach, not an option with <BR>
>> Pacemaker. Is that correct? <BR>
> <BR>
>> _______________________________________________<BR>
>> Pacemaker mailing list: <a href="Pacemaker@oss.clusterlabs.org">Pacemaker@oss.clusterlabs.org</a><BR>
>> <a href="http://oss.clusterlabs.org/mailman/listinfo/pacemaker">http://oss.clusterlabs.org/mailman/listinfo/pacemaker</a><BR>
>> <BR>
>> Project Home: <a href="http://www.clusterlabs.org">http://www.clusterlabs.org</a><BR>
>> Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><BR>
>> Bugs: <BR>
>> <a href="http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker">http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker</a><BR>
> <BR>
> <BR>
> -- <BR>
> : Lars Ellenberg<BR>
> : LINBIT | Your Way to High Availability<BR>
> : DRBD/HA support and consulting <a href="http://www.linbit.com">http://www.linbit.com</a><BR>
> <BR>
> DRBD? and LINBIT? are registered trademarks of LINBIT, Austria.</SPAN></FONT></FONT>
</BODY>
</HTML>