On 15/04/2013, at 5:06 PM, Andreas Mock <andreas.m...@web.de> wrote:
> Hi Andrew, > > that means (when I understand it right), that with this setting > you get two different semantics about what the cluster knows > about itself. > > With setting of a+c as recommended by you the 2-node-cluster > does not get quorum in case only one node survives, but ignores > that info. > > With the setting of b) the cluster does get quorum even when > only one node is left. In this case I need not set c) as pacemaker > believes having quorum (told by cman). > > Is this right? Exactly correct. With a+c you get the truth and (for two node clusters) choosing to ignore it. With b you're telling the cluster to lie to you :) > > Best regards > Andreas > > > -----Ursprüngliche Nachricht----- > Von: Andrew Beekhof [mailto:and...@beekhof.net] > Gesendet: Montag, 15. April 2013 05:58 > An: The Pacemaker cluster resource manager > Betreff: Re: [Pacemaker] RHEL6.x dependency between 2-node-settings for cman > and quorum settings in pacemaker > > > On 12/04/2013, at 4:58 PM, Andreas Mock <andreas.m...@web.de> wrote: > >> Hi all, >> >> another question rised up while reading documentation concerning >> 2-node-cluster under RHEL6.x with CMAN and pacemaker. >> >> a) In the quick start guide one of the things you set is >> CMAN_QUORUM_TIMEOUT=0 in /etc/sysconfig/cman to get one node of the >> cluster up without waiting for quorum. (Correct me if my understanding >> is wrong) >> >> b) There is a special setting in cluster.conf <cman two_node="1" >> expected_votes="1" > </cman> which allows one node to gain quorum in >> a two node cluster (Please also correct me here if my understanding is >> wrong) >> >> c) And there is a pacemaker setting >> no-quorum-policy which is mostly set to 'ignore' in all startup >> tutorials. >> >> My question: I would like to understand how these settings influence >> each other and/or are dependent. > > a) allows "service cman start" to complete (and therefor allow "service > pacemaker start" to begin) before quorum has arrived. > b) is a possible alternative to a) but I've never tested it because it is > superseded by c) and in fact makes c) meaningless since the cluster always > has quorum. > > a+c is preferred for consistency with clusters of more than 2 nodes. > >> >> As most insight as possible appreciated. ;-) >> >> Best regards >> Andreas >> >> >> >> _______________________________________________ >> 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://bugs.clusterlabs.org > > > _______________________________________________ > 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://bugs.clusterlabs.org > > > _______________________________________________ > 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://bugs.clusterlabs.org _______________________________________________ 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://bugs.clusterlabs.org
