COROSYNC_CONF　Ver 3.02

名前

書式

説明

totemプロトコルの設定オプションを記載するトップレベルのディレクティブです。

ネットワークの最大送信単位を指定します。通常フレームのMTUである1500以上の値を指定するには、イーサネットデバイスがラージまたはジャンボフレームに対応している必要があります。ネットワーク中にラージフレームに対応していないデバイスがあると、このプロトコルは正常に動作しません。MTUのサイズは1500以上の値を指定する必要があります。

ラージフレーム対応のNICやスイッチで、最大フレームサイズがIPヘッダ含めて9000MTUに対応するとしているものには注意して下さい。netmtuとホストMTUに9000を指定すると、totemは9000バイトすべてをフレームに使います。そしてLinuxは18バイトのヘッダを加えるので、フレームサイズ全体では9018になります。このため、このデータサイズではハードウェアによっては正常に動作しません。netmtuが8982であれば動作するラージフレームのデバイスがある事を確認しています。実際には4500バイトのフレームサイズ対応でも、ラージフレーム対応とうたうメーカーもあります。

ネットワークが頻繁に再構成されていると、マルチキャストのトラフィックを送信する際に、デバイスによってはラージフレームに対応しないかもしれません。

ラージフレーム対応にあたっては、ハードウェア選定に注意してください。

この値のデフォルトは1500です。

このディレクティブは、使用されるトランスポートメカニズムを制御します。 デフォルトはknetです。トランスポートタイプは、udpuまたはudpに設定することもできます。 knetだけでノードごとに暗号化または複数のインターフェイスを利用できます。

クラスターの名前を指定し、マルチキャストアドレスの自動生成に使用されます。

構成ファイルのバージョンを指定します。 これは、符号なし64ビット整数に変換されます。デフォルトでは0です。オプションは、最新の構成ではない古いノードへの参加を防ぐために使用されます。値が0ではなく、ノードが単一ノードメンバーシップから複数ノードメンバーシップに初めて（初めてのみ、分割後にこのルールに従っていない場合）参加する場合、他のノードconfig_versionsが収集されます。現在のノードconfig_versionが収集されたバージョンの最高と等しくない場合、corosyncは終了します。

DNSリゾルバに問い合わせるIPのバージョンを指定します。 値は、ipv4（IPv4アドレスのみを検索）、ipv6（IPv6アドレスのみを確認）、ipv4-6（すべてのアドレスファミリを検索し、そのようなアドレスがある場合はリストにある最初のIPv4アドレスを使用します。 最初のIPv6アドレス）およびipv6-4（すべてのアドレスファミリを探し、そのようなアドレスがある場合はリストにある最初のIPv6アドレスを使用し、そうでない場合は最初のIPv4アドレスを使用します）。

デフォルト（未指定の場合）は、knetおよびudpuトランスポートの場合はipv6-4、udpの場合はipv4です。

knetトランスポートは、各リンクで一貫している場合、IPv4アドレスとIPv6アドレスを同時にサポートします。

totemディレクティブ内には、プロトコルの動作を制御するために使用されるいくつかの構成オプションがあります。 通常、適切なガイダンスと十分なテストなしにこれらの値を変更することはお勧めしません。頻繁に再構成が必要な場合、ネットワークによってはより大きな値が必要になる場合があります。 一部のアプリケーションでは、より高速な障害検出時間が必要になる場合があります。 これはトークンのタイムアウトを減らすことで実現できます。

このタイムアウトは、直接使用されるか、実際のトークンタイムアウトの計算のベースとして使用されます。（token_coefficientセクションで説明します。） トークンタイムアウトは、トークンを受信しなかった後にトークンの損失が宣言されるまでのミリ秒単位で指定します。 これは、現在の構成でプロセッサの障害の検出に費やされた時間です。 このタイムアウトに加えて、新しい構成の変更には約50ミリ秒かかります。

トーテムで使用される実際のトークンタイムアウトの場合、runtime.config.totem.tokenキーのcmap値を読み取ることができます。

クラスター内の各ノードで同じタイムアウト値を使用するように注意してください。そうしないと、予期しない結果が生じる可能性があります。

この値のデフォルトは1000ミリ秒です。

トークンが受信されなかったことを警告する間隔を指定します。 値はトークンタイムアウトの割合です。0に設定すると警告を無効にすることができます。

The default is 75%.
この値のデフォルトは75%です。

