4.3. ストレージクラスターの作成

OpenShift Data Foundation オペレーター自体はストレージ機能を提供しないため、必要なストレージ設定を定義する必要があります。

オペレーターをインストールした後、OpenShift Container Platform コンソールウィザードまたは CLI のいずれかを使用して、新しい StorageCluster を作成し、ocs-operator がこの StorageCluster を調整します。OpenShift Data Foundation は、インストールごとに 1 つの StorageCluster をサポートします。最初の CR の後に作成された StorageCluster CR は、ocs-operator によって無視されます。

OpenShift Data Foundation では、以下の 3 つの StorageCluster 設定が可能です。

内部
内部モードでは、すべてのコンポーネントが OpenShift Container Platform クラスター内でコンテナー化されて実行され、インストールウィザードで管理者が指定した StorageClass に対して作成された、動的にプロビジョニングされた永続ボリューム (PV) を使用します。
内部割り当て
このモードは内部モードに似ていますが、管理者は、Ceph がバッキングストレージに使用するクラスターノードに直接接続されているローカルストレージデバイスを定義する必要があります。また、管理者は、ローカルストレージオペレーターが StorageClass を提供するために調整する CR を作成する必要があります。ocs-operator は、この StorageClass を Ceph のバッキングストレージとして使用します。
外部
このモードでは、Ceph コンポーネントは OpenShift Container Platform クラスター内で実行されません。代わりに、アプリケーションが PV を作成できる外部の OpenShift Container Storage インストールへの接続が提供されます。他のコンポーネントは、必要に応じてクラスター内で実行されます。

MCG スタンドアロン: このモードでは、CephCluster を伴わずに Multicloud Object Gateway システムを簡単にインストールできます。

StorageCluster CR が見つかった後、ocs-operator はそれを検証し、ストレージコンポーネントを定義するための後続のリソースの作成を開始します。

4.3.1. 内部モードストレージクラスター

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

StorageClasses

クラスターアプリケーションが Ceph ボリュームの作成に使用するストレージクラスを作成します。

SnapshotClasses

クラスターアプリケーションが Ceph ボリュームのスナップショットを作成するのに使用するボリュームスナップショットクラスを作成します。

Ceph RGW 設定

さまざまな Ceph オブジェクト CR を作成して、Ceph RGW オブジェクトストレージエンドポイントへのアクセスを有効にして提供します。

Ceph RBD 設定

CephBlockPool CR を作成して、RBD ストレージを有効にします。

CephFS 設定

CephFilesystem CR を作成して、Ceph FS ストレージを有効にします。

Rook-Ceph 設定

基礎となる Ceph クラスターの全体的な動作を管理する rook-config-override ConfigMap を作成します。

CephCluster

Ceph Cluster CR を作成して、rook-ceph-operator から Ceph 調整をトリガーします。詳細については、Rook-Ceph オペレーター を参照してください。

NoobaaSystem

NooBaa CR を作成して、mcg-operator からの調整をトリガーします。詳細については、MCG オペレーター を参照してください。

ジョブテンプレート

OpenShift Container Storage の管理操作を実行するジョブを定義するOpenShift テンプレート CR を作成します。

クイックスタート

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

4.3.1.1. クラスターの作成

ocs-operatorCephCluster CR を作成した後、rook-operator は目的の設定に従って Ceph クラスターを作成します。rook-operator は、次のコンポーネントを設定します。

Ceph mon デーモン

3 つの Ceph mon デーモンは、クラスター内の異なるノード上で開始しています。これらは Ceph クラスターのコアメタデータを管理し、過半数のクォーラムを形成する必要があります。各 mon のメタデータは、クラウド環境にある場合は PV によって、ローカルストレージデバイス環境にある場合はローカルホスト上のパスによってサポートされます。

Ceph mgr デーモン

このデーモンが起動し、クラスターのメトリックを収集して Prometheus に報告します。

Ceph OSD

これらの OSD は、storageClassDeviceSets の設定に従って作成されます。各 OSD は、ユーザーデータを格納する PV を消費します。デフォルトでは、Ceph は、CRUSH アルゴリズムを使用して高い耐久性と可用性を実現するために、異なる OSD 間でアプリケーションデータの 3 つのレプリカを維持します。

