Storage Virtual Machine（SVM）は、ONTAPシステム上のテナント間の分離と管理の分離を実現します。SVMをアプリケーション専用にすることで、権限の委任が可能になり、リソース消費を制限するためのベストプラクティスを適用できるようになります。

SVM の管理にはいくつかのオプションがあります：

いずれの場合も、インターフェイスはDNSに登録され、Tridentの設定時にDNS名を使用する必要があります。これにより、ネットワークIDの保持を使用しないSVM-DRなど、一部のDRシナリオが容易になります。

SVM に専用の管理 LIF を使用するか、共有の管理 LIF を使用するかという優先順位はありませんが、ネットワーク セキュリティ ポリシーが選択したアプローチと一致していることを確認する必要があります。いずれにせよ、管理 LIF は DNS 経由でアクセスできるようにして、 "SVM-DR"Trident と組み合わせて使用する場合に最大限の柔軟性を実現する必要があります。

ONTAP ストレージシステムには最大ボリューム数があり、ソフトウェアのバージョンとハードウェア プラットフォームによって異なります。特定のプラットフォームと ONTAP バージョンの正確な制限を確認するには、 "NetApp Hardware Universe"を参照してください。ボリューム数が上限に達すると、Trident だけでなく、すべてのストレージ要求に対してプロビジョニング操作が失敗します。

Tridentの `ontap-nas`および `ontap-san`ドライバーは、作成される各Kubernetes永続ボリューム（PV）に対してFlexVolumeをプロビジョニングします。 `ontap-nas-economy`ドライバーは、200PVごとに約1つのFlexVolumeを作成します（50～300の間で設定可能）。 `ontap-san-economy`ドライバーは、100PVごとに約1つのFlexVolumeを作成します（50～200の間で設定可能）。Tridentがストレージシステム上の使用可能なボリュームをすべて消費しないようにするには、SVMに制限を設定する必要があります。コマンドラインから次のように実行できます：

この `max-volumes`値は、ONTAP クラスタ内のすべてのノードにプロビジョニングされたボリュームの合計であり、個々の ONTAP ノードのものではありません。その結果、ONTAP クラスタノードによっては、Trident でプロビジョニングされたボリュームが他のノードよりもはるかに多い場合や少ない場合があります。

たとえば、2ノードのONTAPクラスタには、最大2000個のFlexVolボリュームをホストする機能があります。最大ボリューム数を1250に設定することは非常に妥当に思えます。ただし、1つのノードからの "アグリゲート"のみがSVMに割り当てられている場合、または1つのノードから割り当てられたアグリゲートをプロビジョニングできない場合（容量不足など）、もう一方のノードがすべてのTridentプロビジョニングボリュームのターゲットになります。つまり、 `max-volumes`の値に達する前に、そのノードのボリューム制限に達する可能性があり、その結果、Tridentとそのノードを使用する他のボリューム操作の両方に影響を与えます。この状況を回避するには、クラスタ内の各ノードからのアグリゲートが、Tridentで使用されるSVMに同数割り当てられるようにします。

NetApp Tridentは、 ontap-nas、 ontap-san、および `solidfire-san`ストレージドライバーを使用する場合、ボリュームのクローン作成をサポートします。 `ontap-nas-flexgroup`または `ontap-nas-economy`ドライバーを使用する場合、クローン作成はサポートされません。既存のボリュームから新しいボリュームを作成すると、新しいスナップショットが作成されます。

Tridentで作成できるボリュームの最大サイズを設定するには、 `limitVolumeSize`パラメータを `backend.json`定義で使用します。

ストレージ アレイでのボリューム サイズの制御に加えて、Kubernetes の機能も活用する必要があります。

ontap-san-economyドライバおよびontap-nas-economyドライバのプールとして使用されるFlexVolsの最大サイズを設定するには、 `limitVolumePoolSize`パラメータを `backend.json`定義で使用してください。

バックエンド定義で CHAP イニシエーターとターゲットのユーザー名とパスワードを指定し、Trident で SVM の CHAP を有効にすることができます。バックエンド構成で `useCHAP`パラメータを使用すると、Trident は CHAP を使用して ONTAP バックエンドの iSCSI 接続を認証します。

