corosyncでは、heartbeatとは異なるプロトコルで各ノードと通信を行っていますので、当然ながら各オプションについても全く異なっております。今回は、タイムアウトを規程するオプションが何かについて書きたいと思います。

タイムアウトを決めているオプションは？

結論を最初に書いてしまいますと、主にtokenとconsensusが効いてます。

token

このタイムアウト値は直接、また実際のトークンのタイムアウト計算で使用されますトークンを受信できない場合に、それを宣言するまでの時間をミリ秒で指定します。

 

 consensus

新しいメンバーシップ構成のラウンドを開始する前に、コンセンサス(合意)を得るために待つ時間をミリ秒単位で指定します。コンセンサスの最小値は1.2*トークンでなければなりません。

本当に？

manページを見るとたくさんオプションがあり、token_retransmits_before_loss_constとかmergeとかもタイムアウトに関係していそうに見えますが、どうなのでしょうか。

token_retransmits_before_loss_const

新しい構成を形成するまでに、何回トークンの再送を試みるか指定します。この値をセットすると、retransmitとholdが、retransmits_before_lossとtokenから自動的に算出されます。

 

merge

マルチキャストの通信が行われていない時に、パーティションのチェックを行うまでに待つ時間をミリ秒単位で指定します。マルチキャスト通信が送信されれば、プロトコルの機能としてマージ検知が発生します。

測ってみました

環境はCentOS 7.1、corosync2.3.4で、VirtualBox内のユニキャスト通信の2ノードクラスタです。一方のノードの通信用ネットワークを切断してから、他方のノードが切断されたノードをオフラインだと宣言するまでを、ログの出力から調べます。

まず、tokenのみを1000,4000,10000と増やしていく場合を、token_retransmits_before_loss_constが2の場合と6の場合について調べました。

tokenを増やせばタイムアウト時間が増える事が分かります。一方でtoken_retransmits_before_loss_constが2の場合と6の場合では、ほぼ同じに見えます。(ログからは１秒未満の時間は分かりません)

よく分かりませんので、token_retransmits_before_loss_constを変化させて調べてみました。

最後は思いきって増やしてしまいましたが、ほとんど変わっていません。token_retransmits_before_loss_constを変えてもタイムアウトにはあまり影響しないといってよいかと思います。

では、次にconsensusを調べてみます。

consensusを増やすと、それに応じてタイムアウト時間も増えていきました。

最後にmergeです。

mergeを増やしていってもタイムアウト時間は変わらないようです。

という事で、タイムアウト時間についてはtoken_retransmits_before_loss_constやmergeによって左右されず、tokenとconsensusを調節すれば変化するという事が分かります。