ストレージ構成
ネットアップポートフォリオの各ストレージプラットフォームには、コンテナ化されたアプリケーションやそうでないアプリケーションに役立つ独自の機能があります。
プラットフォームの概要
Trident は ONTAP や Element と連携1 つのプラットフォームが他のプラットフォームよりもすべてのアプリケーションとシナリオに適しているわけではありませんが、プラットフォームを選択する際には、アプリケーションのニーズとデバイスを管理するチームを考慮する必要があります。
使用するプロトコルに対応したホストオペレーティングシステムのベースラインベストプラクティスに従う必要があります。必要に応じて、アプリケーションのベストプラクティスを適用する際に、バックエンド、ストレージクラス、 PVC の設定を利用して、特定のアプリケーションのストレージを最適化することもできます。
ONTAP と Cloud Volumes ONTAP のベストプラクティス
Trident 向けに ONTAP と Cloud Volumes ONTAP を設定するためのベストプラクティスをご確認ください。
次に示す推奨事項は、 Trident によって動的にプロビジョニングされたボリュームを消費するコンテナ化されたワークロード用に ONTAP を設定する際のガイドラインです。それぞれの要件を考慮し、環境内で適切かどうかを評価する必要があります。
Trident 専用の SVM を使用
Storage Virtual Machine ( SVM )を使用すると、 ONTAP システムのテナントを分離し、管理者が分離できます。 SVM をアプリケーション専用にしておくと、権限の委譲が可能になり、リソース消費を制限するためのベストプラクティスを適用できます。
SVM の管理には、いくつかのオプションを使用できます。
-
バックエンド構成でクラスタ管理インターフェイスを適切なクレデンシャルとともに指定し、 SVM 名を指定します。
-
ONTAP System Manager または CLI を使用して、 SVM 専用の管理インターフェイスを作成します。
-
NFS データインターフェイスで管理ロールを共有します。
いずれの場合も、インターフェイスは DNS にあり、 Trident の設定時には DNS 名を使用する必要があります。これにより、ネットワーク ID を保持しなくても SVM-DR などの一部の DR シナリオが簡単になります。
専用の管理 LIF または共有の管理 LIF を SVM に使用する方法は推奨されませんが、ネットワークセキュリティポリシーを選択した方法と一致させる必要があります。最大の柔軟性を確保するには、どのような場合でも DNS 経由で管理 LIF にアクセスできるようにします "SVM-DR" Trident と組み合わせて使用できます。
最大ボリューム数を制限します
ONTAP ストレージシステムの最大ボリューム数は、ソフトウェアのバージョンとハードウェアプラットフォームによって異なります。を参照してください "NetApp Hardware Universe の略" 具体的な制限については、使用しているプラットフォームと ONTAP のバージョンに対応しています。ボリューム数を使い果たした場合、 Trident のプロビジョニング処理だけでなく、すべてのストレージ要求に対してプロビジョニング処理が失敗します。
Trident ontap-nas
および ontap-san
ドライバによって、作成された各Kubernetes Persistent Volume(PV;永続ボリューム)用のFlexVolがプロビジョニングされます。。 ontap-nas-economy
ドライバは、200 PVSごとに約1つのFlexVolを作成します(50~300で構成可能)。。 ontap-san-economy
ドライバは、PVS 100個につきFlexVolを約1つ作成します(50~200の間で設定可能)。Trident がストレージシステム上の使用可能なボリュームをすべて消費しないようにするには、 SVM に制限を設定する必要があります。コマンドラインから実行できます。
vserver modify -vserver <svm_name> -max-volumes <num_of_volumes>
の値 max-volumes
環境に固有のいくつかの条件によって異なります。
-
ONTAP クラスタ内の既存のボリュームの数
-
他のアプリケーション用に Trident 外部でプロビジョニングするボリュームの数
-
Kubernetes アプリケーションで消費されると予想される永続ボリュームの数
。 max-volumes
値は、ONTAP クラスタ内のすべてのノードでプロビジョニングされているボリュームの合計であり、個々のONTAP ノードではプロビジョニングされていません。その結果、 ONTAP クラスタノードの Trident でプロビジョニングされたボリュームの数が、別のノードよりもはるかに多い、または少ない場合があります。
たとえば、 2 ノードの ONTAP クラスタでは、最大 2 、 000 個の FlexVol をホストできます。最大ボリューム数を 1250 に設定していると、非常に妥当な結果が得られます。 ただし、のみの場合 "アグリゲート" あるノードから SVM に割り当てられている場合や、あるノードから割り当てられたアグリゲートをプロビジョニングできない場合(容量など)は、他のノードが Trident でプロビジョニングされたすべてのボリュームのターゲットになります。つまり、そのノードがボリューム数の上限に達するまでの可能性があります max-volumes
の値に達したため、そのノードを使用するTridentと他のボリューム処理の両方に影響が生じます。* クラスタ内の各ノードのアグリゲートを、 Trident が使用する SVM に同じ番号で確実に割り当てることで、この状況を回避できます。 *
Trident で作成できるボリュームの最大サイズを制限
Tridentで作成できるボリュームの最大サイズを設定するには、を使用します limitVolumeSize
のパラメータ backend.json
定義(Definition):
ストレージアレイでボリュームサイズを制御するだけでなく、 Kubernetes の機能も利用する必要があります。
双方向 CHAP を使用するように Trident を設定します
バックエンド定義で CHAP イニシエータとターゲットのユーザ名とパスワードを指定し、 Trident を使用して SVM で CHAP を有効にすることができます。を使用する useCHAP
バックエンド構成のパラメータであるTridentは、CHAPを使用してONTAP バックエンドのiSCSI接続を認証します。双方向 CHAP のサポートは Trident 20.04 以降で利用できます。
SVM QoS ポリシーを作成して使用します
SVM に適用された ONTAP QoS ポリシーを使用すると、 Trident でプロビジョニングされたボリュームが使用できる IOPS の数が制限されます。 これはに役立ちます "Bully を防止します" Trident SVM 外のワークロードに影響を及ぼす、制御不能なコンテナ。
SVM の QoS ポリシーはいくつかの手順で作成します。正確な情報については、ご使用の ONTAP バージョンのマニュアルを参照してください。 次の例は、 SVM で使用可能な合計 IOPS を 5000 に制限する QoS ポリシーを作成します。
# create the policy group for the SVM qos policy-group create -policy-group <policy_name> -vserver <svm_name> -max-throughput 5000iops # assign the policy group to the SVM, note this will not work # if volumes or files in the SVM have existing QoS policies vserver modify -vserver <svm_name> -qos-policy-group <policy_name>
また、使用しているバージョンの ONTAP でサポートされている場合は、最小 QoS を使用してコンテナ化されたワークロードへのスループットを保証することもできます。アダプティブ QoS は SVM レベルのポリシーには対応していません。
コンテナ化されたワークロード専用の IOPS は、さまざまな要素によって異なります。その中には、次のようなものがあります。
-
ストレージアレイを使用するその他のワークロード。Kubernetes 環境とは関係なく、ストレージリソースを利用するほかのワークロードがある場合は、それらのワークロードが誤って影響を受けないように注意する必要があります。
-
想定されるワークロードはコンテナで実行されます。IOPS 要件が高いワークロードをコンテナで実行する場合は、 QoS ポリシーの値が低いとエクスペリエンスが低下します。
SVM レベルで割り当てた QoS ポリシーを使用すると、 SVM にプロビジョニングされたすべてのボリュームで同じ IOPS プールが共有されることに注意してください。コンテナ化されたアプリケーションの 1 つまたは少数のに高い IOPS が必要な場合、コンテナ化された他のワークロードに対する Bully になる可能性があります。その場合は、外部の自動化を使用したボリュームごとの QoS ポリシーの割り当てを検討してください。
ONTAP バージョン 9.8 より前の場合は、 QoS ポリシーグループを SVM * only * に割り当ててください。 |
Trident の QoS ポリシーグループを作成
Quality of Service ( QoS ;サービス品質)は、競合するワークロードによって重要なワークロードのパフォーマンスが低下しないようにします。ONTAP の QoS ポリシーグループには、ボリュームに対する QoS オプションが用意されており、ユーザは 1 つ以上のワークロードに対するスループットの上限を定義できます。QoS の詳細については、を参照してください "QoS によるスループットの保証"。
QoS ポリシーグループはバックエンドまたはストレージプールに指定でき、そのプールまたはバックエンドに作成された各ボリュームに適用されます。
ONTAP には、従来型とアダプティブ型の 2 種類の QoS ポリシーグループがあります。従来のポリシーグループは、最大スループット(以降のバージョンでは最小スループット)がフラットに表示されます。アダプティブ QoS では、ワークロードのサイズの変更に合わせてスループットが自動的に調整され、 TB または GB あたりの IOPS が一定に維持されます。これにより、何百何千という数のワークロードを管理する大規模な環境では大きなメリットが得られます。
QoS ポリシーグループを作成するときは、次の点に注意してください。
-
を設定する必要があります
qosPolicy
キーを押しますdefaults
バックエンド構成のブロック。次のバックエンド設定例を参照してください。
--- version: 1 storageDriverName: ontap-nas managementLIF: 0.0.0.0 dataLIF: 0.0.0.0 svm: svm0 username: user password: pass defaults: qosPolicy: standard-pg storage: - labels: performance: extreme defaults: adaptiveQosPolicy: extremely-adaptive-pg - labels: performance: premium defaults: qosPolicy: premium-pg
-
ボリュームごとにポリシーグループを適用して、各ボリュームがポリシーグループの指定に従ってスループット全体を取得するようにします。共有ポリシーグループはサポートされません。
QoS ポリシーグループの詳細については、を参照してください "ONTAP 9.8 QoS コマンド"。
ストレージリソースへのアクセスを Kubernetes クラスタメンバーに制限する
Trident によって作成される NFS ボリュームと iSCSI LUN へのアクセスを制限することは、 Kubernetes 環境のセキュリティ体制に欠かせない要素です。これにより、 Kubernetes クラスタに属していないホストがボリュームにアクセスしたり、データが予期せず変更されたりすることを防止できます。
ネームスペースは Kubernetes のリソースの論理的な境界であることを理解することが重要です。ただし、同じネームスペース内のリソースは共有可能であることが前提です。重要なのは、ネームスペース間に機能がないことです。つまり、 PVS はグローバルオブジェクトですが、 PVC にバインドされている場合は、同じネームスペース内のポッドからのみアクセス可能です。* 適切な場合は、名前空間を使用して分離することが重要です。 *
Kubernetes 環境でデータセキュリティを使用する場合、ほとんどの組織で最も懸念されるのは、コンテナ内のプロセスがホストにマウントされたストレージにアクセスできることですが、コンテナ用ではないためです。 "ネームスペース" この種の妥協を防ぐように設計されています。 ただし、特権コンテナという例外が 1 つあります。
権限付きコンテナは、通常よりもホストレベルの権限で実行されるコンテナです。デフォルトでは拒否されないため、を使用してこの機能を無効にしてください "ポッドセキュリティポリシー"。
Kubernetes と外部ホストの両方からアクセスが必要なボリュームでは、 Trident ではなく管理者が導入した PV で、ストレージを従来の方法で管理する必要があります。これにより、 Kubernetes と外部ホストの両方が切断され、ボリュームを使用していない場合にのみ、ストレージボリュームが破棄されます。また、カスタムエクスポートポリシーを適用して、 Kubernetes クラスタノードおよび Kubernetes クラスタの外部にあるターゲットサーバからのアクセスを可能にすることもできます。
専用のインフラノード(OpenShiftなど)や、ユーザアプリケーションをスケジュールできない他のノードを導入する場合は、ストレージリソースへのアクセスをさらに制限するために別 々 のエクスポートポリシーを使用する必要があります。これには、これらのインフラノードに導入されているサービス( OpenShift Metrics サービスや Logging サービスなど)のエクスポートポリシーの作成と、非インフラノードに導入されている標準アプリケーションの作成が含まれます。
専用のエクスポートポリシーを使用します
Kubernetes クラスタ内のノードへのアクセスのみを許可するエクスポートポリシーが各バックエンドに存在することを確認する必要があります。Trident では、 20.04 リリース以降、エクスポートポリシーを自動的に作成、管理できます。これにより、 Trident はプロビジョニング対象のボリュームへのアクセスを Kubernetes クラスタ内のノードに制限し、ノードの追加や削除を簡易化します。
また、エクスポートポリシーを手動で作成し、各ノードのアクセス要求を処理する 1 つ以上のエクスポートルールを設定することもできます。
-
を使用します
vserver export-policy create
ONTAP のCLIコマンドを使用してエクスポートポリシーを作成します。 -
を使用して、エクスポートポリシーにルールを追加します
vserver export-policy rule create
ONTAP CLIコマンド。
これらのコマンドを実行すると、データにアクセスできる Kubernetes ノードを制限できます。
無効にします showmount
アプリケーションSVM用
。 showmount
機能を使用すると、NFSクライアントがSVMを照会して、使用可能なNFSエクスポートのリストを表示できます。Kubernetesクラスタに導入されたポッドは、問題 に対応しています showmount -e
コマンドをデータLIFに対して実行し、アクセス権のないマウントも含めて使用可能なマウントのリストを取得します。これだけではセキュリティ上の妥協ではありませんが、権限のないユーザが NFS エクスポートに接続するのを阻止する可能性のある不要な情報が提供されます。
を無効にする必要があります showmount
SVMレベルのONTAP CLIコマンドを使用して、次の作業を行います。
vserver nfs modify -vserver <svm_name> -showmount disabled
SolidFire のベストプラクティス
Trident に SolidFire ストレージを設定するためのベストプラクティスをご確認ください。
SolidFire アカウントを作成します
各 SolidFire アカウントは固有のボリューム所有者で、 Challenge Handshake Authentication Protocol ( CHAP ;チャレンジハンドシェイク認証プロトコル)クレデンシャルのセットを受け取ります。アカウントに割り当てられたボリュームには、アカウント名とその CHAP クレデンシャルを使用してアクセスするか、ボリュームアクセスグループを通じてアクセスできます。アカウントには最大 2 、 000 個のボリュームを関連付けることができますが、 1 つのボリュームが属することのできるアカウントは 1 つだけです。
QoS ポリシーを作成する
標準的なサービス品質設定を作成して保存し、複数のボリュームに適用する場合は、 SolidFire のサービス品質( QoS )ポリシーを使用します。
QoS パラメータはボリューム単位で設定できます。QoS を定義する 3 つの設定可能なパラメータである Min IOPS 、 Max IOPS 、 Burst IOPS を設定することで、各ボリュームのパフォーマンスが保証されます。
4KB のブロックサイズの最小 IOPS 、最大 IOPS 、バースト IOPS の値を次に示します。
IOPSパラメータ | 定義( Definition ) | 最小価値 | デフォルト値 | 最大値( 4KB ) |
---|---|---|---|---|
最小 IOPS |
ボリュームに対して保証されたレベルのパフォーマンス。 |
50です |
50です |
15、000 |
最大 IOPS |
パフォーマンスはこの制限を超えません。 |
50です |
15、000 |
20万 |
バースト IOPS |
短時間のバースト時に許容される最大 IOPS 。 |
50です |
15、000 |
20万 |
Max IOPS と Burst IOPS は最大 200 、 000 に設定できますが、実際のボリュームの最大パフォーマンスは、クラスタの使用量とノードごとのパフォーマンスによって制限されます。 |
ブロックサイズと帯域幅は、 IOPS に直接影響します。ブロックサイズが大きくなると、システムはそのブロックサイズを処理するために必要なレベルまで帯域幅を増やします。帯域幅が増えると、システムが処理可能な IOPS は減少します。を参照してください "SolidFire のサービス品質" QoS およびパフォーマンスの詳細については、を参照してください。
SolidFire 認証
Element では、認証方法として CHAP とボリュームアクセスグループ( VAG )の 2 つがサポートされています。CHAP は CHAP プロトコルを使用して、バックエンドへのホストの認証を行います。ボリュームアクセスグループは、プロビジョニングするボリュームへのアクセスを制御します。CHAP はシンプルで拡張性に制限がないため、認証に使用することを推奨します。
Trident と強化された CSI プロビジョニングツールは、 CHAP 認証の使用をサポートします。VAG は、従来の CSI 以外の動作モードでのみ使用する必要があります。 |
CHAP 認証(イニシエータが対象のボリュームユーザであることの確認)は、アカウントベースのアクセス制御でのみサポートされます。認証に CHAP を使用している場合は、単方向 CHAP と双方向 CHAP の 2 つのオプションがあります。単方向 CHAP は、 SolidFire アカウント名とイニシエータシークレットを使用してボリュームアクセスを認証します。双方向の CHAP オプションを使用すると、ボリュームがアカウント名とイニシエータシークレットを使用してホストを認証し、ホストがアカウント名とターゲットシークレットを使用してボリュームを認証するため、ボリュームを最も安全に認証できます。
ただし、 CHAP を有効にできず VAG が必要な場合は、アクセスグループを作成し、ホストのイニシエータとボリュームをアクセスグループに追加します。アクセスグループに追加した各 IQN は、 CHAP 認証の有無に関係なく、グループ内の各ボリュームにアクセスできます。iSCSI イニシエータが CHAP 認証を使用するように設定されている場合は、アカウントベースのアクセス制御が使用されます。iSCSI イニシエータが CHAP 認証を使用するように設定されていない場合は、ボリュームアクセスグループのアクセス制御が使用されます。
詳細情報の入手方法
ベストプラクティスのドキュメントの一部を以下に示します。を検索します "NetApp ライブラリ" 最新バージョンの場合。
-
ONTAP *
-
"SAN アドミニストレーションガイド" ( iSCSI の場合)
-
Element ソフトウェア *
-
NetApp HCI *
-
アプリケーションのベストプラクティス情報 *
すべてのアプリケーションに具体的なガイドラインがあるわけではありません。そのためには、ネットアップのチームと協力し、を使用することが重要です "NetApp ライブラリ" 最新のドキュメントを検索できます。