📝 はじめに
以前の記事で、高額な電気代に愕然とし、省電力な自宅サーバー環境へと構成を刷新した話を紹介しました。現在は省電力なMINI PCや中古PCを組み合わせて、なんとか快適なProxmoxクラスタ生活を送っています。
さて、Proxmoxで「クラスタ」を組むと、複数台のサーバーを1つの画面で管理できたり、VMをライブマイグレーションできたりと、めちゃくちゃ便利ですよね。
※再構築中でpve1がなかったり、VMが色々テスト用だったりですがお気になさらず..
でも、この便利な機能の裏側で、一体何が動いているのかって、自分はあまり意識したことがありませんでした。
今回は仕事でも色々リサーチする機会があり、Proxmoxクラスタの安定性を支えるらしい超重要なコンポーネント、Corosync（コロシンク）について、その役割や大事なポイント、そして「自宅サーバー（Homelab）ならどこまで気にすればいいの？」という現実的な落としどころまで、自分なりにまとめてみようと思います。
🤝 Corosyncってそもそも何者？
Corosyncをすごくざっくり一言でいうと、
クラスタを組んだサーバー同士が、お互いの状態を確認し合い、情報を共有するための「神経系」みたいなものらしいです。
Proxmoxのクラスタは、このCorosyncというソフトウェア（オープンソースソフトウェア）の上で成り立っているんですね。こいつが裏で健気に働いてくれているおかげで、自分たちは便利な機能を使えている、と。
主な役割はこんな感じみたいです。
- メンバーシップ管理: クラスタに参加しているノード（サーバー）を管理。「誰が今、クラスタにいるのか」を常に把握しているらしい。
- メッセージング: ノード間で確実な情報伝達を行う。例えば、VMの起動や停止といった命令を、全てのノードに正確に伝える役割。
- クォーラム（Quorum）の管理: クラスタが正常な状態を保つための「多数決」の仕組み。ここが一番大事なポイントらしいです！
⚖️ クラスタの安定を守る「クォーラム」とは？
Proxmoxクラスタを運用する上で、絶対に避けて通れないのがクォーラム (Quorum) という考え方みたいです。
一言でいうと、サーバーたちの話し合いが、混乱しないためのルールのことです。
なんでそんなルールが必要？ 「スプリットブレイン」問題
もし、サーバー間のネットワークに問題が起きて、クラスタが分断されてしまったらどうなるでしょう？
例えば、4台のサーバーで組んだクラスタが、ネットワークの故障で2台ずつのグループに分裂してしまったとします。
↓そもそもこんな構成にしないと思いますが、今回は例えばということで。。
こうなると、お互いのグループは「自分たち以外のサーバーは全員ダウンした！」と勘違いしてしまいます。
そして、それぞれのグループが「自分たちが本物のクラスタだ！」と思って、同じVMを起動しようとしたり、同じディスクに書き込みを始めたり… まさに脳が2つに分かれて、それぞれが勝手に体を動かそうとしちゃうような状態。これがスプリットブレインです。怖すぎます...。
クォーラムの仕組み - シンプルな「多数決」
このスプリットブレインを防ぐのがクォーラムの役割です。
ルールはとてもシンプルで、クラスタ全体の半数を超える（過半数の）メンバーがいるグループだけが、正式な活動を許可されるという、ただの多数決です。
クラスで何かを決めるとき、過半数の賛成がないと決まらないのと同じですね。
半数に満たない少数派のグループは、クォーラムを失ったと判断され、勝手なことをしないように自動的にサービスを停止します。これをフェンシングと呼ぶらしいです。
だから、ProxmoxのWeb UIでノードが赤く表示され、「No Quorum?」といったエラーが出ているときは、あなたは今、多数派から外れて少数派になっちゃったので、安全のためにおとなしくしてますよという状態というわけです。
クォーラムを失うと、実際に何が起きるのか？
この「フェンシング」、ただサービスが止まるだけじゃなく、もっとアグレッシブな動きをすることもあるみたいです。
ネットワークの遅延などでCorosyncの通信が不安定になると、ノードが「自分はクラスタから孤立した！」と判断して、安全のために自ら再起動することがあります。
実際、ネットワークが瞬断するだけでも、かなり素早くセルフフェンシングが作動して再起動に至ることがあるので、重要なVMを動かしているときは結構焦ります…。
素早くといっても数十秒は余力があるようにも見える。。
その時のシステムログを見ると、何が起きているかがよく分かります。
なぜノードは「奇数台」がいいの？
この「多数決」のルールがあるから、Proxmoxでは3台以上の奇数台でクラスタを組むことが強く推奨されているらしいです。
- 3台構成なら: 1台ダウンしても、残りの2台で多数派（過半数）を維持できます。
- 4台構成だと: 2台ダウンすると、残りは2台。2対2に分かれる可能性があり、どちらも多数派になれずクラスタが停止するリスクがあります。
- 5台構成なら: 2台ダウンしても、残りの3台で多数派を維持できます。
偶数台だと、ちょうど半分に分裂したときに「多数派」が存在しなくなり、クラスタ全体が機能停止してしまうリスクが高まる、というわけですね。
🏢 推奨設定（本番環境ではこうするべきらしい）
本番環境でCorosyncの通信を安定させるためには、以下のような構成が推奨されています。
- 冗長化された専用ネットワーク: Corosync専用の物理NICを最低2本用意し、ネットワーク経路を分ける。
- 専用スイッチ: Corosyncの通信を他のトラフィック（VMやストレージの通信）から完全に物理的に分離する。
現実的にHomelabでここまで揃えるのは難しいですが、「とにかくCorosyncの通信を最優先で安定させる」という基本思想を知っておくだけでも、トラブルシューティングの時に役立つと思います。
🏡 自宅サーバー（Homelab）ならどうする？
小規模な自宅クラスタなら、管理用ネットワークとの兼用でも問題なく動作するケースが多いです。自分の環境も、各ノード1本のNICで管理アクセス、VM通信、Corosync通信をすべてまかなっています。
注意点:
- ネットワーク帯域の逼迫: 大量のデータ転送で帯域を使い切ると、Corosyncの通信（ハートビート）が遅延し、ノードがダウンしたと誤検知される可能性があります。（自分も実際、VMのマイグレーションやISOファイルのアップロードを同時にやっていたら、クラスタが不安定になったことがあります…）
- スイッチの性能: 安価なスイッチだと、通信が不安定になる要因になることも考えられます。
まずは1本のNICで始めてみて、もし問題が出るようならネットワークの増強を検討する、というのが現実的な進め方かなと思います。
2台構成はやっぱりダメ？
2台構成は、片方がダウンすると即クォーラムを失うためHA（高可用性）には向きませんが、「管理を楽にしたい」という目的でクラスタを組むことは可能です。
注意点: 片方が落ちると、残ったノードもクォーラムを失い、新しいVMの起動などができなくなります。
対策: 生き残ったノードで pvecm expected 1 を実行し、「今は自分1台だけで動くのが正常な状態だよ」と教えてあげることで、手動で復旧できます。
# 2台構成のノードで、片方がダウンしたと仮定
# クォーラムの状態を確認
$ pvecm status
...
Quorum: No
...
# 期待ノード数を1に設定（緊急復旧用）
$ pvecm expected 1
# 再度状態を確認
$ pvecm status
...
Quorum: Yes
...
自宅でいろいろいじってて急に一個のノード動かなくなった！ってときにも上記のコマンド使えます。。
また、QDeviceという仕組みを使って、ラズパイなどを「投票権だけを持つ3台目のメンバー」として追加し、2台構成のクォーラム問題を解決する方法もあるらしいです。ただ、設定はやや複雑になるとのこと。
英語記事ですが下記参照リンク
- https://forum.proxmox.com/threads/2-node-ha-with-external-qdevice.135429/
- https://pve.proxmox.com/wiki/Cluster_Manager#_quorum:~:text=i*)%20%3B%3B%0A%20%20%20%20%20%20*)%20return%3B%3B%0Aesac-,Corosync%20External%20Vote%20Support,-This%20section%20describes
💭 おわりに
今回はProxmoxクラスタを支えるCorosyncについて、自分なりにまとめてみました。
キーとなるのは「クォーラム」と「ネットワークの安定性（特に遅延）」ということがよく分かりました。
本番環境のベストプラクティスを学びつつ、自分のHomelab環境に合わせてどこまで手を加え、どこで割り切るかを判断するのが大事なんだな、と改めて感じます！