Skip to main content
本製品の最新リリースがご利用いただけます。
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

Tridentの統合

共同作成者

Tridentを統合するには、ドライバの選択と導入、ストレージクラスの設計、仮想プールの設計、永続的ボリューム要求(PVC)によるストレージプロビジョニングへの影響、ボリューム処理、Tridentを使用したOpenShiftサービスの導入など、設計とアーキテクチャの要素を統合する必要があります。

ドライバの選択と展開

ストレージシステム用のバックエンドドライバを選択して導入します。

ONTAP バックエンドドライバ

ONTAP バックエンドドライバは、使用されるプロトコルと、ストレージシステムでのボリュームのプロビジョニング方法によって異なります。そのため、どのドライバを展開するかを決定する際には、慎重に検討する必要があります。

アプリケーションに共有ストレージを必要とするコンポーネント(同じ PVC にアクセスする複数のポッド)がある場合、 NAS ベースのドライバがデフォルトで選択されますが、ブロックベースの iSCSI ドライバは非共有ストレージのニーズを満たします。アプリケーションの要件と、ストレージチームとインフラチームの快適さレベルに基づいてプロトコルを選択してください。一般的に、ほとんどのアプリケーションでは両者の違いはほとんどないため、共有ストレージ(複数のポッドで同時にアクセスする必要がある場合)が必要かどうかに基づいて判断することがよくあります。

使用可能なONTAP バックエンドドライバは次のとおりです。

  • ontap-nas:プロビジョニングされた各PVは、完全なONTAP FlexVolです。

  • ontap-nas-economy:プロビジョニングされた各PVはqtreeであり、FlexVolあたりのqtree数は設定可能です(デフォルトは200)。

  • ontap-nas-flexgroup:各PVがフルONTAP FlexGroupとしてプロビジョニングされ、SVMに割り当てられているすべてのアグリゲートが使用されます。

  • ontap-san:プロビジョニングされた各PVは、専用のFlexVol内のLUNです。

  • ontap-san-economy:プロビジョニングされた各PVはLUNであり、FlexVolあたりのLUN数は設定可能です(デフォルトは100)。

3 つの NAS ドライバの間で選択すると、アプリケーションで使用できる機能にいくつかの影響があります。

次の表では、すべての機能がTridentを通じて公開されているわけではないことに注意してください。一部の機能は、プロビジョニング後にストレージ管理者が適用する必要があります。上付き文字の脚注は、機能やドライバごとに機能を区別します。

ONTAP NASドライバ スナップショット クローン 動的なエクスポートポリシー マルチアタッチ QoS サイズ変更 レプリケーション

ontap-nas

はい

はい

Yesfootnote: 5[]

はい

Yesfootnote: 1[]

はい

Yesfootnote: 1[]

ontap-nas-economy

注:3[]

注:3[]

Yesfootnote: 5[]

はい

注:3[]

はい

注:3[]

ontap-nas-flexgroup

Yesfootnote: 1[]

いいえ

Yesfootnote: 5[]

はい

Yesfootnote: 1[]

はい

Yesfootnote: 1[]

Tridentでは、ONTAP向けに2つのSANドライバを提供しています。その機能は次のとおりです。

ONTAP SANドライバ スナップショット クローン マルチアタッチ 双方向 CHAP QoS サイズ変更 レプリケーション

ontap-san

はい

はい

Yesfootnote: 4[]

はい

Yesfootnote: 1[]

はい

Yesfootnote: 1[]

ontap-san-economy

はい

はい

Yesfootnote: 4[]

はい

注:3[]

はい

注:3[]

上記の表の脚注: Yes[1]: Tridentで管理されていないYes[2]: Tridentで管理されているがPVではないYes[3]: Tridentで管理されていないPVで管理されていないYes[4]: rawブロックボリュームでサポートYes[5]: Tridentでサポート

PV に細分化されていない機能は FlexVol 全体に適用され、 PVS (共有 FlexVol 内の qtree または LUN )にはすべて共通のスケジュールが適用されます。

