Proxmox VEでCorosync冗長ネットワーク（Dual Ring）を構築しSplit-Brainを防ぐ - ITFROMZERO - Share tobe shared! Proxmox VEにおけるCorosync Dual Ring（冗長ネットワーク）の詳細な構築手順を解説。Kronosnetを用いたネットワーク冗長化により、高可用性（HA）クラスタをクォーラム喪失やスプリットブレインのリスクから確実に保護します。

Table of Contents

1本のLANケーブルが招くProxmox HAクラスタの崩壊

深夜2時、ネットワークスイッチのファームウェアが突然フリーズした場面を想像してみてください。その瞬間、Proxmox HAクラスタはクォーラム信号を見失います。各ノードは対向ノードがダウンしたと判断し、ウォッチドッグ機構が作動して一斉に自己再起動を開始します。さらに深刻なのは、共有ストレージへの接続が維持されていた場合です。スプリットブレイン（Split-Brain）が発生し、分断されたノード群が同時にデータ書き込みを競合してしまいます。その結果、わずか数秒で仮想ディスクのデータ破損（VM disk corruption）に至ります。

筆者自身、18台のVMを稼働させていた3ノードのホームラボ環境でこの手痛い障害を経験しました。当初は、Corosync、VMネットワーク、バックアップに至る全トラフィックをVLAN経由で単一の物理NICにまとめていました。しかし、Proxmox Backup Server（PBS）が110MB/sのフルスピードでデータ転送を始めた途端、ネットワークポートが完全に飽和してしまったのです。

Corosyncのpingレイテンシは突如80msまで跳ね上がり、クラスタはノード喪失のアラートを連発。この経験から得た教訓は明確です。「Corosyncに必要なのは広帯域ではなく、極めて安定した低遅延である」ということ。クラスタを本番稼働させる前に、冗長ネットワーク（Redundant Ring / Dual Ring）の構築は絶対に欠かせない必須作業です。

Corosync Dual Ringの本質：Kronosnet（knet）の仕組みとは？

Proxmox VE 6以降、Corosyncはバージョン3.xへアップグレードされ、基盤としてKronosnet（knet）を採用しました。この進化により、クラスタ間通信のあり方が根本から変わりました。

マルチリンク（Multi-link）対応：最大8系統の物理リンク（link0〜link7）を接続可能です。スイッチ側で遮断されがちだったIPマルチキャストへの依存も解消されました。
柔軟なフェイルオーバー機構：Knetはpassiveとactiveの2つの転送モードを提供します。デフォルトのpassiveモードではプライマリリンクの完全切断時のみバックアップリンクへ切り替えますが、activeモードでは両方の経路へ同時にパケットを送信し、切替時の遅延を完全に排除します。
LACPの限界を克服：LACP（802.3adボンディング）でNICを束ねても、スイッチ自体の電源障害や制御チップのハングアップには耐えられません。Corosync Dual Ringなら、link0をスイッチAに、link1をスイッチBに収容することで、完全に独立した2系統のネットワークを確立できます。

Corosyncルーティングにおける3大鉄則

帯域幅よりも低ジッターを最優先：ハートビートパケットのサイズはわずか100〜300 bytes/s程度ですが、2ms未満の極めて安定したレイテンシが求められます。Cephやバックアップの負荷がかかる10Gbps光ファイバーよりも、独立した1Gbpsケーブル1本のほうが遥かに安全です。
サブネットの完全分離：Corosyncの各リンクには、それぞれ独立したIPセグメントを割り当てる必要があります（例: link0には192.168.10.0/24、link1には192.168.20.0/24）。
デフォルトゲートウェイを設定しない：通信はLayer 2で完結させます。Corosyncのパケットを経路上のルーターに通過させては絶対にいけません。

3ノードクラスタにおけるDual Ring設定手順

今回はpve-01、pve-02、pve-03の3ノード構成を例に進めます。既存のlink0は192.168.10.0/24で稼働している前提とし、冗長スイッチ経由のセカンダリNIC（link1）に192.168.20.0/24を割り当てていきます。

ステップ1：各ノードでセカンダリNICを設定する

各サーバーにSSHでログインし、ネットワーク設定ファイルを編集します。

nano /etc/network/interfaces

