Andrew Beekhof @ 21/02/2011 11:01 -0300 dixit:
On Mon, Feb 21, 2011 at 2:05 PM, Carlos G Mendioroz <[email protected]> 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 <[email protected]> LW7 EQI Argentina
_______________________________________________
Pacemaker mailing list: [email protected]
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 <[email protected]> LW7 EQI Argentina
_______________________________________________
Pacemaker mailing list: [email protected]
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
