はじめに

みなさん、こんにちは。 Red Hatでソリューションアーキテクトをしている小野です。

OpenShift にはエッジ向けデプロイメントとして、Control Plane と Worker のデプロイメントパターンがいくつか存在します。本稿では、各デプロイメントパターンの違いや使い分け、CPU やメモリのサイジングなどの最小ハードウェア要件をまとめます。

まとめ記事ですので、ぜひブックマークしておいて頂ければ幸いです！

デプロイメントパターン

エッジ環境へ OpenShift をデプロイする際に、大きく以下の5パターンの選択肢があります。

OpenShiftの基本構成は、Control Plane 3台、Worker 2台です。

OCP 4.6よりサポートされた Remote Worker Node は、何か特別な機能を提供するものでなく、Control Plane からネットワーク的に離れたオンプレミス環境へ Worker Node のみをデプロイできる、という構成の一つと理解頂くのが良いかと思います。スペース制約のあるエッジ環境へも OpenShift を展開できるようにする目的で提供されています。

例えば、vRAN のコンポーネントである CU(Central Unit) と DU(Distributed Unit) のトポロジを考えたときに、スペース制約のある県内の分散局舎に Remote Worker Node を配置して DU を稼働させ、県を統括する集約局舎で CU を配置し、県内のDUを集約する、というような使い方が考えられます。

ただし、Remote Worker Node を採用する際は、Control Plane と Worker 間のネットワーク障害を考慮した設計が必要である点に注意して下さい。注意事項の詳細は以下のドキュメントをご参照下さい。

access.redhat.com

3 Nodeは、OCP 4.5 よりサポートされ、OpenShift の可用性とFootprintのバランスを取りたい場合の選択肢です。 Red Hat のコンテナストレージ製品の Red Hat OpenShift Data Foundation (ODF) のデプロイも可能です。

Single Node は、OCP 4.9 よりサポートされ、単一のサーバで OpenShift の Control Plane と Worker を展開するパターンです。 Remote Worker Node と同様、スペース制約のあるエッジ環境への OpenShift の展開を目的に提供されていますが、Remote Worker Node との違いは、ネットワーク障害発生によりエッジサイトが NW上孤立状態に陥っても、エッジサイト内でノードの管理が可能である点です。

その反面、OpenShiftのControl Planeが分散配置される形となりますので、アプリケーションのデプロイが煩雑になります。Single Nodeのクラスタが多くのエッジサイトへデプロイされるケースでは、Red Hat Advanced Cluster Management for Kubernetes（RHACM）を用いて各クラスタを一元管理することもあわせて検討するのが良いかと思います。

Single Node の構成は、Red Hat の実験プロジェクトである MicroShift というソフトウェアでも実現可能です。 MicroShiftはラズパイなどのエッジデバイスへのOpenShiftのデプロイを目的に開発されたバイナリサイズ160MBの最小Footprintの OpenShift です。但し、MicroShiftは実験プロジェクトですので、現時点で製品サポートは無く、将来の製品リリースが約束されているわけではない点ご注意下さい。

各パターン一長一短あり、どのパターンを採用するかは、Footprint(消費リソースの多さ)の大きさと Availability のどちらをどれだけ重視するかに依るかと思います。以下にて各パターンのポジションと使い分けの例をまとめてみました。

Remote Worker Nodeは、前述の通りControl PlaneとWorker間のネットワーク断により、クラスタの動作が不安定になるリスクが潜在しています。したがって、品質を自分達でコントロールできるネットワークを介して構成するのをお薦めします。同時に、エッジサイトの消費リソースを小さくするという目的を考えると、特定のアプリケーション専用のWorker Nodeとする、という使い方が適していると考えます。

OpenShift Installの最小ハードウェア要件

最後に各パターンの最小ハードウェア要件を以下にまとめます。

パターン	ノード	台数	CPU/台	メモリ/台	DISK/台	備考
default	Bootstrap Control Plane Worker	1 3 2	4 4 2	16GB 16GB 8GB	120GB	・基本的な構成・Bootstrapはインストール後に削除してOK ・install後にWorker/Remote Worker Nodeを追加可能
3 Node Cluster	Control Plane+Worker	3	6	24GB	120GB	・Small Footprintかつ高可用性のバランス重視・このクラスタへODFのデプロイも可能・install後にWorker/Remote Worker Nodeを追加可能
Remote Worker Node	Worker	1	2	8GB	120GB	・Workerをリモート配置するoption (何か特別な機能があるわけでなくパターンの一つ) ・Control Plane間は2ms未満のレイテンシ要件でリモート設置はNG（Raftアルゴリズムのため）・Control Plane-Worker間のレイテンシは、サポート要件はないが200ms未満が推奨される
Single Node	Control Plane+Worker	1	8	16GB	120GB	・高可用性よりもFootprint重視・Control Planeは約2コアとメモリ16GBが使用され、残りはユーザーワークロードの実行に使用・専用のISOを用いてinstall(Red Hat ACM 2.4のゼロタッチプロビジョニング or Assisted Installer )
MicroShift	Control Plane+Worker	1	2	2GB	1GB	・ラズパイなどのエッジデバイス向けのバイナリサイズ160MBの軽量OpenShift ・現時点ではRed Hatの実験プロジェクトでありサポートされない・対象OS：RHEL8/CentOS Stream8/Fedora 34+ ・AMD64/ARM64/RISCV64も対象・(参考)Qiitaにてインストール方法を少し触れてます
(参考)CodeReadyContainer	Control Plane+Worker	1	4	9GB	35GB	・実稼働環境での使用は目的外。開発や試験用途・対象OS: MAC/Windows/Linux ・新バージョンへのアップグレードパス無
(参考)MiniShift	Control Plane+Worker	1	2	4GB	20GB	・実稼働環境での使用は目的外。開発や試験用途・OpenShift 3のデプロイとなり現在の使用は非推奨
(参考) RHEL	ー	ー	1	1.5GB	10GB