25.01.2012 14:07, Fabio M. Di Nitto wrote: > On 1/25/2012 6:19 AM, Fabio M. Di Nitto wrote: >>>>> >>>>> And I do not like idea of touching configuration file every time I want >>>>> to add node to cluster. And then re-distributing that config over all >>>>> nodes, and then reload it on every node. >>>>> >>>>> Now I have all 17 nodes listed in corosync.conf (UDPU), but my >>>>> expected_votes in pacemaker CIB is 3. That's why Steve's idea of >>>>> calculating expected_votes from a vote-list would be a regression for me. >>>> >>>> Ok, I´ll make it happen by allow expected_votes: XX overrides the >>>> calculated one from the nodelist. >>>> >>>> You will be able to change expected_votes at runtime if necessary (up or >>>> down) and new "seen" nodes will automatically increase the expected_votes. >>> >>> Do I need to do it on every node or just on one? >> >> Just one and the change is propagated to all nodes. >> > > I also verified this condition. One node propagates to all. Wonderful. > >>> >>> And, it should not be allowed to set it lower than number of votes from >>> currently active nodes. > > This is how it already works. If you issue the command asking for > expected_votes < number_of_active_nodes, you get ev = number_of_active_node. Great. > >>> Probably even not lower than number of votes from nodes which are now >>> either active or inactive but joined at least once (I suppose that >>> nodelist is fully editable at runtime, so admin may some-how reset join >>> count of node and only than reduce expected_votes). > > I have been thinking about this some more, but I am not sure I grasp the > use case or what kind of protection you try to suggest. > > Reducing the number of expected_votes is an admin action, it´s not very > different from removing a node from the "seen" list manually and > recalculating expected_votes. > > Can you clarify it for me? Imagine (this case is a little bit hypothetical, but anyways): * You have cluster with 8 active nodes, and you (for some historical reasons or due to admin fault/laziness) have expected_votes set to 3 (ok, you had 3-node cluster not so long ago, but added more nodes because of growing load). * Cluster splits 5+3 due to loss of communication between switches (or switch-stacks). * 3 nodes are fenced. * Partition with majority continues operation. * 3 fenced nodes boot back, and form *quorate* partition because they have expected_votes set to 3 * Data is corrupted If fenced nodes know right after boot that cluster consists of 8 active nodes, they would not override expected_votes obtained from the persistent "seen" list with the lower value from the config, and the data is safe. Is it possible to prevent such behavior currently, assuming that you have dynamically-growing cluster (nodes are powered-on on demand)? (I've seen your amazing documentation commits, but still did not dive deep enough.) Best, Vladislav _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