上記の表からわかるように、との `ontap-nas-economy`機能の大部分は同じです。 `ontap-nas`ただし、スケジュールをPV単位で制御する機能が制限されるため、 `ontap-nas-economy`ディザスタリカバリやバックアップ計画に特に影響する可能性があります。ONTAPストレージでPVCクローン機能を活用したい開発チームでは、 `ontap-san`ドライバのまたはを `ontap-san-economy`使用している場合にのみ可能 `ontap-nas`です。

メモ `solidfire-san`ドライバはPVCをクローニングすることもできます。

Cloud Volumes ONTAP バックエンドドライバ

Cloud Volumes ONTAP は、ファイル共有や NAS および SAN プロトコル( NFS 、 SMB / CIFS 、 iSCSI )を提供するブロックレベルストレージなど、さまざまなユースケースでデータ制御とエンタープライズクラスのストレージ機能を提供します。Cloud Volume ONTAPと互換性があるドライバは ontap-nas、、 ontap-nas-economy ontap-san `ontap-san-economy`です。Cloud Volume ONTAP for Azure と Cloud Volume ONTAP for GCP に該当します。

ONTAP バックエンドドライバ用のAmazon FSX

Amazon FSx for NetApp ONTAPを使用すると、AWSにデータを格納する際のシンプルさ、即応性、セキュリティ、拡張性を活用しながら、使い慣れたNetAppの機能、パフォーマンス、管理機能を活用できます。FSx for ONTAPは、多くのONTAPファイルシステム機能と管理APIをサポートしています。Cloud Volume ONTAPと互換性があるドライバは ontap-nas、、 ontap-nas-economyontap-nas-flexgroup ontap-san `ontap-san-economy`です。

NetApp HCI / SolidFireバックエンドドライバ

`solidfire-san`NetApp HCI / SolidFireプラットフォームで使用されるドライバは、管理者がQoS制限に基づいてElementバックエンドをTrident用に設定するのに役立ちます。Tridentでプロビジョニングするボリュームに特定のQoS制限を設定するようにバックエンドを設計する場合は、バックエンドファイルでパラメータを使用し `type`ます。管理者は、パラメータを使用して、ストレージに作成できるボリュームサイズを制限することもできます `limitVolumeSize`。現時点では、ボリュームサイズ変更やボリュームレプリケーションなどのElementストレージ機能は、ドライバを使用してサポートされていませ `solidfire-san`ん。これらの処理は、 Element ソフトウェアの Web UI から手動で実行する必要があります。
SolidFire ドライバ スナップショット クローン マルチアタッチ CHAP(CHAP) QoS サイズ変更 レプリケーション

solidfire-san

はい

はい

Yesfootnote: 2[]

はい

はい

はい

Yesfootnote: 1[]

脚注:はい脚注: 1[]: Tridentで管理されていません脚注: 2[]: raw-blockボリュームでサポートされています

Azure NetApp Files バックエンドドライバ

Tridentはドライバを使用して `azure-netapp-files`サービスを管理し"Azure NetApp Files"ます。

このドライバとその設定方法の詳細については、を参照してください"Azure NetApp Files 向けの Trident バックエンド構成"

Azure NetApp Files ドライバ スナップショット クローン マルチアタッチ QoS 展開表示 レプリケーション

azure-netapp-files

はい

はい

はい

はい

はい

Yesfootnote: 1[]

脚注:はい脚注: 1[]: Tridentで管理されていません

Google Cloudバックエンドドライバ上のCloud Volumes Service

Tridentはドライバを使用し `gcp-cvs`てGoogle Cloud上のCloud Volumes Serviceとリンクします。

`gcp-cvs`ドライバは仮想プールを使用してバックエンドを抽象化し、Tridentがボリュームの配置を決定できるようにします。管理者がファイルに仮想プールを定義し `backend.json`ます。ストレージクラスには、ラベルで仮想プールを識別するセレクタが使用されます。
  • バックエンドで仮想プールが定義されている場合、Tridentはそれらの仮想プールが制限されているGoogle Cloudストレージプール内にボリュームを作成しようとします。

  • バックエンドで仮想プールが定義されていない場合、Tridentはリージョン内の使用可能なストレージプールからGoogle Cloudストレージプールを選択します。

