ONTAPの pNFS はFlexVolボリュームとFlexGroupボリュームの両方で動作しますが、全体的に最良の結果を得るにはFlexGroupボリュームを使用します。

FlexGroupボリュームは以下を提供します。

"FlexGroupボリューム管理について学ぶ"

すべてのNFSクライアントがpNFSをサポートしているわけではありませんが、最近のクライアントのほとんどはpNFSをサポートしています。RHEL 6.4とFedora 17は、最初にpNFSをサポートしたクライアント（およそ2014年）であるため、過去数年間にリリースされたクライアントバージョンは、この機能を完全にサポートしていると想定するのが妥当です。ONTAP の NFS サポートのスタンスは、「クライアントが機能をサポートし、RFC に準拠しており、当社がその機能をサポートしている場合、その組み合わせはサポートされます」というものです。ただし、クライアント OS ベンダーが pNFS をサポートしていることを確認することがベスト プラクティスです。

ONTAP は、同じクラスタ内のノードまたはアグリゲート間でボリュームを中断なく移動し、容量とパフォーマンスのバランスを柔軟に調整する機能を提供します。ONTAPでボリュームの移動が行われると、pNFS デバイス マッピングが自動的に更新され、必要に応じて新しいボリュームとインターフェイスの関係を使用するようにクライアントに通知されます。

"ボリュームの移動について学ぶ"

ONTAP は、同じクラスタ内のノード間でネットワーク インターフェイスを移動する機能を提供し、パフォーマンスのバランスとメンテナンスの柔軟性を実現します。ボリュームの移動と同様に、 ONTAPでネットワーク インターフェイスの移行が行われると、pNFS デバイス マッピングが自動的に更新され、必要に応じて新しいボリュームとインターフェイスの関係を使用するようにクライアントに通知されます。

ただし、NFSv4.1 はステートフル プロトコルであるため、ネットワーク インターフェイスの移行は、NFS マウントをアクティブに使用しているクライアントに混乱をもたらす可能性があります。ネットワーク インターフェイスの移行をメンテナンス ウィンドウに実行し、ネットワークの中断の可能性をクライアントに通知することがベスト プラクティスです。

pNFS は、NFSv4.1 と同じストレージ フェイルオーバーの考慮事項に従います。これらについては、 "NetAppテクニカルレポート4067：『NFS Best Practice and Implementation Guide』"一般に、pNFS に関連するストレージのフェイルオーバー/ギブバックは、プロトコルのステートフル性によりストレージの中断が発生する可能性があることを考慮して、メンテナンス ウィンドウ内で実行する必要があります。

メタデータ操作はサイズが小さく、ワークロードに応じて数が大きくなる可能性があります (多数のファイルを作成しますか? 「find」コマンドを実行していますか? ) およびファイルの合計数。その結果、メタデータ呼び出しの多いワークロードは NFS サーバーの CPU に負担をかけ、単一の接続でボトルネックになる可能性があります。pNFS (および NFSv4.x 全般) は、ステートフルネス、ロック メカニズム、およびプロトコル バージョンの一部のセキュリティ機能が CPU 使用率とレイテンシに悪影響を与える可能性があるため、パフォーマンスに依存する高メタデータ ワークロードには適していません。これらのワークロード タイプ (GETATTR や SETATTR が高い場合など) は、通常、NFSv3 の方が適しています。

pNFS のメタデータ サーバーは、NFS エクスポートの最初のマウント時に確立されます。マウント ポイントが確立されると、再マウントされるかデータ インターフェイスが移動されるまで、そのマウント ポイントはそのまま残ります。このため、同じボリュームにアクセスする複数のクライアントが、SVM 全体の異なるノードとデータ インターフェイスにマウントされるようにすることがベスト プラクティスです。このアプローチにより、クラスター内のネットワーク インターフェイスを最大限に活用しながら、ノードと CPU リソース全体でメタデータ サーバーの負荷分散が実現します。これを実現する一つの方法は、ラウンドロビンDNS設定を確立することです。これは "NetAppテクニカルレポート 4523: ONTAPにおける DNS ロードバランシング"。

NFSv4.xは、さまざまな方法でセキュリティ機能を提供します（詳細は "NetAppテクニカルレポート4067：『NFS Best Practice and Implementation Guide』"）。NFSv4.x ID ドメインはそのような方法の 1 つであり、NFS エクスポートでユーザーとグループを認証しようとするときに、クライアントとサーバーは ID ドメインに同意する必要があります。ID ドメインの不一致の副作用の 1 つは、望ましくないアクセスを防ぐために、ユーザーまたはグループが匿名ユーザーとして表示される (基本的に押しつぶされた) ことです。NFSv4.x (および pNFS) では、クライアントとサーバーの NFSv4.x ID ドメインが一致するようにすることがベスト プラクティスです。

前述したように、 ONTAPの nconnect は、一部のワークロードのパフォーマンスを向上させるのに役立ちます。pNFS では、nconnect によってストレージ システムへの TCP 接続の総数が大幅に増加してパフォーマンスが向上する一方で、多くのクライアントがマウント オプションを利用してストレージ上の TCP 接続を圧倒することで問題が発生する可能性があることを理解することが重要です。NetApp Hardware Universe、ノードあたりの TCP 接続制限について説明します。

ノードの TCP 接続制限を超えると、既存の接続が解放されるまで新しい TCP 接続は許可されません。これにより、山の嵐が発生する可能性のある環境では複雑な問題が発生する可能性があります。

次の表は、nconnect を使用した pNFS が TCP 接続制限を超える可能性があることを示しています。

¹ ほとんどのONTAPシングルノード TCP 接続制限を超えています

