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

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

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

すべてのNFSクライアントがpNFSをサポートしているわけではありませんが、最近のクライアントのほとんどはサポートしています。RHEL 6.4とFedora 17は、最初にpNFSをサポートしたクライアントです（2014年頃）。そのため、ここ数年でリリースされたクライアントバージョンは、この機能を完全にサポートしていると想定しても問題ありません。ONTAPのNFSサポートに関するスタンスは、「クライアントが機能をサポートし、RFCに準拠しており、かつONTAPもその機能をサポートしている場合、その組み合わせはサポートされます」というものです。ただし、クライアント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リソース間でメタデータ サーバのロード バランシングが実現され、クラスタ内のネットワーク インターフェイスを最大限に活用できます。これを実現する方法の1つとして、ラウンドロビンDNS設定を確立することが挙げられます。これについては "NetAppテクニカルレポート4523：ONTAPにおけるDNSロードバランシング"で説明します。

NFSv4.xは様々な方法でセキュリティ機能を提供します（詳細は "NetAppテクニカル レポート4067：『NFS Best Practice and Implementation Guide』"で説明されています）。NFSv4.x IDドメインはその一つで、NFSエクスポートでユーザーとグループを認証する際に、クライアントとサーバーはIDドメインについて合意する必要があります。IDドメインの不一致による副作用の一つとして、不要なアクセスを防ぐために、ユーザーまたはグループが匿名ユーザー（実質的には圧縮されたユーザー）として表示されることがあります。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クライアントにルーティング可能である必要があります。セッション トランキングとpNFSは、nconnectも併用すると正常に動作しません。nconnectとセッション トランキングは相互に排他的な機能であることを考慮してください。

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

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

NFSv4.0は、ONTAP NFSサーバでNFSv4.1と併用できるオプションです。ただし、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 内のネットワークインターフェースごとに有効化され、詳細は "NetApp テクニカルレポート 4616：ONTAP における NFS Kerberos と 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はパケットの暗号化/復号化によってパフォーマンスが低下する可能性があることにご注意ください。そのため、パフォーマンスの低下がワークロードに過度の影響を及ぼさないことを確認するために、ワークロードでpNFSとNFS Kerberosを徹底的にテストすることをお勧めします。

以下は、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をサポートしている場合、 `minorversion=2`マウント オプションで別途指定しない限り、マウント コマンドの実行中にサポートされているNFSの最新バージョンがネゴシエートされます。

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

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

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