【ProxmoxVE】偶数ノードクラスタでのauto_tie_breaker検証
【ProxmoxVE】偶数ノードクラスタでのlast_man_standing検証
の2つの検証結果を踏まえて、偶数ノードに関する考えをまとめてみます。
本番環境を想定した内容になります。
開発環境や検証環境であれば、障害発生時も可能な限り稼働継続させる目的で、ノード数に限らずlast_man_standingを設定するのが良いかなと思います。
いっそクラスタを組まないという選択肢もありますが、ノード数が増えてくると管理が面倒になりそうです。
ノード数の決め方
まず、仮想基盤のノード数の決め方についてです。
観点は様々あると思いますが、必要なリソース量を満たすノード数＋障害を許容するノード数＋メンテナンス時に停止を許容するノード数、という感じで決めることになると思います。
例えば、必要なリソースが2ノード分・1ノードの障害を許容・メンテナンス時に1ノード停止を想定する場合は合計4ノード、必要なリソースが4ノード・2ノード障害を許容・メンテナンス1ノードであれば合計7ノードというように決めるのがよいでしょう。
ProxmoxVEの場合、バージョンアップが速いためメジャーなHWベンダーのサーバを利用する場合はHWの保守期間中に1回はバージョンアップを検討することになると思いますので、それに備えてメンテナンス用に1ノード追加しておく、というのは悪くない考え方かなと思います。
4ノード構成について
最低限必要なリソースが2ノードで足りる場合、1ノードの故障を許容し、メンテナンス用に1ノード追加すると4ノードとなるため、あり得る構成だと思います。
4ノードクラスタのデフォルト状態ではQuoram 3となってしまうため、本記事冒頭のリンクを貼った記事の検証結果を踏まえてlast_man_standingを採用するのが良いと思います。
スプリットブレイン対策にはなりませんが、NW冗長化等でスプリットブレインが起きにくい構成とすることは可能だと思います。
また、どうしてもlast_man_standingを使いたくない場合やスプリットブレイン対策を取りたい場合は
- 1ノード追加して5ノード構成にする（予算が許せば）
- 4台のProxmoxVEとは別に投票権を持つノードを用意する（RaspberryPiなどでも可能なようですが、対障害性の考慮が必要でしょうか）
- Quoram Diskを設定する（特にHCI構成にしようとしている場合、このためにストレージを用意する？）
あたりが対策になると思いますが、それぞれ一長一短ありますね。
6ノード以上の偶数ノード構成について
6ノード以上の偶数台構成で50%の障害を許容したい場合は、1ノード減らして奇数台構成にするのが良いと思います。
例えば、6ノード構成で3ノードまで障害を許容させたいと考えているようであれば、5ノードに減らしても耐障害性・運用性とも大きく落ちることはないでしょう。
そのうえでどうしてもという場合は、auto_tie_breakerよりは4ノード構成と同じくlast_man_standingを採用して、最小ノード数を割らないよう運用でカバーするのが良いと思います。
そもそも同時に3ノードが停止する可能性は高くないですし、本番環境で半数が停止するまで対処しないということもないと思いますので、「運用でカバー」と大げさに書くようなことではないかもしれません。
多ノードでのクラスタ構成について
観点は少し変わりますが、構成ノード数が多いクラスタ、例えば20ノード構成の場合にQuoramが11だからといって11ノードまで減っても問題ないかというとそんなことはないと思います。感覚的にですが、許容できる障害は4～5ノードくらいで設計するのではないでしょうか。
そう考えると、auto_tie_breakerやlast_man_standingといった設定は少ノード構成だからこそ必要になる設定なのかもしれません。