CSI プロビジョナー

これらのプロビジョナーは RBD と CephFS のために開始されます。OpenShift Container Storage のストレージクラスに対してボリュームがリクエストされると、リクエストは Ceph-CSI ドライバーに送信され、Ceph でボリュームをプロビジョニングします。

CSI ボリュームプラグインおよび CephFS

RBD および CephFSの CSI ボリュームプラグインは、クラスター内の各ノードで開始されます。ボリュームプラグインは、Ceph ボリュームをアプリケーションでマウントする必要がある場所で実行する必要があります。

CephCluster CR が設定された後、Rook は残りの Ceph CR を調整してセットアップを完了します。

CephBlockPool

CephBlockPool CR は、Rook オペレーターが RWO ボリューム用の Ceph プールを作成するための設定を提供します。

CephFilesystem

CephFilesystem CR は、通常 RWX ボリューム用に CephFS を使用して共有ファイルシステムを設定するように Rook オペレーターに指示します。共有ボリュームを管理するために、CephFS メタデータサーバー (MDS) が起動します。

CephObjectStore

CephObjectStore CR は、RGW サービスを使用してオブジェクトストアを設定するように Rook オペレーターに指示します。

CephObjectStoreUser CR

CephObjectStoreUser CR は、Rook オペレーターに、Noo Baa が消費するオブジェクトストアユーザーを設定し、access/private キーと CephObjectStore エンドポイントを公開するように指示します。

オペレーターは Ceph の状態を監視して、ストレージプラットフォームが正常な状態を維持していることを確認します。mon デーモンが長時間 (10 分) ダウンした場合、Rook はその場所で新しい mon を開始し、クォーラム全体を完全に復元できるようにします。

ocs-operatorCephCluster CR を更新すると、Rook は要求された変更に即座に応答して、クラスター設定を更新します。

4.3.1.2. NooBaa システムの作成

NooBaa システムが作成されると、mcg-operator は以下を調整します。

デフォルトの BackingStore

OpenShift Container Platform および OpenShift Data Foundation がデプロイされているプラットフォームに応じて、バケットが配置ポリシーに使用できるように、デフォルトのバッキングストアリソースが作成されます。さまざまなオプションは次のとおりです。

Amazon Web Services (AWS) のデプロイ

mcg-operator は、CloudCredentialsOperator (CCO) を使用して認証情報を作成し、新しい AWS::S3 バケットを作成し、そのバケットの上に BackingStore を作成します。

Microsoft Azure のデプロイ

mcg-operator は、CCO を使用して認証情報を作成し、新しい Azure Blob を作成し、そのバケットの上に BackingStore を作成します。

Google Cloud Platform (GCP) のデプロイ

mcg-operator は、CCO を使用して認証情報を作成して新しい GCP バケットを作成し、そのバケットに BackingStore を作成します。

オンプレミスデプロイメント

RGW が存在する場合、mcg-operator は RGW の上に新しい CephUser と新しいバケットを作成し、そのバケットの上に BackingStore を作成します。

前述のデプロイメントはいずれも適用できません

mcg-operator は、デフォルトのストレージクラスに基づいて pv-pool を作成し、そのバケットの上に BackingStore を作成します。

デフォルトの BucketClass

デフォルトの BucketClass への配置ポリシーを持つ BackingStore

NooBaa Pod

次の Noo Baa Pod が作成され、開始します。

データベース (DB)

これは、メタデータ、統計、イベントなどを保持する Postgres DB です。ただし、保存されている実際のデータは保持されません。

コア

これは、設定、バックグラウンドプロセス、メタデータ管理、統計などを処理する Pod です。

エンドポイント

これらの Pod は、重複排除や圧縮、さまざまなサービスとの通信によるデータの書き込みと読み取りなど、実際の I/O 関連の作業を実行します。エンドポイントは、HorizonalPodAutoscaler と統合されており、既存のエンドポイント Pod で観察された CPU 使用率に応じて、エンドポイントの数が増減します。

ルート

NooBaa S3 インターフェイスのルートは、S3 を使用するアプリケーション用に作成されます。

サービス

NooBaa S3 インターフェイスのサービスは、S3 を使用するアプリケーション用に作成されます。