<br><br><div class="gmail_quote">On Thu, Jan 14, 2010 at 1:40 AM, Miki Shapiro <span dir="ltr"><<a href="mailto:Miki.Shapiro@coles.com.au">Miki.Shapiro@coles.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-AU" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">When you suggest:</span></p><div class="im">
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">>>> </span>What about setting no-quorum-policy to
freeze and making the third node a full cluster member (that just doesn't run
any resources)?</p>
<p class="MsoNormal">That way, if you get a 1-1-1 split the nodes will leave all
services running where they were and while it waits for quorum.</p>
<p class="MsoNormal">And if it heals into a 1-2 split, then the majority will
terminate the rogue node and acquire all the services.</p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
</div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">No-quorum-policy ‘Freeze’ rather than ‘Stop’
pretty much ASSURES me of getting a split brain for my fileserver cluster. Sounds
like the last thing I want to have. Any data local clients write to the cutoff node
(and its DRBD split-brain volume) cannot be later reconciled and will need to
be discarded. I’d rather not give the local clients that can still reach
that node a false sense of security of their data having been written to disk
(to a drbd volume that will be blown away and resynced with the quorum side
once connectivity is re-established). ‘Stop’ policy sounds safer.</span></p></div></div></blockquote><div><div>Are you using DRBD in dual-master mode?</div></div><div>Because freeze wont start anything new, so if you had one writer before the split, you'll still only have one during.</div>
<div>Then when the split heals DRBD can resync as normal. Right?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-AU" link="blue" vlink="purple">
<div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;color:#1F497D">Question 1:</span></b><span style="font-size:11.0pt;color:#1F497D"> Am I missing anything re stop/ignore
no-quorum policy?</span></p></div></div></blockquote><div><br></div><div>Possibly for the freeze option.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-AU" link="blue" vlink="purple"><div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Further, I’m having more trouble working out a list of
tabulated failure modes for this 3-way scenario, where 3-way outage-prone WAN
links get introduced. </span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;color:#1F497D">Question 2:</span></b><span style="font-size:11.0pt;color:#1F497D"> If one WAN link is broken – (A)
can speak to (B), (B) can speak to (C), but (A) CANNOT speak to (C), what
drives the quorum decision and what would happen? In particular, what would
happen if the node that can see both is the DC? </span></p></div></div></blockquote><div><br></div><div>I'm not sure how totem works in this situation, but whether the node that can see both is the DC is irrelevant.</div>
<div>Membership happens at a much lower level.</div><div><br></div><div>I _think_ you'd end up with a 2-1 split, but I'm not sure how it decides if its A-B or B-C</div><div>Steve could probably tell you.</div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-AU" link="blue" vlink="purple"><div>
<p class="MsoNormal"><b><span style="font-size:11.0pt;color:#1F497D">Question 3:</span></b><span style="font-size:11.0pt;color:#1F497D"> Just to verify I got this right - what
drives pacemaker’s STONITH events, </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">[a] RESOURCE monitoring failure, </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">or </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">[b] CRM’s crosstalk that establishes quorum-state / DC-election?</span></p></div></div></blockquote><div><br></div><div>Its not an XOR condition.</div><div>
Membership events (from openais) AND resource failures can both result in fencing occurring.</div><div><br></div><div>But please forget about DCs and DC elections - they are really not relevant to any of this.</div></div>