Lars,
Thank you for your comments. I did confirm I was running 8.3.8.1, 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:
http://www.drbd.org/users-guide/s-ocfs2-create-resource.html
http://www.drbd.org/users-guide/s-configure-split-brain-behavior.html#s-automatic-split-brain-recovery-configuration
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?
_______________________________________________
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
