目次
はじめに
Red Hat OpenShift 系サブスクリプション製品
Red Hat OpenShift Kubernetes Engine
Red Hat OpenShift Container Platform
Red Hat OpenShift Platform Plus
セルフマネージド OpenShift の環境
サブスクリプションの種類
障害復旧
移行とスイングアップグレード
コアと vCPU およびハイパースレッディング
コアバンド
ベアメタルサーバーに関する考慮事項
上記以外のアーキテクチャ (IBM Z、Power)
Microsoft Windows Server コンテナのサポート
Red Hat OpenShift Platform Plus コンポーネントのサポート
セルフマネージド Red Hat OpenShift のサイジング
サイジングのプロセス
ステップ 1:標準 VM またはハードウェアコアとメモリーを決定する
ステップ 2:必要なアプリケーション・インスタンスの数を計算する
ステップ 3:推奨される最大 OpenShift ノード使用率を決定する
ステップ 4:合計メモリー・フットプリントを決定する
ステップ 5:合計を計算する
はじめに
この資料では、セルフマネージド Red Hat® OpenShift® 製品のサブスクリプションモデルに関する説明のほか、OpenShift 環境のサイズを見積もるための手順を紹介します。サイジングに関してより詳細な情報をご希望の場合は、Red Hat までお問い合わせください。
Red Hat OpenShift 系サブスクリプション製品
Red Hat OpenShift は、オープン・ハイブリッドクラウド環境全体で一貫したアプリケーション開発および管理プラットフォームを提供し、オンプレミスの仮想および物理インフラストラクチャ、プライベートクラウド、パブリッククラウド、エッジデプロイメントに対応します。Red Hat OpenShift を運用および使用する方法には、セルフマネージド OpenShift とフルマネージド OpenShift クラウドサービスの 2 つがあります。
セルフマネージド OpenShift を使用すると、最大限の制御とカスタマイズが可能で非常に柔軟な Red Hat OpenShift 環境をインストール、運用、および管理できるため、インフラストラクチャを始めとするお客様独自の環境を運用することができます。セルフマネージド OpenShift は、サポートされているパブリッククラウド環境だけでなく、オンプレミスの物理サーバー、仮想化、プライベートクラウド環境に対応します。お客様は、アップグレードの制御、下位レベルのインフラストラクチャの管理、サービスレベル契約 (SLA) の維持を行います。
OpenShift クラウドサービスの管理と運用は、Red Hat と主要なパブリッククラウドにおける当社のパブリッククラウド・パートナーによって行われます。専任のサイト信頼性エンジニアリング (SRE) チームが Red Hat OpenShift のコアサービスとインフラストラクチャの管理と保守を行うため、DevSecOps チームは新しいアプリケーションの開発とデプロイ、既存アプリケーションのモダナイズに集中できます。
OpenShift のすべてのエディションにおいて、環境全体で開発者と運用に一貫したユーザーエクスペリエンスが提供されるため、お客様のスキルとアプリケーションは、アプリケーションが最適に実行されるクラウド環境で活用できます。
セルフマネージド OpenShift ソフトウェア製品:
-
Red Hat OpenShift Kubernetes Engine:データセンター、パブリッククラウド、またはエッジ環境にインストールして管理するアプリケーションをデプロイおよび実行するための OpenShift のコア機能を提供する、ハイブリッドクラウドのエンタープライズ向け Kubernetes ランタイムエンジンです。
-
Red Hat OpenShift Container Platform:データセンター、パブリッククラウド、およびエッジ環境にインストールして管理するアプリケーションを構築、デプロイ、実行するためのハイブリッドクラウドのエンタープライズ向け Kubernetes プラットフォームです。
-
Red Hat OpenShift Platform Plus:単一のハイブリッドクラウド・プラットフォームで、複数のクラスタとクラウドのフットプリントにわたり、インテリジェントなアプリケーションを大規模かつ安全に構築、デプロイ、実行、および管理できます。セキュリティ、管理の容易性、自動化を複数レイヤーで展開し、ソフトウェア・サプライチェーン全体で一貫性を提供します。
OpenShift クラウドサービス製品:
- Amazon Web Services (AWS) および Google Cloud で動作するフルマネージドの Red Hat OpenShift サービスです。価格設定などの詳細は、openshift.com をご覧ください。
- 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 Kubernetes Service on IBM Cloud:IBM Cloud で動作するフルマネージドの Red Hat OpenShift サービスです。Red Hat と IBM が共同で管理します。詳細はこちら。
Red Hat OpenShift Kubernetes Engine
サブスクリプションに含まれるもの:
- Red Hat OpenShift Kubernetes Engine は、Kubernetes ランタイムエンジンおよびインフラストラクチャであり、OpenShift Container Platform の高度な機能や開発者向け機能は含まれません。OpenShift Kubernetes Engine には、OpenShift Kubernetes ディストリビューション、Red Hat Enterprise Linux® と Red Hat Enterprise Linux CoreOS (詳細は後述)、および、統合された Kubernetes クラスタのサービスコンポーネント (OpenShift インストーラー、モニタリング、ログ転送、SDN、Ingress ルーター、レジストリなど) が含まれます。詳細は、OpenShift ドキュメントの OpenShift Kubernetes Engine についてを参照してください。
- Red Hat Enterprise Linux および Red Hat Enterprise Linux CoreOS:OpenShift の各サブスクリプションには、ワーカーノード、コントロールプレーン・ノード、およびサポートするインフラストラクチャ・ノードに必要なソフトウェアがすべて含まれています。これには、Red Hat Enterprise Linux CoreOS および Red Hat Enterprise Linux ソフトウェアが含まれます。OpenShift コントロールプレーンには、Red Hat Enterprise Linux CoreOS が必要です。Red Hat Enterprise Linux CoreOS は、OpenShift のコンポーネントとして使用している場合にサポートの対象となります。OpenShift を利用するお客様は、Red Hat Enterprise Linux CoreOS の代わりに、Red Hat OpenShift ワーカーノードに Red Hat Enterprise Linux バージョン 7 または 8 を使用することもできます。Red Hat Enterprise Linux は、これらのワーカーノードにお客様が別途インストールする必要があります。そのために、OpenShift サブスクリプションには Red Hat Enterprise Linux ソフトウェアが含まれています。お使いの OpenShift デプロイメントでサポートされている Red Hat Enterprise Linux のバージョンを確認するには、製品ドキュメントを参照してください。
- Red Hat OpenShift Virtualization:仮想マシン (VM) とコンテナを同じツールとチームで管理できる単一のプラットフォームを使用して、アプリケーション提供を加速できます。OpenShift Virtualization により、OpenShift は KubeVirt を使用して、Kubernetes でコンテナと VM の両方を管理および消費できます。これには、OpenShift でホストされるすべての仮想マシンで Red Hat Enterprise Linux をゲスト・オペレーティングシステムとして使用するためのエンタイトルメントが含まれます。
- Red Hat Application Streams:OpenShift では、Red Hat Enterprise Linux に含まれる Red Hat Application Streams (旧称 Software Collections) で提供されるコンテナイメージを使用できます。これらのイメージには、一般的な言語やランタイム (PHP、Python、Perl、Node.js、Ruby など) に加えて、MySQL、MariaDB、Redis などのデータベースが含まれます。この製品には、Java™ フレームワーク用の OpenJDK イメージも含まれています。詳細は、Application Streams に関するこちらの記事をご覧ください。
Red Hat OpenShift Container Platform
サブスクリプションに含まれるもの:
- Red Hat OpenShift Kubernetes Engine:OpenShift Container Platform の各サブスクリプションには、OpenShift Kubernetes Engine のすべてのコンポーネントに加えて、階層化されたサービス (詳細は後述) が付帯しています。
- Red Hat JBoss® Web Server:OpenShift Container Platform サブスクリプションには、Red Hat JBoss Web Server が含まれます。Red Hat JBoss Web Server は Apache Web サーバーと Apache Tomcat サーブレットエンジンを組み合わせ、Red Hat がサポートを提供するエンタープライズ向けソリューションです。OpenShift Container Platform には、JBoss Web Server を使用する無制限の権利が含まれます。JBoss Web Server の詳細はこちらをご覧ください。
- Red Hat のシングルサインオン (SSO) テクノロジー:Red Hat は、Security Assertion Markup Language (SAML) 2.0、OpenID Connect、および Open Authorization (OAuth) 2.0 仕様に基づく Web SSO と ID フェデレーションを提供します。OpenShift サブスクリプションに含まれるこの機能は、OpenShift 環境内にのみデプロイできます。ただし、OpenShift の内部または外部にデプロイされているどのアプリケーションでも、Red Hat の SSO を使用できます。
- ログ管理:ログ収集向けに Fluentd と統合された Elasticsearch および Kibana を介したログ集約と管理のサポートを追加します。
- Red Hat CodeReady Workspaces:OpenShift ワークスペースとブラウザ内の統合開発環境 (IDE) を提供する Kubernetes ネイティブのコラボレーティブな開発環境です。
- Red Hat ビルドの Quarkus:Java 仮想マシン (JVM) およびネイティブコンパイルのために作成されたフルスタックの Kubernetes ネイティブ Java フレームワークで、Java をコンテナに最適化し、サーバーレス、クラウド、Kubernetes の各環境で効果的なプラットフォームとして使用できるようにします。
- OpenShift コンソール:開発者 (Developer) と管理者 (Administrator) の両方に最適化されたエクスペリエンスを提供します。Developer パースペクティブにはアプリケーション・コンポーネントへの可視性があり、Administrator パースペクティブではユーザーが OpenShift および Kubernetes リソースを表示できます。
- Red Hat OpenShift Pipelines:Tekton に基づくKubernetes ネイティブの継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインを使用して、オンプレミスおよびパブリッククラウド・プラットフォーム間でのアプリケーション提供を自動化および制御します。
- Red Hat OpenShift GitOps:git リポジトリ、CI/CD ツール、および Kubernetes を統合する独自のワークフローにより、Argo CD に基づいて、品質を損なうことなく、セキュリティに重点を置いたスケーラブルなソフトウェア開発をより迅速に実現します。
- Red Hat OpenShift Serverless:サーバーレスコンテナのデプロイと実行を可能にするイベント駆動型のサーバーレスコンテナおよび機能です。イベントソースの豊富なエコシステムを利用して、OpenShift でサーバーレス・アプリケーションをネイティブに管理できます。OpenShift Serverless は Knative をベースにしており、これを使用すると、OpenShift が実行されている場所ならどこでもサーバーレス・アプリケーションを実行できます。
- Red Hat OpenShift Service Mesh: Red Hat OpenShift Service Mesh を使うと、サービス間のトラフィックフローを管理および保護する Istio、分散トレース向けの Jaeger、構成を表示してトラフィックを監視する Kiali などで、マイクロサービスベースのアプリケーションの接続、管理、および監視方法を統一できます。
- Red Hat Insights for OpenShift: Red Hat Insights for OpenShift は、cloud.redhat.com のホステッドサービスをセットにしたもので、Red Hat サブスクリプションに含まれています。これは、お客様のデプロイメントから cloud.redhat.com に送信される構成およびデータとルールベースの分析モデルを使用して、お客様による支出の追跡と最適化に加え、安定性とパフォーマンスの向上を支援します。
- IBM Cloud Satellite:Red Hat OpenShift Container Platform を利用するお客様が IBM Cloud Satellite ソリューションを購入してデプロイする場合、OpenShift ノードのサブスクリプションを使用して、データセンター内にあるお客様のワークロードに関連する Red Hat OpenShift Kubernetes Service on IBM Cloud クラスタのエンタイトルメントを取得できます。お客様は IBM と Red Hat のいずれにもサポートを依頼できますが、最終的なお客様へのサポートは、まず IBM Cloud Satellite のサポートサービスから提供されます。OpenShift サブスクリプションをこのように使用できるのは、IBM Cloud Satellite をデータセンター内にデプロイするお客様のみであり、パブリッククラウド環境の場合は対象外です。コアのカウント方法は、OpenShift の通常使用の場合、この資料で説明している方法と同じです。
Red Hat OpenShift Platform Plus
サブスクリプションに含まれるもの:
- Red Hat OpenShift Container Platform:OpenShift Platform Plus の各サブスクリプションには、OpenShift Container Platform のすべてのコンポーネントに加えて、マルチクラスタおよびハイブリッドクラウドの管理とセキュリティを大規模かつ階層的に提供する製品 (詳細は後述) が付帯しています。
- Red Hat Advanced Cluster Management for Kubernetes:Red Hat Advanced Cluster Management for Kubernetes は、複数のデータセンターとパブリッククラウド環境にわたる OpenShift ドメイン全体のセキュリティとコンプライアンスを提供するとともに、クラスタとアプリケーションのライフサイクルを管理するためのエンドツーエンド管理を可視化し、その制御を可能にします。
- Red Hat Advanced Cluster Security for Kubernetes:Red Hat Advanced Cluster Security for Kubernetes は、業界初の Kubernetes ネイティブのセキュリティ・プラットフォームで、クラウドネイティブ・アプリケーションの構築、デプロイ、実行をあらゆる場所で安全に行えます。Red Hat Advanced Cluster Security for Kubernetes は、ソフトウェア開発ライフサイクル全体で組み込みのセキュリティをサポートする Kubernetes ネイティブのアプローチを通じて、運用コストの削減、運用リスクの緩和、開発者の生産性の向上を実現します。
- Red Hat Quay:Red Hat Quay は、グローバルデータセンター全体でコンテナ化されたコンテンツを効率的に管理するための信頼できるオープンソース・レジストリ・プラットフォームで、クラウドネイティブおよび DevSecOps の開発モデルと環境に重点を置いています。OpenShift と緊密に統合され、世界最大のパブリックレジストリ SaaS (Software-as-a-Service) の 1 つである Quay.io を実行してきた長い実績を持つ Quay は、クラスタ上で実行されているすべてのソフトウェア・アーティファクトを一元的に管理できる、信頼性の高いスケーラブルな場所を提供します。
- Red Hat OpenShift Data Foundation Essentials:Red Hat Openshift Data Foundation は、OpenShift および OpenShift インフラストラクチャ・サービスで実行されているアプリケーションに対して、永続的なソフトウェア・デファインドのファイル、ブロック、オブジェクトストレージ、データサービスを提供します。Red Hat OpenShift と統合されており、Red Hat OpenShift 向けに最適化されています。
セルフマネージド OpenShift の環境
セルフマネージド OpenShift (Red Hat OpenShift Platform Plus、Red Hat OpenShift Container Platform、および Red Hat OpenShift Kubernetes Engine) は、64 ビットの Red Hat Enterprise Linux が認定およびサポートされている場所ならどこでも使用できます。
Red Hat OpenShift 4 は、3 つの主要なデプロイメント手法に対応しています。
- プラットフォーム固有のインストーラー・プロビジョニング・インフラストラクチャ (IPI):クラスタのプロビジョニングとインストールプロセスを自動化するために、基盤となるインフラストラクチャ・プラットフォーム (詳細は後述) との完全な統合を提供します。インストーラーは、クラスタのインストールに必要なすべてのリソースをプロビジョニングし、OpenShift クラスタとインフラストラクチャ・プロバイダー間の統合を構成します。
- プラットフォーム固有のユーザー・プロビジョニング・インフラストラクチャ (UPI):インフラストラクチャのプラットフォームに応じて、OpenShift と基盤となるプラットフォームの間でさまざまな量の統合を利用できます。クラスタのインストールに必要なリソースは管理者がプロビジョニングします。プラットフォームに応じて、インストーラーがインフラストラクチャ統合を構成したり、管理者がデプロイ後に統合を追加したりする場合があります。
- プラットフォームに依存しない UPI:このタイプのデプロイメントでは、基盤となるインフラストラクチャとの統合は提供されません。このインストール手法では最も広範な互換性が得られますが、クラスタ・インフラストラクチャのリソースの作成と管理は管理者が行います。
セルフマネージド・デプロイメントの場合、OpenShift をインストールできる環境は、次のとおりです。
- ベアメタルサーバー
- 以下を含む仮想化環境
- VMware vSphere
- Red Hat Virtualization
- その他の認定された仮想化プラットフォーム:他のプラットフォームは、プラットフォームに依存しない UPI のインストール手法によってサポートされます。
- プライベートクラウド環境
- Red Hat OpenStack® Platform
- 以下を含むパブリッククラウド環境
- Amazon Web Services、Azure、Google Cloud Platform
- その他の認定されたパブリッククラウド・プラットフォーム:他のプラットフォームは、プラットフォームに依存しない UPI のインストール手法によってサポートされます。
サポートされているプラットフォームの詳細については、 OpenShift Container Platform の公式ドキュメントページをご覧ください。
認定パブリッククラウド環境で OpenShift サブスクリプションを使用するには、Red Hat Cloud Access への登録が必要です。詳細は Red Hat Cloud Access ページをご覧ください。
Red Hat OpenShift でテストおよび認定済みのプラットフォームとクラウド環境の詳細はこちらをご覧ください。
サブスクリプションの種類
Red Hat OpenShift Platform Plus、Red Hat OpenShift Container Platform、Red Hat OpenShift Kubernetes Engine のサブスクリプションの利用には 2 つのオプションがあり、それぞれに 2 つのサポートレベルがあります。
- コアベース (2 コア、または 4 vCPU):これは、すべての OpenShift クラスタで実行されているすべての OpenShift ワーカーノードの物理コアまたは仮想コア (vCPU) の総数に基づいています。Standard (月 - 金、8 時間の営業時間内) または Premium (年中無休 24 時間) サポートの SLA で利用可能です。
- ベアメタルソケットペア (1 - 2 ソケット、最大 64 コア):このサブスクリプションは、コアベースのサブスクリプションを使用する必要がある IBM Z および Power アーキテクチャを除き、OpenShift がハードウェアに直接インストールされる x86 ベアメタル物理ノードでのみ使用できます。
Red Hat Enterprise Linux を利用する場合:
- OpenShift サブスクリプション (Red Hat OpenShift Platform Plus、Red Hat OpenShift Container Platform、および Red Hat OpenShift Kubernetes Engine) はスタック可能で、ホストの規模が拡大しても対応できます。
- コアベースのサブスクリプションは、OpenShift クラスタ全体ですべての OpenShift ワーカーノードをカバーできるように分散することができます。たとえば、100 個の 2 コア Red Hat OpenShift Platform Plus サブスクリプションで 200 コア (400 vCPU) が提供されますが、これらは実行中のすべての OpenShift クラスタにわたり、任意の数のワーカーノードで使用できます。
障害復旧
Red Hat は、ホット、ウォーム、コールドの 3 種類の障害復旧 (DR) 環境を定義しています。有料の OpenShift サブスクリプションが必要なのは、ホットの DR のみです。
- ホットの場合、完全に機能する DR システムがプロダクションシステムと同時に実行されます。プライマリー環境内で障害が発生した場合、すぐにトラフィックを引き継いで処理を継続させます。
- ウォームの DR システムには、プライマリーサイトにあるものを適正に複製したハードウェアが備えられていますが、お客様のデータは含まれていません。サービスを復元するには、復旧を開始する前に、オフサイトのストレージ施設からの最終バックアップを配信し、ベアメタルを復元する必要があります。
- コールドの DR システムでは、インフラストラクチャは整っていますが、サービスの復元に必要なテクノロジー (ハードウェア、ソフトウェア) は揃っていません。
ウォームまたはコールド DR 用に明示的に構成および設計されていない休止状態のクラスタ (クラウドサービスで実行されており、需要が低いために一時的に休止状態になっているクラスタなど) には、サブスクリプションが必要です。ワークロードを実行するためにクラスタを休止状態から復帰させる場合は、サブスクリプションが必要です。定期的なメンテナンスやテストのためにクラスタを一時的に休止状態から復帰させる場合は、OpenShift ソフトウェア製品のいずれのコンポーネントについても追加のサブスクリプションは必要ありません。サブスクリプションが必要なのは、ワークロードがクラスタにデプロイされている場合のみです。
ウォームの場合もコールドの場合も、障害の発生時には Red Hat OpenShift サブスクリプションをプライマリー環境から DR 環境に移転してサービスを復元できます。また、Red Hat のサブスクリプション条件への準拠も維持できます。
移行とスイングアップグレード
Red Hat OpenShift 4 では、マイナーバージョン間のインプレース・アップグレードが可能です。ただし、Red Hat OpenShift 3 からアップグレードする場合、またはメンテナンスウィンドウなどの考慮事項のためにスイングアップグレードを実行する必要がある場合、Red Hat OpenShift サブスクリプションは、一方向移行の元のインフラストラクチャと宛先インフラストラクチャの両方を、その移行が完了するまでカバーします。移行中、Red Hat のサブスクリプション管理ツールは、お客様が購入した OpenShift サブスクリプションの数に基づいて、お客様の環境は非準拠であると表示します。Red Hat はこのような状態での移行をメジャーバージョンのアップグレードで認めており、移行中に準拠状態に戻すために追加のサブスクリプションを購入する必要はありません。そして、OpenShift はこれらの移行を支援するツールを提供します。また、必要に応じて Red Hat コンサルティングサービスもご利用いただけます。コンテナ移行ツールキットに関するドキュメントを参照してください。
コアと vCPU およびハイパースレッディング
特定のシステムが 1 つ以上のコアを使用しているかどうかの判断は現在、そのシステムでハイパースレッディングが使用可能であるかどうかに応じて異なります。ハイパースレッディングは Intel CPU の一機能にすぎないことに注意してください。特定のシステムがハイパースレッディングをサポートしているかどうかを判断するには、詳細をご覧ください。
ハイパースレッディングが有効であり、1 つのハイパースレッドが 1 つの可視システムコアに相当するシステムでは、2 つのコア = 4 つの vCPU という比率でコアの計算が行われます。
つまり、ハイパースレッド・システムでは、2 コア・サブスクリプションが 4 つの vCPU をカバーします。大規模な VM に 8 つの vCPU が存在する場合、これは 4 つのサブスクリプション・コアに相当します。サブスクリプションは 2 コア単位で提供されるため、これらの 4 つのコア (8 つの vCPU) をカバーするには、2 つの 2 コア・サブスクリプションが必要となります。
ハイパースレッディングが有効になっておらず、各可視システムコアが、基盤となる物理コアに直接関連する場合は、2 つのコア = 2 つの vCPU という計算が使用されます。
コアバンド
Red Hat OpenShift サブスクリプションでは、コアバンドと呼ばれる測定システムが使用されます。つまり、サブスクリプション (OpenShift を消費するためのエンタイトルメント) は、OpenShift のクラスタレベルで適用および消費され、そのクラスタ上のすべての OpenShift ワーカーノードに適用されます。複数の OpenShift クラスタを使用している場合は、すべてのクラスタの OpenShift ワーカーノードが消費するコアの総数を集計し、必要なサブスクリプションの数を判別します。たとえば、100 個の 2 コア Red Hat OpenShift Container Platform サブスクリプションを使用している場合、実行中のすべての OpenShift クラスタ全体で合計 200 コア (ハイパースレッディングで 400 vCPU) を OpenShift ワーカーノードに適用できます。
ベアメタルサーバーに関する考慮事項
物理サーバーには、コアベース (2 コア/4 vCPU) かソケットベース (1 - 2 ソケット) のいずれかの OpenShift サブスクリプションを使用してエンタイトルメントを付与することができます。コアベースのサブスクリプションが使用されている場合は、サーバー内の物理コアの総数をカバーするのに十分な数のサブスクリプションをスタックします。
Red Hat は、コアベースのサブスクリプションに加えて、ソケットベースの OpenShift サブスクリプションも提供しています。一部のデプロイメントにおいて、これはより経済的なオプションです。ソケットベースのサブスクリプションは x86 サーバーでの使用に限定されており、ソケットは最大 2 つ、コアは合計 64 までです。現在、ソケットベースのサブスクリプションは x86 サーバーでのみ使用可能であり、IBM Z または Power のアーキテクチャでは使用できません。
物理サーバーにエンタイトルメントを付与するには、そのサーバー内のソケットまたは物理コアの総数 (どちらか大きい方) に応じて、1 つ以上のサブスクリプションをスタックします。たとえば、あるサーバーに 2 つのソケットと 48 のコアがあるとします。そのサーバーのソケットは 2 つでコアの数は 64 未満なので、必要なサブスクリプションは 1 つですが、サーバーのソケットが 2 つでコアが 96 の場合は、サブスクリプションは 2 つ必要です。1 つのサブスクリプションがカバーするのは最大 64 コアなので、96 コアをカバーするには 2 つのサブスクリプションが必要になります。
ベアメタル・ソケットペア・サブスクリプションには、コントロールプレーンとインフラストラクチャ向けのインフラストラクチャ・サブスクリプションも付帯しています。ベストプラクティスは、これらを、同種のクラスタで機能するインフラストラクチャ自動化を利用するベアメタル物理サーバーにすることです。別の仮想化サーバーをコントロールプレーンとして使用する (「混合」クラスタを作成する) という選択肢もありますが、その場合は、できるだけ手作業に依存しないインストーラー手法を使用する必要があり、すべてのベアメタルクラスタ (つまり、すべてのベアメタルワーカーノードとインフラストラクチャ・ノード) で可能なインフラストラクチャ自動化を利用することはできません。
そして、ベアメタル・ソケットペア・サブスクリプションを使用しても、ノードあたりのコンテナ数の制限 (現在は 250 - 500) は変更されません。物理ベアメタルサーバーはそれぞれ単一のノードであり、仮想化を使用して多数の小さなノードに分割することはできません (そのためには、コアベースのサブスクリプションを使用する必要があります)。つまり、ベアメタル・ソケットペア・モデルは、Red Hat OpenShift Virtualization (各ワークロードが完全な仮想マシンを実行している) や AI/ML (各ワークロードが大量の CPU と GPU を消費する) などのリソース集約型のワークロードに最適です。
上記以外のアーキテクチャ (IBM Z、Power)
クラウドネイティブ・アプリケーションおよびマイクロサービスの構築とデプロイの標準として IBM Z および IBM LinuxONE システムと IBM Power Systems を使用している場合、Red Hat OpenShift Container Platform はこれらのプラットフォームで実行することもできます。IBM Z および IBM Power では、コアベースのサブスクリプションモデルのみがサポートされます。
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 つ必要です。パーティショニングを行わないことも可能です。その場合、任意の 3 つの IFL がコントロールプレーン IFL としてカウントされ、残りの IFL は各 OpenShift クラスタインスタンスのコンピューティングノードとしてカウントされます (3 ノードのコンパクトなクラスタデプロイメントで使用される場合を除く)。
OpenShift Container Platform 以外の Red Hat OpenShift Platform Plus コンポーネントは、以下の例外を除いて、現時点では IBM Z および IBM LinuxONE システムや IBM Power Systems ではサポートされていません。
- x86 アーキテクチャで動作する Red Hat Quay のスタンドアローン・サブスクリプションは、IBM Z および IBM Power クラスタを含む複数のアーキテクチャのグローバルレジストリを提供します。Red Hat Quay 自体は IBM Z または Power では動作しません。
- Red Hat Advanced Cluster Management for Kubernetes は、IBM Z または IBM Power 環境にインストール可能であり、IBM Z または IBM Power 環境で稼働する Red Hat OpenShift ノードを管理できます。
- Red Hat OpenShift Data Foundation は、IBM Z または IBM Power でのインストールを完全にサポートします。
Red Hat OpenShift Kubernetes Engine は、IBM Z および IBM LinuxONE システムでも、IBM Power Systems でもサポートされていません。
Microsoft Windows Server コンテナのサポート
セルフマネージド Red Hat OpenShift は Windows コンテナをサポートします。サポートは、インストール・インフラストラクチャと OpenShift 機能のサブセットに限定されます。Windows コンテナは、Microsoft Windows Server ベースのワーカーノードでのみサポートされます。OpenShift 環境のコントロールプレーンとインフラストラクチャ・プレーンは、Red Hat Enterprise Linux または Red Hat Enterprise Linux CoreOS を使用して x86 インフラストラクチャで実行されている必要があります。このため、Windows コンテナのサポートは、コアごとに価格設定されたスタンドアローン・サブスクリプションとして販売されています。
Windows ワーカーノードのデプロイおよび管理は Red Hat OpenShift Platform Plus および Red Hat OpenShift Container Platform インフラストラクチャを使用して行えますが、Red Hat OpenShift サブスクリプションの Windows コンテナのサポートは、別途購入する必要があります。
この個別のサブスクリプション要件は、Bring Your Own Host Support for Windows ノード機能を通じて追加されたコンテナには適用されないことに注意してください。
Red Hat Advanced Cluster Management for Kubernetes および Red Hat Advanced Cluster Security for Kubernetes は、Windows ノードの管理についてはサポートされていませんが、x86 アーキテクチャで動作する Red Hat Quay は、Windows コンテナワーカーノードのコンテナイメージを管理できます。
Red Hat OpenShift Platform Plus コンポーネントのサポート
Red Hat OpenShift Platform Plus サブスクリプションのコンポーネントは、他 (x86 以外) のアーキテクチャと Windows に対して異なるレベルのサポートを提供します。表 1 はそのサポートの概要を示しています。
表 1:Red Hat OpenShift Platform Plus のサポートの概要
Red Hat OpenShift Platform Plus コンポーネント |
IBM System Z | IBM Power | Windows コンテナ | |||
インストール | 管理 |
インストール | 管理 | インストール | 管理 | |
Red Hat OpenShift |
〇 インフラストラクチャ、コントロール、 およびワーカー |
〇 インフラストラクチャ、コントロール、 およびワーカー |
ワーカーのみ (個別の サブスクリプションと Windows ライセンスが必要) |
|||
Red Hat Advanced Cluster Management for Kubernetes |
〇 | 〇 | 〇 | 〇 | × | × |
Red Hat Advanced Cluster Security for Kubernetes |
× | × | × | × | × | × |
Red Hat OpenShift Data Foundation | 〇 | 〇 | 〇 | 〇 | × | × |
Red Hat Quay |
× | 〇 | × | 〇 | × | 〇 |
詳細は、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 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 ノードおよびクラスタを管理することができます。それに加えて Red Hat OpenShift Service on AWS のクラスタも管理する場合は、それらのクラスタをカバーするために、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 Securuity でサポートされているサードパーティの 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 サブスクリプションを別途購入する必要があります。Red Hat Quay は、フルマネージド SaaS 製品としても利用できます。
- Red Hat Data Foundation:OpenShift Platform Plus サブスクリプションを使用すると、OpenShift Platform Plus エンタイトルメントを持つ任意のクラスタに Red Hat Data Foundation Essentials をインストールできます。Red Hat Data Foundation エンタイトルメントは Essentials で利用可能な機能に制限されており、データストレージは OpenShift クラスタ 1 つにつき 256 TB が上限となります。追加のサブスクリプションによって機能と容量を拡張することができます (Red Hat OpenShift Data Foundation プランニングガイドに詳述)。
セルフマネージド Red Hat OpenShift のサイジング
より詳細なサイジングを実施してセルフマネージド OpenShift (Red Hat OpenShift Platform Plus、Red Hat OpenShift Container Platform、または Red Hat OpenShift Kubernetes Engine) またはアドオンのサブスクリプションがいくつ必要であるかを決定するには、以下の質問と例を使用してください。
これらのサイジング方法の説明では、OpenShift に関する以下のような基本用語が使用されています。
- Pod:OpenShift でデプロイ可能な Kubernetes の最小単位です。Kubernetes Pod インスタンスには、サイドカーとして実行されている単一のコンテナまたは複数のコンテナが含まれる場合があります。
- アプリケーション・インスタンス:「アプリケーション」は、単一の Pod インスタンスの場合もあれば、アプリケーションサービスを構成する複数の Pod インスタンスにデプロイされる場合もあります。たとえば、高可用性 Tomcat アプリケーションサービスは、2 つ以上の Tomcat Pod で構成されている場合があります。
- ワーカーノード:エンドユーザー・アプリケーションの Pod が実行される Red Hat Enterprise Linux または Red Hat Enterprise Linux CoreOS のインスタンス (VM またはベアメタルホスト) を指します。OpenShift 環境には、多くのワーカーノードを含めることができます。
- コントロールプレーン・ノード:OpenShift の Kubernetes オーケストレーション/管理レイヤーとして機能する Red Hat Enterprise Linux CoreOS のインスタンス (VM またはベアメタルホスト) を指します。コントロールプレーン・ノードは、セルフマネージド OpenShift サブスクリプションに含まれています。詳細については、「Red Hat OpenShift コントロールプレーンとインフラストラクチャ・ノード」の項を参照してください。
- インフラストラクチャ・ノード:OpenShift のクラスタ・インフラストラクチャをサポートする Pod を実行している、あるいは Ingress トラフィック用に HAProxy ベースのロードバランサーを実行している Red Hat Enterprise Linux または Red Hat Enterprise Linux CoreOS のインスタンス (仮想ホストまたは物理ホスト) を指します。インフラストラクチャ・ノードは、セルフマネージド OpenShift サブスクリプションに含まれています。詳細については、以下の「Red Hat OpenShift コントロールプレーンとインフラストラクチャ・ノード」の項を参照してください。
- クラスタ:コントロールプレーンと 1 つまたは複数のワーカーノードで構成される OpenShift Kubernetes クラスタです。
まとめ
- アプリケーションはコンテナイメージとしてパッケージ化されています。
- コンテナは Pod としてデプロイされます。
- Pod は、Kubernetes コントロールプレーン・ノードによって管理される Kubernetes ワーカーノードで実行されます。
Red Hat OpenShift コントロールプレーンとインフラストラクチャ・ノード
セルフマネージド Red Hat OpenShift の各サブスクリプションは、Red Hat OpenShift、Red Hat Enterprise Linux、および他の OpenShift 関連コンポーネントに対する追加のエンタイトルメントを提供します。これらの追加のエンタイトルメントは、OpenShift コントロールプレーンおよびインフラストラクチャ・ノードを実行する目的で含まれています。
Red Hat OpenShift Platform Plus サブスクリプションには、Red Hat Advanced Cluster Security for Kubernetes および Red Hat Advanced Cluster Management for Kubernetes によるこれらのコントロールプレーンとインフラストラクチャ・ノードの管理が含まれます。
インフラストラクチャ・ノード
OpenShift インストーラーは、エンドユーザー・アプリケーションを実行するための OpenShift ワーカーノードに加えて、3 つのコントロールプレーン・ノードで構成される、可用性の高い OpenShift コントロールプレーンをデプロイします。デフォルトでは、Kubernetes コントロールプレーン・コンポーネント (API サーバー、etcd、スケジューラーなど) とサポートするクラスタサービス (モニタリング、レジストリなど) が OpenShift コントロールプレーン・ノードにデプロイされます。ただしお客様によっては、これらのサポートするクラスタサービスの一部を専用のインフラストラクチャ・ノードに移行したい場合があります。
インフラストラクチャ・ノードとしての権限を取得し、含まれているエンタイトルメントを使用するためには、クラスタをサポートしており、エンドユーザー・アプリケーションの一部ではないコンポーネントのみをそれらのインスタンスで実行します。以下はその例です。
- OpenShift レジストリ
- OpenShift Ingress ルーター (ローカルおよびグローバル/マルチクラスタ Ingress)
- OpenShift モニタリング
- OpenShift ログ管理
- クラスタ Ingress に使用される HAProxy ベースのインスタンス
- Red Hat Quay
- Red Hat OpenShift Data Foundation (旧称 Red Hat OpenShift Container Storage)
- Red Hat Advanced Cluster Management for Kubernetes
- Red Hat Advanced Cluster Security for Kubernetes
- Red Hat OpenShift GitOps
- Red Hat OpenShift Pipelines
インフラストラクチャ・ライセンスのノードの権限を削除することなく、モニタリング、ログデータの収集と転送、ハードウェアドライバー、仮想化エージェントのようなインフラストラクチャ統合などのカスタムエージェントやサードパーティ・エージェントとツールをインフラストラクチャ・ノードにデプロイして実行することができます。ただし、これはエージェントと、オペレーター用のコントローラー Pod などの関連コンポーネントのみに限定され、カスタムまたはサードパーティのソフトウェアスイートは含まれません。インフラストラクチャ・ワークロードに該当する Red Hat 以外のソフトウェアの例としては、次のようなものがあります。
- カスタムおよびサードパーティのモニタリングエージェント
- コンテナ・ネットワーク・インタフェース (CNI) およびコンテナ・ストレージ・インタフェース (CSI) のドライバーとコントローラー (プラグイン)
- ハードウェアまたは仮想化を有効にするためのアクセラレーター
- Kubernetes CRD または Operator に使用されるコントローラー Pod (カスタムまたはサードパーティ・ソフトウェア)
追加で含まれているエンタイトルメントを使用する場合、インフラストラクチャ・ノード上で他のエンドユーザー・アプリケーション・インスタンスまたはタイプを実行することはできません。Red Hat OpenShift で他のインフラストラクチャ・ワークロードをアプリケーション・インスタンスとして実行するには、それらのインスタンスを通常のアプリケーション・ノードで実行する必要があります。アプリケーションまたはサービスがインフラストラクチャ・ワークロードに該当するかどうかは、Red Hat に確認できます。
承認されているインフラストラクチャ・ノードの追加使用
エンドユーザーによる Red Hat OpenShift の使用が増えていくと、より高度なアプリケーション・デプロイメント・パターンを使うようになる可能性があります。その結果、プラットフォームへのソフトウェア・コンポーネントの追加が必要になる場合があります。一般原則として、Red Hat OpenShift サブスクリプションは、ワーカーノードにデプロイされたアプリケーション・ワークロードとそれらのアプリケーションをサポートするサービスを実行するために必要な Red Hat OpenShift ワーカーノードの総容量に基づいています。プラットフォームの機能、またはアプリケーション・ワークロードをデプロイする機能を拡張するために使用される Red Hat OpenShift コントロールプレーン・ノードおよびコンポーネントは、Red Hat OpenShift コントロールプレーン・ノードで実行するか、またはユーザーが構成したエンタイトルメントを必要としない追加インフラストラクチャ・ノードで実行できます。該当する場合、エンドユーザーは、該当ノードをインフラストラクチャ・ライセンスの対象外とすることなく、インフラストラクチャ・ノードを使用してこれらのソフトウェア・コンポーネントを収容できます。以下はその例です。
- CNI および CSI のドライバーとコントローラー (プラグインとも呼ばれる)
- ハードウェアまたは仮想化を有効にするためのアクセラレーター (Special Resource Operator または Node Feature Discovery Operator に関連)
- クラウドまたは仮想化エージェント
サードパーティの管理およびモニタリング製品
クラスタモニタリング、クラスタロギング、高度なクラスタ管理、高度なクラスタセキュリティなど、Red Hat が提供するモニタリングおよび管理機能を使用して Red Hat OpenShift を管理することを望まないお客様もいます。あるいは、これらの管理機能を追加のソリューションで強化したい場合もあるかもしれません。Red Hat は、このような場合にそれらのソリューション (カスタム・ソリューションでも、サードパーティベンダーから購入したものでも) のソフトウェア・コンポーネントが Red Hat OpenShift 内のインフラストラクチャ・ラベルを使用できるようにしており、フレームワークの負荷に対してワーカーノードのコアをカウントする必要はありません。これらのソフトウェア・ソリューションは、Red Hat OpenShift のモニタリング、アラート、セキュリティスキャン、構成管理、およびその他の Day 2 管理タスクのいくつかのユースケースに関連している場合があります。これらは、プラットフォームで実行されているエンドユーザー・アプリケーションではなく、Red Hat OpenShift の管理とモニタリングにのみ使用されるべきものです。
このセクションで説明している以外のインフラストラクチャ・ノードで、他のエンドユーザー・アプリケーションを実行することはできません。必要に応じて、お客様のソフトウェアのインフラストラクチャ・ノード・ステータスの必要条件を Red Hat テクニカルサポートに確認できます。
コントロールプレーン・ノード
OpenShift Kubernetes コントロールプレーン・ノードは一般にワーカーノードとして使用されず、デフォルトではアプリケーション・インスタンスを実行しません。しかし、エンドユーザー・アプリケーションをホストするノードとしてコントロールプレーン・ノードを使用することができます。コントロールプレーン・ノードが完全な OpenShift サブスクリプションを必要とするかどうかは、OpenShift クラスタ・コンポーネントのみをサポートして実行するか、エンドユーザー・アプリケーションを実行するかによって異なります。詳細は、「インフラストラクチャ・ノード」セクションを参照してください。
3 ノードのコンパクトなクラスタでは、エンドユーザー・アプリケーションのワークロードはコントロールプレーン・ノードで実行されます。これには特別な価格設定はありません。3 つのノードのコアは、それらが果たす役割に関係なくカウントされます。
コンテナレジストリのブートストラップによる OpenShift コンテナイメージのミラーリング
OpenShift のミラーレジストリは、切断された OpenShift クラスタのブートストラップに必要なコンテンツをミラーリングするプロセスを容易にすることを唯一の目的とした Quay エンタイトルメントであり、OpenShift サブスクリプションの一部として含まれています。これは、特定のインストーラーによって作成される最小限の Quay デプロイメントに対する限定的なサポートのエンタイトルメントで、お客様が管理する事前プロビジョニング済みの Red Hat Enterprise Linux 8 ホストで Quay レジストリを実行できます。
注:OpenShift リリースペイロード、OperatorHub コンテンツ、Operator のサンプルイメージ、および Cincinnati グラフイメージをミラーリングする目的に限定されたレジストリミラーとして Quay を使用することが許可されています。
OpenShift のミラーレジストリは、任意の規模で機能する汎用レジストリを意図したものではありません。しかし、一定限度のカスタムイメージのセットを保存することが許可されており、それには必須の補助ソフトウェアのようなエージェントが含まれます。これらのエージェントは、ノードレベルのみを対象とする必要があり、外部向けのアプリケーションサービスそのものを提供することはできません。また、エンドユーザーが直接これらのエージェントを操作することはありません。これらの例として、次のようなものがあります。
- 監視エージェント
- CNI/CSI プロバイダー
- ハードウェアまたは仮想化を有効にするためのエージェント
- ISV サービスをサポートするオペレーター
- デプロイメント・コントローラーとしてのカスタムオペレーター
セルフマネージド Red Hat OpenShift の初期デプロイメントの例
以下の BOM の例は、VM 上での動作を想定して設計された、極めて柔軟かつスケーラブルな Red Hat OpenShift 環境を提供し、数百のアプリケーション・コンテナをサポートします。
- OpenShift Platform Plus × 16 (2 コア Premium サブスクリプション):以下のものが含まれます。
- コントロールプレーン・ノード (VM × 3)
- 追加のインフラストラクチャ・ノード (VM × 3)
- ワーカーノード (2 コアまたは 4 vCPU でサイジングされた VM × 16)
- マルチクラスタ管理、高度な可観測性、およびポリシー準拠
- 宣言型のセキュリティと能動的な脅威の検出および対応
- スケーラブルなグローバル・コンテナ・レジストリ
- アプリケーションおよび OpenShift インフラストラクチャ・サービス用の永続ストレージ
任意:
- Red Hat OpenShift Data Foundation Advanced × 16:強化されたスケーラビリティ、粒度が小さい暗号化、障害復旧機能、データセキュリティのほか、OpenShift インフラストラクチャ・サービスに加えて、Red Hat OpenShift 内にデプロイされたワークロードのファイル、ブロック、およびオブジェクトストレージ・サービス向けの回復力のあるブロックとファイルを追加します。これは、永続ストレージを必要とするステートフル・アプリケーションを実行しているお客様、または複数の OpenShift クラスタが共有する専用の外部ストレージクラスタの構築と運用を行いたいお客様向けの任意のアドオンです。Red Hat OpenShift Data Foundation Advanced は、Red Hat OpenShift Data Foundation Advanced を含む Red Hat OpenShift Platform Plus というバンドルの一部としても利用できます。
Red Hat は、独自のサブスクリプション・モデルと消費モデルを持つ多くのアプリケーションサービスおよびランタイムも提供します。
サイジングのプロセス
Red Hat OpenShift サブスクリプションにアプリケーション・インスタンス数の制限はありません。Red Hat OpenShift 環境では、基礎となるハードウェアとインフラストラクチャがサポートできる限りの数のアプリケーション・インスタンスを実行できます。大容量ハードウェアは少数のホスト上で多くのアプリケーション・インスタンスを実行できますが、小容量ハードウェアで多数のアプリケーション・インスタンスを実行するには多くのホストが必要となります。OpenShift 環境のサイズを決定する主な要因は、任意の時点で実行される Pod またはアプリケーション・インスタンスの数です。
ステップ 1:標準 VM またはハードウェアコアとメモリーを決定する
企業では、アプリケーション・インスタンス用の標準的な VM 容量や、(通常ベアメタルにデプロイする場合は) 標準的なサーバー構成が決まっている場合があります。VM とハードウェアに関するニーズをより正確に理解するためには、以下の質問が役立ちます。ほとんどの場合、2 つの vCPU は 1 つのコアに相当します。
表 2:VM およびハードウェアのサイジングに関する質問
関連する質問 | 回答例 |
ノードに使用する VM のメモリー容量はどれくらいですか? ノードに使用する VM の vCPU の数はいくつですか? ハイパースレッディングは使用していますか? |
VM はそれぞれ 64GB のメモリと 4 つの vCPU を備えており、ハイパースレッディングが使用されています。 |
ステップ 2:必要なアプリケーション・インスタンスの数を計算する
次に、デプロイする予定のアプリケーション・インスタンス (Pod) の数を決定します。環境のサイジングの際、Red Hat OpenShift にデプロイされたアプリケーション・コンポーネントは、すべてアプリケーション・インスタンスとみなされます。これには、データベース、フロントエンドの静的サーバー、およびメッセージブローカー・インスタンスなどが含まれます。
この数値はおおよその推定値でよく、Red Hat OpenShift 環境サイズの総見積もりを計算するために役立ちます。CPU、メモリー・オーバーサブスクリプション、クォータとリミット、およびその他の機能を使用して、この見積もりをさらに絞り込むことができます。
表 3:VM およびハードウェアのサイジングに関する質問
関連する質問 | 回答例 |
各 Red Hat OpenShift 環境でどの程度の数のアプリケーション・インスタンスをデプロイする予定ですか? それらはどのような種類のアプリケーションですか? (言語、フレームワーク、データベースなど) |
開発環境には約 1,250 のアプリケーション・インスタンスが存在し、プロダクション環境には約 250 のアプリケーション・インスタンスが存在します。 主に Java アプリケーションをデプロイしますが、Microsoft.NET Core および Ruby アプリケーションもあります。また MySQL も多用します。 |
ステップ 3:推奨される最大 OpenShift ノード使用率を決定する
需要が増えた場合、特にワークロードのオートスケーリングが有効になっている場合には、スペースを確保することをお勧めします。推奨される使用率は、OpenShift 上で実行されるアプリケーションの履歴負荷に基づいて異なります。
表 4:推奨される最大 OpenShift ノード使用率に関する質問
関連する質問 | 回答例 |
需要増加に備えてどの程度のスペースを確保しておきたいですか? | 総容量の最大平均 80% (20% を予備として残す) でノードを稼働させたいと考えています。 |
ステップ 4:合計メモリー・フットプリントを決定する
次に、デプロイされたアプリケーションの合計メモリー・フットプリントを計算します。全く新しい環境を検討している場合はメモリー使用量データを利用できないケースもありますが、「Java アプリケーション・インスタンス 1 つあたり 1GB のメモリ」などの経験に基づく近似値を使用して見積もりを行うことができます。
表 5:OpenShift のメモリー・フットプリントに関する質問
関連する質問 | 回答例 |
アプリケーションのメモリー・フットプリントの平均値はどのくらいですか? |
アプリケーションインスタンスは 2GB 以下のメモリーを使用します。 または 通常、JVM ヒープには 2GB を割り当てます。 |
ステップ 5:合計を計算する
ステップ 1 - 4 で収集したデータに基づき、必要な OpenShift サブスクリプションの数を特定します。
-
有効なノード単位のメモリー容量 (GB)
= 推奨される最大 OpenShift ノード使用率 (%) × 標準 VM またはハードウェアメモリー -
合計メモリー使用率
= アプリケーション・インスタンス数 × アプリケーション・メモリー・フットプリント平均 -
使用率をカバーするために必要なノード数
= 合計メモリー使用率 × VM またはハードウェアの標準メモリー容量 -
必要なコア数の合計
= 使用率をカバーするために必要なノード数 × 標準 VM またはハードウェアコア数 -
有効な仮想コア数
= 必要なコア数の合計 ÷ 2OpenShift Platform Plus サブスクリプションの数1
-
= 合計コア数 ÷ 2 または
= 有効な仮想コア数 ÷ 2
仮想化環境の計算例
システムサイジング (ステップ 1 - 5)
- VM コアの標準数 = 4 (ハイパースレッディング使用、有効な仮想コア数 2)
- 標準 VM メモリー = 64GB
- 推奨される最大ノード使用率 = 80%
- アプリケーション・メモリー・フットプリント平均 = 2GB
- アプリケーション・インスタンス数 = 1500
サブスクリプションの計算
- 有効なノードメモリー容量
- 推奨されるノード使用率 80% × 標準 VM メモリー 64GB
- 51GB
- 合計メモリー使用率
- アプリケーション・インスタンス数 1500 × アプリケーション・メモリー・フットプリント平均 2GB
- 3000GB
- 使用率をカバーするために必要なノード数
- 合計メモリー使用率 3000GB ÷ 有効なノードメモリー容量 51GB
- ノード数 59
- 合計コア数
- 必要なノード数 59 × 1 ノードあたりのコア数 2
- 合計コア数 118
- 合計サブスクリプション数
- 合計コア数 118 ÷ 1 サブスクリプションあたりのコア数 2
- サブスクリプション数 59
この例では、OpenShift Platform Plus の 2 コア・サブスクリプションの必要数は 59 となります。
注:
Red Hat OpenShift は、スケーラビリティ、オーバーコミット、アイドリング、リソースクォータや制限などに関するさまざまな機能をサポートしています。上記の計算は目安であり、実際の環境に合わせて調整することで、リソース使用率の改善や、全体の環境サイズの縮小を実現できる場合があります。OpenShift Platform Plus を使用する場合、追加のワーカー・サブスクリプションが必要なくても、ストレージやコンピューティング・リソースなどの追加のソフトウェア・アプリケーション (Red Hat Advanced Cluster Management、Red Hat Advanced Cluster Security、および Quay) の必要性を考慮するべきです。
サードパーティのリセラーと連携する場合は、そのリセラーが Red Hat 製品およびサービスに関して定めている条件と契約を参照してください。
ハイパースレッディングが使用されている場合、2 つの仮想コアは、サブスクリプションの 1 コアとしてカウントされます。この計算で実効コア数と実際のコア数のいずれを使用するかについて詳しくは、「ハイパースレッディングについて:コアと vCPU」セクションを参照してください。