SVMに適用されるONTAP QoSポリシーを活用することで、Tridentでプロビジョニングされたボリュームが消費できるIOPSの数を制限します。これにより、 "いじめを防ぐ"または制御不能なコンテナがTrident SVM外部のワークロードに影響を与えるのを防ぎます。

SVM の QoS ポリシーは数ステップで作成できます。最も正確な情報については、お使いのバージョンの ONTAP のドキュメントを参照してください。以下の例では、SVM で使用可能な合計 IOPS を 5000 に制限する QoS ポリシーを作成します。

さらに、ONTAP のバージョンでサポートされている場合は、コンテナ化されたワークロードへのスループット量を保証するために、QoS 最小値の使用を検討できます。アダプティブ QoS は SVM レベルのポリシーと互換性がありません。

コンテナ化されたワークロード専用の IOPS の数は、さまざまな側面によって異なります。とりわけ、次のようなものがあります：

SVM レベルで割り当てられた QoS ポリシーにより、SVM にプロビジョニングされたすべてのボリュームが同じ IOPS プールを共有することになるということを覚えておくことが重要です。コンテナ化されたアプリケーションの 1 つまたは少数に高い IOPS 要件がある場合、他のコンテナ化されたワークロードに対して脅威となる可能性があります。このような場合は、外部自動化を使用してボリュームごとの QoS ポリシーを割り当てることを検討してください。

サービス品質（QoS）は、競合するワークロードによって重要なワークロードのパフォーマンスが低下しないことを保証します。ONTAP QoS ポリシーグループはボリュームの QoS オプションを提供し、ユーザーが 1 つ以上のワークロードのスループット上限を定義できるようにします。QoS の詳細については、 "QoSによるスループットの保証"を参照してください。バックエンドまたはストレージプールで QoS ポリシーグループを指定すると、そのプールまたはバックエンドで作成された各ボリュームに適用されます。

ONTAP には、従来型とアダプティブ型の 2 種類の QoS ポリシー グループがあります。従来のポリシー グループは、IOPS で一定した最大（または後のバージョンでは最小）スループットを提供します。アダプティブ QoS は、ワークロードのサイズの変化に応じて IOPS と TB|GB の比率を維持しながら、スループットをワークロードのサイズに合わせて自動的にスケーリングします。これは、大規模な展開で数百または数千のワークロードを管理する場合に大きな利点となります。

QoS ポリシー グループを作成するときは、次の点を考慮してください：

QoSポリシーグループの詳細については、 "ONTAPコマンド リファレンス"を参照してください。

Tridentによって作成されたNFSボリューム、iSCSI LUN、FC LUNへのアクセスを制限することは、Kubernetesデプロイメントのセキュリティ体制にとって重要なコンポーネントです。こうすることで、Kubernetesクラスターの一部ではないホストがボリュームにアクセスして予期せずデータを変更する可能性を防ぐことができます。

名前空間は Kubernetes 内のリソースの論理的な境界であることを理解することが重要です。同じ名前空間内のリソースは共有できると想定されていますが、重要なのは、名前空間間の機能がないことです。つまり、PV はグローバル オブジェクトですが、PVC にバインドされている場合は、同じ名前空間にあるポッドからのみアクセスできます。適切な場合には、名前空間を使用して分離を行うことが重要です。

Kubernetes コンテキストでのデータセキュリティに関してほとんどの組織が主に懸念するのは、コンテナ内のプロセスが、ホストにマウントされているがコンテナ用ではないストレージにアクセスできることです。 "ネームスペース"は、この種の侵害を防ぐように設計されています。ただし、特権コンテナという例外が 1 つあります。

特権コンテナとは、通常よりも大幅に高いホストレベルの権限で実行されるコンテナです。これらはデフォルトでは拒否されないため、 "Pod セキュリティポリシー"を使用してこの機能を無効にしてください。

Kubernetes と外部ホストの両方からアクセスする必要があるボリュームの場合、ストレージは従来の方法で管理する必要があります。PV は管理者によって導入され、Trident では管理されません。これにより、Kubernetes と外部ホストの両方が切断され、ボリュームを使用しなくなった場合にのみ、ストレージ ボリュームが破棄されるようになります。さらに、カスタム エクスポート ポリシーを適用して、Kubernetes クラスター ノードおよび Kubernetes クラスター外部の対象サーバーからのアクセスを有効にすることもできます。

