Red Hat OpenShift Container Storage は主に 3 つの Operator で構成されており、管理タスクとカスタムリソースをコード化し、タスクおよびリソースの特性をより簡単に自動化できるようにします。管理者はクラスターの必要な最終状態を定義し、OpenShift Container Storage Operator は管理者の介入を最小限に抑えてクラスターをその状態にするか、またはその状態に近づけるようにします。

さらに、内部モードクラスターの場合、以下を表すデプロイメントおよびサービスを管理する Ceph クラスターリソースを提供します。

さらに、これは NooBaa クラスターリソースを提供します。このクラスターリソースは、NooBaa コア、データベースおよびエンドポイントのデプロイメントとサービスを管理します。

柔軟性は、複数モード (operating modalities) 一覧の拡張によって確認されるように Red Hat OpenShift Container Storage の中心的な特徴です。本セクションでは、お使いの環境に最も適した方法を選択するのに役立つ情報を提供します。OpenShift Container Storage は OpenShift Container Platform 内で完全にデプロイ (内部アプローチ) することも、OpenShift Container Platform 外で実行されるクラスターからサービスを利用可能する方法 (外部アプローチ) を実行することもできます。

ノードはコンテナーランタイムとサービスを実行し、コンテナーが実行中の状態にし、Pod 間のネットワーク通信および分離を保ちます。OpenShift Container Storage には、3 種類のノードがあります。

FIPS-140-2 (Federal Information Processing Standard Publication 140-2) は、暗号モジュールの使用についての一連のセキュリティー要件を定義する標準です。この標準は、米国の政府機関や請負業者に対して法律で義務付けられており、他の国際標準および業界固有の標準でも参照されています。

Red Hat OpenShift Container Storage は、Red Hat Enterprise Linux OS/CoreOS (RHCOS) によって配信される FIPS で検証済みの暗号モジュールを使用するようになりました。

現時点で、暗号モジュールは Cryptographic Module Validation Program (CMVP) によって処理され、それらの状態は Modules in Process List で確認できます。最新の情報は、ナレッジベースのアーティクルを参照してください。

詳細は、「installing a cluster in FIPS mode」および「support for FIPS cryptography」を参照してください。

プロキシー環境は、インターネットへの直接アクセスを拒否し、代わりに利用可能な HTTP または HTTPS プロキシーを提供する実稼働環境です。Red Hat Openshift Container Platform は、既存クラスターのプロキシーオブジェクトを変更するか、または新規クラスターについて install-config.yaml ファイルでプロキシーを設定してプロキシーを使用するように設定されます。

Red Hat では、OpenShift Container Platform がクラスター全体のプリキシーの設定に応じて設定されている場合に、プロキシー環境での Openshift Container Storage バージョン 4.5 以上のデプロイメントをサポートします。

Red Hat OpenShift Container Storage のサブスクリプションは、OpenShift Container Platform と同様に「コアのペア」をベースとして提供されます。Red Hat OpenShift Container Storage 2 コアサブスクリプションは、OpenShift Container Platform が実行されるシステムの CPU 上の論理コア数をベースとしています。

以下の点は、OpenShift Container Platform と同様です。

Red Hat OpenShift Container Storage は、障害復旧 (DR)、コールドバックアップその他のサブスクリプションタイプを提供しません。OpenShift Container Storage がインストールされたシステムでは、電源がオン/オフであるか、ワークロードを実行中かどうかにかかわらず、アクティブなサブスクリプションが必要になります。

現時点で特定のシステムが 1 つまたは複数のコアを消費するかどうかについての決定は、そのシステムでハイパースレッディング機能を利用できるかどうかによって異なります。ハイパースレッディングは Intel CPU のみの機能です。Red Hat カスタマーポータルにアクセスし、特定のシステムがハイパースレッディングをサポートしているかどうかを判断します。

ハイパースレッディングが有効にされており、1 つのハイパースレッドが 1 つの利用可能なシステムコアに等しいシステムの場合、コアの計算 は 2 コア対 4 vCPU の比率になります。したがって、2 コアのサブスクリプションは、ハイパースレッドシステムの 4 vCPU に対応します。大規模な仮想マシン (VM) には、4 サブスクリプションコアに相当する 8 vCPU がある場合があります。サブスクリプションは 2 コア単位で提供されるため、4 コアまたは 8 vCPU に対応するには 2 つの 2 コアサブスクリプションが必要になります。