TridentでGoogle Cloudバックエンドを設定するには、バックエンドファイルで、、 apiRegion`を `apiKey`指定する必要があります `projectNumber。プロジェクト番号はGoogle Cloudコンソールで確認できます。APIキーは、Google CloudでCloud Volumes Service のAPIアクセスを設定するときに作成したサービスアカウントの秘密鍵ファイルから取得されます。

Google Cloudのサービスタイプとサービスレベルに関するCloud Volumes Serviceの詳細については、を参照してください"CVS for GCPでのTridentサポートの詳細"

Cloud Volumes Service for Google Cloudドライバ スナップショット クローン マルチアタッチ QoS 展開表示 レプリケーション

gcp-cvs

はい

はい

はい

はい

はい

CVS -パフォーマンスサービスタイプでのみ利用できます。

メモ
レプリケーションに関する注意事項
  • レプリケーションはTridentで管理されません。

  • クローンは、ソースボリュームと同じストレージプールに作成されます。

ストレージクラスの設計

Kubernetes ストレージクラスオブジェクトを作成するには、個々のストレージクラスを設定して適用する必要があります。このセクションでは、アプリケーション用のストレージクラスの設計方法について説明します。

特定のバックエンド使用率

フィルタリングは、特定のストレージクラスオブジェクト内で使用でき、そのストレージクラスで使用するストレージプールまたはプールのセットを決定します。ストレージクラスでは、、 additionalStoragePools、またはその両方の excludeStoragePools`3セットのフィルタを設定できます `storagePools

パラメータを使用 `storagePools`すると、指定した属性に一致するプールだけにストレージを制限できます。パラメータは、 `additionalStoragePools`属性とパラメータで選択された一連のプールとともに、Tridentがプロビジョニングに使用する一連のプールを拡張するために使用し `storagePools`ます。どちらか一方のパラメータを単独で使用することも、両方を使用して、適切なストレージプールセットが選択されていることを確認することもできます。

`excludeStoragePools`パラメータは、属性に一致するリストされた一連のプールを具体的に除外するために使用します。

QoSポリシーをエミュレートします

QoSポリシーをエミュレートするようにストレージクラスを設計する場合は、属性をまたは ssd`にし `hdd`てストレージクラスを作成します `media。ストレージクラスで指定された属性に基づいて media、Tridentはメディア属性に一致するサービスまたは ssd`アグリゲートを提供する適切なバックエンドを選択し `hdd、ボリュームのプロビジョニングを特定のアグリゲートに転送します。そのため、Premiumという属性が設定され ssd`たストレージクラスを作成し `media、Premium QoSポリシーに分類できるようにします。メディア属性を「 hdd 」に設定し、標準の QoS ポリシーとして分類できる、別のストレージクラス標準を作成できます。また、ストレージクラスの「 IOPS 」属性を使用して、 QoS ポリシーとして定義できる Element アプライアンスにプロビジョニングをリダイレクトすることもできます。

特定の機能に基づいてバックエンドを利用する

ストレージクラスは、シンプロビジョニングとシックプロビジョニング、 Snapshot 、クローン、暗号化などの機能が有効になっている特定のバックエンドでボリュームを直接プロビジョニングするように設計できます。使用するストレージを指定するには、必要な機能を有効にしてバックエンドに適したストレージクラスを作成します。

仮想プール

仮想プールは、すべてのTridentバックエンドで使用できます。Tridentが提供する任意のドライバを使用して、任意のバックエンドに仮想プールを定義できます。

仮想プールを使用すると、管理者はストレージクラスで参照可能なバックエンド上に抽象化レベルを作成して、バックエンドにボリュームを柔軟かつ効率的に配置できます。同じサービスクラスを使用して異なるバックエンドを定義できます。さらに、同じバックエンドに異なる特性を持つ複数のストレージプールを作成することもできます。ストレージクラスに特定のラベルを持つセレクタが設定されている場合、Tridentはボリュームを配置するすべてのセレクタラベルに一致するバックエンドを選択します。ストレージクラスセレクタのラベルが複数のストレージプールに一致する場合、Tridentはそのうちの1つをボリュームのプロビジョニング元として選択します。

仮想プールの設計

