Ok the proposal I made is now "set in stone" (TM) for 2.0.
The changes from my original proposal based upon Fabio's good first cut
are that that quorum vote isn't mandatory for the config in the nodelist
(defaults to 1 if not set).
The nodelist isn't mandatory for quorum to operate.
Regards
-steve
On 01/13/2012 10:10 AM, Steven Dake wrote:
> 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
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
