ONTAPにおけるpNFSのユースケース
変更を提案
PDF
pNFSはさまざまなONTAP機能と併用して、NFSワークロードのパフォーマンスを向上させ、柔軟性を高めることができます。
nconnect を使用した pNFS
NFSは、最近のクライアントとサーバーに新しいマウントオプションを導入しました。これにより、単一のIPアドレスをマウントしながら複数のTCP接続を提供することができます。これにより、処理の並列化が向上し、NFSサーバとクライアントの制限を回避できるようになり、特定のワークロードの全体的なパフォーマンスが向上する可能性があります。nconnectは、クライアントがnconnectをサポートしている場合、ONTAP 9.8以降でサポートされます。
pNFSでnconnectを使用する場合、NFSサーバによってアドバタイズされる各pNFSデバイスに対して、nconnectオプションを使用して接続が並列化されます。例えば、nconnectが4に設定され、pNFSに使用できるインターフェースが4つある場合、作成される接続の総数はマウントポイントごとに最大16（nconnect 4個 × IPアドレス4個）になります。
NFSv4.1セッショントランキングを使用したpNFS
NFSv4.1セッション トランキング("RFC 5661、セクション2.10.5"）は、クライアントとサーバ間で複数のTCP接続を使用することで、データ転送速度を向上させるものです。NFSv4.1セッション トランキングのサポートはONTAP 9.14.1で追加されており、セッション トランキングをサポートするクライアントと併用する必要があります。
ONTAPでは、NFSv4.1セッショントランキングは、クラスタ内の単一ノード上の複数の物理インターフェイスにわたって使用され、独立した接続間で追加のスループットと冗長性を提供します。
pNFSと併用することで、これらのトランクはクラスタ全体にわたってより高い総合的なパフォーマンスを提供できます。
セッショントランキングは複数の方法で確立されます：
-
*マウントオプションによる自動検出：*最新の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
RHEL ディストリビューションで `max_connect`を使用しようとすると、代わりに nconnect として扱われ、セッション トランキングは期待どおりに機能しません。 -
*手動で確立：*個々のIPアドレスを同じエクスポート パスとマウント ポイントにマウントすることで、セッション トランキングを手動で確立できます。例えば、エクスポート パスが `/pNFS`である同じノードに2つのIPアドレス（10.10.10.10と10.10.10.11）がある場合、マウント コマンドを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はマウント パスのローカライズを試みません。代わりに、マウント パスを使用してメタデータ サーバを確立し、必要に応じてデータ パスを動的にローカライズします。
pNFSでもNFSv4.1リファラルを使用できますが、その機能は不要です。pNFSでリファラルを有効にしても、目立った効果は得られません。
pNFSと高度な容量バランス調整の相互作用
"高度な容量バランシング"ONTAPでは、ファイルデータの一部をFlexGroupボリュームを構成する複数のボリュームに書き込みます（単一FlexVolボリュームではサポートされません）。ファイルのサイズが大きくなると、ONTAPは別の構成ボリューム（同じノードまたは異なるノード）上の新しいマルチパートinodeへのデータの書き込みを開始します。これらのマルチinodeファイルへの書き込み、読み取り、およびメタデータ操作は、クライアントに対して透過的で、中断を伴いません。高度な容量バランス調整により、FlexGroup構成ボリューム間のスペース管理が改善され、より安定したパフォーマンスが実現します。
pNFSは、NFSサーバに格納されているファイル レイアウト情報に応じて、データIOをローカライズされたネットワーク パスにリダイレクトできます。単一の大きなファイルが、クラスタ内の複数のノードにまたがる可能性のある複数の構成ボリュームに分割して作成される場合でも、ONTAPのpNFSは、すべてのファイル パートのファイル レイアウト情報も保持しているため、各ファイル パートにローカライズされたトラフィックを提供できます。ファイルが読み取られると、データ パスのローカル性は必要に応じて変化します。
