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

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

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

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

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

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

の価値 `max-volumes`環境に固有のいくつかの基準によって異なります。

その `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 、 そして `gcp-cvs`ストレージ ドライバー。使用する際は `ontap-nas-flexgroup`または `ontap-nas-economy`ドライバーの場合、クローン作成はサポートされません。既存のボリュームから新しいボリュームを作成すると、新しいスナップショットが作成されます。

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

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

ontap-san-economyおよびontap-nas-economyドライバのプールとして使用されるFlexVolの最大サイズを設定するには、 `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 つあります。

特権コンテナとは、通常よりも大幅に高いホストレベルの権限で実行されるコンテナです。これらはデフォルトでは拒否されないので、 "ポッドセキュリティポリシー" 。

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

専用のインフラストラクチャ ノード (OpenShift など) またはユーザー アプリケーションをスケジュールできないその他のノードがあるデプロイメントでは、ストレージ リソースへのアクセスをさらに制限するために、別のエクスポート ポリシーを使用する必要があります。これには、インフラストラクチャ ノードにデプロイされるサービス (OpenShift Metrics サービスや Logging サービスなど) と、非インフラストラクチャ ノードにデプロイされる標準アプリケーションのエクスポート ポリシーの作成が含まれます。

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

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

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

その `showmount`この機能により、NFS クライアントは SVM に対して利用可能な NFS エクスポートのリストを照会できるようになります。 Kubernetesクラスタにデプロイされたポッドは、 `showmount -e`に対してコマンドを実行し、アクセスできないマウントも含め、使用可能なマウントのリストを受け取ります。これ自体はセキュリティ侵害にはなりませんが、権限のないユーザーが NFS エクスポートに接続する際に役立つ可能性のある不要な情報を提供します。

無効にする必要があります `showmount`SVM レベルのONTAP CLI コマンドを使用します。

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

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

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

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

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

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

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

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