On 01/10/2012 03:08 AM, Fabio M. Di Nitto wrote:
> 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.
>
My suggestion is detailed and has detailed requirements, so please read
through and see if this meets the interested parties needs.
nodelist {
node X {
ring0_interface: 192.168.1.1
ring1_interface: 192.168.2.1
nodeid: 1
quorum_votes: 1
}
node Y {
ring0_interface: 192.168.1.2
ring1_interface: 192.168.2.2
nodeid: 2
quorum_votes: 2
}
}
+ nodelist is optional (mandatory when using quorum or UDPU
+ X is just a name which doesn't use the resolver but could be the DNS
name of the machine
+ nodeid is the node identifier of the containing node.
+ nodeid is mandatory for IPV6 networks, optional for IPV4 networks
+ nodeid will be autogenerated from the ip address if not specified
+ quorum_votes is mandatory if a quorum stanza is defined, otherwise ignored
quorum {
provider: corosync_votequorum
two_node: 0
wait_for_all: 0
last_man_standing: 0
auto_tie_breaker: 0
}
+ expected_votes is removed and instead auto-calculated based upon
quorum_votes in the node list
+ votes is moved to the individual node list
totem {
}
node id being set with node list defined prints a warning that node id
in totem stanza is deprecated and ignored.
if transport: udpu is specified without the node list stanza, the
configuration is rejected printing a warning that the node list must be
specified to operate in udpu mode
if the udpu member stanzas are specified, the configuration is printing
a warning that the udpu member stanza has changed
logging {
}
remains unchanged
remove service section entirely
if service section is parsed, print warning that service section is
deprecated and ignored
What we get:
+ full ability to copy 1 configuration file to all nodes assuming they
are in the same subnet with the same interface netmasks
+ node list specified in one place
+ If expected votes is needed, it can be calculated from the node list
rather then hard specified
+ old configuration files will work as they always have (with exception
of transport: udpu), but not well with quorum. This isn't a problem
because likely people are not using quorum already.
+ When totem determines its IP address via binding, it can then lookup
the node id in the node list (if its defined, or autogenerate)
What we lose:
Configurations with the UDPU stanza will need to be modified before
upgrading the software
Assuming folks agree on the general principles, We can slip the current
schedule 1 week up to RC4. RC5 would be removed from the schedule and
the end release date (3/13) remains the same assuming no problems during
the RC process.
Regards
-steve
> Thanks
> Fabio
> _______________________________________________
> discuss mailing list
> discuss@xxxxxxxxxxxx
> http://lists.corosync.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