この値は、nodelistセクションが指定され、少なくとも3つのノードが含まれる場合にのみ使用されます。その場合、トークン+（number_of_nodes-2）* token_coefficientとして実際のトークンタイムアウトが計算されます。 これにより、新しいノードが追加されるたびにトークンタイムアウトを手動で変更せずにクラスターを拡張できます。 この値を0に設定すると、この機能が効果的に削除されます。

この値のデフォルトは650ミリ秒です。

このタイムアウトは、トークンを受信する前にトークンが再送信されるまでの時間をミリ秒単位で指定します。 トークンが変更されると、これは自動的に計算されます。 この値を変更すること場合はcorosyncコミュニティに相談されることを勧めます。

最小値は30ミリ秒です。 設定されておらずエラーが発生した場合は、トークン/（token_retransmits_before_loss_const + 0.2）が30を超えていることを確認してください。

2ノードクラスタのデフォルトは238ミリ秒です。 3つ以上のノードはtoken_coefficientを参照します。

Kronosnetが使用する（オプションの）圧縮のタイプ。 利用可能な値は、ビルドおよび利用可能なライブラリによって異なります。 通常、zlibとlz4が使用可能になりますが、bzip2なども許可されます。デフォルトは「なし」です

指定された値より小さいパケットを圧縮しないようにknetに指示します。 デフォルトは100バイトです。

0に設定すると、デフォルトにリセットされます。 すべてを圧縮するには1に設定します。

多くの圧縮ライブラリでは、圧縮パラメーターの調整が可能です。 たとえば、0または1 … 9は一般に圧縮レベルを決定するために使用されます。 この値は変更されずに圧縮ライブラリに渡されるため、詳細についてはライブラリのドキュメントを参照することをお勧めします。

このタイムアウトは、プロトコルの使用率が低い場合にトークンを保持する時間をミリ秒単位で指定します。 corosyncコミュニティの指導なしでこの値を変更することはお勧めしません。

デフォルトは180ミリ秒です。

この値は、新しい構成を形成する前に再送信を試行する必要があるトークンの数を識別します。token_retransmitおよびhold計算にも使用されます。

デフォルトは4回の再送信です。

このタイムアウトは、メンバーシッププロトコルで参加メッセージを待機する時間をミリ秒単位で指定します。

デフォルトは50ミリ秒です。

このタイムアウトは、結合メッセージを送信する前に待機する0からsend_joinまでの範囲をミリ秒単位で指定します。 32ノード未満の構成の場合、このパラメーターは不要です。 大きなリングの場合、このパラメーターは、新しいリングの形成時に参加メッセージでNICがオーバーフローしないようにするために必要です。 大きなリング（128ノード）の妥当な値は80ミリ秒です。 この値を変更した場合、他のタイマー値も変更する必要があります。 大規模な構成を実行しようとする場合は、corosyncメーリングリストからアドバイスを求めてください。

デフォルトは0ミリ秒です。

このタイムアウトは、メンバーシップ構成の新しいラウンドを開始する前にコンセンサスが達成されるまで待機する時間をミリ秒単位で指定します。 コンセンサスの最小値は1.2 *トークンでなければなりません。ユーザーがコンセンサス値を指定しない場合、この値は1.2 *トークンで自動的に計算されます。

2ノードクラスタの場合、コンセンサスは参加タイムアウトよりも大きく、トークンよりも小さい方が安全です。 3ノード以上のクラスターの場合、コンセンサスはトークンよりも大きくする必要があります。コンセンサスがトークンよりも少ない場合、ノード数が増えると、メンバーシップの変更のリスクが高まり、仮想同期が保証されます。

デフォルトは1200ミリ秒です。

このタイムアウトは、マルチキャストトラフィックが送信されていないときにパーティションをチェックするまでの待機時間をミリ秒単位で指定します。 マルチキャストトラフィックが送信されている場合、マージ検出はプロトコルの機能として自動的に行われます。

デフォルトは200ミリ秒です。

このタイムアウトは、ネットワークインターフェイスがダウンした後にバックアップされることを確認する前に待機する時間をミリ秒単位で指定します。

デフォルトは1000ミリ秒です。

この定数は、新しい構成が形成される前にメッセージを受信する必要があるときに、メッセージを受信せずにトークンをローテーションする回数を指定します。

デフォルトでは、メッセージの受信に失敗する回数は2500です。

この定数は、ホールドタイマーが開始される前に、マルチキャストトラフィックなしでトークンをローテーションする回数を指定します。

デフォルトの回数は30回です。

[HeartBeating mechanism] 障害検出を高速化するために、オプションのHeartBeatingメカニズムを構成します。損失の多いネットワークでこのメカニズムを使用すると、メカニズムがハートビートをネットワークに依存しているため、損失に誤りが生じる可能性があることに注意してください。

