[ClusterLabs] Antw: corosync.conf token configuration

Ulrich Windl Ulrich.Windl at rz.uni-regensburg.de
Fri Dec 22 04:20:55 EST 2017

I agree that documentation for all these parameters and theit dependencies
could (=should) be better.

>>> Adrián Gómez <a.gomez at medlabmg.com> schrieb am 19.12.2017 um 14:18 in
<0A91BB3C-0039-424E-8DAC-2961055B164D at medlabmg.com>:
> Hello,
> I was wondering if someone have some description of the parameters: token, 
> token_retransmits, token_retransmits_before_loss_const and consensus. I have

> read about it in the man page of corosync.conf but trying some configuration

> of the cluster I realized that I did not control when the new configuration

> or stonith was going to happened. I have tried corosync 1.X and 2.X in 
> several virtual servers (debian-9). 
> corosync.conf:
> 	# How long before declaring a token lost (ms)
> 	token: 20000
> 	# Consensus, time before token lost to stonith the server (ms)
> 	# consensus: 60000
> 	# Interval between tokens (ms)
> 	# token_retransmit: 10000
> 	# How many token retransmited before forming a new configuration
> 	token_retransmits_before_loss_const: 20
> I expected to declare the token lost before 20s after the processor failed 
> (for example, connection lost to the servers), then 
> "token_retransmit_before_lost_const" should act (I don’t know how it
> and the stonith occurs 24s before the message of “new configuration”
> consensus = 1,2 * token -> 1,2 * 20s = 24s). In brief, the cluster is barely

> 44s awake without connection before reboot (stonith) is done, in contrast, I

> expect the parameter "token_retransmits_before_loss_const: 20” to delay
> token lost whilel is trying to reconnect.
> I am right?
> On the other hand, If I use the parameter consensus, I can calculate exactly

> when the stonith is going to happen.
> Please, if someone knows the answer I will appreciate any help.
> Thank you

More information about the Users mailing list