odf-operatorは、ocs-operator パッケージに依存しています。また、mcg-operator のサブスクリプションも管理します。さらに、odf-operator バンドルは、OpenShift Console 用の OpenShift Data Foundation 外部プラグインの 2 番目のデプロイメントを定義します。これは、OpenShift Data Foundation ダッシュボードを OpenShift Container Platform Console に直接登録および統合するために必要なファイルを提供する nginx ベースの Pod を定義します。

この図は、odf-operator が OpenShift Container Platform にどのように統合されているかを示しています。

図3.1 OpenShift Data Foundation Operator

odf-operator は、次の CRD を定義します。

StorageSystem CRD は、OpenShift Container Platform にデータストレージとサービスを提供する基盤となるストレージシステムを表します。これにより、オペレーターは、特定の 種類 のストレージシステムの サブスクリプション が存在することを確認します。

ocs-operator は、特定の StorageSystem の仕様に応じて、次の CR を作成します。

odf-operator は、データストレージやサービス自体を提供しません。これは、他のストレージシステムの統合および管理レイヤーとして存在します。

高可用性は、他のほとんどの Operator と同様、odf-operator Pod の主な要件ではありません。通常、プロセスのディストリビューションに必要な操作や利点はありません。OpenShift Container Platform は、現在の Pod が利用できなくなるか、または削除されるたびに、置換 Pod を迅速に立ち上げます。

odf-operator には、演算子の動作を変更するのに使用できる変数の ConfigMap が付属しています。

OpenShift Data Foundation の問題の理解を深めるには、以下を確認してください。

OpenShift Data Foundation バンドルがインストールされている限り、odf-operator が存在する必要があります。これは OpenShift Data Foundation CSV の OLM の調整の一部として管理されます。Pod の少なくとも 1 つのインスタンスが Ready 状態にある必要があります。

CRD などの Operator オペランドは Operator のライフサイクルには影響しません。StorageSystems の作成と削除は、オペレーターの制御外の操作であり、管理者が開始するか、適切なアプリケーションプログラミングインターフェイス (API) 呼び出しで自動化する必要があります。

ocs-operator には依存コンポーネントがありません。ただし、Operator には、ClusterServiceVersion (CSV) で定義される他の Operator からすべてのカスタムリソース定義 (CRD) の存在に依存しています。

この図は、OpenShift Container Storage が OpenShift Container Platform とどのように統合されているかを示しています。

図3.2 OpenShift Container Storage Operator

2 つの ocs-operator CRD は次のとおりです。

OCSInitialization は、Operator レベルで適用されるカプセル化操作に使用されるシングルトン CRD です。オペレーターは、1 つのインスタンスが常に存在することを確認します。CR は以下をトリガーします。

StorageCluster CRD は、OpenShift Container Storage の全機能を提供するシステムを表します。これは Operator をトリガーし、CRD Rook-Ceph および NooBaa の生成および調整を行うことができます。ocs-operator アルゴリズムは、StorageCluster 仕様の設定に基づいて CRD CephCluster および NooBaa を生成します。Operator は CephBlockPools、Routes などの追加の CR も作成します。これらのリソースは、OpenShift Container Storage のさまざまな機能を有効にするのに必要です。現時点で、OpenShift Container Platform クラスターごとに 1 つの StorageCluster CR のみがサポートされます。

ocs-operator は、定義する CRD の仕様に応じて、次の CR を作成します。これらのリソースの一部の設定は上書きでき、生成された仕様の変更を許可したり、新規に作成しなくて済むようにできます。

ocs-operator は OpenShift Data Foundation の他の Pod をデプロイしたり、調整したりしません。ocs-operator CSV は、Operator Deployment および Operator Lifecycle Manager (OLM) などの最上位のコンポーネントを定義します。

高可用性は、他のほとんどの Operator と同様、ocs-operator Pod の主な要件ではありません。通常、プロセスのディストリビューションに必要な操作や利点はありません。OpenShift Container Platform は、現在の Pod が利用できなくなるか、または削除されるたびに、置換 Pod を迅速に立ち上げます。

ocs-operator 設定は CSV によって完全に指定され、CSV のカスタムビルドなければ変更することができません。

OpenShift Container Storage を理解し、問題のトラブルシューティングを行うには、以下を参照してください。

OpenShift Container Storage バンドルがインストールされている限り、ocs-operator が存在する必要があります。これは、OLM による OpenShift Container Storage CSV の調整の一部として管理されます。Pod の少なくとも 1 つのインスタンスが Ready 状態にある必要があります。

CRD などの Operator オペランドは Operator のライフサイクルには影響しません。OCSInitialization CR は常に存在しているはずです。Operator が存在しない場合はこれを作成します。StorageClusters の作成および削除は Operator の制御外の操作であり、管理者によって開始するか、または適切な API 呼び出しによって自動化される必要があります。