したがって、使用率の低いネットワークから中程度のネットワークで障害を改善する必要がある場合、経験則としてこのメカニズムを使用します。

この定数は、システムがハートビート障害を宣言する前に許容する必要があるハートビート障害の数、例えば3などを指定します。また、この値が設定されていないか0である場合、ハートビートメカニズムはシステムに関与しておらず、トークンローテーションが障害検出の方法になります。

デフォルトは0（無効）です。

[HeartBeating mechanism]この定数は、あるマシンから別のマシンにパケットを転送するためにネットワークが要するおおよその遅延をミリ秒単位で指定します。 この値はシステムエンジニアが設定するものであり、ハートビートを使用した障害検出メカニズムに影響するため、不明な場合は変更しないでください。

デフォルトは50ミリ秒です。

この定数は、1回のトークンローテーションで送信できるメッセージの最大数を指定します。すべてのプロセッサーのパフォーマンスが同等であれば、この値は大きくなる可能性があり（300）、非常に大きなリングの発信から配信までの待ち時間が長くなります。 大きなリング（16以上）のレイテンシを減らすために、デフォルトは安全な妥協案です。 高速プロセッサの中に1つ以上の低速プロセッサが存在する場合、window_sizeはカーネル受信バッファのオーバーフローを回避するために 256000 / netmtuより大きくない必要があります。 このことは、通知ログに再送信リストを表示することでユーザーに通知されます。 データが損失することはありませんが、これらのエラーが発生するとパフォーマンスが低下します。

デフォルトは50メッセージです。

この定数は、トークンの受信時に1つのプロセッサが送信できるメッセージの最大数を指定します。カーネル送信バッファーのオーバーフローを防ぐため、max_messagesパラメーターは256000 / netmtuに制限されています。

デフォルトは17メッセージです。

この定数は、トークンの受信時に、再送信が発生する前に再送信についてメッセージがチェックされる最大回数を定義します。 このパラメーターは、ユニキャストパケットと比較してマルチキャストパケットを遅延させるスイッチを変更するのに役立ちます。 デフォルト設定は、ほぼすべての最新のスイッチでうまく機能します。

デフォルトは5メッセージです。

ネットワークMTUの変更を探すためにknet PMTUdが実行される頻度。 値のデフォルトは30秒です。

udpuとknetがcorosyncに認識されていないIPアドレス（ノードリストに存在しないノード）からパケットをドロップできるようにします。 値はyesまたはnoです。

この機能は主に、クラスター分割後の古い構成を持つノードの結合を防ぐためのものです。 別の使用例は、2つの独立したクラスターのアトミックマージを許可することです。

デフォルト値を変更することはお勧めできません。オーバーヘッドが小さく、古い構成でリストされていないノードでcorosyncを起動すると、既存のクラスターで障害が発生する可能性があります。

この値のデフォルトはyesです。

ロギングディレクティブ内には、すべてオプションの設定オプションがいくつかあります。

次の3つのオプションは、最上位のロギングディレクティブに対してのみ有効です。

これは、すべてのログメッセージにタイムスタンプが配置されることを指定します。 off（タイムスタンプなし）、on（秒精度のタイムスタンプ）、またはhires（ミリ秒精度のタイムスタンプ-LibQBでサポートされている場合のみ）のいずれかです。

デフォルトはhires（またはhiresがサポートされていない場合はオン）です。

これは、ファイルと行を記録することを指定します。

デフォルトはオフです。

これは、コード関数名を表示することを指定します。

デフォルトはオフです。

これは、ブラックボックス機能を有効にすることを指定します。

デフォルトはオンです。

次のオプションは、トップレベルのロギングディレクティブの両方に有効であり、logger_subsysエントリでオーバーライドできます。

これらは、ログ出力の宛先を指定します。 これらのオプションの任意の組み合わせを指定できます。 有効なオプションはyesおよびnoです。

デフォルトはsyslogおよびstderrです。

to_logfileを使用していて、ファイルをローテーションする場合は、オプションcopytruncateを指定してlogrotate（8）を使用してください。 例えば次のように設定します。

/var/log/corosync.log {
    missingok
    compress
    notifempty
    daily
    rotate 7
    copytruncate
}

to_logfileディレクティブがyesに設定されている場合、このオプションはログファイルのパス名を指定します。
これは、この特定のサブシステムのログファイルの優先順位を指定します。 デバッグがオンの場合は無視されます。 可能な値は、alert、crit、debug（debug = onと同じ）、emerg、err、info、notice、warningです。