ONTAPのセッション トランキングを使用すると、NFSv4.x マウントに対するスループットとパスの復元力を向上させることができます。pNFS と併用すると、クラスター内の各ノードはセッション トランクを確立できます。ただし、セッション トランクではノードごとに少なくとも 2 つのインターフェイスが必要であり、pNFS では意図したとおりに動作するためにノードごとに少なくとも 1 つのインターフェイスが必要です。さらに、SVM 内のすべてのインターフェイスは NFS クライアントにルーティング可能である必要があります。nconnect も活用している場合、セッション トランキングと pNFS は正常に動作しません。nconnect とセッション トランキングは相互に排他的な機能として考慮してください。

"NFSトランキングについて学ぶ"

pNFS が適切に機能するには、クラスター内の各ノードにルーティング可能なネットワーク インターフェイスが必要です。pNFS をホストしている NFS サーバと同じ SVM 内に、NFS クライアントにルーティングできない他のネットワーク インターフェイスが存在する場合でも、 ONTAP はデバイス マッピングでそれらのインターフェイスをクライアントにアドバタイズします。NFS クライアントが別のサブネット内のインターフェース経由でデータにアクセスしようとすると、接続できず、障害が発生します。pNFS を使用する場合は、クライアントがアクセスできる SVM 内のネットワーク インターフェイスのみを許可するのがベスト プラクティスです。

NFSv4.0 は、NFSv4.1 と並行してONTAP NFS サーバーで有効にできるオプションです。ただし、pNFS は NFSv4.0 では動作しません。NFS サーバーで NFSv4.0 が有効になっている場合、クライアントは知らないうちにそのプロトコル バージョンをマウントする可能性があり、pNFS を活用できなくなります。したがって、pNFS を使用する場合は、NFSv4.0 を明示的に無効にすることがベスト プラクティスです。NFSv4.1 は引き続き有効にする必要があり、NFSv4.0 とは独立して動作できます。

NFSv4.1 参照は、クライアントからボリュームを所有するノード上のネットワーク インターフェイスへのマウント パスをローカライズします。pNFS はデータ パスをローカライズし、マウント パスはメタデータ サーバーになります。

これら 2 つの機能は併用可能ですが、NFSv4.1 参照を pNFS で使用すると、複数のメタデータ サーバーが同じノードにスタックされ、複数のクラスター ノードにメタデータ サーバーを分散する能力が低下するという望ましくない影響が生じる可能性があります。pNFS を使用する際にメタデータ サーバーがクラスター全体に均等に分散されていない場合、単一ノードの CPU がメタデータ要求で過負荷になり、パフォーマンスのボトルネックが発生する可能性があります。

そのため、pNFS を使用するときは NFSv4.1 参照を使用しないことがベスト プラクティスです。代わりに、マウント ポイントをクラスター内の複数のネットワーク インターフェイスとノードに分散します。

"NFSv4 紹介の有効化または無効化について学習します"

NFS Kerberos を使用すると、krb5 を使用して認証を暗号化し、さらに krb5i と krb5p を使用してデータ パケットを暗号化できます。これはSVMのネットワークインターフェースごとに有効化され、詳細は "ネットアップテクニカルレポート 4616 ：『 NFS Kerberos in ONTAP with Microsoft Active Directory 』"。

pNFS は SVM 内のノードおよびネットワーク インターフェイス間でデータ トラフィックをリダイレクトできるため、SVM 内の各ネットワーク インターフェイスで NFS Kerberos が有効になっていて機能している必要があります。SVM 内のいずれかのネットワーク インターフェイスで Kerberos が有効になっていない場合、それらのインターフェイス上のデータ ボリュームにアクセスしようとしても pNFS は正常に機能しません。

たとえば、2 つのネットワーク インターフェイス (Kerberos が有効になっているのは 1 つだけ) を備えた pNFS 対応 SVM で並列 dd を使用して読み取りテストを実行すると、Kerberos 対応インターフェイスにあるファイルは適切に実行されましたが、Kerberos が有効になっていないインターフェイスを持つノードにあるファイルは読み取りを完了できませんでした。両方のインターフェースで Kerberos を有効にすると、すべてのファイルが期待どおりに実行できるようになりました。

SVM 内のすべてのネットワーク インターフェイスで NFS Kerberos が有効になっている場合は、pNFS で NFS Kerberos を使用できます。NFS Kerberos では、パケットの暗号化/復号化によってパフォーマンスが低下する可能性があることに留意してください。そのため、パフォーマンスの低下がワークロードに過度の影響を与えないことを確認するために、NFS Kerberos を使用した pNFS をワークロードで徹底的にテストすることがベスト プラクティスです。

以下は、RHEL 9.5 クライアント上の pNFS で krb5 (認証) と krb5p (エンドツーエンド暗号化) を使用した場合の並列読み取りパフォーマンスの例です。このテストでは、Krb5p のパフォーマンスが 70% 低下しました。

"強力なセキュリティを実現する NFS を使用した Kerberos について学ぶ"

NFSv4.2 はONTAP 9.8 に追加され、利用可能な最新の NFSv4.x バージョンです (RFC-7862)。NFSv4.2 には、これを有効化/無効化する明示的なオプションはありません。代わりに、NFSv4.1と一緒に有効化/無効化されます。 (-4.1 enabled）。クライアントがNFSv4.2をサポートしている場合、マウントコマンド中にNFSの最高サポートバージョンをネゴシエートします。 minorversion=2 マウント オプション。

ONTAPの NFSv4.2 は次の機能をサポートしています。

pNFS は NFSv4.1 で導入されましたが、NFSv4.2 でも、付随する機能とともにサポートされています。

"ONTAPのNFSv4.2サポートについて"