Proxmox Advent Calender 2025 4日目の記事です。
Corosync ネットワークの要件
帯域はいらないので、レイテンシー優先。かつ物理的にNICを分けることが推奨されています。
The Proxmox VE cluster stack requires a reliable network with latencies under 5 milliseconds (LAN performance) between all nodes to operate stably. While on setups with a small node count a network with higher latencies may work, this is not guaranteed and gets rather unlikely with more than three nodes and latencies above around 10 ms.
The network should not be used heavily by other members, as while corosync does not uses much bandwidth it is sensitive to latency jitters; ideally corosync runs on its own physically separated network. Especially do not use a shared network for corosync and storage (except as a potential low-priority fallback in a redundant configuration).
なぜ強く推奨するの？
クラスタ停止するから。
他の推奨事項ではそこまでの影響は出ない（例えばVMのSCSIコントローラはVirtIO SCSI利用が推奨、では性能が劣化）なんですが、Corosyncが不安定なクラスタではノード・クラスタ停止のリスクを伴うため。
このノード・クラスタ停止がわかりづらく、条件によってクラスタから外れたSelf-fenceで再起動したり、Self-fenceはせずにリソース（VM/CT）実行だけがNGになったりします。
またその状況に一時的になっていても自動復旧しており、気が付かないなんてことも。
If there are active services on the node, or if the LRM or CRM process is not scheduled or is killed, this will trigger a reboot after the watchdog has timed out (this happens after 60 seconds).
Note that if a node has an active CRM but the LRM is idle, a quorum loss will not trigger a self-fence reset.
また、昨年までは小規模環境・評価環境での利用が中心だったので他ネットワークと共用してても事象発生しなかったが、本格利用がされ始め大規模クラスタ化（≒Corosyncトラフィックの増加）・他ネットワークでの利用帯域増により事象発生というケースもちらほら。
NIC余ってないけど、どうすればいいの？
帯域幅は太くなくていい（1Gbpsでいい）ので、NICを購入してください。
HWへのコストとシステムへのリスクはトレードオフと言ってよいと思っています。
本家にチケット使っての問い合わせ、公式トレーニングでもこれは必ず言われます。
ちなみに、ZFSのL2ARC・ZILや、CephのWALも同様です。
でもSSDなどの他パーツと比較すればNICは安い方なので…
専用ネットワークを用意できない場合のアイデア
これ以降の内容はすべて根本的な解決ではない、非推奨・次善の策・ムリヤリな行為です。
自己責任で実施してください。
専用ネットワークを用意できないやんごとなき理由
- 既存HWの流用
- 半導体・サーバ全体の価格上昇
- 接続先のNW機器・ラック・電源等、周辺環境
つまり、お金がない。
お金がないからProxmox使ってる面あるし…
複数クラスタネットワークの設定
Corosync専用ネットワークを用意していても有用な設定。
共用しているCorosyncネットワークにバースト通信が発生した場合に、優先度低いネットワーク（通称？フェイルオーバーリンク）で拾える可能性あり。
ただし、フェイルオーバー先が不安定であれば中途半端にノードが生き残ってしまうので、注意が必要。
データセンターオプションのネットワーク設定
Corosync専用ネットワークを用意していても有用な設定。
マイグレーション、レプリケーションネットワークをCorosyncと分けておかないと、各動作時にCorosyncと干渉するリスクあり。
特にマイグレーションは普段実行しないので、実施時に突然クラスタが不安定になるケースはあり。
帯域制御はNICが指定できない・指定できる通信が一部なので、実用性はほぼない気が。
Corosyncのチューニング
以下記事がよくまとまっているかと。
ノード数によって可変なので係数として利用されるtoken_coefficientを修正することになります。
ちなみに、クラスタノード数が増えた場合（20ノード後半～）には、別途チューニングが推奨されます。
※ノード数によって可変な部分のチューニング。
このようなチューニングガイドについては本家で準備中・公開予定とのこと。
QoS
PVEとしてはネイティブサポートされていないが、TCなどを利用すれば可能性あり。
PVEノードだけでは完結せずに、周辺NWとの兼ね合いもあり、アウトバウンド方向にしか効果がないため、まさに苦肉の策。
Qdevice
PVEで設定するCorosyncネットワーク以外のネットワークからもQdeviceはVoteに参加可能。
これを利用して3ノードだとNW機器などの用意が難しい場合に、2ノード間でCorosyncは直結＋Qdeviceは別ネットワークから、というのは選択肢になりうる。
もちろん、Qdevice側のネットワークがある程度信頼性がある必要あり。
直結するためのNICが余ってるのでは？という突っ込みはなしで
まとめ
システムへのリスク、HW・設計コスト等諸々鑑みて、自己責任でチャレンジしてみてください。