※この記事は OpenShift Advent Calendar 2023 の 2日目の記事です。
こんにちは。レッドハットでクラウドインフラを生業にしている宇都宮(うつぼ)です。
なんだか久しぶりな感じがしますが、今回は Red Hat OpenShift Container Platform（OCP）の設計的な話をします。
OCP のノード構成と言えば
- Control Plane（いわゆる Master）x 3台
- Worker x 2台以上
- Infra x 2台以上
と3種類のノードを分けるのが標準です。
しかしこんなにマシンを用意したくないぜというケースもあります。そんなあなたに紹介する3ノードクラスタです。
3ノードクラスタの特徴
3ノードクラスタについては、結構前に試された記事があります。が、それ以来あまり触れられていません。ですのでベタベタ触れていきます。
参考: https://rheb.hatenablog.com/entry/openshift42-3node-baremetal
3ノードクラスタは、Control Plane と Worker と Infra で分かれて動くものを1台に全部突っ込んだノード 3 台で構成するクラスタです。 これによってマシンの数を減らすことができ、
- マシンの管理が楽になる
- IP アドレスリソースを節約できる
- インストールが早い、アップデートも早い
- インストール後にクラスタサービス（Router や Monitoring など）を Infra ノードに移動させる必要がない
といったメリットが得られます。個人的にはクラスタサービスを Infra ノードに移動させる手間が無いのは嬉しいと感じます。
事前検証や PoT/PoC などでちょっと OpenShift 試したいという場合にぴったりですし、本番用途でも全く問題なく使えます。
3ノードクラスタの注意点
一方でもちろん注意すべきデメリットもあります。
マシン1台あたりの CPU/Memory リソースは増える
Control Plane と Worker と Infra の全部が1つになるのですから、各々必要な CPU/RAM リソースも積算しなくてはなりません。これによってマシンに求められるリソースは大きくなります。
特に、標準的な構成では Infra ノードで動いていた Logging や Monitoring、OpenShift Data Foundation のような CPU/Memory intensive なコンポーネントも、3ノードクラスタだとコミコミになるので、結構リソースが必要になってきます。マシン障害時のインパクトは大きい
これは宿命みたいなものですが、みんな3台に同舟しているので、1台ズドンと落ちると Control Plane のコンポーネントもユーザーアプリケーションもクラスタサービスも、みんな影響を受けます。
1台落ちたくらいで OpenShift のサービスが止まるわけではないですが、多少の degradation は発生し得ます。ものによっては残ったノードに再スケジュールするような動きも走るので、あらかじめノードのリソースは余裕を持たせておくよう注意しましょう。
サブスクリプション費用
ここはエンジニアブログですが、私はプリセールスなので費用的な話もしておきます。
ご存知の方も少なくないと思いますが、基本的に OCP のサブスクリプションは、Worker ノードが持つ CPU コアの数を対象にチャージすると言われます。
ここで言う Worker ノードとは、"ユーザアプリケーションが稼働するノード" ということです。したがって、3ノードクラスタでは、3ノード全てがチャージ対象となります。
それでは 3ノードクラスタの場合、Control Plane や Infra コンポーネントが使う分の CPU コアはチャージ対象外になるのでしょうか？
答えは NO です。どのコンポーネントがどれだけ CPU を使うかは関係なく、あくまでマシンが持つ CPU コアで決めます。
これらを踏まえると、3ノードクラスタはサブスクリプション的には損に思えます。サブスクリプションではマシンが持つ CPU 全体がチャージされるのに、ユーザアプリケーションが使えるのは、Control Plane や Infra コンポーネントで使われる分を除いた分だからです。
この認識は正しく、基本的に Worker ノードと Control Plane または Infra を同舟させるのは、サブスクリプションとしては損をします。基本的には。
しかし例外があり、それがベアメタル OCP の場合です。
ベアメタル OCP 向けサブスクリプションはお得
ベアメタル OCP とは、仮想マシンではなく物理サーバに直接 OCP をインストールしたクラスタのことです。
OCP のサブスクリプションは基本的に CPU コア課金ですが、ベアメタル OCP の場合のみ適用できるソケット課金のサブスクリプションもあります。
これは、1 台の物理サーバがもつ CPU 合計 2 ソケットまで、かつ合計 64 コア（x86_64 では 128 スレッド）まで適用できるサブスクリプションです。
例えば 2 ソケット / 48コアのマシンを使う場合を考えます。
コア課金のサブスクリプションは 2コア単位で販売しているので、 48 コア分購入するには、24個のサブスクリプションをオーダーすることになります。これは結構な金額になります。
しかしソケット課金のサブスクリプションの場合は、1個で済みます。
いやいやソケット課金のサブスクリプションは単価が高いんでしょ？と思われるでしょう。確かにコア課金のものよりも単価は高いです。が、全体を積み重ねるとかなり得になっています。
大人の事情で詳しくは書けないのですが、1ノードあたり 16 コア前後がコア課金とソケット課金の分岐点、とだけ言っておきます。
なお、仮想マシンの OCP の場合はソケット課金は使えず、基本のコア課金となりますので、標準構成の方がサブスクリプション的にはお得になります。
OpenShift のサブスクリプションについては、こちらのサイトに細かく記載されています。
3ノードクラスタはベアメタルで、ベアメタルは 3 ノードクラスタで
前述の通り、3ノードクラスタではマシン1台あたりの CPU/Memory リソースは増えます。どれだけユーザアプリケーションを動かすか、どれだけ Infra コンポーネントを動かすかで変わりますが、4コアや8コアで済むケースは多くないでしょう。
積み重ねた結果、上記の分岐点を超えるようであれば、ベアメタル OCP は有力な選択肢になります。
反対に、ベアメタル OCP を作ることが前提の場合は、3 ノードクラスタをベースにして、必要に応じて Worker を増やしていく考えがよいでしょう。
また、ベアメタル OCP では OpenShift Virtualization という OCP 上で仮想マシンを動かす機能もサポートします。これを使っていろいろやる話はここでは省きますが、私はどこまで行ってもインフラ小僧なので物理サーバを触るのは楽しいです。ベアメタルはいいもんだぞ。ベアメタルは楽しいぞ。
というわけで、やけに生々しい話でしたが、今回はここまで。