バックエンドの作成時に、一般に一連のパラメータを指定できます。管理者が、同じストレージクレデンシャルと異なるパラメータセットを使用して別のバックエンドを作成することはできませんでした。仮想プールの導入により、この問題 は軽減されました。仮想プールは、バックエンドとKubernetesストレージクラスの間に導入されたレベル抽象化です。管理者は、Kubernetes Storage Classesでセレクターとして参照できるラベルとともにパラメータをバックエンドに依存しない方法で定義できます。仮想プールは、TridentでサポートされるすべてのNetAppバックエンドに対して定義できます。リストには、 SolidFire / NetApp HCI 、 ONTAP 、 GCP 上の Cloud Volumes Service 、 Azure NetApp Files が含まれます。

メモ 仮想プールを定義する場合は、バックエンド定義で既存の仮想プールの順序を変更しないことをお勧めします。また、既存の仮想プールの属性を編集または変更したり、新しい仮想プールを定義したりしないことを推奨します。

さまざまなサービスレベル/QoSのエミュレート

サービスクラスをエミュレートするための仮想プールを設計できます。Cloud Volume Service for Azure NetApp Files の仮想プール実装を使用して、さまざまなサービスクラスをセットアップする方法を見ていきましょう。Azure NetApp Filesバックエンドには、異なるパフォーマンスレベルを表す複数のラベルを設定します。アスペクトを適切なパフォーマンスレベルに設定し servicelevel、各ラベルの下にその他の必要なアスペクトを追加します。次に、異なる仮想プールにマッピングするさまざまなKubernetesストレージクラスを作成します。フィールドを使用して parameters.selector、各StorageClassはボリュームのホストに使用できる仮想プールを呼び出します。

特定の一連の側面を割り当てます

特定の側面を持つ複数の仮想プールは、単一のストレージバックエンドから設計できます。そのためには、バックエンドに複数のラベルを設定し、各ラベルに必要な側面を設定します。次に、異なる仮想プールにマッピングするフィールドを使用して、異なるKubernetesストレージクラスを作成し `parameters.selector`ます。バックエンドでプロビジョニングされるボリュームには、選択した仮想プールに定義された設定が適用されます。

ストレージプロビジョニングに影響する PVC 特性

要求されたストレージクラスを超える一部のパラメータは、PVCの作成時にTridentプロビジョニングの決定プロセスに影響する可能性があります。

アクセスモード

PVC 経由でストレージを要求する場合、必須フィールドの 1 つがアクセスモードです。必要なモードは、ストレージ要求をホストするために選択されたバックエンドに影響を与える可能性があります。

Trident は、以下のマトリックスに記載されているアクセス方法で使用されているストレージプロトコルと一致するかどうかを試みます。これは、基盤となるストレージプラットフォームに依存しません。

ReadWriteOnce コマンドを使用します ReadOnlyMany ReadWriteMany

iSCSI

はい

はい

○( Raw ブロック)

NFS

はい

はい

はい

NFS バックエンドが設定されていない Trident 環境に送信された ReadWriteMany PVC が要求された場合、ボリュームはプロビジョニングされません。このため、リクエスタは、アプリケーションに適したアクセスモードを使用する必要があります。

ボリューム操作

永続ボリュームの変更

永続ボリュームとは、 Kubernetes で変更不可のオブジェクトを 2 つだけ除いてです。再利用ポリシーとサイズは、いったん作成されると変更できます。ただし、これにより、ボリュームの一部の要素がKubernetes以外で変更されることが防止されるわけではありません。特定のアプリケーション用にボリュームをカスタマイズしたり、誤って容量が消費されないようにしたり、何らかの理由でボリュームを別のストレージコントローラに移動したりする場合に便利です。

メモ Kubernetes のツリー内プロビジョニングツールは、現時点では NFS または iSCSI PVS のボリュームサイズ変更処理をサポートしていません。Trident では、 NFS ボリュームと iSCSI ボリュームの拡張がサポートされています。

作成後に PV の接続の詳細を変更することはできません。

オンデマンドのボリューム Snapshot を作成

Trident では、 CSI フレームワークを使用して、ボリュームスナップショットのオンデマンド作成とスナップショットからの PVC の作成がサポートされます。Snapshot は、データのポイントインタイムコピーを管理し、 Kubernetes のソース PV とは無関係にライフサイクルを管理する便利な方法です。これらの Snapshot を使用して、 PVC をクローニングできます。

Snapshot からボリュームを作成します

