【ITニュース解説】The cluster joined fine. Its heartbeat was on the wrong network.

複数のコンピューターを連携させて一つのシステムとして動かす「クラスター」技術は、システムの可用性や性能を高めるためにITインフラで広く利用されている。仮想化基盤であるProxmoxなどでは、クラスターを組むことで一部のサーバー故障時にもサービスを継続できる高可用性を実現できる。

ある日、Proxmoxクラスターを構築する際、管理者側は全てのコマンドが正常に完了し、システムが問題なく連携していると認識していた。クラスターを作成し、他のノードを参加させる一連の作業は、システムから「正常」を意味する緑色の表示で報告され、一見すると完璧な状態に見えた。しかし、この「正常」の裏には、将来的に大きな障害を引き起こす可能性のある潜在的な設定ミスが隠されていた。

問題の核心は、クラスター内のノード間でお互いの生存確認や設定同期を行うための「ハートビート」通信が、管理者の意図とは異なるネットワーク経路を使っていたことにある。対象のサーバーは「マルチホーム」構成であり、これは一台のサーバーが複数のネットワークインターフェースと、それに紐づく複数のIPアドレスを持っている状態を指す。具体的には、クラスター間の主要な通信を行うための「サーバーネットワーク」と、管理者がアクセスするための「マネジメントネットワーク」の二つが存在した。管理者はクラスター参加コマンドに、最初のノードのサーバーネットワークのアドレスを指定したが、参加ノードは自動的にマネジメントネットワークのアドレスをハートビート通信のアドレスとして登録してしまったのだ。

この自動選択の原因は、クラスター参加コマンド pvecm add で --link0 という重要なオプションフラグを省略したことにある。このフラグは、クラスターのメンバーシップや設定の合意を担う「Corosync」というプロトコルが使用するローカルのIPアドレスを明示的に指定するためのものだ。--link0 を指定しない場合、ノードは自身の判断ロジックに基づいてネットワークインターフェースを選択し、マルチホーム環境ではそれが必ずしも意図したものではない場合がある。今回は、偶発的にマネジメントネットワーク経由でも他のノードとの通信が可能だったため、クラスターは一時的に正常に動作していると報告し続けた。

この「正常に動作している」状態こそが最も危険な部分だった。もし通信が全くできなければ、設定ミスはすぐに発覚し、即座に修正できたはずだ。しかし、問題が表面化しないまま潜伏したため、将来的に予測不能な障害に繋がる可能性があった。マネジメントネットワークは、通常、メンテナンスのために停止したり、ファイアウォールの設定が変更されたりすることがある。一方、Corosyncのハートビート通信は、決して途切れてはならない極めて重要なプロトコルだ。もしノードが長時間ハートビートを失うと、クラスターはそのノードが故障したと判断し、高可用性（HA）が有効な環境では、クラスターが正常に動作するために必要な過半数のノード数（クォーラム）を失ったノードを、共有データの整合性保護のために強制的に再起動（「フェンス」と呼ばれる処理）させる。これは、管理者が管理用ネットワークに対して行った何気ない変更が、数ヶ月後、本番環境のサーバーを突然再起動させてしまう可能性を意味していた。このように、あらゆるテストを通過しながら、潜伏し続けるバグは、インフラシステムにおいて最も深刻な問題の一つだと言える。

この設定ミスを修正するには、Corosyncの設定ファイル /etc/pve/corosync.conf を直接編集する必要がある。このファイルには、各ノードのハートビート通信用アドレスが ring0_addr として記述されている。意図しないマネジメントネットワークのアドレスが登録されていたノードの ring0_addr を、本来使うべきサーバーネットワークのアドレスに修正する。この際、非常に重要なのが、設定ファイルのバージョンを示す totem ブロック内の config_version を一つ増やすことだ。このバージョン番号の更新により、Corosyncはこの変更を新しい有効な設定と認識し、クラスター全体で同期しようとする。この更新を怠ると、ノードが設定変更を拒否したり、クラスターが分裂したりする恐れがある。設定ファイルを修正し、config_version を更新したら、各ノードで systemctl restart corosync コマンドを使ってCorosyncサービスを一つずつ再起動する。各ノードの再起動後には、pvecm status コマンドでクラスターのクォーラムが正常に回復していることを確認しながら、次のノードに進む。この一連の修正作業は、原因が特定されれば約10分程度で完了し、作業中もクラスターはクォーラムを失うことなく稼働し続けることができた。

この経験から学んだ最も重要な教訓は、複数のネットワークインターフェースを持つサーバーをクラスターに参加させる際には、pvecm add コマンドで --link0 <このノードのクラスター用アドレス> のように、クラスター通信に使うネットワークインターフェースを明示的に指定することの重要性だ。これは単なる推奨事項ではなく、意図した通りのネットワーク構成を確実に構築するための必須作業である。そして、クラスター参加コマンドの出力が「正常」を示していても、必ずその後の設定確認を徹底するべきだ。具体的には、grep ring0_addr /etc/pve/corosync.conf コマンドで /etc/pve/corosync.conf ファイル内の ring0_addr が、すべてのノードで意図したサーバーネットワークのアドレスになっていることを手動で確認する。システムからの「正常」というメッセージは、パケットが目的地に到着したことを示してくれるが、それがあなたが意図した「正しい経路」を通ったかどうかまでは教えてくれない。特に、ネットワーク障害が直接的なシステム停止や再起動を引き起こす可能性のある重要なインフラにおいては、設定の意図と実際の経路が一致しているかを常に確認する習慣が不可欠である。