専用のインフラストラクチャノードを持つデプロイメント（例：OpenShift）またはユーザーアプリケーションをスケジュールできないその他のノードの場合は、別のエクスポートポリシーを使用して、ストレージリソースへのアクセスをさらに制限する必要があります。これには、これらのインフラストラクチャノードに導入されるサービス（例：OpenShift MetricsおよびLoggingサービス）、およびインフラストラクチャ以外のノードに導入される標準アプリケーションのエクスポートポリシーの作成が含まれます。

各バックエンドに対して、Kubernetes クラスター内に存在するノードへのアクセスのみを許可するエクスポート ポリシーが存在することを確認する必要があります。Trident はエクスポート ポリシーを自動的に作成および管理できます。これにより、Trident は Kubernetes クラスター内のノードにプロビジョニングされたボリュームへのアクセスを制限し、ノードの追加/削除を簡素化します。

あるいは、エクスポート ポリシーを手動で作成し、各ノード アクセス要求を処理する 1 つ以上のエクスポート ルールを設定することもできます：

これらのコマンドを実行すると、データにアクセスできる Kubernetes ノードを制限できます。

各SolidFireアカウントは一意のボリューム所有者を表し、独自のチャレンジハンドシェイク認証プロトコル（CHAP）クレデンシャルのセットを受け取ります。アカウントに割り当てられたボリュームには、アカウント名と関連するCHAPクレデンシャルを使用するか、ボリュームアクセスグループを通じてアクセスできます。1つのアカウントには最大2,000個のボリュームを割り当てることができますが、1つのボリュームは1つのアカウントにのみ属することができます。

SolidFire のサービス品質（QoS）ポリシーは、多くのボリュームに適用できる標準化されたサービス品質設定を作成して保存する場合に使用します。

ボリュームごとに QoS パラメータを設定できます。QoS を定義する 3 つの構成可能なパラメータ（最小 IOPS、最大 IOPS、バースト IOPS）を設定することで、各ボリュームのパフォーマンスを保証できます。

4KB ブロック サイズで可能な最小、最大、およびバースト IOPS 値は次のとおりです。

ブロック サイズと帯域幅は IOPS の数に直接影響します。ブロック サイズが大きくなるにつれて、システムはより大きなブロック サイズを処理するために必要なレベルまで帯域幅を増加させます。帯域幅が増加すると、システムが達成できる IOPS の数は減少します。QoS とパフォーマンスの詳細については、 "SolidFire のサービス品質"を参照してください。

Element は、CHAP とボリューム アクセス グループ（VAG）の 2 つの認証方法をサポートしています。CHAP は、CHAP プロトコルを使用して、バックエンドに対してホストを認証します。ボリューム アクセス グループは、プロビジョニングするボリュームへのアクセスを制御します。NetApp は、認証には、よりシンプルでスケーリングの制限がない CHAP を使用することをお勧めします。

CHAP 認証（イニシエーターが意図したボリューム ユーザーであることの検証）は、アカウント ベースのアクセス制御でのみサポートされます。認証に CHAP を使用する場合は、単方向 CHAP と双方向 CHAP の 2 つのオプションが利用できます。単方向 CHAP は、SolidFire アカウント名とイニシエーター シークレットを使用してボリューム アクセスを認証します。双方向 CHAP オプションは、ボリュームがアカウント名とイニシエーター シークレットを使用してホストを認証し、次にホストがアカウント名とターゲット シークレットを使用してボリュームを認証するため、ボリュームを認証する最も安全な方法を提供します。

ただし、CHAP を有効にできず、VAG が必要な場合は、アクセス グループを作成し、ホスト イニシエーターとボリュームをアクセス グループに追加します。アクセス グループに追加した各 IQN は、CHAP 認証の有無にかかわらず、グループ内の各ボリュームにアクセスできます。iSCSI イニシエーターが CHAP 認証を使用するように構成されている場合は、アカウントベースのアクセス制御が使用されます。iSCSI イニシエーターが CHAP 認証を使用するように構成されていない場合は、ボリューム アクセス グループのアクセス制御が使用されます。