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

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

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

3 つの NAS ドライバーのいずれかを選択すると、アプリケーションで利用できる機能にいくつかの影響が生じます。

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

Trident はONTAP用の 2 つの SAN ドライバーを提供しており、その機能を以下に示します。

PV 粒度ではない機能は FlexVolume 全体に適用され、すべての PV (つまり、共有 FlexVol 内の qtree または LUN) が共通のスケジュールを共有します。

上の表からわかるように、 ontap-nas`そして `ontap-nas-economy`同じです。しかし、 `ontap-nas-economy`ドライバーは PV 単位の粒度でスケジュールを制御する機能を制限します。これは特に災害復旧とバックアップ計画に影響を与える可能性があります。 ONTAPストレージでPVCクローン機能を活用したい開発チームにとって、これは `ontap-nas、 `ontap-san`または `ontap-san-economy`ドライバー。

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 に適用されます。

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

その `solidfire-san`NetApp HCI/ SolidFireプラットフォームで使用されるドライバーは、管理者が QoS 制限に基づいてTridentの Element バックエンドを構成するのに役立ちます。 Tridentによってプロビジョニングされたボリュームに特定の QoS 制限を設定するようにバックエンドを設計する場合は、 `type`バックエンド ファイルのパラメータ。管理者は、ストレージ上に作成できるボリュームサイズを制限することもできます。 `limitVolumeSize`パラメータ。現在、ボリュームのサイズ変更やボリュームの複製などのElementストレージ機能は、 `solidfire-san`ドライバ。これらの操作は、Element Software Web UI を通じて手動で実行する必要があります。

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

このドライバの詳細と設定方法については、"Azure NetApp FilesのTridentバックエンド構成" 。

Tridentは `gcp-cvs`Google Cloud 上のCloud Volumes Serviceにリンクするためのドライバー。

その `gcp-cvs`ドライバーは仮想プールを使用してバックエンドを抽象化し、 Trident がボリュームの配置を決定できるようにします。管理者は仮想プールを `backend.json`ファイル。ストレージ クラスはセレクターを使用して、ラベルによって仮想プールを識別します。

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

Google CloudのCloud Volumes Serviceのサービスタイプとサービスレベルの詳細については、以下を参照してください。"GCP 向け CVS のTridentサポートについて学ぶ" 。

特定のストレージ クラス オブジェクト内でフィルタリングを使用すると、その特定のストレージ クラスで使用されるストレージ プールまたはプール セットを決定できます。ストレージ クラスでは、次の 3 セットのフィルターを設定できます。 storagePools 、 additionalStoragePools 、および/または excludeStoragePools。

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

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

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

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

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

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

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

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

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

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

Trident は、次のマトリックスに従って、使用されるストレージ プロトコルと指定されたアクセス メソッドを一致させようとします。これは、基盤となるストレージ プラットフォームとは独立しています。

NFS バックエンドが構成されていないTridentデプロイメントに ReadWriteMany PVC の要求を送信すると、ボリュームはプロビジョニングされません。このため、リクエスト側はアプリケーションに適したアクセス モードを使用する必要があります。

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

PV の接続詳細は作成後に変更できません。

Trident は、 CSI フレームワークを使用したオンデマンドのボリューム スナップショットの作成とスナップショットからの PVC の作成をサポートします。スナップショットは、データの特定時点のコピーを維持する便利な方法を提供し、Kubernetes のソース PV から独立したライフサイクルを持ちます。これらのスナップショットを使用して PVC を複製できます。

Trident は、ボリューム スナップショットからの PersistentVolume の作成もサポートしています。これを実現するには、PersistentVolumeClaimを作成し、 `datasource`ボリュームを作成するために必要なスナップショットとして。 Trident は、スナップショットに存在するデータを含むボリュームを作成することで、この PVC を処理します。この機能を使用すると、リージョン間でデータを複製したり、テスト環境を作成したり、破損または壊れた本番ボリューム全体を交換したり、特定のファイルやディレクトリを取得して別の接続されたボリュームに転送したりすることが可能になります。

ストレージ管理者は、ストレージ コンシューマーに支障をきたすことなく、 ONTAPクラスタ内のアグリゲートとコントローラ間でボリュームを移動できます。宛先アグリゲートがTridentが使用している SVM がアクセスできるものである限り、この操作はTridentまたは Kubernetes クラスターに影響を与えません。重要なのは、集計が SVM に新しく追加された場合、それをTridentに再度追加してバックエンドを更新する必要があることです。これにより、 Trident はSVM の再インベントリを実行し、新しいアグリゲートが認識されるようになります。

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

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

Trident は、 NFS、iSCSI、および FC PV のサイズ変更をサポートしています。これにより、ユーザーは Kubernetes レイヤーを通じてボリュームのサイズを直接変更できるようになります。ボリューム拡張は、 ONTAP、 SolidFire/ NetApp HCI 、 Cloud Volumes Serviceバックエンドを含むすべての主要なNetAppストレージ プラットフォームで可能です。後で拡張できるように設定するには `allowVolumeExpansion`に `true`ボリュームに関連付けられた StorageClass 内。永続ボリュームのサイズを変更する必要がある場合は、 `spec.resources.requests.storage`永続ボリューム要求の注釈を必要なボリューム サイズに設定します。 Trident は、ストレージ クラスター上のボリュームのサイズ変更を自動的に処理します。

ボリューム インポートでは、既存のストレージ ボリュームを Kubernetes 環境にインポートできます。これは現在、 ontap-nas 、 ontap-nas-flexgroup 、 solidfire-san 、 azure-netapp-files 、 そして `gcp-cvs`ドライバー。この機能は、既存のアプリケーションを Kubernetes に移植する場合や、災害復旧シナリオ時に役立ちます。

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

もし `azure-netapp-files`または `gcp-cvs`ドライバーを使用する場合は、コマンド `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 サービスと同様に、ログ サービスは、プレイブックに提供されるインベントリ ファイル (ホスト) によって提供される構成パラメーターを使用して Ansible を使用してデプロイされます。説明するインストール方法は 2 つあります。OpenShift の初期インストール時にログをデプロイする方法と、OpenShift のインストール後にログをデプロイする方法です。

ログサービスでNFSを使用する場合は、Ansible変数を設定する必要があります。 `openshift_enable_unsupported_configurations`に `true`インストーラーが失敗するのを防ぐためです。

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

上記の変数とデプロイのプロセスは、OpenShift のバージョンごとに変更される可能性があります。必ず確認して従ってください"Red HatのOpenShiftデプロイメントガイド"お使いの環境に合わせて構成されるように、バージョンに応じて変更してください。