Rook-Ceph Operator は、OpenShift Data Foundation デプロイメントの一部として多数のコンポーネントを管理します。

以下の図は、Ceph Rook を OpenShift Container Platform と統合する方法を示しています。

図3.3 Rook-Ceph Operator

OpenShift Container Platform クラスターで Ceph が実行されている場合、OpenShift Container Platform アプリケーションは、Rook-Ceph によって管理されるブロックデバイスおよびファイルシステムをマウントしたり、オブジェクトストレージに S3/Swift API を使用できます。

Rook-Ceph Operator は、ストレージクラスターをブートストラップし、監視するコンテナーです。以下の機能を実行します。

Rook-Ceph Operator イメージには、クラスターを管理するのに必要なすべてのツールが含まれます。データパスへの変更はありません。ただし、Operator はすべての Ceph 設定を公開しません。配置グループやクラッシュマップなどの Ceph 機能の多くはユーザーに表示されなくなり、物理リソース、プール、ボリューム、ファイルシステム、およびバケットにおけるユーザーエクスペリエンスが改善されました。

Rook-Ceph Operator は、openshift-storage namespace に作成するすべてのリソースに所有者参照を追加します。クラスターがアンインストールされると、所有者参照により、リソースがすべてクリーンアップされるようにします。これには、configmaps、secrets、services、deployments, daemonsets などの OpenShift Container Platform リソースが含まれます。

Rook-Ceph Operator は CR を監視し、CephCluster、CephObjectStore、CephFilesystem、CephBlockPool などの OpenShift Data Foundation によって決定されます。

Rook-Ceph Operator は、Ceph クラスターで以下の Pod のライフサイクルを管理します。

MCG オペレーターには、サブコンポーネントがありません。ただし、これは、それによって制御されるさまざまなリソースの調整ループで設定されます。

MCG Operator にはコマンドラインインターフェイス (CLI) があり、OpenShift Data Foundation の一部として利用できる。これにより、各種リソースの作成、削除、およびクエリーが可能になります。この CLI は、YAML ファイルを直接適用するのではなく、設定が適用される前に、入力サニタイテーションおよびステータス検証のレイヤーを追加します。

MCG Operator はカスタムリソース定義 (CRD) および OpenShift Container Platform エンティティーについて調整されます。

デフォルトのバッキングストアは、OpenShift Container Platform が実行しているプラットフォームに応じてデプロイメントの一部として作成されます。たとえば、OpenShift Container Platform または OpenShift Data Foundation が Amazon Web Services (AWS) にデプロイされる場合は、AWS::S3 バケットであるデフォルトのバッキングストアになります。同様に、Microsoft Azure の場合、デフォルトのバッキングストアは Blob コンテナーなどです。

デフォルトのバッキングストアは、OpenShift Container Platform に含まれるクラウド認証情報 Operator の CRD を使用して作成されます。MCG に追加できるバッキングストアの量に制限はありません。バッキングストアは、バケットの異なるポリシーを定義するためにバケットクラス CRD で使用されます。バッキングストアとしてサポートされるサービスまたはリソースのタイプを特定するには、特定の OpenShift Data Foundation バージョンのドキュメントを参照してください。

デフォルトのバケットクラスはデプロイメント中に作成され、デフォルトのバッキングストアを使用する配置ポリシーで設定されます。追加できるバケットクラスの数に制限はありません。

サポート対象のポリシーの種類を特定するには、特定の OpenShift Data Foundation バージョンのドキュメントを参照してください。

Operator として提供される唯一の高可用性は、OpenShift Container Platform が障害のある Pod を再スケジュールすることです。

NooBaa Operator の問題のトラブルシューティングを行うには、以下を確認します。

MCG オペレーターは、OpenShift Data Foundation がデプロイされた後、実行および調整が行われてからアンインストールされます。

内部ストレージクラスターと内部接続ストレージクラスターの両方で、次のような同じセットアッププロセスがあります。

外部ストレージクラスターの場合、ocs-operator はわずかに異なるセットアッププロセスに従います。ocs-operator は、rook-ceph-external-cluster-details ConfigMap の存在を探しますが、これは管理者かコンソールのどちらか他の人が作成したものでなければなりません。ConfigMap の作成方法については、Creating an OpenShift Data Foundation Cluster for external mode を参照してください。次に、ocs-operator は、ConfigMap で指定されているように、次のリソースの一部またはすべてを作成します。

ConfigMap で指定されたリソースを作成した後、StorageCluster の作成プロセスは次のように進行します。

QuickStarts: コンソールにクイックスタートガイドを表示する Quickstart CR を作成します。

このモードでは、CephCluster は作成されません。代わりに、デフォルト値を使用して NooBaa システム CR が作成され、OpenShift Container Platform ダッシュボードの既存の StorageClasses を利用します。