Trident では、ボリューム Snapshot から PersistentVolumes を作成することもできます。そのためには、PersistentVolumeClaimを作成し、ボリュームの作成元となるSnapshotとしてを指定します datasource。Trident は、 Snapshot にデータが存在するボリュームを作成することで、この PVC を処理します。この機能を使用すると、複数のリージョン間でデータを複製したり、テスト環境を作成したり、破損した本番ボリューム全体を交換したり、特定のファイルとディレクトリを取得して別の接続ボリュームに転送したりできます。

クラスタ内でボリュームを移動します

ストレージ管理者は、 ONTAP クラスタ内のアグリゲート間およびコントローラ間で、ストレージ利用者への無停止でボリュームを移動できます。この処理は、Tridentが使用しているSVMからアクセスできるデスティネーションアグリゲートであるかぎり、TridentまたはKubernetesクラスタには影響しません。重要なことは、アグリゲートがSVMに新しく追加されている場合は、バックエンドをTridentに再追加してリフレッシュする必要があることです。これにより、 Trident が SVM のインベントリを再設定し、新しいアグリゲートが認識されます。

ただし、バックエンド間でのボリュームの移動は Trident では自動でサポートされていません。これには、同じクラスタ内の SVM 間、クラスタ間、または別のストレージプラットフォームへの SVM の間も含まれます( Trident に接続されているストレージシステムの場合も含む)。

ボリュームが別の場所にコピーされた場合、ボリュームインポート機能を使用して現在のボリュームを Trident にインポートできます。

ボリュームを展開します

Tridentでは、NFSおよびiSCSI PVSのサイズ変更がサポートされています。これにより、ユーザは Kubernetes レイヤを介してボリュームのサイズを直接変更できます。ボリュームを拡張できるのは、 ONTAP 、 SolidFire / NetApp HCI 、 Cloud Volumes Service バックエンドなど、主要なすべてのネットアップストレージプラットフォームです。あとで拡張できるようにするには、ボリュームに関連付けられているStorageClassでをに true`設定し `allowVolumeExpansion`ます。永続的ボリュームのサイズを変更する必要がある場合は、永続的ボリューム要求で必要なボリュームサイズになるようにアノテーションを編集します `spec.resources.requests.storage。Tridentによって、ストレージクラスタ上のボリュームのサイズが自動的に変更されます。

既存のボリュームを Kubernetes にインポートする

Volume Import では、既存のストレージボリュームを Kubernetes 環境にインポートできます。これは、現在、、 ontap-nas-flexgroup solidfire-san、、 `azure-netapp-files`および `gcp-cvs`ドライバでサポートされて `ontap-nas`います。この機能は、既存のアプリケーションを Kubernetes に移植する場合や、ディザスタリカバリシナリオで使用する場合に便利です。

ONTAPドライバとドライバを使用する場合 `solidfire-san`は、コマンドを使用し `tridentctl import volume <backend-name> <volume-name> -f /path/pvc.yaml`て、Tridentで管理するKubernetesに既存のボリュームをインポートします。import volume コマンドで使用した PVC YAML または JSON ファイルは、 Trident をプロビジョニングツールとして識別するストレージクラスを指定します。NetApp HCI / SolidFire バックエンドを使用する場合は、ボリューム名が一意であることを確認してください。ボリューム名が重複している場合は、ボリュームインポート機能で区別できるように、ボリュームを一意の名前にクローニングします。

ドライバまたは `gcp-cvs`ドライバを使用している場合 `azure-netapp-files`は、コマンドを使用し `tridentctl import volume <backend-name> <volume path> -f /path/pvc.yaml`て、Tridentで管理するKubernetesにボリュームをインポートします。これにより、ボリューム参照が一意になります。

上記のコマンドが実行されると、 Trident はバックエンド上のボリュームを検出してサイズを確認します。設定されたPVCのボリュームサイズを自動的に追加(および必要に応じて上書き)します。Trident が新しい PV を作成し、 Kubernetes が PVC を PV にバインド

特定のインポートされた PVC を必要とするようにコンテナを導入した場合、ボリュームインポートプロセスによって PVC/PV ペアがバインドされるまで、コンテナは保留状態のままになります。PVC/PV ペアがバインドされると、他に問題がなければコンテナが起動します。

