Hi all,
in some recent discussions, it come up the issue on how to configure
quorum module. As I don´t really have a complete solution yet, I need to
seek advice in the community :)
Problem:
it would be very nice if corosync.conf could be simply scp´ed/copied
between nodes and everything works as expected on all nodes.
Issue being that some quorum bits are, at this point in time, node
specific. It means that to alter some values, it is necessary to edit
corosync.conf on the specific node.
On top of that, it would be nice if expected_votes could be
automatically calculated based on votes: values.
The current quorum configuration (based on topic-quorum patches):
quorum {
provider: corosync_votequorum
expected_votes: 8
votes: 1
two_node: 0
wait_for_all: 0
last_man_standing: 0
auto_tie_breaker: 0
}
totem {
nodeid: xxx
}
The 2 values that cannot be copied around are quorum.votes and totem.nodeid.
In current votequorum/totem incarnation, votes/expected_votes/nodeid are
all broadcasted to all nodes. so each node that joins the cluster
becomes aware of the other peers values.
As a consequence of the current config format, auto_tie_breaker feature,
requires wait_for_all to work (in order to have the complete list of
nodeids, see auto_tie_breaker implementation in topic-quorum branch for
details).
Honza and I quickly explored options to add those values into the node
list of udpu, but that´s limiting because it doesn´t work well in
multicast and/or broadcast and it has integration issues with RRP.
Also adding lists to quorum {} involves a certain level of duplicated
information.
For example:
quorum {
nodeid_list: x y z...
node.x.votes: ..
node.y.votes: ..
}
that IMHO is all but nice to look at.
So the question of changing the config format also raise the following
questions:
1) do we really need to support an auto_tie_breaker feature without
wait_for_all? if NO, then we don´t need the list of nodeids upfront.
2) do we really care about votes other than 1? If NO, then votes: can
simply be dropped from corosync.conf defaults, and in case an override
is necessary, it can be done specific to the node. This solution poses
the problem that expected_votes need to be set in corosync.conf (one
liner in the config file vs different liners) but it might be slightly
more tricky to calculate if votes are not balanced.
Please let me know your opinions and we need to come down to an
agreement rather soon, since this might be a blocker for corosync 2.0
release.
Thanks
Fabio
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
