[Pacemaker] Quorum: a couple of ideas

[Carlos G Mendioroz]

Andrew Beekhof @ 21/02/2011 11:01 -0300 dixit:
> On Mon, Feb 21, 2011 at 2:05 PM, Carlos G Mendioroz <tron at huapi.ba.ar> wrote:
>> Hi,
>> As I understand it, pacemaker decides on having quorum
> 
> Let me stop you there... pacemaker doesn't normally decide this at all.
> It doesn't for heartbeat based clusters and once the corosync quorum
> plugin is functional it wont there either.
> 
> Quorum is something that should normally come from the underlying
> cluster messaging layer.

Ok, then the ideas belongs there, not here :)

>> when
>> the number of nodes it can talk to is strictly greater than
>> half of the existing nodes, or 2 * N > T .
>>
>> This has the unfortunate consequence of turning it useless for
>> N = 2, and less than optimal for any even T.
>>
>> I would like you to consider having one node a double vote.
> 
> Short answer:       No.
> Medium answer:   Thats what no quorum policy is for.
> Long answer:        See your local encyclopedia for the definition of
> quorum, we ain't perverting it here :-)

Hmm, if wikepedia qualifies:

	A quorum is the minimum number of members of a deliberative
	assembly (a body that uses parliamentary procedure, such as a
	legislature) necessary to conduct the business of that group.

In fact, what I propose is used in many organisms to disambiguate a tie,
where the president has in such a stance, a double vote.
Also, some administrative bodies have "qualified members" with access
to double or even quad vote rights, so I was not trying to pervert
the concept. I feel that keeping the concept clean is always best. KISS.

> Historical answer: Vote fudging became common practice because cluster
> managers had a meltdown when quorum was lost.
>                            Pacemaker does not suffer this problem and
> thus does not wish to encourage the practice :-)

Don't know what is the case you are referring too, but I know that some
solid active/standby systems rely on having one side being "preferred"
in the sense I was proposing. I don't see a downside, for the record
I would like to know if there is one, other than that inherently of
any change.

-Carlos

> Summary:            No :-)
> 
>> (And that would also jump T to T+1) The properties of quorum
>> would stay (not going schizophrenic, so to say) but if you
>> happen to partition a 2 node set, the chosen one would stay up.
>>
>> An more flexible approach could be to base quorum on the number of
>> resources that can stay up in this node, a number that can be
>> statically configured per node. As long as the number of connected
>> resources is above half of the defined, quorum is mantained.
>>
>> Forgive me is this has already been discussed and discarded by some
>> reason.
>>
>> Regards,
>> --
>> Carlos G Mendioroz  <tron at huapi.ba.ar>  LW7 EQI  Argentina
>>
>> _______________________________________________
>> Pacemaker mailing list: Pacemaker at 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
>>

-- 
Carlos G Mendioroz  <tron at huapi.ba.ar>  LW7 EQI  Argentina