Red Hat Summitセルフマネージド Red Hat OpenShift サブスクリプションガイド
はじめに
この資料では、セルフマネージド Red Hat® OpenShift® 製品のサブスクリプションモデルに関する説明のほか、Red Hat OpenShift 環境に必要なエンタイトルメントの数を見積もるための手順を紹介します。サイジングに関してより詳細な情報をご希望の場合は、Red Hat までお問い合わせください。
定義
まず、理解する必要があるいくつかの用語を定義します。
- コアペア：セルフマネージド OpenShift サブスクリプションのベースの 1 つで、2 つの物理コアまたは 4 つの vCPU として定義されます。ベアメタルマシンでは、どのハイパースレッディングまたは対称マルチスレッディング・テクノロジーであっても、常に物理コアを指します。ハイパースレッディングがオンになっている場合、4 つの vCPU となる 2 つの物理コアは 1 つのコアペアとしてカウントされます。ハイパースケーラーのデプロイメントの場合 (例：AWS、Azure、GCP)、4 つの vCPU は常に単一のコアペアとみなされます。コアペアのサブスクリプションはクラスタレベルでカウントされるため、複数のクラウドインスタンス、仮想マシン (VM)、および物理サーバーにまたがることができます。
- ベアメタルソケットペア：これはセルフマネージド OpenShift サブスクリプションのもう 1 つのベースです。サーバーごとに少なくとも 1 つのベアメタルソケットペアのサブスクリプションが必要であり、最大 128 コアをカバーします。1 つのベアメタルソケットペアのサブスクリプションが複数のサーバーにまたがることはできません。また、サブスクリプション内のコアが複数のサーバーにまたがることもできません。ベアメタルソケットペアのサブスクリプションをスタックして、より多くのコアおよびソケットをカバーすることができます。
- AI Accelerator：必要な Red Hat AI Accelerator サブスクリプションの数は、中央処理装置 (CPU) の外部で特定のコンピュート機能を高速化する物理ハードウェア・アドオン・デバイスの数に基づきます。これらには、アドオンとしてインストールされるディスクリート・グラフィックス・プロセッシング・ユニット (GPU)、テンソル・プロセッシング・ユニット (TPU)、データ・プロセッシング・ユニット (DPU)、フィールド・プログラマブル・ゲート・アレイ (FPGA)、特定用途向け集積回路 (ASIC)、およびネットワーク・プロセッシング・ユニット (NPU) が含まれますが、これらに限定されません。メイン CPU と緊密に統合されたアクセラレーター (統合 GPU、NPU、その他のタイプのアクセラレーターなど) は含まれません。多くの場合、これらは仮想化され、複数の VM またはインスタンスに対応し、CPU コアに似た 1 つまたは複数の「コア」を備えている場合がありますが、サブスクリプションは物理デバイスの数に基づきます。
- SLA：Red Hat サブスクリプションには、サポートのサービスレベル契約 (SLA) を選択する必要があります。選択できるサポートは、8x5 (スタンダード) または 24x7 (プレミアム) の 2 つです。
- ワーカーノード：エンドユーザー・アプリケーションの Pod が実行される Red Hat Enterprise Linux® または Red Hat Enterprise Linux CoreOS のインスタンス (VM またはベアメタルホスト) を指します。OpenShift 環境には多数のコンピュートノードが存在可能です。これらのノードには OpenShift サブスクリプションが必要です。コンピュートノードをサポートするコントロールプレーン・ノードとインフラストラクチャ・ノードにはサブスクリプションは必要ありませんが、インフラストラクチャのコストが発生する場合があります。
- コントロールプレーン・ノード：Red Hat OpenShift の Kubernetes オーケストレーションまたは管理レイヤーとして機能する Red Hat Enterprise Linux CoreOS のインスタンス (VM またはベアメタルホスト) を指します。コントロールプレーン・ノードのエンタイトルメントはセルフマネージド OpenShift サブスクリプションに含まれており、購入するサブスクリプションの数を決定するためにカウントする必要はありません。詳細については、「Red Hat OpenShift コントロールプレーンとインフラストラクチャ・ノード」の項を参照してください。
- インフラストラクチャ・ノード：アプリケーション・インスタンスではなく、OpenShift クラスタ・インフラストラクチャをサポートする Pod を実行しているノードです(たとえば、Ingress トラフィック用に HAProxy ベースのロードバランサーを実行しているノード)。インフラストラクチャ・ノードのエンタイトルメントはセルフマネージド OpenShift サブスクリプションに含まれており、ユーザー・アプリケーション・インスタンスが実行されていない限り、購入するサブスクリプションの数を決定するためにカウントする必要はありません。
- クラスタ：コントロールプレーン、オプションのインフラストラクチャ・ノード、1 つまたは複数のコンピュートノードで構成される OpenShift Kubernetes クラスタです。
アプリケーション・インスタンス：アプリケーションは、単一の Pod インスタンスの場合もあれば、複数の Pod インスタンスにデプロイされてアプリケーションサービスを構成する場合もあります。たとえば、高可用性 Tomcat アプリケーションサービスは、2 つ以上の Pod で構成されている場合があります。アプリケーション・インスタンスは常に、Red Hat OpenShift サブスクリプションによってエンタイトルメントが付与されたコンピュートノード上で実行する必要があります。
Red Hat OpenShift サブスクリプションのエディション
Red Hat OpenShift は、オープン・ハイブリッドクラウド環境全体で一貫したアプリケーション開発および管理プラットフォームを提供し、オンプレミス、仮想、物理インフラストラクチャ、およびプライベートクラウド、パブリッククラウド、エッジデプロイメントに対応します。Red Hat OpenShift を運用および使用する方法には、セルフマネージド OpenShift とフルマネージド OpenShift クラウドサービスの 2 つがあります。このガイドではセルフマネージド OpenShift に焦点を当てます。
セルフマネージド OpenShift を使用すると、最大限の制御とカスタマイズが可能であり、非常に柔軟な Red Hat OpenShift 環境をインストール、運用、および管理できるため、インフラストラクチャを始めとするお客様独自の環境を運用することができます。セルフマネージド OpenShift は、オンプレミス (物理サーバー、仮想化、プライベートクラウド環境を使用)、およびサポートされているパブリッククラウド環境にも対応します。お客様は、アップグレードの制御、下位レベルのインフラストラクチャの管理、サービスレベル契約 (SLA) の維持を行います。
マネージド OpenShift クラウドサービスは、Red Hat と、主要なパブリッククラウドにおける当社のパブリッククラウド・パートナーによって完全に管理および運用されます。専任のサイト信頼性エンジニアリング (SRE) チームが Red Hat OpenShift のコアサービスとインフラストラクチャの管理と保守を行うため、DevSecOps チームは新しいアプリケーションの開発とデプロイ、既存アプリケーションのモダナイズに集中できます。
OpenShift クラウドサービスの提供内容と詳細情報の入手先：
- Red Hat OpenShift Dedicated：Amazon Web Services (AWS) および Google Cloud で実行されるフルマネージドの Red Hat OpenShift サービス。
- Microsoft Azure Red Hat OpenShift：Microsoft Azure で動作するフルマネージドの Red Hat OpenShift サービス。Red Hat とマイクロソフトが共同で管理します。
- Red Hat OpenShift Service on AWS：Amazon Web Services で動作するフルマネージドの Red Hat OpenShift サービス。Red Hat と AWS が共同で管理します。
- Red Hat OpenShift on IBM Cloud：IBM Cloud で動作するフルマネージドの Red Hat OpenShift サービス。Red Hat と IBM が共同で管理します。
OpenShift のすべてのエディションでは、あらゆる環境全体で開発者チームと運用チームに一貫したユーザーエクスペリエンスが提供されるため、アプリケーションが最適に実行されるクラウド環境においてお客様のスキルとアプリケーションを活用できます。
セルフマネージド OpenShift サブスクリプションで考慮すべき点
セルフマネージド OpenShift (Red Hat OpenShift Platform Plus、Red Hat OpenShift Container Platform、Red Hat OpenShift Kubernetes Engine、Red Hat OpenShift Virtualization Engine) は、64 ビットの Red Hat Enterprise Linux が認定およびサポートされている場所ならどこでも使用できます。こちらのドキュメントを参照して、OpenShift のデプロイ方法とサポートされているインフラストラクチャのタイプの詳細をご確認ください。
セルフマネージド OpenShift ソフトウェアのエディション：
- Red Hat OpenShift Kubernetes Engine：エンタープライズ向けのハイブリッドクラウドの Kubernetes ランタイムエンジンであり、アプリケーションをデプロイおよび実行するための Red Hat OpenShift のコア機能を提供します。データセンター、パブリッククラウド、またはエッジ環境にインストールして管理します。
- Red Hat OpenShift Container Platform：エンタープライズ向けのハイブリッドクラウドの Kubernetes プラットフォームであり、アプリケーションを構築、デプロイ、実行するためのフル機能を備えています。データセンター、パブリッククラウド、およびエッジ環境にインストールして管理します。
- Red Hat OpenShift Platform Plus：単一のハイブリッドクラウド・プラットフォームで、複数のクラスタおよびクラウド環境にわたり、インテリジェントなアプリケーションを大規模に構築、デプロイ、実行、管理できます。セキュリティ、管理性、自動化に関して複数のレイヤーを備えており、ソフトウェア・サプライチェーン全体で一貫性を提供します。OpenShift Platform Plus サブスクリプションは、x86 ベースのクラスタでのみ使用できます。
- Red Hat OpenShift Virtualization Engine：Red Hat OpenShift とオープンソースのカーネルベースの仮想マシン (KVM) ハイパーバイザーに基づく、ベアメタルのみの仮想化インフラストラクチャ製品です。VM のデプロイ、管理、拡張のための信頼性の高いエンタープライズグレードのソリューションを提供することを目的として構築されています。OpenShift 機能のサブセットであるこの OpenShift エディションは、仮想マシンのみのワークロードを対象とし、コンテナではインフラストラクチャ・サービスのみがサポートされます (つまり、エンドユーザー・アプリケーション・コンテナはサポートされません)。
サブスクリプションの種類
セルフマネージド OpenShift には 2 種類のサブスクリプション (コアペアとベアメタルソケットペア) があり、各サブスクリプションでは 2 つのサポートレベルが利用できます。
環境内のコンピュートノードには、コンピュートノードのサブスクリプションが必要です。これらは、コアペアまたはベアメタルソケットペアによってエンタイトルメントが与えられます。
- コアペア (2 つのコアまたは 4 つの vCPU)
- サブスクリプション・オプションは、OpenShift Kubernetes Engine、OpenShift Container Platform、OpenShift Platform Plus で利用できます。コアペアのサブスクリプションは OpenShift Virtualization Engine には適用されません。
- CPU コアにエンタイトルメントを付与する場合は、コアペア・サブスクリプションを使用してエンタイトルメントを付与する、すべての OpenShift クラスタで実行されているすべての OpenShift コンピュートノードにわたる物理コアまたは vCPU の合計数をカウントします。
- 標準の 8x5 またはプレミアムの 24x7 のサポート SLA が利用できます。
- ベアメタルソケットペア (1 - 2 ソケット、合計最大 128 コア)
- このサブスクリプション・オプションは、すべてのセルフマネージド OpenShift エディションで利用でき、OpenShift Virtualization Engine の唯一のオプションです。
- このサブスクリプションは、OpenShift がハードウェアに直接インストールされる x86 および ARM ベアメタル物理ノードでのみ使用できます。サードパーティのハイパーバイザーは許可されません。
- これは「仮想データセンター」サブスクリプション (単一のサブスクリプションで任意のハイパーバイザーホストに VM ゲスト・オペレーティングシステム (OS) を無制限にインストールできる仮想データセンター用 Red Hat Enterprise Linux など) ではありません 。
- 標準の 8x5 またはプレミアムの 24x7 のサポート SLA が利用できます。
- 2 ソケットを超える、または 128 コアを超えるベアメタルサーバーの場合はスタックすることができますが、1 つのサブスクリプションで複数のベアメタルサーバーをカバーすることはできません。
さらに、環境内のアクセラレーターに対して Red Hat AI Accelerator サブスクリプションが必要になります。
- AI Accelerator (1 アクセラレーター)
- このサブスクリプションは、AI ワークロードの演算アクセラレーションを提供する、CPU パッケージの一部ではなく個別のアドオンであるアクセラレーターカード (GPU、TPU、NPU、FPGA、DPU など) に必要です。
- Red Hat OpenShift のエディションに関係なく、各物理 AI アクセラレーターに同じサブスクリプションが使用されます。
- Red Hat OpenShift と OpenShift AI の両方がクラスタにインストールされている場合は、単一の AI Accelerator サブスクリプションで十分です。
- アクセラレーター機能が演算アクセラレーションに使用されていない限り、このサブスクリプションは必要ありません。たとえば、ネットワーク・アクセラレーションのためだけに SmartNIC として使用する DPU (DPU に未使用のアドレス指定可能な ARM コアがある場合でも)、または AI アクセラレーションではなくグラフィックスのレンダリングに使用される GPU などです。
- 標準の 8x5 またはプレミアムの 24x7 のサポート SLA が利用できます。SLA は、サポートするコアペアまたはベアメタルソケットペアのサブスクリプションの SLA と一致する必要があります。
コアペアのサブスクリプションを選択するケース
セルフマネージド OpenShift をパブリッククラウド・ハイパースケーラーにデプロイする場合や、サービスとしてのインフラストラクチャ (IaaS) のプライベートクラウド内にデプロイする場合、または VMware vSphere、Red Hat OpenStack® Platform、Nutanix などのハイパーバイザーにデプロイする場合は、コアペア・サブスクリプションを選択することが最も多くなります。
コアペア・サブスクリプションにより、物理サーバーにサブスクリプションを適用する必要がなくなり、必要なときにいつでもどこでも Pod をハイブリッドクラウド全体に自由にデプロイできるようになります。
ベアメタルサーバーまたはデバイス (ハイパーバイザーなし) でコアペア・サブスクリプションを使用することもできます。注意が必要なのは、コンピュート Pod の密度によっては、ベアメタルソケットペアのサブスクリプションのほうがコスト効率が高くなる場合があることです。
OpenShift Virtualization Engine を専用の仮想化プラットフォームとして使用する場合に選択できるのは、ハイパーバイザー自体のためのベアメタル・ソケットペア・サブスクリプションに加えて、コアペア・サブスクリプションを使用して VM 上の OpenShift コンテナにエンタイトルメントを付与することです。セルフマネージド OpenShift のコアペア・サブスクリプションを個別に購入し、この環境内の VM に割り当てることができます。これはつまり、アプリケーションを購入してそれを VM として実行するのと同様です。この場合、コアの密度が高いと、セルフマネージド OpenShift のベアメタル・ソケットペア・モデルに切り替えたほうがコスト効率が高くなる場合があります。こちらのモデルでは、ベアメタルサーバー上の OpenShift コンテナが無制限となり、OpenShift VM でのそれらのコンテナの実行がサポートされるからです。
コアペア・サブスクリプションは、OpenShift クラスタ全体ですべての OpenShift コンピュートノードをカバーできるように分散することができます。たとえば、100 個のコアペア Red Hat OpenShift Platform Plus サブスクリプションで 200 コア (400 vCPU) がカバーされますが、これらはハイブリッドクラウド環境全体の実行中のすべての OpenShift クラスタにわたり、任意の数のコンピュートノードで使用できます。
ベアメタルソケットペアのサブスクリプションを選択するケース
ベアメタルソケットペアのサブスクリプションは、データセンター内またはサポートされているベアメタルオファリング上のホスト型プライベートクラウド内で、あるいはサポートされているベアメタルオファリング上のハイパースケーラーを使用して、専用の物理サーバーにデプロイされた OpenShift コンピュートノードのためのオプションです。ベアメタルソケットペアのサブスクリプションは、OpenShift Virtualization Engine の唯一のオプションです。また、もう一方のセルフマネージド OpenShift エディションで OpenShift Virtualization 機能をサポートするために必要です。
ベアメタルソケットペアのサブスクリプションごとに、ソケットペア全体で最大 128 個の物理コアにエンタイトルメントが付与されます。ベアメタル・サブスクリプションは、合計 128 コアを超えるソケットペアと、2 つ以上のソケットペアを持つ物理サーバーの両方をカバーするためにスタックできます。
物理サーバーにエンタイトルメントを付与するには、そのサーバー内のソケットまたは物理コアの総数 (どちらか大きい方) に応じて、1 つ以上のサブスクリプションをスタックします。たとえばサーバーに、各 CPU に 48 コアを備えた 2 つのソケットがあり、合計 96 コアがあるとします。このサーバーには 1 - 2 個のソケットがあり、コア数が 128 未満であるため、1 つのサブスクリプションが必要です。また、2 つのソケットと合計 192 のコアを持つサーバーの場合は、2 つのサブスクリプションが必要です。1 つのサブスクリプションがカバーするのは最大 128 コアなので、192 コアをカバーするには 2 つのサブスクリプションが必要になります。それぞれ 1 つのソケットがある 2 台のサーバーをカバーするために、または別々のサーバーのコアをカバーするために、単一のベアメタルソケットペアのサブスクリプションを複数の物理ホストに分割することはできません。
ソケットベースのエンタイトルメントを使用する各物理ベアメタルサーバーは、Kubernetes アーキテクチャの性質により、単一の OpenShift ノードとしてのみ使用できます。Kubernetes の各ノードは 1 つのクラスタにのみ属することができるからです。つまり、ベアメタルサーバー上のすべてのコンテナは同じクラスタに属することになります。これは、OpenShift Virtualization (各ワークロードが完全な VM を実行している) のようなリソースを大量に消費するワークロードには適していますが、他のワークロードには適していない可能性があります。OpenShift は単一ノード上で最大 2,500 個のコンテナをサポートしますが、パフォーマンスやアーキテクチャ上の理由から、異なるノードまたは異なるクラスタ間でコンテナを分割したい場合があります。これは、仮想化を使用してベアメタルサーバー上に個別のコンピュートノードを作成しない限り不可能です。
コンテナの一般的なデプロイメントモデルは、それぞれコンテナ数が少ない多数のクラスタを構築することです。このモデルはハイパースケーラー環境において一般的であり、データセンターでは、ハイパーバイザーを使用して、コンテナがデプロイされるコンピュートノードとなる VM を作成することで実現できます。VMware vSphere、Red Hat OpenStack Platform、Nutanix などのハイパーバイザーの場合は、VM にデプロイされた OpenShift 向けにコアペア・サブスクリプションを使用する必要があります。
ベアメタルにデプロイされ、エンタイトルメントのあるソケットペアのサブスクリプションを持つ OpenShift Kubernetes Engine、OpenShift Container Platform、OpenShift Platform Plus クラスタには、OpenShift Virtualization と、それらにデプロイされる同じ製品タイプの仮想 OpenShift クラスタのサブスクリプションを含めます。これは、たとえばベアメタル OpenShift Container Platform クラスタにデプロイされた仮想 OpenShift クラスタが、ホストしているベアメタルクラスタから OpenShift Container Platform サブスクリプションを継承することを意味します。
重要な注意事項は、OpenShift Virtualization Engine サブスクリプションにはコンテナ化されたアプリケーション・インスタンスのサポートが含まれていないことです。例外は、以下の OpenShift Virtualization Engine セクションで定義されているインフラストラクチャ・ワークロードです。 OpenShift Virtualization Engine を使用して独自のコンテナ化されたアプリケーションのワークロードを実行したい場合は、セルフマネージド OpenShift のコアペア・サブスクリプションを使用して VM にエンタイトルメントを付与する必要があります。または、より高い密度では、セルフマネージド OpenShift Kubernetes Engine、OpenShift Container Platform、または OpenShift Platform Plus にベアメタルソケットペアのサブスクリプションを購入することを選択できます。これにより、コンテナベースのアプリケーションをベアメタルクラスタ上でネイティブに実行できる、または前の段落で説明したように仮想クラスタがサブスクリプションを継承できます。
同じクラスタ内で OpenShift 製品タイプを混在させることはできません。すべてのノードは、同じ OpenShift Virtualization Engine、OpenShift Kubernetes Engine、OpenShift Container Platform、または OpenShift Platform Plus 製品タイプを使用してサブスクリプションを購入する必要があります。ただし、単一クラスタ内でコアペア・サブスクリプションとソケットペア・サブスクリプションを使用することはできます。たとえば、VM をホストするためのいくつかの OpenShift Virtualization Engine ノードと、コンテナ化されたアプリケーションおよび仮想 OpenShift インスタンスをホストするために OpenShift Platform Plus を使用してサブスクライブされている他のノードを、単一のベアメタルクラスタに含めることはできません。
AI Accelerator サブスクリプションのカウント方法
最近では、特定の計算ワークロードの高速実行が可能な特定のハードウェア・テクノロジーが市場に登場しています。これらのタイプのハードウェアデバイスは、Red Hat の一部のコンテンツではアクセラレーターまたは AI アクセラレーターと総称されます。最新のサーバーで利用できるハードウェアデバイスには、GPU、TPU、ASIC、NPU、FPGA など (これらに限定されません)、アクセラレーターとして分類できるいくつかの種類があります。
これらのアクセラレーターは通常、サーバーの PCI (Peripheral Component Interconnect) スロットを占有するカード、ボード、またはその他の物理デバイスです。これはほとんどの場合、アクセラレーターベンダーから購入したユニット数です。たとえば、ベンダーが「8 つの GPU を搭載している」としているサーバーの場合、これはほとんどの場合、8 つの物理アクセラレーターユニットを意味します。
各 AI Accelerator サブスクリプションは、1 つの物理アクセラレーターデバイスをカバーします。たとえば、AI Accelerator のサブスクリプションだけに焦点を当てると、次のようになります。
- 4 つの物理 GPU デバイスを備えた物理コンピュートノードには、コンピュートノードをカバーする CPU コアペアまたはソケットペアのサブスクリプションに加えて、4 つの AI Accelerator サブスクリプションが必要になります。
- 複数の vGPU として VM に提示される、1 つの物理 GPU デバイスを備えた単一の仮想コンピュートノードでは、仮想アクセラレーターではなく物理アクセラレーターに基づいてカウントされるため、1 つの AI Accelerator サブスクリプションが必要になります。
アクセラレーターは、コンピュート・ワークロードの実行に使用される場合にのみカウントされます。ワークロードの主な目的が、ユーザーの画面上にほぼリアルタイムでアクティブにピクセルを描画したり、ネットワーク上でデータを移動したりすることではない場合、そのワークロードはコンピュート・ワークロードとみなされます。
この区別は重要です。VFX (視覚効果) およびストリーミング・アプリケーションでは GPU やその他のアクセラレーター・ハードウェアが使用される場合がありますが、これらの場合の主な目的は画面上にピクセルを描画することだからです。場合によっては、ネットワーク上でのデータの移動 (ネットワーク機能専用のデータ処理ユニットなど) が主な機能の場合がありますが、これもコンピュートとはみなされません。
コンピュート・ワークロードの例には以下が含まれます。
- Java、Python、Perl などの従来のソフトウェア・アプリケーション
- LLM またはその他の処理負荷の高いソフトウェア
- データサイエンスモデルのトレーニングとチューニング
- タンパク質フォールディングや流体力学などの科学モデリングと物理シミュレーション。
カウントしないもの
Red Hat OpenShift コントロールプレーンとインフラストラクチャ・ノード
セルフマネージド Red Hat OpenShift の各サブスクリプションには、Red Hat OpenShift および他の OpenShift 関連コンポーネントに対するエンタイトルメントが含まれます。OpenShift Kubernetes Engine、OpenShift Container Platform、および OpenShift Platform Plus には、コンピュートノードとインフラストラクチャ・ノード用の Red Hat Enterprise Linux エンタイトルメントが含まれています。Red Hat OpenShift Virtualization Engine は、標準の Red Hat Enterprise Linux ワーカーノードまたはインフラストラクチャ・ノードをサポートせず、OpenShift エンタイトルメントの一部である Red Hat Enterprise Linux CoreOS OS のみをサポートします。
これらのエンタイトルメントは、必要な OpenShift コントロールプレーンとインフラストラクチャを実行するために含まれていますが、必要な Red Hat サブスクリプションの数を決定する際にカウントする必要はありません。
Red Hat OpenShift Platform Plus サブスクリプションには、Red Hat Advanced Cluster Security for Kubernetes および Red Hat Advanced Cluster Management for Kubernetes によるすべてのノードの管理も含まれます。
デフォルトのインストーラーは、エンドユーザー・アプリケーションを実行するための 2 つ以上の OpenShift コンピュートノードに加えて、3 つのコントロールプレーン・ノードで構成される可用性の高い OpenShift コントロールプレーンをデプロイします。デフォルトでは、Kubernetes コントロールプレーン・コンポーネント (アプリケーション・プログラミング・インタフェース (API) サーバー、etcd、スケジューラーなど) とサポートするクラスタサービス (モニタリング、レジストリなど) が OpenShift コントロールプレーン・ノードにデプロイされます。ただしお客様によっては、これらのサポートするクラスタサービスの一部を専用の「インフラストラクチャ・ノード」に移行したい場合があります。
インフラストラクチャ・ノードの条件を満たし、含まれているエンタイトルメントを使用するためには、クラスタをサポートしており、エンドユーザー・アプリケーションの一部ではないコンポーネントのみをそれらのインスタンスで実行します。以下はその例です。
- OpenShift レジストリ
- OpenShift Ingress ルーター (ローカル、グローバルおよびマルチクラスタ Ingress)
- OpenShift Observability
- クラスタ Ingress に使用される HAProxy ベースのインスタンス
- Red Hat Quay
- Red Hat OpenShift Data Foundation
- Red Hat Advanced Cluster Management for Kubernetes
- Red Hat Advanced Cluster Security for Kubernetes
- Red Hat OpenShift GitOps
- Red Hat OpenShift Pipelines
- Red Hat OpenShift 向けのホスト型コントロールプレーン
モニタリング、ログデータの収集と転送、ハードウェアドライバー、インフラストラクチャ統合 (仮想化エージェントなど) のためのカスタムエージェントやサードパーティ・エージェントとツールを、インフラストラクチャ・ライセンスのノードとしての資格を失うことなくインフラストラクチャ・ノードにデプロイして実行することができます。ただし、これはエージェントと、Operator 用のコントローラー Pod などの関連コンポーネントのみに限定され、カスタムまたはサードパーティのソフトウェアスイートは含まれません。インフラストラクチャ・ワークロードに該当する Red Hat 以外のソフトウェアの例としては、次のようなものがあります。
- カスタムおよびサードパーティのモニタリングエージェント
- コンテナ・ネットワーク・インタフェース (CNI) およびコンテナ・ストレージ・インタフェース (CSI) のドライバーとコントローラー (プラグイン)
- ハードウェアまたは仮想化を有効にするためのアクセラレーター
- Kubernetes カスタムリソース定義 (CRD) または Operator に使用されるコントローラー Pod (カスタムまたはサードパーティ・ソフトウェア)
含まれているエンタイトルメントを使用する場合、インフラストラクチャ・ノード上で他のエンドユーザー・アプリケーションのインスタンスまたはタイプを実行することはできません。Red Hat OpenShift で他のインフラストラクチャ・ワークロードをアプリケーション・インスタンスとして実行するには、有効な Red Hat OpenShift サブスクリプションを使用してそれらのインスタンスを通常のアプリケーション・ノードで実行する必要があります。アプリケーションまたはサービスがインフラストラクチャ・ワークロードに該当するかどうかは、Red Hat に確認できます。
Red Hat Enterprise Linux エンタイトルメント
OpenShift Kubernetes Engine、OpenShift Container Platform、OpenShift Platform Plus には、コンピュートノードとインフラストラクチャ・ノード用の Red Hat Enterprise Linux エンタイトルメントが含まれています。これには、アプリケーション向け Pod のエンタイトルメントと、VM 向けのゲスト OS のエンタイトルメントも含まれます。ただし OpenShift サブスクリプションには、以下の例外を除き、Red Hat Enterprise Linux ノードの他のエンタイトルメントは含まれません。
- ベアメタルのインストーラー・プロビジョニング・インフラストラクチャ (IPI) のプロビジョニング専用の Red Hat Enterprise Linux ノード
OpenShift Virtualization Engine には、コンピュートノードやインフラストラクチャ・ノードにも、VM のゲスト OS エンタイトルメントにも、Red Hat Enterprise Linux は含まれていません。OpenShift Virtualization Engine 上の Red Hat Enterprise Linux ゲストには、Red Hat Enterprise Linux for Virtual Datacenters サブスクリプションまたは VM ごとのサブスクリプションが必要です。
Red Hat Enterprise Linux エンタイトルメントは、インターネットプロキシ、ロードバランサー、ミラーレジストリなど、OpenShift が依存するサービスをホストする外部ノードには含まれません。Red Hat Satellite はエンタイトルメントの一部として含まれていません。
コンテナレジストリのブートストラップによる OpenShift コンテナイメージのミラーリング
OpenShift のミラーレジストリは、切断された OpenShift クラスタのブートストラップに必要なコンテンツをミラーリングするプロセスを容易にすることを唯一の目的とした Quay エンタイトルメントであり、Red Hat OpenShift サブスクリプションの一部として含まれています。これは、特定のインストーラーによって作成される最小限の Quay デプロイメントに対する限定的なサポートのエンタイトルメントであり、お客様が管理する事前プロビジョニング済みの Red Hat Enterprise Linux ホストで Quay レジストリを実行できます。
注：OpenShift リリースペイロード、OperatorHub コンテンツ、Operator のサンプルイメージ、Cincinnati グラフイメージ、および Red Hat OpenStack Services on OpenShift や Red Hat OpenShift Data Foundation を含む Red Hat OpenStack Platform オファリングに関連するイメージをミラーリングする目的に限定されたレジストリミラーとして、Quay を使用することが許可されています。
OpenShift のミラーレジストリは、任意の規模で機能する汎用レジストリを意図したものではありません。 しかし、一定限度のカスタムイメージのセットを保存することが許可されており、それには必須の補助ソフトウェア (たとえば、適格なインフラストラクチャ・ワークロードのエージェントやコンテナイメージなど) が含まれます。これらの例として、次のようなものがあります。
- 監視エージェント
- CNI および CSI プロバイダー
- ハードウェアまたは仮想化を有効にするためのエージェント
- 独立系ソフトウェアベンダー (ISV) サービスをサポートする Operator
- デプロイメント・コントローラーとしてのカスタム Operator
ホスト型コントロールプレーン
従来の OpenShift インフラストラクチャでは、OpenShift クラスタごとに少なくとも 3 つのコントロールプレーン・ノードが必要です。代替手段は、ホスト型コントロールプレーンを使用することです。この場合、コントロールプレーンは中央のコントロールプレーン・クラスタ上で実行され、OpenShift クラスタの論理コントロールプレーンを提供します。ここでも、コントロールプレーン・ノードとインフラストラクチャ・ノードはサブスクリプションにはカウントされませんが、アーキテクチャでは考慮する必要があります。
ホスト型コントロールプレーンは、任意のベアメタル OpenShift クラスタ上で実行できますが、これらのクラスタのコンピュートノードには、実行されているインフラストラクチャに応じたエンタイトルメントが必要です。たとえば、OpenShift Virtualization Engine でホストされる仮想クラスタにはコンピュートノードのコアペア・サブスクリプションが必要ですが、コントロールプレーンが OpenShift Virtualization Engine クラスタによってホストされベアメタル・コンピュートノードを使用するクラスタには、ベアメタル・ソケットペア・サブスクリプションが必要になります。
例外 1：コントロールプレーンまたはインフラストラクチャ・ノードでアプリケーション・インスタンスを実行することを選択した場合
OpenShift Kubernetes コントロールプレーン・ノードはデフォルトではワーカーノードとして使用されず、したがってアプリケーション・インスタンスを実行しません。コントロールプレーン・ノードが完全な Red Hat OpenShift サブスクリプションを必要とするかどうかは、OpenShift クラスタ・コンポーネントのみをサポートして実行するか、エンドユーザー・アプリケーションを実行するかによって異なります。エンドユーザー・アプリケーションをホストするノードとしてコントロールプレーン・ノードを使用することを選択した場合、すべてのコアにサブスクリプションが必要になります。サブスクリプションを必要としない適格なワークロードを特定するには、インフラストラクチャ・ノードのセクションを参照してください。
例外 2：コンパクトなクラスタデプロイメント
3 ノードの OpenShift のようなコンパクトなクラスタデプロイメントでは、エンドユーザー・アプリケーションのワークロードはコントロールプレーン・ノードで実行されます。Red Hat OpenShift サブスクリプションの場合、果たす役割に関係なく、3 つのノード上のコア数をカウントする必要があります。
シングルノードの OpenShift インスタンスは、すべての OpenShift サービスとエンドユーザー・アプリケーションを単一の物理ノードまたは仮想ノードにデプロイし、最適化によってフットプリントを削減し、アプリケーションで利用できるリソースを最大化します。上述のコンパクトな 3 ノードクラスタと同様、このデプロイメントモデルには特別な対応はなく、ノード上のすべてのコアにエンタイトルメントを付与する必要があります。
特殊なユースケース
障害復旧
Red Hat は、ホット、ウォーム、コールドの 3 種類の障害復旧 (DR) 環境を定義しています。有料の Red Hat OpenShift サブスクリプションが必要なのは、ホットの DR のみです。
- ホット DR システムは、完全に機能し、プロダクションシステムと同時に実行されるシステムとして定義されます。これらは、プライマリー環境内で災害が発生した場合に、直ちにトラフィックを受信して引き継ぐ準備ができています。データボリュームがクラスタ間で同期または非同期でアクティブにレプリケートされている場合、それらは「ホット」DR システムとみなされます。
- ウォーム DR システムは、プライマリーサイトで見つかったワークロードの合理的な複製を表すコンテナ化されたワークロードをデプロイおよびホストする準備がすでに整っているものとして定義されますが、ソースクラスタからのお客様のワークロードは含まれていません。ウォーム DR システムは、同期でも非同期でも、クラスタ間でのアクティブなデータボリューム・レプリケーションに参加させることはできません。ウォーム DR リカバリーでは、お客様のデータをクラスタの外部から既存のクラスタハードウェアに復元する必要があります。
- コールド DR システムでは、インフラストラクチャは整っていますが、サービスの復元に必要なテクノロジー (ハードウェア、ソフトウェア、データ) が揃っていません。
ウォームまたはコールド DR 用に明示的に構成および設計されていない休止状態のクラスタ (クラウドサービスで実行されており、需要が低いために一時的に休止状態になっているクラスタなど) には、サブスクリプションが必要です。ワークロードを実行するためにクラスタを休止状態から復帰させる場合は、サブスクリプションが必要です。定期的なメンテナンスやテストのためにクラスタを一時的に休止状態から復帰させる場合は、OpenShift ソフトウェア製品のいずれのコンポーネントについても追加のサブスクリプションは必要ありません。
ウォームの場合もコールドの場合も、障害の発生時には Red Hat OpenShift サブスクリプションをプライマリー環境から DR 環境に移してサービスを復元できます。また、Red Hat のサブスクリプション条件への準拠も維持されます。
移行とスイングアップグレード
Red Hat OpenShift 4 では、マイナーバージョン間のインプレース・アップグレードを行えます。ただし、Red Hat OpenShift 3 からアップグレードする場合、またはメンテナンスウィンドウなどの考慮事項のために Red Hat OpenShift 4 マイナーバージョン間でのスイングアップグレードを実行する必要がある場合、Red Hat OpenShift サブスクリプションは、一方向移行の元のインフラストラクチャと宛先インフラストラクチャの両方を、その移行が完了するまでカバーします。移行中、Red Hat のサブスクリプション管理ツールは、お客様が購入した OpenShift サブスクリプションの数に基づいて、お客様の環境は非準拠であると表示します。Red Hat では、メジャーバージョンのアップグレードについてはこれを許可しており、移行中にコンプライアンス準拠の状態に戻すために追加のサブスクリプションを購入する必要はありません。そして、Red Hat OpenShift はこれらの移行を支援するツールを提供します。また、必要に応じて Red Hat コンサルティングサービスもご利用いただけます。コンテナ移行ツールキットに関するドキュメントを参照してください。
ハイパースレッディング対応のコアのエンタイトルメント
特定の OpenShift ノードが 1 つ以上の物理コアを使用するかどうかは、システムでコアごとに複数のスレッドが有効になっているかどうかによって決まります。特定のシステムがハイパースレッディングをサポートしているかどうかを判断する方法については、こちらでご確認ください。
論理 CPU スレッドを使用する仮想化 OpenShift ノード (AMD EPYC CPU では同時マルチスレッド (SMT)、Intel CPU ではハイパースレッディングとも呼ばれます) は、ノードに割り当てられたコア/CPU の数に基づいて Red Hat OpenShift サブスクリプションのコア使用率を計算します。ただし、論理 CPU スレッドが使用される場合、各サブスクリプションは 4 vCPU/コアをカバーします。Red Hat のサブスクリプション管理ツールは、すべてのシステムで論理 CPU スレッドがデフォルトで有効になっていると想定しています。
ベアメタル・サブスクリプションでは物理コアのみがカウントされます。ベアメタルに必要なサブスクリプションの数を計算する際に論理 CPU スレッドはカウントされません。
上記以外のアーキテクチャ (ARM、IBM Z、IBM LinuxONE、IBM Power)
注：このドキュメントでは以降、IBM Z についてのみ言及しますが、IBM Z について言及するすべての情報は IBM LinuxONE にも適用されます。
クラウドネイティブ・アプリケーションおよびマイクロサービスの構築とデプロイの標準として ARM、IBM Z および IBM Power を使用している場合、Red Hat OpenShift Container Platform はこれらのプラットフォームで実行することもできます。IBM Z および IBM Power プラットフォームでは、コアベースのサブスクリプションモデルのみがサポートされます。
ARM クラスタには、x86 と同じルールを使用してエンタイトルメントが付与されます。
IBM Z を利用している場合、Red Hat OpenShift では物理ノード全体にエンタイトルメントを付与する必要はなく、OpenShift によって使用されるコアのみが必要になります。IBM Z では、これを「サブキャパシティ」エンタイトルメントと呼んでいます。OpenShift Container Platform 向けの IBM Z 環境で使用可能なコア (コンピュートキャパシティ) のサブセットのみを使用している場合に必要なのは、コンピュートノードに使用されるサブセットのサブスクリプションのみです。これは、CPU プーリング、キャッピング、別個の論理パーティション (LPAR) などの手段によって、CPU パーティションの作成方法に関係なく適用されます。
IBM Z の場合、1 つの Integrated Facility for Linux (IFL) には、OpenShift のコアペアベースのサブスクリプションが 1 つ必要です。パーティショニングが使用されていない場合は、ホスト上で実行されているコントロールプレーンまたはインフラストラクチャ・サービスの OpenShift クラスタごとに、クラスタあたり最大 3 つの IFL を識別できます。これらは、対象となるためにコントロールプレーンやインフラサービスで積極的に使用されている必要があり、OpenShift のエンタイトルメントは必要ありません。3 ノードのコンパクトなクラスタデプロイメントでは、すべての IFL にエンタイトルメントが付与されている必要があります。
OpenShift Container Platform 以外の Red Hat OpenShift Platform Plus コンポーネントは、以下の例外を除いて、現時点では IBM Z および IBM Power ではサポートされていません。
- x86 アーキテクチャで動作する Red Hat Quay のスタンドアローン・サブスクリプションは、IBM Z および IBM Power クラスタを含む複数のアーキテクチャのグローバルレジストリを提供します。Red Hat Quay 自体は IBM Z または IBM Power では動作しません。
- Red Hat Advanced Cluster Management for Kubernetes は、IBM Z または IBM Power 環境にインストール可能であり、IBM Z または IBM Power 環境で稼働する Red Hat OpenShift ノードを管理できます。
- Red Hat Advanced Cluster Security for Kubernetes では、Red Hat Advanced Cluster Security Operator を使用して、IBM Z または IBM Power 上の Red Hat OpenShift で実行されているクラスタを保護できます。
- Red Hat OpenShift Data Foundation は、IBM Z または IBM Power でのインストールを完全にサポートします。
Red Hat OpenShift Platform Plus サブスクリプションのコンポーネントには、その他 (非 x86) のアーキテクチャに対するさまざまなレベルのサポートがあります。Red Hat OpenShift Container Platform 4.16 マルチアーキテクチャ・コンポーネントの可用性マトリックスの記事をご覧ください。OpenShift Platform Plus コンポーネントと非 x86 アーキテクチャ間の相互運用性の詳細については、Red Hat OpenShift Container Platform、Red Hat Advanced Cluster Management、Red Hat Advanced Cluster Security、Red Hat Quay、Red Hat OpenShift Data Foundation の互換性マトリックスを参照してください。
Red Hat OpenShift Kubernetes Engine および Red Hat OpenShift Virtualization Engine は、IBM Z および IBM Power ではサポートされていません。
Microsoft Windows Server コンテナのサポート
セルフマネージド OpenShift は、Microsoft Windows Server コンテナを使用したインストール・インフラストラクチャと OpenShift 機能のサブセットをサポートします。Windows Server コンテナは、Microsoft Windows Server ベースのコンピュートノードでのみサポートされます。OpenShift 環境のコントロールプレーンとインフラストラクチャ・プレーンは、Red Hat Enterprise Linux または Red Hat Enterprise Linux CoreOS を使用して x86 インフラストラクチャで実行されている必要があります。このため、Windows Server コンテナのサポートは、コアごとに価格設定されるスタンドアロンのサブスクリプションとして販売されます。
Red Hat OpenShift Platform Plus および Red Hat OpenShift Container Platform インフラストラクチャを使用して、Windows Server コンピュートノードをデプロイおよび管理できます。Red Hat OpenShift サブスクリプションに対する Microsoft Windows Server コンテナのサポートは、別個のアドオンとして購入する必要があります。
Red Hat Advanced Cluster Management および Red Hat Advanced Cluster Security は Microsoft Windows ノードの管理をサポートしていませんが、x86 アーキテクチャで実行されている Red Hat Quay は Microsoft Windows Server ベースのワークロードのコンテナイメージを管理できます。
状況はそれぞれ異なるため、これらは単なるガイドラインであり、保証するものではありません。
Red Hat OpenShift は、スケーラビリティ、Pod のスケジューリング、アイドリング、リソースクォータや制限などに影響を与えるさまざまな機能をサポートしています。上記の計算は目安であり、実際の環境に合わせて調整することで、リソース使用率の改善や、全体の環境サイズの縮小を実現できる場合があります。OpenShift Platform Plus を使用する場合、追加のコンピュート・サブスクリプションが必要なくても、ストレージやコンピュートリソースなどの追加のソフトウェア・アプリケーション (Red Hat Advanced Cluster Management、Red Hat Advanced Cluster Security、および Quay) の必要性を考慮するべきです。
サードパーティのリセラーと連携する場合は、そのリセラーが Red Hat 製品およびサービスに関して定めている条件と契約を参照してください。
Red Hat OpenShift Platform Plus コンポーネントのサポート
Red Hat OpenShift Platform Plus には、OpenShift Container Platform 以外に追加のソフトウェアが含まれており、複数のクラスタや複数のクラウドにまたがる大規模な Red Hat OpenShift 環境を管理および保護するのに役立ちます。Red Hat OpenShift Platform Plus は、コアペア・サブスクリプションモデルでも、ベアメタル・ソケットペア・サブスクリプションモデルでも利用できますが、上記の制限があります。
Red Hat OpenShift Platform Plus に付帯するソフトウェアは、通常、OpenShift Platform Plus サブスクリプションでエンタイトルメントを付与されたノードを管理するためのものに限定されています。たとえば、OpenShift Platform Plus に付帯する Red Hat Advanced Cluster Management のサブスクリプションは、OpenShift Platform Plus のエンタイトルメントを付与されたノードおよびクラスタの管理にのみ使用できます。OpenShift Platform Plus のエンタイトルメントを付与されていないノードやクラスタ (AWS クラスタ上の Red Hat OpenShift Services など) も管理したい場合は、それらのクラスタをカバーするために、Red Hat Advanced Cluster Management アドオン・サブスクリプションを追加で購入する必要があります。
また、OpenShift Platform Plus サブスクリプションには追加のソフトウェア・サブスクリプションが必要です。たとえば、100 個の OpenShift Platform Plus サブスクリプションを購入したお客様が、200 コアの Red Hat OpenShift Container Platform サブスクリプションをインストールしたり、Red Hat Advanced Cluster Management を別途使用して、200 コアの Azure Red Hat OpenShift を管理したりすることはできません。追加のソフトウェアは、OpenShift Platform Plus ソフトウェアがインストールされているところで、その 200 コアを管理するためにのみ使用できます。
階層化された各製品に関するルールは次のとおりです。
- Red Hat Advanced Cluster Management for Kubernetes：OpenShift Platform Plus サブスクリプションを使用すると、環境の管理に必要な数の Red Hat Advanced Cluster Management の中央インスタンスをインストールでき、コントロールプレーンやインフラストラクチャ・ノードを含め、OpenShift Platform Plus でエンタイトルメントを付与されたすべてのノードおよびクラスタの管理をカバーできます。OpenShift Platform Plus のエンタイトルメントなしでノードおよびクラスタを管理したい場合 (たとえば、セルフマネージド OpenShift Container Platform または Red Hat OpenShift Kubernetes Engine のエンタイトルメントを付与されたクラスタ、フルマネージド OpenShift クラウドで実行されているクラスタ、あるいは Red Hat Advanced Cluster Management でサポートされているサードパーティの Kubernetes 環境も使用している場合) は、これらの環境をカバーするために Red Hat Advanced Cluster Management アドオン・サブスクリプションを購入する必要があります。OpenShift Platform Plus にインストールされている Red Hat Advanced Cluster Management コンソールから、または要件を満たす場合は別個の中央アプリケーションから、それらを一元的に管理することもできます。Red Hat Advanced Cluster Management のサブスクリプション、Red Hat Advanced Cluster Management がサポートする環境、Red Hat Advanced Cluster Management のベストプラクティスについて詳細をご覧ください。
- Red Hat Advanced Cluster Security for Kubernetes：OpenShift Platform Plus サブスクリプションを使用すると、環境の管理に必要な数の Red Hat Advanced Cluster Security の中央インスタンスをインストールでき、コントロールプレーンやインフラストラクチャ・ノードを含め、OpenShift Platform Plus でエンタイトルメントを付与されたすべてのノードおよびクラスタの管理をカバーできます。OpenShift Platform Plus のエンタイトルメントなしでノードおよびクラスタを管理したい場合 (たとえば、セルフマネージド OpenShift Container Platform または OpenShift Kubernetes Engine のエンタイトルメントを付与されたクラスタ、フルマネージド Red Hat OpenShift クラウドで実行されているクラスタ、あるいは Red Hat Advanced Cluster Security でサポートされているサードパーティの Kubernetes 環境も使用している場合) は、これらの環境をカバーするために Red Hat Advanced Cluster Security アドオン・サブスクリプションを購入する必要があります。Red Hat では、Red Hat Advanced Cluster Security の中央アプリケーションを別途使用して各環境を管理することをおすすめしています。Red Hat Advanced Cluster Security がサポートする環境について、詳細をご覧ください。
- Red Hat Quay：OpenShift Platform Plus サブスクリプションを使用すると、OpenShift Platform Plus エンタイトルメントを持つ任意のクラスタに Red Hat Quay をインストールできます。OpenShift Platform Plus クラスタにインストールできる Quay デプロイメントの数に制限はありません。Quay は、OpenShift Platform Plus 環境、他のセルフマネージド OpenShift クラスタ、OpenShift マネージドサービス、サポートされているサードパーティの Kubernetes など、サポートされている任意の Kubernetes 環境にサービスを提供できます。OpenShift Platform Plus 以外の環境に Quay をインストールしたい場合は、Red Hat Quay サブスクリプションを別途購入する必要があります。Quay は、フルマネージド SaaS (Software-as-a-Service) 製品としても利用できます。
- Red Hat OpenShift Data Foundation：OpenShift Platform Plus サブスクリプションを使用すると、OpenShift Platform Plus エンタイトルメントを持つ任意のクラスタに Red Hat OpenShift Data Foundation Essentials をインストールできます。Red Hat Data Foundation エンタイトルメントは Essentials で利用可能な機能に制限されており、データストレージは OpenShift クラスタ 1 つにつき 256 TB が上限となります。追加のサブスクリプションによって機能と容量を拡張することができます。詳細は、OpenShift Data Foundation サブスクリプションガイド (カスタマーポータルへのログインが必要) を参照するか、Red Hat の営業担当者にご相談ください。
Red Hat OpenShift Virtualization Engine および関連製品
OpenShift Virtualization は長年にわたってすべてのセルフマネージド OpenShift エディションに組み込まれている機能であり、お客様は VM ワークロードをクラウドネイティブ・アプリケーションに組み込み、VM をマイクロサービスやコンテナにモダナイズできます。
仮想化市場における最近の変化により、代替の仮想化プラットフォーム、特にモダナイゼーションへのパスを提供する仮想化プラットフォームに対する需要が高まっています。これらのお客様の多くは、VM の初期移行に OpenShift のすべての機能を必要とするわけではなく、そのようなユースケースには、より低コストの単純化されたセルフマネージド OpenShift のエディションを好みます。
Red Hat OpenShift Virtualization Engine は、VM を実行するための代替の仮想化プラットフォームを必要とするお客様を特に対象としたセルフマネージド OpenShift エディションです。OpenShift Virtualization Engine は、サポートされている物理サーバーおよびサポートされているハイパースケーラー・ベアメタル・インスタンスのベアメタル・ソケットペア・サブスクリプションによってエンタイトルメントが付与されます。
OpenShift Virtualization Engine には、仮想マシンのデプロイ、管理、実行に必要な次のような機能のみが含まれています。
- サブスクライブされたホスト上の無制限の VM。
- コンテナ内でアプリケーション・インスタンス (商用ソフトウェアや顧客アプリケーションなど) を実行するためには使用できません。VM のみに使用できます。
- VM 内で Red Hat OpenShift エディションを実行するためのサブスクリプションは含まれません (コアペアのサブスクリプションを別途購入する必要があります)。
- VM の Red Hat Enterprise Linux のゲスト・エンタイトルメントは含まれていません (Red Hat Enterprise Linux for Virtual Datacenter または VM ごとのサブスクリプションを別途購入する必要があります)。
現在、Red Hat には OpenShift Virtualization Engine 用の 2 つのアドオン製品があります。
- Red Hat Advanced Cluster Management for Virtualization は、Advanced Cluster Management のフルバージョン (OpenShift Virtualization Engine サブスクリプションごとに 1 サブスクリプション) と比較して、低コストで仮想化とハイパーバイザーのライフサイクル管理および運用をサポートします。
- Red Hat Ansible® Application Platform for Virtualization は、移行および Day 1 オペレーションを目的として、OpenShift Virtualization Engine を実行するハイパーバイザーノードのサポートを提供します (OpenShift Virtualization Engine サブスクリプションごとに 1 つのサブスクリプション)。
Advanced Cluster Management および Ansible Application Platform の既存のお客様の場合は、これらの中央アプリケーションの既存のインストールを使用して、環境の残りの部分をサポートし、前述のアドオン・サブスクリプションを購入して OpenShift Virtualization Engine ホストを管理できます。
既存の Advanced Cluster Management または Ansible Application Platform の中央アプリケーションをインストールしていないお客様の場合、前述のアドオンのサブスクリプションには、OpenShift Virtualization Engine ホスト上のインフラストラクチャ・コンテナとして中央アプリケーションをインストールするためのサポートも含まれています。これらの中央アプリケーションのインストールとアーキテクチャのベストプラクティスについては、Advanced Cluster Management または Ansible Application Platform のドキュメントを参照してください。
VM の Day 2 自動化が必要なお客様には、Ansible Automation Platform をお勧めします。上記のハイパーバイザー・ノード・サブスクリプションに加えて、お客様は VM インスタンスごとにノードサブスクリプションが必要になります。詳細については、Ansible Automation Platform ドキュメントを参照してください。
OpenShift Virtualization Engine のエンタイトルメントでは、お客様のアプリケーション・インスタンスが VM のみに制限されていますが、ストレージドライバー、バックアップ・アプリケーション、転送エージェント、Advanced Cluster Management、Ansible Automation Platform などのインフラストラクチャ要件の多くは、Red Hat OpenShift のインフラストラクチャ・コンテナとして実行されます。したがって、エンタイトルメントにより、これらのインフラストラクチャ機能をコンテナで実行することができます。さらに、VM にストレージを提供し、それらの VM 自体はコンテナ内で実行されるソフトウェア・デファインド・ストレージ・ソリューションもエンタイトルメントに含まれます。これらのインフラストラクチャ・コンテナに該当するものに関するガイダンスは、Red Hat OpenShift の他のエディションのインフラストラクチャ・ノードで許可されるワークロードと同じです。「カウントしないもの」セクションのインフラストラクチャ・ノードに関する情報を参照してください。アプリケーションまたはサービスが OpenShift Virtualization Engine のインフラストラクチャ・ワークロードに該当するかどうかについては、Red Hat の担当者に確認してください。
セルフマネージド OpenShift 環境のサイジングへのアプローチ方法
セルフマネージド OpenShift (Red Hat OpenShift Platform Plus、Red Hat OpenShift Container Platform、または Red Hat OpenShift Kubernetes Engine) またはアドオンのサブスクリプションがいくつ必要であるかを決定するには、以下の質問と例を使用してください。
まとめ：
- アプリケーションはコンテナイメージまたは VM にパッケージ化されています。
- コンテナおよび VM は Pod としてデプロイされます。
- Pod は OpenShift コンピュートノード上で実行され、OpenShift コントロールプレーン・ノードによって管理されます。
必要なエンタイトルメントの見積もり方法
Red Hat OpenShift サブスクリプションにアプリケーション・インスタンス数の制限はありません。Red Hat OpenShift 環境では、基礎となるハードウェアとインフラストラクチャがサポートできる限りの数のアプリケーション・インスタンスを実行できます。大容量ハードウェアは少数のホスト上で多くのアプリケーション・インスタンスを実行できますが、小容量ハードウェアで多数のアプリケーション・インスタンスを実行するには多くのホストが必要となります。Red Hat OpenShift 環境のサイズを決定する主な要因は、任意の時点で実行される Pod またはアプリケーション・インスタンスの数です。
ステップ 1：必要なアプリケーション・インスタンスの数とタイプを特定する
アプリケーションから始めましょう。デプロイする予定のアプリケーション・インスタンス (Pod) の数を決定します。環境のサイジングの際、Red Hat OpenShift にデプロイされたアプリケーション・コンポーネントは、すべてアプリケーション・インスタンスとみなされます。これには、データベース、フロントエンドの静的サーバー、VM インスタンスなどが含まれます。
この数値はおおよその推定値でよく、Red Hat OpenShift 環境サイズの総見積もりを計算するために役立ちます。CPU、メモリー・オーバーサブスクリプション、クォータとリミット、およびその他の機能を使用して、この見積もりをさらに絞り込むことができます。
表 1：アプリケーションおよびインスタンスのサイジングに関する質問
関連する質問 | 回答例 |
|
|
ステップ 2：必要な合計メモリーと合計コア数を決定する
1 つのアプリケーション・インスタンスの要件とアプリケーション・インスタンス数を決定したら、必要なリソース (コンピュートとメモリーの両方) の合計量は簡単に決定できます。
この時点で、コンピュートノードが満たすべき最大使用率を決定する必要があります。これにより、OpenShift の管理オーバーヘッドに対応する余地が確保され (詳細についてはドキュメントを参照してください。ただし、通常はコンピュートノードごとに 1 コアまたは 1 vCPU と<1 GB の読み取りアクセスメモリー (RAM) が必要です)、自動スケーリングが必要になる前にアプリケーションの通常の変動を許容できるようになります。かなり高めの使用率 (80% を超える) を想定する場合は、メモリーとコアリソースの計算において OpenShift のオーバーヘッド要件を明示的に考慮することが必要になる可能性があります。
仮想化のユースケースでは、CPU とメモリーのオーバーコミット、冗長性と高可用性に関する懸念、環境全体のアーキテクチャを考慮する必要があります。サイジングの例 3 で詳しく説明します。
表 2：推奨される最大 OpenShift ノード使用率に関する質問
関連する質問 | 回答例 |
需要増加に備えてどの程度のスペースを確保しておきたいですか？ | 総容量の最大平均 80% (20% を予備として残す) でノードを稼働させたいと考えています。 |
最大使用率 = アーキテクトが選択した割合
必要なコア数 (または vCPU) の合計 = 「1 つのアプリケーションのコア数」×「アプリケーション・インスタンスの数」× 1/「使用率」
必要なメモリーの合計 = 「1 つのアプリケーションのメモリー」×「アプリケーション・インスタンスの数」× 1/「使用率」
ステップ 3：標準のコンピュートノード (VM、クラウドインスタンス、またはベアメタルサーバー) を選択する
これで、対応する合計コア数と合計メモリーがわかりました。ここで、アプリケーションのワーカーノードをデプロイする標準のコンピュートノードを選択する必要があります。
仮想化インフラストラクチャでは、環境によってはコンピュートノードとして機能する VM の構成を選択できる場合があります。また、いくつかの標準的な「T シャツサイズ」の VM タイプから 1 つを選択することが必要な場合もあります。
ハイパースケーラー・クラウドでは、通常、さまざまなコンピュートやメモリー、およびオプション機器 (AI アクセラレーターなど) へのアクセスを備えたクラウドインスタンス・タイプを選択する必要があります。
オンプレミスまたはハイパースケーラー・ベアメタル・インスタンスのいずれかでベアメタルにデプロイしている場合は、標準のサーバー構成が存在する可能性があり、構成を指定できる場合もあります。
可能であれば、比率、コア要件、メモリー要件に最も一致するコンピュートノードを選択しましょう。たとえば、コンテナの合計要件が 400 vCPU と 1,600 GB の RAM である場合、vCPU とメモリーの比率が約 1:4 であるコンピュートノードを選択することで、最適な平均統合率が得られます。
表 3：VM およびハードウェアのサイジングに関する質問
関連する質問 | 回答例 |
|
|
ステップ 4：必要なサブスクリプションの合計を計算する
最後に、ステップ 1 - 3 で収集したデータに基づき、必要な Red Hat OpenShift サブスクリプションの数を特定します。VM またはハイパースケーラー・クラウドインスタンスのサブスクリプションの場合は、コアペア・サブスクリプションモデルを使用する必要があります。ベアメタルサーバーの場合は、両方のモデルを使用してサブスクリプションを計算し、各モデルのコストと柔軟性の違いを比較し、ニーズに最も適したものを選択する必要があります。
コアペア・サブスクリプションモデルの場合
- セルフマネージド OpenShift コアペア・サブスクリプションの数
= 合計コア数/2 (切り上げ)、または
= 合計 vCPU 数/4 (切り上げ)
ベアメタル・ソケットペア・サブスクリプションモデルの場合
- まず、ベアメタルインストールではコアペアモデルを使用できるため、アプリケーションに必要なコアペア・サブスクリプションの数を計算します。
- 次に、ベアメタルコアペアのサブスクリプションの数を計算します。これは次のように計算します。
- ベアメタルサーバーの数 =
次のうち大きい方：- 必要なコア数の合計/ベアメタルサーバー・モデルごとのコア数 (整数に切り上げ)、
または - 必要なメモリーの合計/ベアメタルサーバー・モデルごとのメモリー (整数に切り上げ)
- 必要なコア数の合計/ベアメタルサーバー・モデルごとのコア数 (整数に切り上げ)、
- ベアメタルサーバーごとに必要なベアメタルコアペアのサブスクリプションの数 =
ベアメタルサーバーが 1 - 2 ソケットの場合： - ベアメタルサーバー・モデルあたりのコア数/128 コアまたは 256 vCPU (整数に切り上げ)
ベアメタルサーバーが>2 ソケットの場合：- ベアメタルサーバー・モデルあたりのコア数/(128 × ソケットペア数) (整数に切り上げ)
- ソケットペアごとに少なくとも 1 つのサブスクリプションが必要であり、合計ソケット数と合計コア数を満たすようにサブスクリプションをスタックできます。
- サブスクリプションはソケットにまたがることはできますが、追加のサーバーにまたがることはできません。
- ベアメタルサーバーの数 =
- 3 番目に、2 つのモデルのコストと柔軟性の違いを比較します。
- コスト面：
- 環境の規模によっては、1 つのサブスクリプションモデルが他のサブスクリプションモデルよりも安価になる可能性があります。
- 将来の計画を立てる際には、どちらが安価になるかの分岐点となる容量があることを知っておく必要があります。それを超えるとコスト面でもう一方のモデルの方がより良い選択となる場合があります。
- アーキテクチャ面：
- コアペア・サブスクリプションは環境 (VM、クラウドインスタンス、ベアメタルサーバー) 内のどこでも使用できますが、ベアメタルソケットペアはベアメタルサーバーでのみ使用できます。
- ベアメタルサーバー上のコアペア・サブスクリプションは、ベアメタル上でコンテナを実行し、同じ単一クラスタ内に存在する必要があります。
- OpenShift Virtualization Engine をベアメタルサーバーにインストールしてから、コンテナ向けに OpenShift コアペア・サブスクリプションをスタックする (OpenShift-on-OpenShift) ことを選択できます。これは、サーバーあたりの OpenShift の量が比較的少ない混合 VM 環境に最適です。
- ベアメタルサーバー上で高密度の OpenShift ワークロードが必要な場合、ベアメタル・ソケットペア・サブスクリプションを選択すると、ベアメタル上で直接、または OpenShift 仮想化機能を使用してサーバー上で実行されている VM 内で、OpenShift コンテナを無制限に利用できます。
- コスト面：
ステップ 5：AI Accelerator サブスクリプションの合計を計算する (該当する場合)
上記の AI Accelerator サブスクリプションをすべて追加します。オンプレミスまたはベアメタルサーバー上の物理アクセラレーターごとに 1 つの AI Accelerator サブスクリプションが必要です。ハイパースケーラー・クラウド環境では、高速化されたコンピュートのインスタンスタイプに、そのインスタンスタイプに含まれる物理 GPU またはアクセラレーターの数がリストされます。AI Accelerator サブスクリプションの SLA を、対応する Red Hat OpenShift サブスクリプションと必ず一致させてください。
注：Red Hat OpenShift は、スケーラビリティ、Pod のスケジューリング、アイドリング、リソースクォータや制限などに影響を与えるさまざまな機能をサポートしています。上記の計算は目安であり、実際の環境に合わせて調整することで、リソース使用率の改善や、全体の環境サイズの縮小を実現できる場合があります。OpenShift Platform Plus を使用する場合、追加のコンピュート・サブスクリプションが必要なくても、ストレージやコンピュートリソースなどの追加のソフトウェア・アプリケーション (Red Hat Advanced Cluster Management、Red Hat Advanced Cluster Security、および Quay) の必要性を考慮するべきです。
サードパーティのリセラーと連携する場合は、そのリセラーが Red Hat 製品およびサービスに関して定めている条件と契約を参照してください。
例 1：ハイパースケーラー・クラウドで実行されるコンテナ化されたアプリケーション
200 個のコンテナインスタンスで構成されるアプリケーションがあり、それぞれが平均 1 vCPU と 4 GB の RAM を消費します。推奨される最大使用率は 80% です。AWS でアプリケーションを実行しており、EC2 M6i インスタンスタイプにアクセスできます。アプリケーションは、特定のハードウェアや AI アクセラレーターを必要としません。セルフマネージド・エディションとして Red Hat OpenShift Platform Plus を選択しましたが、現時点では必要なサブスクリプション数の見積もりだけが必要です。
ステップ 1：必要なアプリケーション・インスタンスの数とタイプを特定する
この例の情報から算出：
- アプリケーション・インスタンス数 = 200
- 推奨される最大ノード使用率 = 80%
- 平均アプリケーション vCPU 要件 = 1 vCPU
- アプリケーション・メモリー・フットプリント平均 = 4 GB
ステップ 2：必要な合計メモリーと合計コア数を決定する
ステップ 1 の数値を計算に使用：
- 最大使用率 = 80%
- 必要な vCPU の合計 = 1 vCPU × 200 × 1/80% = 250 vCPU
- 必要な合計メモリー = 4 GB × 200 × 1/80% = 1,000 GB
ステップ 3：標準のコンピュートノードを選択する
上記の情報によると、GPU や特殊なハードウェアを備えたインスタンスタイプは必要ありません。vCPU とメモリーの比率は 250 vCPU:1,000 GB、つまり 1:4 です。幸いなことに、この比率のインスタンスタイプはたくさんあります。アプリケーションに必要な他の要素を分析した結果、them6i.4xlarge インスタンスタイプがニーズに最も適していると判断しました。各インスタンスには 16 個の vCPU と 64 GB のメモリーがあります。
ステップ 4：必要なサブスクリプションの合計を計算する
この場合、ハイパースケーラー・クラウドで実行されており、ハイパースケーラー・クラウドは vCPU を使用していることからコアペア・サブスクリプションが必要であることがわかっているため、ステップ 2 でコアペア・サブスクリプションの式を使用します。
コアペア・サブスクリプションの合計 = 必要な vCPU の合計/4 (切り上げ)
250 vCPU/4 = 62.5 (切り上げて 63)
ステップ 5：AI Accelerator サブスクリプションの合計を計算する (該当する場合)
このサイジングの例では、AI アクセラレーターを使用していないため、これは適用されません。
結果
この例 1 では、63 の OpenShift Platform Plus コアペア・サブスクリプションが必要となります。
例 2：ベアメタル上でオンプレミスで実行されるコンテナ化されたアプリケーション
次に、この同じアプリケーションをオンプレミスのベアメタルで実行し、Red Hat OpenShift に含まれる OpenShift Virtualization 機能を使用して VM コンピュートノードにプロビジョニングしたいと考えています。200 個のコンテナインスタンスで構成されるアプリケーションがあり、それぞれが平均 1 vCPU と 4 GB の RAM を消費します。推奨される最大使用率は 80% です。アプリケーションは、特定のハードウェアや AI アクセラレーターを必要としません。セルフマネージド・エディションとして Red Hat OpenShift Platform Plus を選択しましたが、現時点では必要なサブスクリプション数の見積もりだけが必要です。選択するベアメタル構成にはある程度の柔軟性がありますが、標準的な既製のサーバー構成を使用しています。
ステップ 1：必要なアプリケーション・インスタンスの数とタイプを特定する
この例の情報から算出：
- アプリケーション・インスタンス数 = 200
- 推奨される最大ノード使用率 = 80%
- 平均アプリケーション vCPU 要件 = 1 vCPU
- アプリケーション・メモリー・フットプリント平均 = 4 GB
ステップ 2：必要な合計メモリーと合計コア数を決定する
ステップ 1 の数値を計算に使用：
- 最大使用率 = 80%
- 必要な vCPU の合計 = 1 vCPU × 200 × 1/80% = 250 vCPU
- 必要な合計メモリー = 4 GB × 200 × 1/80% = 1,000 GB
ステップ 3：標準のコンピュートノードを選択する
現在のベアメタルサーバーの標準は、ソケットあたり 32 コア/64 vCPU を備えた 2 ソケットサーバーです。RAM は選択できます。vCPU と RAM の比率は 1:4 であるため、サーバーには 256 GB の RAM を搭載します。したがって、ベアメタルサーバーの選択は、ソケットあたり 32 コア/64 vCPU (サーバーあたり 64 コア/128 vCPU) と 256 GB RAM を備えた 2 ソケットサーバーです。
ステップ 4：必要なサブスクリプションの合計を計算する
ベアメタルサーバーの場合は、コアペア・サブスクリプションまたはベアメタル・ソケットペア・サブスクリプションを選択できます。両方を計算しましょう。
コアペア・サブスクリプションの合計 = 必要な vCPU の合計/4 (切り上げ)
250 vCPU/4 = 62.5 (切り上げて 63)
合計ソケットペア・サブスクリプション数 =
- 必要なサーバーの合計数 = サーバーあたり 250 vCPU/128 vCPU (切り上げ) = 2 サーバー
- サーバーごとに必要なサブスクリプションの合計数 = ソケットペアごとのコア数/128 (切り上げ) = 64/128 = 0.5 (切り上げて 1 サブスクリプション)
- 2 サーバー × 1 サブスクリプション/サーバー = 2 ベアメタル・ソケットペア・サブスクリプション
この場合、適切な vCPU とメモリーの比率となるサーバーを選択できたので、メモリー要件を満たすために必要なサーバーの数を計算して 2 つのうちの大きい方を取る必要はありません。選択したサーバーの RAM の量が異なる場合は、その差を考慮する必要があります。
ステップ 5：AI Accelerator サブスクリプションの合計を計算する (該当する場合)
このサイジングの例では、AI アクセラレーターを使用していないため、これは適用されません。
結果
この例では、63 の OpenShift Platform Plus コアペア・サブスクリプションまたは 2 つのベアメタル・ソケットペア・サブスクリプションが必要となります。この決定は、コスト面およびアーキテクチャ面で最善の決定になります。
例 3：VM のみの環境
仮想マシンを別のハイパーバイザーから Red Hat に移行しています。これは混合環境ですが、次の数のさまざまなサイズの仮想マシンが特定されました。
- 1,000 小規模 = 1,000 vCPU、4,000 GiB。プラス 228 GiB のメモリーオーバーヘッド
- 300 中規模 = 600 vCPU、2,400 GiB。プラス 73 GiB のメモリーオーバーヘッド
- 200 大規模 = 800 vCPU、4,800 GiB。プラス 58 GiB のメモリーオーバーヘッド
- 200 超大規模 = 1,600 vCPU、9,600 GiB。プラス 64 GiB のメモリーオーバーヘッド
ステップ 1：必要なアプリケーション・インスタンスの数とタイプを特定する
この例の情報から算出：
- アプリケーション・インスタンス数 = 1700
- 合計 vCPU = 4,000 vCPU
- 合計メモリー = 20,800 GB + 423 GB オーバーヘッド = 21,223 GB
- 平均アプリケーション vCPU 要件 = 2.4 vCPU
- アプリケーション・メモリー・フットプリント平均 = 12.5 GB
ステップ 2：必要な合計メモリーと合計コア数を決定する
ステップ 1 の数値を計算に使用：
- 必要な合計メモリー = 20,800 GB + 423 GB オーバーヘッド = 21,223 GB
- 必要な合計 vCPU = 4,000 vCPU
VM の最大使用率の指標はコンテナの場合とは若干異なりますが、仮想化管理者にはよくわかるはずです。
一般的に、VM のメモリーのオーバーコミットは推奨されないため、総メモリー要件がコンピュートノードの数を決定する主な要因となります。
コンピュートリソースについては、平均してほとんどの VM がすべてのコンピュートリソースを使用していないため、CPU のオーバーコミットが予想されます。OpenShift Virtualization の最大 CPU オーバーコミット比率は 10:1 に設定されているため、4:1 のような比率を選択するのは控えめと言えます。ここで、vCPU と同等のコアとスレッド (ハイパースレッディング・サポートにより、各コアを 2 スレッドにすることができます) を使用するかどうかを選択することもできます。控えめに 1 vCPU = 1 コアを選択し、ハイパースレッディングなしを選択することもできます。さて、ここでの要件は次のとおりです。
- 必要な合計メモリー = 20,800 GB + 423 GB オーバーヘッド = 21,223 GB
- 必要な合計コア = 4,000 vCPU × 1/4 × 1 コア/vCPU = 1,000 コア
ステップ 3：標準のコンピュートノードを選択する
仮想化用のベアメタル・コンピュートノードの選択は、冗長性、障害ドメイン、クラスタのサイズなど、多くの要素によって決まります。オンプレミスでは、サーバーごとの RAM を増やすなど、いくつかの選択肢があります。通常、サーバー要件はメモリーによって決まるため、そこから始めることができます。
ここでは 1,700 台の VM があり、ソケットあたり 32 コアの 2 ソケットサーバーを選択します。サーバーの数に合わせてコア数を使用する場合、次が必要になります。
- 1,000 コア/64 コア/サーバー (切り上げ) = 16 サーバー
サーバーが 16 台の場合、サーバーごとに、21,223 GB/16 サーバー = 1,326 GB の RAM が必要になります。当社のサーバーでは、1,536 GB の RAM を選択できます。ここで、ベアメタルの構成は次のとおりとなります。
- 32 コア/ソケット (合計 64 コア)、1,536 GB RAM の 2 ソケットサーバー
最終的に、この構成のサーバーを 16 台使用すると、合計は次のようになります。
- 16 × 64 コア = 1024 コア
- 16 × 1,536 GB = 24,576 GB メモリー
VM ロードを実行するにはこれで十分ですが、冗長性を確保するために追加のサーバーが必要になります。このままでは、サーバーの停止や重大なパフォーマンスへの影響によって 1 台のサーバーが失われた場合、対応できません。仮想化管理者は、フェイルオーバーと冗長性のために 25% の予備容量を確保するようアドバイスしています。したがって、次が必要になります。
- 16 サーバー + (16 サーバー × 25%) = 合計 20 サーバー
VM を 20 台のサーバーすべてに分散して、1 - 4 台のサーバーを失った場合でも VM の要件を満たすことができるようにします(レジリエンシーの要件は異なる場合があります)。
ステップ 4：必要なサブスクリプションの合計を計算する
仮想化のみのユースケースでは、ベアメタルソケットペアのサブスクリプションでのみ利用できる OpenShift Virtualization Engine を使用します。
合計ソケットペア・サブスクリプション数 =
- 必要なサーバーの合計数 = 20
- 当社のサーバーは最大 64 コア/ソケットペアであるため、サーバーごとに必要なサブスクリプションの合計数 = 1 となります
- 20 サーバー × 1 サブスクリプション/サーバー = 20 ベアメタル・ソケットペア・サブスクリプション
ステップ 5：AI Accelerator サブスクリプションの合計を計算する (該当する場合)
このサイジングの例では、AI アクセラレーターを使用していないため、これは適用されません。
結果
この例では、20 の OpenShift Virtualization Engine ベアメタルソケットペアのサブスクリプションが必要になります。
付録 1：セルフマネージド OpenShift エディションとその内容
表 1：Red Hat OpenShift エディションごとの全体的な特長の違い
特長 | Red Hat OpenShift Kubernetes Engine | Red Hat OpenShift Container Platform | Red Hat OpenShift Platform Plus | Red Hat OpenShift Virtualization Engine |
管理者用 Web コンソール | 〇 | 〇 | 〇 | 〇 |
認証統合、ロールベースのアクセス制御 (RBAC)、セキュリティ・コンテキストによる制約 (SCC)、マルチテナンシー・アドミッション・コントローラー | 〇 | 〇 | 〇 | 〇 |
自動スケーリング (クラスタおよび Pod) | 〇 | 〇 | 〇 | 〇 |
クラスタ監視 | 〇 | 〇 | 〇 | 〇 |
コスト管理の SaaS サービス | 〇 | 〇 | 〇 | 〇 |
Open Container Initiative (OCI) 互換ランタイム用の Kubernetes コンテナ・ランタイム・インタフェース (CRI)、または CRI-O ランタイム | 〇 | 〇 | 〇 | 〇 |
エンタープライズ向けのセキュアな Kubernetes | 〇 | 〇 | 〇 | 〇 |
完全に自動化されたインストーラー | 〇 | 〇 | 〇 | 〇 |
kubectl と oc 自動化コマンドライン | 〇 | 〇 | 〇 | 〇 |
OpenShift Virtualization | 〇 | 〇 | 〇 | 〇 |
Operator Lifecycle Manager (OLM) | 〇 | 〇 | 〇 | 〇 |
スマートな OTA アップグレード | 〇 | 〇 | 〇 | 〇 |
シークレット管理 | 〇 | 〇 | 〇 | 〇 |
ストレージドライバー | 〇 | 〇 | 〇 | 〇 |
ユーザー提供の仮想マシンのワークロード | 〇 | 〇 | 〇 | 〇 |
Red Hat OpenShift GitOps | VM ユースケースのみ | 〇 | 〇 | VM ユースケースのみ |
プラットフォームのロギング | VM ユースケースのみ | 〇 | 〇 | VM ユースケースのみ |
ユーザーワークロードの監視 | VM ユースケースのみ | 〇 | 〇 | VM ユースケースのみ |
Red Hat Enterprise Linux のサポート、ワーカーノードとインフラストラクチャ・ノードのエンタイトルメント | 〇 | 〇 | 〇 | |
Red Hat Enterprise Linux VM ゲスト・オペレーティングシステムおよびコンテナビルドのエンタイトルメント | 〇 | 〇 | 〇 | |
ユーザー提供のコンテナワークロード | 〇 | 〇 | 〇 | |
Red Hat OpenShift のビルド | 〇 | 〇 | ||
開発者のアプリケーションカタログ | 〇 | 〇 | ||
開発者用 Web コンソール | 〇 | 〇 | ||
IBM Cloud Pak および Red Hat Application Services バンドルの組み込みコンポーネント | 〇 | 〇 | ||
統合開発環境 (IDE) | 〇 | 〇 | ||
分散トレース | 〇 | 〇 | ||
odo | 〇 | 〇 | ||
Red Hat OpenShift Pipelines | 〇 | 〇 | ||
Red Hat OpenShift サンドボックスコンテナ | 〇 | 〇 | ||
Red Hat OpenShift Serverless | 〇 | 〇 | ||
Red Hat OpenShift Service Mesh | 〇 | 〇 | ||
Red Hat Advanced Cluster Management for Kubernetes | 〇 | |||
Red Hat Advanced Cluster Security for Kubernetes | 〇 | |||
Red Hat OpenShift Data Foundation Essentials | 〇 | |||
Red Hat Quay | 〇 |
表 2：Red Hat OpenShift エディションの詳細な違い (それらの機能を提供する Operator を含む)
特長 | Red Hat OpenShift Kubernetes Engine | Red Hat OpenShift Container Platform | Red Hat OpenShift Platform Plus | Red Hat OpenShift Virtualization Engine | Operator 名 |
AWS EFS CSI ドライバー Operator | 〇 | 〇 | 〇 | 〇 | aws-efs-csi-driver-operator |
AWS Load Balancer Operator | 〇 | 〇 | 〇 | 〇 | aws-load-balancer-operator |
Red Hat OpenShift 向け cert-manager Operator | 〇 | 〇 | 〇 | 〇 | openshift-cert-manager-operator |
クラスタ監視 | 〇 | 〇 | 〇 | 〇 | クラスタ監視 |
クラスタ可観測性 Operator | 〇 | 〇 | 〇 | 〇 | cluster-observability-operator |
ClusterResourceOverride Operator | 〇 | 〇 | 〇 | 〇 | clusterresourceoverride |
CNI プラグイン ISV 互換性 | 〇 | 〇 | 〇 | 〇 | なし |
コンプライアンス Operator | 〇 | 〇 | 〇 | 〇 | コンプライアンス Operator |
コンフィデンシャル・コンピューティング・アテステーション | 〇 | 〇 | 〇 | 〇 | trustee-operator |
CSI プラグイン ISV 互換性 | 〇 | 〇 | 〇 | 〇 | なし |
Custom Metrics Autoscaler | 〇 | 〇 | 〇 | 〇 | openshift-custom-metrics-autoscaler-operator |
デバイスマネージャー (例：GPU) | 〇 | 〇 | 〇 | 〇 | なし |
DPU Network Operator | 〇 | 〇 | 〇 | 〇 | dpu-network-operator |
Egress Pod と名前空間のきめ細かな制御 | 〇 | 〇 | 〇 | 〇 | なし |
組み込みのマーケットプレイス | 〇 | 〇 | 〇 | 〇 | なし |
組み込みの OperatorHub | 〇 | 〇 | 〇 | 〇 | なし |
組み込みのレジストリ | 〇 | 〇 | 〇 | 〇 | なし |
外部 DNS Operator | 〇 | 〇 | 〇 | 〇 | external-dns-operator |
フェンスエージェントの修復 | 〇 | 〇 | 〇 | 〇 | fence-agents-remediation |
ファイル整合性 Operator | 〇 | 〇 | 〇 | 〇 | ファイル整合性 Operator |
GCP FileStore CSI ドライバー Operator | 〇 | 〇 | 〇 | 〇 | gcp-filestore-csi-driver-operator |
HAProxy Ingress コントローラー | 〇 | 〇 | 〇 | 〇 | なし |
Helm | 〇 | 〇 | 〇 | 〇 | なし |
クラスタ全体の Ingress ファイアウォール | 〇 | 〇 | 〇 | 〇 | なし |
Ingress 用非標準ポート | 〇 | 〇 | 〇 | 〇 | なし |
IPv6 シングルおよびデュアルスタック | 〇 | 〇 | 〇 | 〇 | なし |
Kube Descheduler Operator (Red Hat 提供) | 〇 | 〇 | 〇 | 〇 | Kube Descheduler Operator |
Kubernetes NMState Operator | 〇 | 〇 | 〇 | 〇 | kubernetes-nmstate-operator |
ローカルストレージ Operator | 〇 | 〇 | 〇 | 〇 | ローカルストレージ Operator |
ログ転送 | 〇 | 〇 | 〇 | 〇 | Red Hat OpenShift Logging Operator |
Loki Operator | 〇 | 〇 | 〇 | 〇 | loki-operator |
論理ボリューム管理ストレージ | 〇 | 〇 | 〇 | 〇 | lvms-operator |
マシン削除の修復 | 〇 | 〇 | 〇 | 〇 | machine-deletion-remediation |
MetalLB Operator | 〇 | 〇 | 〇 | 〇 | metallb-operator |
仮想化移行ツールキット | 〇 | 〇 | 〇 | 〇 | mtv-operator |
マルチアーキテクチャ・チューニング | 〇 | 〇 | 〇 | 〇 | multiarch-tuning-operator |
Multus および利用可能な Multus プラグイン | 〇 | 〇 | 〇 | 〇 | なし |
Network-Bound Disk Encryption (NBDE) Tang サーバー | 〇 | 〇 | 〇 | 〇 | nbde-tang-server |
ネットワークポリシー | 〇 | 〇 | 〇 | 〇 | なし |
Node Feature Discovery (Red Hat 提供) | 〇 | 〇 | 〇 | 〇 | NFD |
ノードヘルスチェック | 〇 | 〇 | 〇 | 〇 | node-healthcheck-operator |
ノードメンテナンス | 〇 | 〇 | 〇 | 〇 | node-maintenance-operator |
NUMA Resources Operator | 〇 | 〇 | 〇 | 〇 | numaresources-operator |
OpenShift APIs for Data Protection (OADP) | 〇 | 〇 | 〇 | 〇 | OADP Operator |
OpenShift クラウドマネージャー SaaS サービス | 〇 | 〇 | 〇 | 〇 | なし |
OpenShift 更新サービス | 〇 | 〇 | 〇 | 〇 | cincinnati-operator |
OpenShift Virtualization | 〇 | 〇 | 〇 | 〇 | OpenShift Virtualization Operator |
OVS および OVN SDN | 〇 | 〇 | 〇 | 〇 | なし |
Red Hat OpenShift 向け電力モニタリング | 〇 | 〇 | 〇 | 〇 | power-monitoring-operator |
PTP Operator (Red Hat 提供) | 〇 | 〇 | 〇 | 〇 | PTP Operator |
Red Hat Quay 互換性 | 〇 | 〇 | 〇 | 〇 | なし |
Red Hat Enterprise Linux Software Collections および RHT SSO Common Service | 〇 | 〇 | 〇 | 〇 | なし |
Run Once Duration Override Operator | 〇 | 〇 | 〇 | 〇 | run-once-duration-override-operator |
Red Hat OpenShift 向け Secondary Scheduler Operator | 〇 | 〇 | 〇 | 〇 | openshift-secondary-scheduler-operator |
シークレットストア CSI | 〇 | 〇 | 〇 | 〇 | シークレットストア CSI Operator |
セキュリティプロファイル | 〇 | 〇 | 〇 | 〇 | セキュリティプロファイル Operator |
サービスバインディング Operator | 〇 | 〇 | 〇 | 〇 | rh-service-binding-operator |
SR-IOV network operator | 〇 | 〇 | 〇 | 〇 | SR-IOV Network Operator |
Telemeter and Insights コネクテッド・エクスペリエンス | 〇 | 〇 | 〇 | 〇 | なし |
垂直 Pod 自動スケーラー | 〇 | 〇 | 〇 | 〇 | 垂直 Pod 自動スケーラー |
Web ターミナル | 〇 | 〇 | 〇 | 〇 | web-terminal |
コスト管理 | 〇 | 〇 | 〇 | costmanagement-metrics-operator | |
プラットフォームのロギング | VM ユースケースのみ | 〇 | 〇 | VM ユースケースのみ | Red Hat OpenShift Logging Operator |
ユーザーワークロードの監視 | VM ユースケースのみ | 〇 | 〇 | VM ユースケースのみ | cluster-monitoring-operator |
Red Hat OpenShift のビルド | 〇 | 〇 | openshift-builds-operator | ||
開発者のアプリケーションカタログ | 〇 | 〇 | なし | ||
開発者用 Web コンソール | 〇 | 〇 | なし | ||
Kourier Ingress コントローラー | 〇 | 〇 | OpenShift Serverless | ||
アプリケーション移行ツールキット | 〇 | 〇 | mta-operator | ||
コンテナ移行ツールキット | 〇 | 〇 | mtc-operator | ||
ランタイム移行ツールキット | 〇 | 〇 | mtr-operator | ||
ネットワーク可観測性 Operator | 〇 | 〇 | netobserv-operator | ||
ODF マルチクラスタ・オーケストレーター | 〇 | odf-multicluster-orchestrator | |||
Red Hat OpenShift Dev Spaces | 〇 | 〇 | devspaces | ||
OpenTelemetry の Red Hat ビルド | 〇 | 〇 | klusterlet-product | ||
分散トレース | 〇 | 〇 | tempo-operator | ||
OpenShift DR Cluster Operator | 〇 | odr-cluster-operator | |||
OpenShift DR Hub Operator | 〇 | odr-hub-operator | |||
OpenShift Elasticsearch Operator (注 1) | 〇 | 〇 | elasticsearch-operator | ||
Red Hat OpenShift GitOps | VM ユースケースのみ | 〇 | 〇 | VM ユースケースのみ | openshift-gitops-operator |
Kiali | 〇 | 〇 | Kiali Operator | ||
Red Hat OpenShift Local | 〇 | 〇 | なし | ||
Red Hat OpenShift のロギング | 〇 | 〇 | cluster-logging | ||
Red Hat OpenShift Pipelines | 〇 | 〇 | openshift-pipelines-operator-rh | ||
Red Hat OpenShift サンドボックスコンテナ | 〇 | 〇 | sandboxed-containers-operator | ||
Red Hat OpenShift Serverless | 〇 | 〇 | serverless-operator | ||
Red Hat OpenShift Service Mesh | 〇 | 〇 | servicemeshoperator | ||
Quay Bridge (Red Hat 提供) | 〇 | 〇 | Quay Bridge Operator | ||
Quay Container Security (Red Hat 提供) | 〇 | 〇 | Container Security Operator | ||
Keycloak の Red Hat ビルド | 〇 | 〇 | keycloak-operator | ||
Quarkus の Red Hat ビルド | 〇 | 〇 | なし | ||
シングルサインオン | 〇 | 〇 | rhsso-operator | ||
Source-to-Image およびビルダーの自動化 | 〇 | 〇 | OpenShift Pipelines | ||
Topology Aware Lifecycle Manager | 〇 | 〇 | topology-aware-lifecycle-manager | ||
VolSync | 〇 | 〇 | volsync-product | ||
Web ターミナル (Red Hat 提供) | 〇 | 〇 | Web ターミナル | ||
Windows Machine Config Operator | 〇 | 〇 | Windows Machine Config Operator |
注 1：Red Hat OpenShift に含まれる OpenShift Elasticsearch Operator は、OpenShift クラスタの内部インフラストラクチャの検索ニーズをサポートするためにのみライセンスが付与されており、お客様のアプリケーションにスタンドアローンで使用することはできません。
どの Red Hat OpenShift エディションにも含まれていない一般的な Red Hat ソフトウェア
特に指定がない限り、一般に OpenShift と組み合わせて使用される以下の Red Hat ソフトウェア製品は、別途ライセンスを取得する必要があります。Red Hat OpenShift Platform Plus には、Red Hat Advanced Cluster Management、Red Hat Advanced Cluster Security、Red Hat Quay、および Red Hat OpenShift Data Foundation Essentials が含まれています。その他のセルフマネージド OpenShift サブスクリプションにはこれらの追加製品は含まれていませんが、個別に購入できます。Red Hat OpenShift で使用され、このサブスクリプションガイドには含まれていないその他の Red Hat ソフトウェアは次のとおりです。
- Red Hat Ansible Automation Platform
- Red Hat Application Foundations
- Red Hat Enterprise Linux AI
- Red Hat 統合ポートフォリオ (3scale、AMQ、Camel K、Fuse など)
- Red Hat JBoss EAP
- Red Hat Middleware バンドル
- Red Hat OpenShift Developer Hub (Backstage プロジェクトの Red Hat ビルド)
- Red Hat OpenShift AI
- Red Hat Satellite (Red Hat Enterprise Linux 管理用)
- IBM Cloud Paks
上記のオファリングの詳細については、Red Hat 販売者またはパートナーにお問い合わせください。