OpenShift サービスを導入します

OpenShift の付加価値クラスタサービスは、クラスタ管理者とホストされているアプリケーションに重要な機能を提供します。これらのサービスが使用するストレージはノードローカルリソースを使用してプロビジョニングできますが、これにより、サービスの容量、パフォーマンス、リカバリ性、持続可能性が制限されることがよくあります。エンタープライズストレージアレイを活用してこれらのサービスに容量を提供することで、劇的に向上したサービスを実現できます。ただし、すべてのアプリケーションと同様に、 OpenShift とストレージ管理者は、緊密に連携してそれぞれに最適なオプションを決定する必要があります。Red Hat のドキュメントは、要件を決定し、サイジングとパフォーマンスのニーズを確実に満たすために大きく活用する必要があります。

レジストリサービス

レジストリのストレージの導入と管理については、に記載され"netapp.io のコマンドです""ブログ"います。

ロギングサービス

他のOpenShiftサービスと同様に、ロギングサービスは、Playbookに提供されるインベントリファイル(ホスト)から提供される設定パラメータを使用してAnsibleを使用して導入されます。ここでは、 OpenShift の初期インストール時にロギングを導入し、 OpenShift のインストール後にロギングを導入するという、 2 つのインストール方法について説明します。

注意 Red Hat OpenShift バージョン 3.9 以降、データ破損に関する懸念があるため、記録サービスに NFS を使用しないことを公式のドキュメントで推奨しています。これは、 Red Hat 製品のテストに基づいています。ONTAP NFSサーバにはこのような問題がないため、ロギング環境を簡単にバックアップできます。ロギングサービスには最終的にどちらかのプロトコルを選択する必要がありますが、両方のプロトコルがネットアッププラットフォームを使用する場合に適していることと、 NFS を使用する理由がないことを確認してください。

ログサービスでNFSを使用する場合は、インストーラが失敗しないように `true`Ansible変数を設定する必要があり `openshift_enable_unsupported_configurations`ます。

開始する

ロギングサービスは、必要に応じて、両方のアプリケーションに導入することも、 OpenShift クラスタ自体のコア動作に導入することもできます。オペレーションログの展開を選択した場合は、変数をに `true`指定する `openshift_logging_use_ops`と、サービスの2つのインスタンスが作成されます。操作のロギングインスタンスを制御する変数には「 ops 」が含まれ、アプリケーションのインスタンスには含まれません。

基盤となるサービスで正しいストレージが使用されるようにするには、導入方法に応じてAnsible変数を設定することが重要です。それぞれの導入方法のオプションを見てみましょう。

メモ 次の表には、ロギングサービスに関連するストレージ構成に関連する変数のみを示します。展開に応じて、レビュー、設定、および使用する必要がある他のオプションを見つけることができます"Red Hat OpenShift のロギングに関するドキュメント"

次の表の変数では、入力した詳細を使用してロギングサービスの PV と PVC を作成する Ansible プレイブックが作成されます。この方法は、 OpenShift インストール後にコンポーネントインストールプレイブックを使用するよりもはるかに柔軟性に劣るが、既存のボリュームがある場合はオプションとなります。

変数 詳細

openshift_logging_storage_kind

インストーラによってロギングサービス用のNFS PVが作成されるようにするには、をに設定し `nfs`ます。

openshift_logging_storage_host

NFS ホストのホスト名または IP アドレス。仮想マシンのデータ LIF に設定してください。

openshift_logging_storage_nfs_directory

NFS エクスポートのマウントパス。たとえば、ボリュームがとしてジャンクションされている場合 `/openshift_logging`は、そのパスを変数に使用します。

openshift_logging_storage_volume_name

作成するPVの名前(例: pv_ose_logs)。

openshift_logging_storage_volume_size

NFSエクスポートのサイズ(例:) 100Gi

OpenShift クラスタがすでに実行中で、そのため Trident を導入して設定した場合、インストーラは動的プロビジョニングを使用してボリュームを作成できます。次の変数を設定する必要があります。

変数 詳細

openshift_logging_es_pvc_dynamic

動的にプロビジョニングされたボリュームを使用する場合は true に設定します。

