ONTAPにおけるpNFSのユースケース
pNFS をさまざまなONTAP機能と組み合わせて使用することで、パフォーマンスが向上し、NFS ワークロードの柔軟性が向上します。
nconnect を使用した pNFS
NFS では、最近のクライアントとサーバーに新しいマウント オプションが導入され、単一の IP アドレスをマウントしながら複数の TCP 接続を配信できるようになりました。これにより、操作をより適切に並列化し、NFS サーバーとクライアントの制限を回避し、特定のワークロードの全体的なパフォーマンスを向上させるメカニズムが提供されます。クライアントが nconnect をサポートしている場合、nconnect はONTAP 9.8 以降でサポートされます。
pNFS で nconnect を使用する場合、NFS サーバーによってアドバタイズされた各 pNFS デバイス上で nconnect オプションを使用して接続が並列化されます。たとえば、nconnect が 4 に設定されていて、pNFS に適切なインターフェースが 4 つある場合、作成される接続の合計数はマウント ポイントごとに最大 16 になります (4 つの nconnect x 4 つの IP アドレス)。
NFSv4.1 セッション トランキングを備えた pNFS
NFSv4.1 セッショントランキング ("RFC 5661、セクション2.10.5") は、データ転送速度を向上させるために、クライアントとサーバー間で複数の TCP 接続を使用することです。NFSv4.1 セッション トランキングのサポートがONTAP 9.14.1 に追加されました。セッション トランキングもサポートするクライアントで使用する必要があります。
ONTAPでは、クラスタ内の複数のノード間でセッション トランキングを使用することで、接続全体で追加のスループットと冗長性を実現できます。
セッション トランキングは複数の方法で確立できます。
-
マウント オプションを使用して自動的に検出: 最新の NFS クライアントのセッション トランキングは、マウント オプション (OS ベンダーのドキュメントを確認してください) を使用して確立できます。このオプションは、セッション トランクに関する情報をクライアントに送り返すように NFS サーバーに信号を送ります。この情報はNFSパケットを介して次のように表示されます。
fs_location4電話。使用されるマウント オプションは、クライアントの OS バージョンによって異なります。例えば、Ubuntu Linuxフレーバーでは一般的に
max_connect=nセッション トランクを使用するように通知します。RHEL Linuxディストリビューションでは、trunkdiscoveryマウントオプションが使用されます。Ubuntuの例mount -o vers=4.1,max_connect=8 10.10.10.10:/pNFS /mnt/pNFS
RHELの例mount -o vers=4.1,trunkdiscovery 10.10.10.10:/pNFS /mnt/pNFS
使用しようとする場合 max_connectRHEL ディストリビューションでは、代わりに nconnect として扱われ、セッション トランキングは期待どおりに動作しません。 -
手動で確立: 個々の IP アドレスを同じエクスポート パスとマウント ポイントにマウントすることで、セッション トランキングを手動で確立できます。たとえば、同じノードに2つのIPアドレス(10.10.10.10と10.10.10.11)があり、エクスポートパスが `/pNFS`マウントコマンドを2回実行します。
mount -o vers=4.1 10.10.10.10:/pNFS /mnt/pNFS mount -o vers=4.1 10.10.10.11:/pNFS /mnt/pNFS
トランクに参加させたいすべてのインターフェースでこのプロセスを繰り返します。
|
|
各ノードは独自のセッション トランクを取得します。トランクはノードを通過しません。 |
|
|
pNFS を使用する場合は、セッション トランキングまたは nconnect のみを使用します。両方を使用すると、メタデータ サーバー接続のみが nconnect の利点を得て、データ サーバーは単一の接続を使用するなど、望ましくない動作が発生します。 |
pNFS は、クラスター内の各参加ノードへのローカル パスを提供できます。また、セッション トランキングと組み合わせて使用すると、pNFS はノードごとにセッション トランクを活用して、クラスター全体のスループットを最大化できます。
いつ trunkdiscovery が使用される場合、マウント インターフェイスが配置されている NFS サーバー ノード上のリストされたセッション トランク インターフェイスに対して、追加の GETATTR 呼び出し (FS_Locations) が活用されます。これらが返されると、返されたアドレスに対して後続のマウントが行われます。これはマウント中のパケットキャプチャで確認できます。
pNFS と NFSv4.1 の参照
NFSv4.1 リファラルは、マウント要求時にクライアントをボリュームの場所に誘導する初期マウント パス リダイレクトのモードを提供します。NFSv4.1 リファーラルは単一の SVM 内で機能します。この機能は、NFS マウントをデータ ボリュームと同じノードにあるネットワーク インターフェイスにローカライズしようとします。そのインターフェイスまたはボリュームがクライアントにマウントされている間に別のノードに移動すると、新しいマウントが確立されるまでデータ パスはローカライズされなくなります。
pNFS はマウント パスのローカライズを試行しません。代わりに、マウント パスを使用してメタデータ サーバーを確立し、必要に応じてデータ パスを動的にローカライズします。
NFSv4.1 参照は pNFS で使用できますが、機能は必要ありません。pNFS で紹介を有効にしても、目立った結果は得られません。
pNFS と高度な容量バランス調整の相互作用
"高度な容量分散" ONTAPでは、 FlexGroupボリュームの構成ボリューム全体にファイル データの一部を書き込みます (単一のFlexVolボリュームではサポートされません)。ファイルが大きくなると、 ONTAP は、同じノードまたは別のノードにある別の構成ボリューム上の新しいマルチパート inode にデータの書き込みを開始することを決定します。これらのマルチ inode ファイルへの書き込み、読み取り、およびメタデータ操作は透過的であり、クライアントに中断を及ぼしません。高度な容量バランス調整により、 FlexGroup構成ボリューム間のスペース管理が改善され、より一貫したパフォーマンスが実現します。
pNFS は、NFS サーバーに保存されているファイル レイアウト情報に応じて、データ IO をローカライズされたネットワーク パスにリダイレクトできます。単一の大きなファイルが、クラスタ内の複数のノードにまたがる可能性のある複数の構成ボリュームにまたがって部分的に作成される場合でも、 ONTAPはすべてのファイル部分のファイル レイアウト情報も保持するため、 ONTAPの pNFS は各ファイル部分にローカライズされたトラフィックを提供できます。ファイルが読み取られると、データ パスの局所性は必要に応じて変更されます。