Dne 25.1.2012 06:19, Fabio M. Di Nitto napsal(a):
On 01/24/2012 09:09 PM, Vladislav Bogdanov wrote:
24.01.2012 19:10, Fabio M. Di Nitto wrote:
[snip]
If I power on more "unseen" nodes, expected_votes is automatically
incremented and saved into CIB. If I then power down that nodes, their
votes are still considered until I remove them from CIB and decrement
expected_votes manually (actually that part didn't fully work last time
I checked).
You can do this with votequorum already. New nodes are added to the list
and expected_votes increases automagically. On removal, you will need to
manually decrement expected_votes as you do now pretty much.
BTW, is it now possible to alter nodelist at runtime (remove some nodes
from there)? It is kinda problematic with flatiron.
I believe so, but Honza has been working on that portion of the code and
should be able to answer details better. The quorum module itself tracks
changes in that list and recalculate etc.
Ya, it's perfectly possible. Just create nodelist.node.X.ring0_addr,
where X is even nonexisting number for adding new node, or existing for
change the node (doesn't work for local node, because we are not
supporting rebind of socket yet). You can also (for example) alter
number of votes by setting nodelist.node.X.quorum_votes.
So let's give example:
- Let's add node with address 192.168.1.5
corosync-cmapctl -s nodelist.node.5.ring0_addr str 192.168.1.5
Corosync log should show something like (in debug mode):
adding dynamic member 192.168.1.5 for ring 0
- Now let's change newly added node number of votes:
corosync-cmapctl -s nodelist.node.5.quorum_votes u32 3
- And now remove node:
corosync-cmapctl -d nodelist.node.5.ring0_addr
Honza
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.
And, it should not be allowed to set it lower than number of votes from
currently active nodes.
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).
Hmmm I will need to check explicitly on what the code does if you try to
set it lower than active nodes (I didn't write all the code FYI), but
IIRC you can't really set it lower.
As for blocking it even further down, that might be problematic when
used in combination with expected_votes override and removing nodes.
Since this override feature has been approved only yesterday, I'll need
a few days to look into the corner cases and gotchas. Mostly we need to
make sure we don't introduce windows for total breakage :)
Fabio
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
