はじめに
Corosync深堀記事書きましたのでこちらも是非(2025年10月27日)
以前の記事で、高額な電気代に愕然とし、省電力な自宅サーバー環境へと構成を刷新した話を紹介しました。現在は省電力なMINI PCや中古PCを組み合わせて、なんとか快適なProxmoxクラスタ生活を送っています。
Proxmoxで「クラスタ」を組むと、複数台のサーバーを1つの画面で管理できたり、VMをライブマイグレーションできたりと、めちゃくちゃ便利ですよね。
※再構築中でpve1がなかったり、VMが色々テスト用だったりですがお気になさらず..
でも、この便利な機能の裏側で、一体何が動いているのかって、自分はあまり意識したことがありませんでした。
今回は仕事でも色々リサーチする機会があり、Proxmoxクラスタの安定性を支えるCorosync（コロシンク）について、その役割や大事なポイント、そして「自宅サーバー（Homelab）ならどこまで気にすればいいの？」という落としどころまで、自分なりにまとめてみます。
Corosyncってそもそも何？
すごくざっくり一言でいうと、クラスタを組んだサーバー同士がお互いの状態を確認し合い、情報を共有するためのソフトウェアです。Proxmoxのクラスタはこの上で成り立っているんですね。
主な役割はこんな感じみたいです。
- メンバーシップ管理: クラスタに参加しているノード（サーバー）を管理。「誰が今、クラスタにいるのか」を常に把握しているらしい。
- メッセージング: ノード間で確実な情報伝達を行う。VMの起動や停止といった命令を、全てのノードに正確に伝える役割。
- クォーラム（Quorum）の管理: クラスタが正常な状態を保つための「多数決」の仕組み。ここが一番大事なポイントらしいです！
クォーラムとは？
Proxmoxクラスタを運用する上で避けて通れないのがクォーラム (Quorum) という考え方です。一言でいうと、サーバーたちの話し合いが混乱しないためのルールのことです。
なんでそんなルールが必要なのか
サーバー間のネットワークに問題が起きて、クラスタが分断されてしまったらどうなるでしょう？
例えば、4台のサーバーで組んだクラスタが、ネットワークの故障で2台ずつのグループに分裂してしまったとします。
↓そもそもこんな構成にしないと思いますが、今回は例えばということで。。
こうなると、お互いのグループは「自分たち以外のサーバーは全員ダウンした！」と勘違いしてしまいます。そして、それぞれのグループが「自分たちが本物のクラスタだ！」と思って、同じVMを起動しようとしたり、同じディスクに書き込みを始めたり…これがスプリットブレインです。怖すぎます...。
クォーラムの仕組み
スプリットブレインを防ぐのがクォーラムの役割です。ルールはシンプルで、クラスタ全体の過半数のメンバーがいるグループだけが正式な活動を許可されるという多数決です。
半数に満たない少数派のグループは、クォーラムを失ったと判断され、勝手なことをしないように自動的にサービスを停止します。これをフェンシングと呼ぶらしいです。
ProxmoxのWeb UIでノードが赤く表示され「No Quorum?」といったエラーが出ているときは、あなたは今、多数派から外れて少数派になっちゃったので、安全のためにおとなしくしてますよという状態というわけです。
クォーラムを失うと実際に何が起きるか
フェンシングはただサービスが止まるだけじゃなく、もっとアグレッシブな動きをすることもあるみたいです。
ネットワークの遅延などでCorosyncの通信が不安定になると、ノードが「自分はクラスタから孤立した！」と判断して、安全のために自ら再起動することがあります。
実際、ネットワークが瞬断するだけでも、かなり素早くセルフフェンシングが作動して再起動に至ることがあるので、重要なVMを動かしているときは結構焦ります…。
素早くといっても数十秒は余力があるようにも見える。。
そのときのシステムログを見ると何が起きているかがよく分かります。
ノードは奇数台がいい理由
この多数決のルールがあるから、Proxmoxでは3台以上の奇数台でクラスタを組むことが推奨されているらしいです。
- 3台構成なら: 1台ダウンしても、残りの2台で過半数を維持できます。
- 4台構成だと: 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
おわりに
今回はCorosyncについて自分なりにまとめてみました。キーとなるのは「クォーラム」と「ネットワークの安定性（特に遅延）」ということがよく分かりました。
本番環境のベストプラクティスを学びつつ、自分のHomelab環境に合わせてどこまで手を加え、どこで割り切るかを判断するのが大事なんだな、と改めて感じます！