Please don't do that.
Think of this scenario.
Expected_votes is set to 2 and you boot up two nodes. They work quite
happily.
You then add three more nodes and, again, they work quite happily and
quorum gets increased to 3.
The cluster splits 2+3. The three fence the two nodes, which then
reboot. Because expected_votes in their corosync.conf is 2 they come up
and have quorum.
bingo - you have two quorate clusters. Services are running in two
places, GFS filesystems (if you have them) get corrupted. Frogs,
locusts, etc ... not good :)
Chrissie
On 10/07/15 02:15, renayama19661014@xxxxxxxxx wrote:
> Hi Christine,
>
> Thank you for comments.
>
> I understand that "expected votes" is used for a calculation of QUORUM.
>
> I understood that "expected votes" was incremented automatically as specifications.
>
>
> Let me confirm only another one point.
>
>
> We intend to use the next setting regardless of the number of the nodes of the cluster.
> * Our cluster is always comprised of higher than 2 nodes.
> * In addition, we do not use the setting of "node_list".
>
> (snip)
> quorum {
> provider: corosync_votequorum
> expected_votes: 2
> }
>
> (snip)
>
> Whenever clusters increase than 3 nodes in the case of this setting, "expected votes" rises automatically.
> Right control is in this way performed by "expected votes" which increased even if a cluster divides it after the number of the nodes increased, and a calculation of QUORUM was carried out.
>
> We confirmed that is worked, but should "expected votes" always set it with the number of the nodes to constitute definitely?
>
>
> -------
> 2 node -> expected_votes: 2
> 4 node -> expected_votes: 4
> ...
> N node -> expected_votes: N
> -------
>
> We always think that "expected_votes" may be usable with a fixed value. if we ignore the control of QUORUM of the early stage of stage to constitute a cluster.
> * In this case when the point where we should be careful about is smaller than the number of the nodes that "expected_votes" constitutes, it is what may be judged before all nodes start if QUORUM is effective.
> * However, control of QUORUM cannot have the problem after the constitution of the cluster was completed.
>
>
> Best Regards,
> Hideo Yamauchi.
>
>
> ----- Original Message -----
>> From: Christine Caulfield <ccaulfie@xxxxxxxxxx>
>> To: discuss@xxxxxxxxxxxx
>> Cc:
>> Date: 2015/7/9, Thu 15:52
>> Subject: Re: [Question]About expected_votes.
>>
>> On 09/07/15 03:27, renayama19661014@xxxxxxxxx wrote:
>>> Hi All,
>>>
>>> We compose a cluster of the following setting in corosync and Pacemaekr.
>>>
>>> quorum {
>>> provider: corosync_votequorum
>>> expected_votes: 2
>>> }
>>>
>>> expected_votes increases by the increase of the node.
>>> Is this setting that does not increase possible?
>>> * It looks like specifications to increase as far as it sees a manual.
>>>
>>> When a cluster does not control QUORUM, is it necessary to set
>> expected_votes to the number of the nodes?
>>> * It seems to be necessary to set the number of all nodes by all means in
>> expected_votes when I read the next description.
>>>
>>> ---man/votequorum.5.html---
>>> (snip)
>>> votequorum reads its configuration from corosync.conf. Some values can be
>> changed at runtime, others are only read at corosync startup. It is very
>> important that those values are consistent across all the nodes participating in
>> the cluster or votequorum behavior will be unpredictable.
>>>
>>> votequorum requires an expected_votes value to function, this can be
>> provided in two ways. The number of expected votes will be automatically
>> calculated when the nodelist { } section is present in corosync.conf or
>> expected_votes can be specified in the quorum { } section. Lack of both will
>> disable votequorum. If both are present at the same time, the
>> quorum.expected_votes value will override the one calculated from the nodelist.
>>> Example (no nodelist) of an 8 node cluster (each node has 1 vote):
>>>
>>> quorum {
>>> provider: corosync_votequorum
>>> expected_votes: 8
>>> }
>>> (snip)
>>>
>>> However, I think that it is not necessary to set it because expected_votes
>> increases automatically.
>>> In other words, does expected_votes not necessarily have to set it with the
>> number of all nodes if control of QUORUM is invalid without using nodelist?
>>>
>>
>> expected_votes is needed for the quorum calculation. If the list of all
>> cluster nodes is present in corosync.conf then that is used to calculate
>> the expected votes so that the cluster will know when less than half of
>> the nodes are available.
>>
>> If there is no nodes list then then (without expected_votes) any node
>> does not know whether it is part of quorate partition or not (eg it
>> could start isolated or in a cluster of 2, not knowing there are 5 other
>> nodes it cannot see).
>>
>> So it is extremely important to set expected_votes when not using the
>> nodelist.
>>
>> You are correct that expected_votes will increase (internally, it's not
>> automatically stored in corosync.conf - that's why it should be
>> distributed) as nodes are added, this is to guard against future
>> potential cluster splits.
>>
>> Chrissie
>>
>> _______________________________________________
>> 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