ハイパースレッディングが有効にされていない場合や、表示される各システムのコアが基礎となる物理コアに直接相関する場合、コアの計算は 2 コア対 2 vCPU の比率になります。

奇数のコアを必要とするシステムの場合でも、2 コアのサブスクリプションを使用する必要があります。たとえば、1 コアのみを必要とするように計算されたシステムは、登録およびサブスクライブ後に 2 コアのサブスクリプションすべてを使用します。

2 vCPU を持つ単一の仮想マシン (VM) がハイパースレッディング機能を使用し、1 vCPU が計算される場合、2 コアサブスクリプションが必要になります。単一の 2 コアサブスクリプションは、ハイパースレッディングを使用する 2 vCPU を持つ 2 仮想マシン間で分割することはできません。詳細は、「コア対 vCPU およびハイパースレッディング」のセクションを参照してください。

そのため、仮想インスタンスは偶数のコアを必要とするようにサイズ設定することが推奨されます。

OpenShift Container Storage コンポーネントは、Red Hat CoreOS (RHCOS) または Red Hat Enterprise Linux (RHEL) 7 のいずれかをホストのオペレーティングシステムとして使用できる OpenShift Container Platform ワーカーまたはインフラストラクチャーノードのいずれかで実行できます。ワーカーノードが OpenShift Container Storage コンポーネントに使用される場合、それらのノードには OpenShift Container Platform と OpenShift Container Storage の両方のサブスクリプションが必要です。インフラストラクチャーノードが使用される場合、それらのノードには OpenShift Container Storage サブスクリプションのみが必要となります。ラベルは、ノードをワーカーノードまたはインフラストラクチャーノードとみなされるようにするどうかを示唆するために使用されます。

Red Hat OpenShift Container Storage は、OpenShift Container Storage バージョンより 1 マイナーリリース前または先の OpenShift Container Platform リリースと組み合わせることができます。

OpenShift Container Storage 4.5 は以下で実行できます。

外部クラスターの場合、OpenShift Container Platform バージョン 4.5 以降は Red Hat OpenShift Container Storage 4.5 をデプロイするために必要です。外部クラスターのサブスクリプション要件については、この Red Hat ナレッジベースアーティクルを参照してください。

サポートされているプラットフォームのバージョンについての詳細の一覧は、「Red Hat OpenShift Container Storage and Red Hat OpenShift Container Platform interoperability matrix」を参照してください。

OpenShift Container Storage サービスは、ベースサービスの初期セットとこれに続く追加のデバイスセットで構成されます。これらの OpenShift Container Storage サービス Pod はすべて 「Pod の配置ルール」 に応じて OpenShift Container Platform ノードの kubernetes によってスケジュールされます。

例: 単一デバイスセットを持つ 3 ノードクラスターの場合、最小の 3 x 10 = 30 ユニットの CPU が必要です。CPU の 30 ユニットは 15 コアに相当し、これは Red Hat OpenShift Container Storage（2 コア）の ~8 サブスクリプションに相当します。

詳細は、6章サブスクリプション および「CPU ユニット」を参照してください。

Kubernetes は、宣言型の配置ルールに基づいて Pod の配置を行います。内部クラスターの OpenShift Container Storage ベースサービスの配置ルールは、以下のように要約できます。

これにより、少なくとも 3 つのノードがあり、既存のトポロジーラベルが存在する場合にノードは 3 つの異なるラックまたはゾーン障害ドメインにある必要があります。

追加のデバイスセットについては、3 つの障害ドメインのそれぞれにストレージデバイスがあり、Pod が消費するのに十分なリソースが必要になります。手動の配置ルールはデフォルトの配置ルールを上書きするのに使用できますが、通常この方法はベアメタルのデプロイメントにのみ適しています。

このセクションでは、内部モードのデプロイメントおよびアップグレードの計画時に考慮できる各種のストレージ容量の要件について説明します。通常、ノードごとに 9 以下のデバイスが推奨されます。この推奨事項により、ノードがクラウドプロバイダーの動的ストレージデバイスの割り当て制限下にあり、ローカルストレージデバイスに関連してノードに障害が発生した後の復旧時間を制限することができます。クラスターを（障害ドメインごとに 1 ノードの）3 の倍数に拡張する方法は、Pod の配置ルールに簡単に従える方法です。