[Pacemaker] How to prevent locked I/O using Pacemaker with Primary/Primary DRBD/OCFS2 (Ubuntu 10.10)

Reid, Mike MBReid at thepei.com
Wed Apr 6 12:26:24 EDT 2011


Thank you for your comments. I did confirm I was running, and I have even upgraded to 8.3.10 but am still experiencing the same I/O lock issue. I definitely agree with you, DRBD is behaving exactly as instructed, being properly fenced, etc.

I am quite new to DRBD (and OCFS2), learning a lot as I go. To your question regarding copy/paste, yes, the configuration used was culminated from a series of different tutorials, plus personal trial and error related to this project. I have tried many variations of the DRBD config (including resource-and-stonith) but have not actually set up a functioning STONITH yet, hence the "resource-only". The  Linbit docs have been an amazing resource.

Yes, I realize that a Secondary-node is not indicative of it's data/synch state. The options I am testing here were referenced from this page:


When you say "You do configure automatic data loss here", are you suggesting that I am instructing DRBD survivor to perform a full re-synch to it's peer? If so, that would make sense since I believe this behavior was something I experienced prior to getting fencing fully established. In my hard-boot testing, I did once notice the "victim" was completely resynching, which sounds related to "after-sb-1pri discard-secondary". 

DRBD aside, have you used OCFS2? I'm failing to realize why if DRBD is fencing it's peer that OCFS2 remains in a locked-state, unable to run standalone? To me, this issue does not seem related to DRBD or Pacemaker, but rather a lower-level requirement of OCFS2 (DLM?), etc.

To date, the ONLY way I can restore I/O to the remaining node is to bring the other node back online, which unfortunately won't work in our Production environment. On a separate ML, someone made a suggestion that "qdisk" might be required to make this work, and while I have tried "qdisk", my high-level research leads me to believe that is a legacy approach, not an option with Pacemaker.  Is that correct? 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20110406/7b4ca8bb/attachment-0003.html>

More information about the Pacemaker mailing list