各 NetApp AFX ストレージ ノードは、読み取りと書き込みに対して特定のスループット量を提供します。クラスターにノードが追加されると、"ノード性能の線形スケーリング" で説明されているように、パフォーマンスは直線的に向上します。

現在、ノードの種類は"AFX 1K"および"AFX 2K"であり、読み取りと書き込みのスループットはおおよそ以下の値になります*。新しいハードウェアがNetApp AFXで利用可能になると、これらの制限は変更される可能性があります。

ノードごとのパフォーマンス推定値

各シェルフには、16個の100GBイーサネットポートを備えた高性能シェルフモジュールが搭載されており、RoCEv2通信を利用して、クラスタ内のコンピューティングノードとの間で高帯域幅のストレージ通信を実現します。他の物理的な資源と同様に、これらのシェルフにも達成可能な最大値があります。特にNetApp AFXは、同じディスクセットを指す複数のノードを提示することができます。以下の表は、TLCおよびQLCドライブの場合の、単一シェルフにおける推定最大読み取りおよび書き込み性能を示しています。TLCとQLCの違いに関する詳細については、"TLCとQLC"を参照してください。

シェルフごとのパフォーマンス予測

分散型 ONTAP アーキテクチャでストレージ ノードとシェルフを分離することで、より多くのノードがより少ないシェルフにトラフィックをプッシュできるようになり、必要な容量のみで最大のパフォーマンスを得るために必要なデータセンター全体のフットプリントを削減できます。

この「パフォーマンス密度」という概念により、ストレージ管理者はストレージ環境を過剰にプロビジョニングすることなく、既存のハードウェアを最大限に活用できるようになります。

統一 ONTAP – パフォーマンスの配分方法

例えば、統合された ONTAP クラスターでは、各ノードに専用のディスク セットが備わっています。その結果、パフォーマンスはノードが所有するディスクのみに向けられます。1 つのノードしか 1 組のディスクにアクセスできないため、パフォーマンスは直接アクセスできるディスクに制限されます。

NetApp AFX – パフォーマンス密度

NetApp AFXは、利用可能なすべてのディスクをストレージ可用性ゾーン（SAZ）と呼ばれる単一の容量プールに統合します。その結果、すべてのノードが利用可能なすべてのディスクを読み取り / 書き込みに活用できるようになります。ディスクとノードが分離されているため、統合型ONTAPアーキテクチャと比較して、同じ（またはそれ以上の）スループット性能を得るために必ずしも多くのシェルフを必要とするわけではありません。NetApp AFXの分離型アーキテクチャは、ディスク シェルフのパフォーマンスの可能性を最大限に引き出します。

統合ONTAPノードには、ノードごとに少なくとも1セットのディスクが必要であり、1つのノードに複数のシェルフを接続することができる。その結果、単一ノードにおいてパフォーマンスのボトルネックが発生し、自身のディスクを飽和状態にできない可能性がある。

NetApp AFXは、すべてのディスクシェルフをすべてのノードに提示します。各シェルフには、16 x 100GB RoCE対応インターフェイスを備えたモジュールが搭載されており、シェルフあたりに許容される総パフォーマンス量を増加させます。このため、同じディスクセットに対して読み書きを行う複数のノードで単一のシェルフを飽和させることができます。

ONTAP 9.19.1以降、ノード：シェルフの飽和比は少なくとも4：1であり、8：3も可能です。

次のセクションでは、以下の構成パラメータを持つNetApp AFXクラスタを使用したベンチマーク結果について説明します。

上記の構成では、4ノードクラスタで利用可能な最大読み取り速度（約134GB/秒）に非常に近い値を達成し、ノードあたりに許可されている最大書き込み速度（40GB/秒）にほぼ達しました。

NetApp AFX – ElBencho 読み取りパフォーマンス、4 ノード

NetApp AFX – ElBencho 書き込みパフォーマンス、4 ノード

メディアストリーミングのワークロードでは、4K映画はしばしば数万個のファイルに分割され、各ファイルは通常50MBから250MBのサイズになります。各ファイルはフレームを表し、アプリケーションは1回の要求でフレーム全体を読み取ります。バッファリングが目立たず、スムーズで途切れのないストリームを維持するためには、これらのフレーム読み取りはドロップなしで完了する必要があります。

ONTAPでは、これらのワークロードを最適化するためのボリュームレベルのオプション(`-aggressive-readahead-mode`を提供しています。ONTAP 9.19.1以降、類似のファイルタイプ間で予測可能なI/Oパターンを持つワークロード（メディアレンダリングやストリーミングなど）を高速化するために、AFXでアグレッシブな先読み用の新しい `cross_file_sequential_read`モードが導入されました。

cross_file_sequential_read は、ファイル名に基づいて次に読み込むファイルを予測し、クライアントが read 呼び出しを発行する前に、それらのファイルに対して先読みを開始します。予測ロジックは、ディレクトリ内のすべてのファイルが、単調増加する数値の接尾辞（例：file1、file2、file3）を持つ命名パターンに従うことを前提としています。ディレクトリ内のすべてのファイルは、10進数または16進数のいずれかを使用して、このパターンに従う必要があります。ファイル名は最大255文字までです。このロジックは拡張子に依存せず、現在のディレクトリ内の次のファイル名セットを現在のファイル名のみに基づいて生成します。以前に10進数で生成されたファイル名がディレクトリ内に存在しない場合、ファイル名は16進数で再生成されます。生成されたファイル名がどれも存在しない場合、そのセットに対してプリフェッチは実行されません。プリフェッチは、次のクライアント読み取り要求が発行されたときに再開されます。

これらのオプションを有効にすると、"frametest"パフォーマンス ベンチマークでは、30クライアント（NFSv3およびSMB3）と34クライアント（NFSv4.1）で、30フレーム/秒で30,000個の4Kフレームを、フレーム落ちすることなく読み込むことができました。

ファイル間シーケンシャル読み取りは主にメディアワークロード向けに設計されていますが、AIのトレーニングや推論など、アクセスパターンやファイル名が予測可能な、読み取り負荷の高い他のワークロードにもメリットがあります。

NFSバージョン3は、1995年に初めて正式リリースされて以来、数十年にわたりNFSアプリケーションのゴールドスタンダードであり続けている。その優れた性能と堅牢性の組み合わせにより、より新しいNFSバージョンへの移行を検討することが難しいのは、それなりの理由がある。

しかし、NFSv3にも限界がないわけではない。プロトコルのステートレス性は、パフォーマンスの向上やストレージのフェイルオーバー時の障害を最小限に抑えるという点では優れているが、データの一貫性やロック管理という点では必ずしも優れているとは言えない。NFSサーバはロック状態を実際には追跡しないため、障害が発生した場合、NFSサーバはロックを解除する場合もあれば解除しない場合もあり、NFSクライアントはファイルがロックされているかどうかを認識できない場合がある。

NFSv3のセキュリティもやや不十分です。このプロトコルが正しく機能するには、複数のファイアウォールポートを開放する必要があり、数値IDは平文でネットワーク上に送信されます。さらに、NFSは堅牢なACLサポートを備えておらず、ネイティブなファイルおよびフォルダ監査機能も含まれていません。これらの制限の結果、NFSv4は2003年に"RFC-3530を使用したチャンク アップロード署名要求がサポートされるようになりました。"を通じて作成されました（2015年に"RFC-7530"により廃止）。

NFSv4.xは20年以上前から存在しているにもかかわらず、いくつかの理由からいまだに広く普及していない。