Hi Christine,
Thank you for detailed explanation.
It surely becomes so that a cluster is started at the time of start automatically when it is fenced as you say.
We do not use the setting of the automatic start very much.
However, we decide to set "expected_votes" with the number of all nodes definitely.
Many thanks!
Hideo Yamauchi.
----- Original Message -----
> From: Christine Caulfield <ccaulfie@xxxxxxxxxx>
> To: discuss@xxxxxxxxxxxx
> Cc:
> Date: 2015/7/10, Fri 15:32
> Subject: Re: [Question]About expected_votes.
>
> 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
>
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
