<div>Hi Lon and Thanks for this reply.</div>
<div> </div>
<div>In fact, thinking about it, my test wasn&#39;t very much representative of what I was expecting to do.</div>
<div> </div>
<div>I blocked the qdisk communications to only one node which, after reading your reply, kind of confirmed me that I did the wong test. I&#39;m going to re run it by blocking all the nodes to the qdisk.</div>
<div> </div>
<div>I&#39;ll also try your ping tie-breaker.</div>
<div> </div>
<div>Brem<br><br> </div>
<div><span class="gmail_quote">2009/8/13, Lon Hohberger &lt;<a href="mailto:lhh@redhat.com">lhh@redhat.com</a>&gt;:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Thu, 2009-08-13 at 00:45 +0200, brem belguebli wrote:<br><br>&gt; My understanding of qdisk is that it is used as a tie-breaker, but it<br>
&gt; looks like it is more a heatbeat vector than a simple tie-breaker.<br><br>Right, it&#39;s a secondary membership algorithm.<br><br><br>&gt; Until here, no real problem indeed, if the site gets apart from the<br>&gt; other prod site and also from the third site (hosting the iscsi target<br>
&gt; qdisk) the 2 nodes from the failing site get evicted from the cluster.<br>&gt;<br>&gt;<br>&gt; But, what if my third site gets isolated while the 2 prod ones are<br>&gt; fine ?<br><br>Qdisk votes will not be presented to CMAN any more, but the two sites<br>
should remain online if they still have a &quot;majority&quot; of votes.<br><br><br>&gt; The real  question is what happens in case all the nodes loose access<br>&gt; to the qdisk while they&#39;re still able to see each others ?<br>
<br>Qdisk is just a vote like other voting mechanisms.  If all nodes lose<br>access at the same time, it should behave like a node death.  However,<br>the default action if _one_ node loses access is to kill that node (even<br>
if CMAN still sees it).<br><br><br>&gt; The 4 nodes have each 1 vote and the qdisk 1 vote. The expected quorum<br>&gt; is 3.<br><br><br>&gt; If I loose the qdisk, the number of votes falls to 4, the cluster is<br>&gt; quorate (4&gt;3) but it looks like everything goes bad, each node<br>
&gt; deactivate itself as it can&#39;t write its alive status (--&gt; heartbeat<br>&gt; vector) to the qdisk even if the network heartbeating is working<br>&gt; fine.<br><br>What happens specifically?  Most of the actions qdiskd performs are<br>
configurable.  For example, if the nodes are rebooting, you can turn<br>that behavior off.<br><br><br><br>I wrote a simple &#39;ping&#39; tiebreaker based the behaviors in RHEL3.  It<br>functions in many ways in the same manner as qdiskd with respect to vote<br>
advertisement to CMAN, but without needing a disk - maybe you would find<br>it useful?<br><br><a href="http://people.redhat.com/lhh/qnet.tar.gz">http://people.redhat.com/lhh/qnet.tar.gz</a><br><br>-- Lon<br><br>--<br>Linux-cluster mailing list<br>
<a href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com</a><br><a href="https://www.redhat.com/mailman/listinfo/linux-cluster">https://www.redhat.com/mailman/listinfo/linux-cluster</a><br></blockquote></div><br>