openshift_logging_es_pvc_storage_class_name

PVC で使用されるストレージクラスの名前。

openshift_logging_es_pvc_size

PVC で要求されたボリュームのサイズ。

openshift_logging_es_pvc_prefix

ロギングサービスで使用される PVC のプレフィックス。

openshift_logging_es_ops_pvc_dynamic

opsロギングインスタンスに動的にプロビジョニングされたボリュームを使用するには、をに設定し `true`ます。

openshift_logging_es_ops_pvc_storage_class_name

処理ロギングインスタンスのストレージクラスの名前。

openshift_logging_es_ops_pvc_size

処理インスタンスのボリューム要求のサイズ。

openshift_logging_es_ops_pvc_prefix

ops インスタンス PVC のプレフィックス。

ロギングスタックを導入します

初期の OpenShift インストールプロセスの一部としてロギングを導入する場合、標準の導入プロセスに従うだけで済みます。Ansible は、必要なサービスと OpenShift オブジェクトを構成および導入して、 Ansible が完了したらすぐにサービスを利用できるようにします。

ただし、最初のインストール後に導入する場合は、コンポーネントプレイブックを Ansible で使用する必要があります。このプロセスは、OpenShiftのバージョンによって若干変更される場合がありますので、お使いのバージョンに合わせてお読みください"Red Hat OpenShift Container Platform 3.11 のドキュメント"

指標サービス

この指標サービスは、 OpenShift クラスタのステータス、リソース利用率、可用性に関する重要な情報を管理者に提供します。ポッドの自動拡張機能にも必要であり、多くの組織では、チャージバックやショーバックのアプリケーションに指標サービスのデータを使用しています。

ロギングサービスや OpenShift 全体と同様に、 Ansible を使用して指標サービスを導入します。また、ロギングサービスと同様に、メトリクスサービスは、クラスタの初期セットアップ中、またはコンポーネントのインストール方法を使用して運用後に導入できます。次の表に、指標サービスに永続的ストレージを設定する際に重要となる変数を示します。

メモ 以下の表には、指標サービスに関連するストレージ構成に関連する変数のみが含まれています。このドキュメントには、他にも導入環境に応じて確認、設定、使用できるオプションが多数あります。
変数 詳細

openshift_metrics_storage_kind

インストーラによってロギングサービス用のNFS PVが作成されるようにするには、をに設定し `nfs`ます。

openshift_metrics_storage_host

NFS ホストのホスト名または IP アドレス。これは SVM のデータ LIF に設定されている必要があります。

openshift_metrics_storage_nfs_directory

NFS エクスポートのマウントパス。たとえば、ボリュームがとしてジャンクションされている場合 `/openshift_metrics`は、そのパスを変数に使用します。

openshift_metrics_storage_volume_name

作成するPVの名前(例: pv_ose_metrics)。

openshift_metrics_storage_volume_size

NFSエクスポートのサイズ(例:) 100Gi

OpenShift クラスタがすでに実行中で、そのため Trident を導入して設定した場合、インストーラは動的プロビジョニングを使用してボリュームを作成できます。次の変数を設定する必要があります。

変数 詳細

openshift_metrics_cassandra_pvc_prefix

メトリック PVC に使用するプレフィックス。

openshift_metrics_cassandra_pvc_size

要求するボリュームのサイズ。

openshift_metrics_cassandra_storage_type

指標に使用するストレージのタイプ。適切なストレージクラスを使用して PVC を作成するには、 Ansible に対してこれを dynamic に設定する必要があります。

openshift_metrics_cassanda_pvc_storage_class_name

使用するストレージクラスの名前。

指標サービスを導入する

ホスト / インベントリファイルに適切な Ansible 変数を定義して、 Ansible でサービスを導入します。OpenShift インストール時に導入する場合は、 PV が自動的に作成されて使用されます。コンポーネントプレイブックを使用して導入する場合は、OpenShiftのインストール後にAnsibleによって必要なPVCが作成され、Tridentによってストレージがプロビジョニングされたらサービスが導入されます。

上記の変数と導入プロセスは、 OpenShift の各バージョンで変更される可能性があります。使用しているバージョンを確認し、環境に合わせて構成されるようにして"RedHat OpenShift 導入ガイド"ください。