デフォルトはinfoです。

これは、この特定のサブシステムのログファイルの優先順位を指定します。 デバッグがオンの場合は無視されます。 可能な値は、alert、crit、debug（debug = onと同じ）、emerg、err、info、notice、warningです。

デフォルトはinfoです。

これは、syslog.optionsに送信されるメッセージに使用されるsyslog機能タイプを指定します。optionsは、daemon、local0、local1、local2、local3、local4、local5、local6、およびlocal7です。

デフォルトはdaemonです。

これは、この特定のサブシステムのsyslogレベルを指定します。 デバッグがオンの場合は無視されます。 可能な値は、alert、crit、debug（debug = onと同じ）、emerg、err、info、notice、warningです。

デフォルトはinfoです。

これは、この特定のロガーのデバッグ出力を記録するかどうかを指定します。 また、最高レベルのデバッグ情報である値トレースを含めることができます。

デフォルトはオフです。

ロギングディレクティブ内では、logger_subsysディレクティブはオプションです。

logger_subsysサブディレクティブ内では、上記のロギング構成オプションはすべて有効であり、デフォルト設定をオーバーライドするために使用できます。 以下で説明するsubsysエントリは、サブシステムを識別するために必須です。

これは、ロギングが指定されるサブシステムID（名前）を指定します。 これは、log_init（）呼び出しでサービスが使用する名前です。 例えば。 「CPG」。 このディレクティブは必須です。

quorum ディレクティブ内では、プロバイダーディレクティブで使用するクォーラムアルゴリズムを指定できます。 執筆時点では、corosync_votequorumのみがサポートされています。 設定オプションについては、votequorum（5）を参照してください。

nodelist ディレクティブ内では、クラスター内のノードに関する特定の情報を指定できます。ディレクティブには、メンバーシップのメンバーであるすべてのノードを指定するnodeサブディレクティブのみを含めることができ、デフォルト以外のオプションが必要です。 すべてのノードには、少なくともring0_addrフィールドが入力されている必要があります。

メンバーシップのメンバーである必要があるすべてのノードを指定する必要があります。

可能なオプションは次のとおりです。

これは、特定のノードのIPまたはネットワークホスト名アドレスを指定します。 Xはリンク番号です。

この構成オプションは、Kronosnetモードの各ノードに必要です。 これは、クラスターメンバーシップサービスに配信されるノード識別子を指定する32ビット値です。 ノード識別子の値ゼロは予約されているため、使用しないでください。 knetが設定されている場合、このフィールドを設定する必要があります。

このオプションは、主にknetトランスポートでローカルノードを識別するために使用されます。 クライアントソフトウェア（pacemaker）でも使用されます。 ローカルノードを識別するアルゴリズムは次のとおりです。

1.ノードリストで$ HOSTNAMEを検索します
2.これが失敗した場合、$HOSTNAMEからドメイン名を取り除き、ノードリストでそれを検索します
3.これに失敗した場合は、短いバージョンが$ HOSTNAMEの短いバージョンと一致する完全修飾名をノードリストで検索します
4.すべてが失敗した場合は、nodelist内の名前と一致するアドレスのインターフェースリストを検索します

システムディレクティブ内では、システムオプションを指定できます。

可能なオプションは次のとおりです。

qb_ipc_type

これは、使用するIPCのタイプを指定します。 ネイティブ（デフォルト）、shm、およびソケットのいずれかです。 ネイティブとは、OSでサポートされているものに応じて、shmまたはソケットのいずれかを意味します。 両方をサポートするシステムでは、SHMが選択されています。 SHMは一般に高速ですが、リングバッファファイルを/dev/shmに割り当てる必要があります。

sched_rr

corosyncがそれ自体に最大の優先度でラウンドロビンリアルタイムスケジューリングを設定しようとする場合は、yes（デフォルト）に設定する必要があります。 スケジューラーの設定が失敗した場合、フォールバックして最大の優先順位を設定します。

priority

corosyncプロセスの優先度を設定します。 sched_rrがnoに設定されている場合にのみ有効です。 nice（1）と同様の意味を持つエーテル数値、または最大/最小の優先度を意味するmax / min（したがって、最小/最大のnice値）を指定できます。

move_to_root_cgroup

corosyncが自分自身をルートcgroupに移動しようとする場合は、yes（デフォルト）に設定する必要があります。 この機能は、RT schedが有効になっているcgroupを備えたシステムでのみ使用できます（LinuxオプションCONFIG_RT_GROUP_SCHED）。

state_dir