2つ目のインターフェース（例: ノードpve-01のeno2）を定義します。

auto eno2
iface eno2 inet static
    address 192.168.20.11/24
    # 注意：このインターフェースには絶対にgatewayを設定しないでください

サーバーを再起動することなく、ネットワーク設定を即時反映します。

ifreload -a

残り2台のノードも同様に設定します（ノード2には192.168.20.12、ノード3には192.168.20.13を付与）。設定後、新たに追加したIP同士でpingを実行し、2系統目の物理結線が正常に疎通していることを確認してください。

ステップ2：クラスタ設定ファイルのバックアップ

corosync.confはProxmoxクラスタの生命線です。インデントのズレやタイポが1箇所あるだけでもサービスが起動しなくなる恐れがあります。作業前に必ずバックアップを作成しておきましょう。

cp /etc/pve/corosync.conf /etc/pve/corosync.conf.bak

ステップ3：corosync.confを編集してlink1を追加

/etc/pve/配下はクラスタファイルシステム（pmxcfs）により全ノード間で自動同期されるため、作業はいずれか1台のノード上で行うだけで構いません。

nano /etc/pve/corosync.conf

Corosync 3の仕様に沿って、totemブロックとnodelistセクションを以下のように更新します。

totem {
  cluster_name: homelab-cluster
  config_version: 2
  interface {
    linknumber: 0
  }
  interface {
    linknumber: 1
  }
  ip_version: ipv4
  link_mode: passive
  secauth: on
  version: 2
}

nodelist {
  node {
    name: pve-01
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 192.168.10.11
    ring1_addr: 192.168.20.11
  }
  node {
    name: pve-02
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 192.168.10.12
    ring1_addr: 192.168.20.12
  }
  node {
    name: pve-03
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 192.168.10.13
    ring1_addr: 192.168.20.13
  }
}

必須ルール：このファイルを編集する際は、毎回必ずconfig_versionの数値を1つインクリメント（例: 1から2へ変更）してください。Proxmoxはこのバージョン番号を基準に新しいリビジョンを識別し、クラスタ全体へ正しく同期します。

ステップ4：Corosyncプロセスの再読み込み

ファイルを保存したら、各ノードで以下のコマンドを実行して設定を再読み込みします。

systemctl reload-or-restart corosync

ステップ5：Dual Ringの稼働ステータスを確認

まず、クラスタ全体の健全性を確認します。

pvecm status

続いて、以下のコマンドでknetのリンク詳細ステータスを表示させます。

corosync-cfgtool -s

正常に動作していれば、両方のリンクが健全な状態として出力されます。

Printing link status:
LINK ID 0:
	addr    = 192.168.10.11
	status  = OK
LINK ID 1:
	addr    = 192.168.20.11
	status  = OK

LINK ID 1のステータスがstatus = OKになっていれば、サーバークラスタは2系統の独立した保護経路で安全に防護されています。

実運用で役立つトラブルシューティングとベストプラクティス

ファイアウォール（Firewall）のポート開放：CorosyncはUDPポート5405〜5412を使用します（リンク数に応じて増加）。Proxmoxの組み込みファイアウォールやLayer 3スイッチのACLを有効化している場合は、両方のサブネットでこれらのポートを開放してください。
Activeモードへの移行検討：2台のスイッチが同等の性能・帯域幅を備えている場合は、totemブロック内の設定をlink_mode: passiveからlink_mode: activeに変更することを推奨します。クォーラムパケットが常時双方の回線を流れるため、片方のスイッチが電源断に見舞われても障害検出時間を待たずに通信断をゼロに抑えられます。
Quorum喪失時の緊急レスキュー：万一設定ファイルの記述ミスによりクラスタがロックされ、/etc/pve/が読み取り専用（Read-only）モードに陥った場合は、直ちにpvecm expected 1を実行してください。必要な投票数を一時的に1に引き下げることで、作業中ノードの書き込み権限が復活し、設定ファイルを修復できるようになります。

追加のギガビットスイッチ1台と数本のLANケーブルというわずかな投資で、Proxmoxクラスタはスプリットブレインの脅威に耐えうる堅牢性を手に入れ、夜間のネットワーク障害による緊急呼び出しからも解放されます。