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

現在、ノードの種類は"AFX 1K"で、読み取りと書き込みのスループットは、おおよそ以下の値となります。新しいハードウェアがNetApp AFXで利用可能になると、これらの制限は変更される可能性があります。注：以下の「ベンチマーク結果」セクションに示すように、複数のクライアントが複数のファイルを読み書きすることで、最大のパフォーマンスが得られました。

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

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

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

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

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

たとえば、統合ONTAPクラスタでは、各ノードに独自のディスクセットがあるため、パフォーマンスはそのノードが所有するディスクのみに向けられます。また、1つのディスクセットには1つのノードしかアクセスできないため、使用可能なディスクを必ずしも飽和状態にして最大のパフォーマンスを達成できるとは限りません。

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

NetApp AFXはすべてのディスクを単一のストレージ可用性ゾーンに統合するため、すべてのノードがすべてのディスクを活用できます。ディスクとノードが分離されているため、同じパフォーマンスを得るために必要なシェルフの数が少なくて済みます。これによりパフォーマンスが凝縮され、シェルフの最大パフォーマンスポテンシャルが最大限に引き出されます。

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

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

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

ONTAP 9.19.1の時点で、ノード：シェルフの飽和比は約4：1です。

次のセクションでは、以下の構成パラメータを持つ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クライアントはファイルがロックされているかどうかを認識できない場合がある。