The default is /var/lib/corosync.
デフォルトは/var/lib/corosyncです。

resourcesディレクティブ内では、リソースのオプションを指定できます。

可能なオプションは次のとおりです。

（Corosyncがウォッチドッグサポート付きでコンパイルされた場合のみ有効です。）
使用するウォッチドッグデバイス。たとえば、/dev/watchdog。 未設定、空、または「オフ」の場合、ウォッチドッグは使用されません。

一方、遅いウォッチドッグ通信では、Corosyncメインループで数秒の遅延が発生し、メンバーシップが破壊される可能性があります。 IPMIウォッチドッグはこの点で特に有名です。LinuxカーネルのドキュメントのIPMI.txtでkipmid_max_busy_usについて読んでください。

nozzle ディレクティブ内で、libnozzleデバイスのオプションを指定できます。これは、ネットワークトラフィックをcorosync knetネットワーク上のチャネル（cpgまたはcorosync内部サービスではない）を介してクラスター内の他のノードにルーティングする擬似イーサネットデバイスです。これにより、アプリケーションはマルチパス、自動フェイルオーバー、リンクスイッチングなどのknet機能を利用できます。libnozzleは信頼できるトランスポートではありませんが、信頼できる通信のためにTCPをトンネリングできます。

libnozzleは、/etc/corosync/updown.d/ディレクトリの下に保持されるオプションのインターフェースup/downスクリプトもサポートします。詳細については、knetのドキュメントを参照してください。

使用できるnozzleデバイスは1つだけです。

nozzle stanza にはいくつかのオプションがあります。

作成するネットワークデバイスの名前。 Linuxでは、これはどのような名前でもかまいませんが、他のプラットフォームでは名前に制限があります。

インターフェースのIPアドレス（IPv6またはIPv4）。 このアドレスの下部は、ipprefixと共にローカルノードのnodeidに置き換えられます。 たとえば、ipaddr：192.168.1.0 ipprefix：24は、nodeid 1,2,5がIPアドレス192.168.1.1、192.168.1.2および192.168.1.5を使用するようにします。 プレフィックス長16が使用される場合、下2バイトはノードID番号で埋められます。 IPv6アドレスは「::」で終わる必要があります。ノードIDは2つのコロンの後に追加され、ローカルIPアドレスを作成します。 現在、corosync.confファイルでは1つのIPアドレスのみがサポートされています。 必要に応じて、ifupスクリプトに追加のIPアドレスを追加できます。

ノズルデバイスのIPアドレスプレフィックスを指定します（上記を参照）

ノズルデバイスのMACアドレスプレフィックスを指定します。 IPアドレスについては、MACアドレスの下部にノードIDが入力されます。 この場合、プレフィックスは適用されず、MACアドレスの下位2バイトは常にノードIDで上書きされます。 したがって、nodeid 1にmacaddr：54：54：12：24：12：12を指定すると、MACアドレスは54：54：12：24：00：01になります。

nodelist {
    node {
    	 nodeid: 1
         ring0_addr: 10.24.38.101
         name: node1
     }
     node {
         nodeid: 2
         ring0_addr: 10.24.38.102
         name: node2

     }
}

既存のノードの下にノードの新しいエントリを追加します。 ノードエントリはノードIDの順序である必要はありませんが、正気を保つのに役立ちます。 したがって、ノードリストは次のようになります。

nodelist {
    node {
    	 nodeid: 1
         ring0_addr: 10.24.38.101
         name: node1
     }
     node {
         nodeid: 2
         ring0_addr: 10.24.38.102
         name: node2
     }
     node {
         nodeid: 3
         ring0_addr: 10.24.38.108
         name: NEW
     }
}

次に、このファイルを3つのノードすべて（既存の2つのノードと新しいノード）にコピーする必要があります。 既存のcorosyncノードのいずれかで、更新された構成ファイルをメモリに再読み込みするようにcorosyncに指示します。

corosync-cfgtool -R

このコマンドは、クラスター内の1つのノードでのみ実行する必要があります。 その後、新しいノードでcorosyncを開始すると、クラスターに参加するはずです。 これが期待どおりに機能しない場合は、3つのノードすべて間の通信が機能していることを確認し、すべてのノードのsyslogファイルで詳細を確認してください。 参加に失敗したノードに関する重要な情報は、予想とは異なるノードにある可能性があることに注意することが重要です。

/etc/corosync/corosync.conf
The corosync executive configuration file.

corosync_overview(7), votequorum(5), corosync-qdevice(8), logrotate(8) getaddrinfo(3) gai.conf(5)