Azure NetApp Files 通常ボリュームの Linux 用パフォーマンス ベンチマーク

この記事では、Azure NetApp Files が通常ボリュームの Linux 向けに提供するパフォーマンス ベンチマークについて説明します。

ファイル ストリーミング ワークロード全体 (スケールアウト ベンチマーク テスト)

スケールアウト テストの目的は、同じボリュームに対して同時ワークロードを生成するクライアントの数をスケールアウトする (増やす) ときの、Azure NetApp Files ボリュームのパフォーマンスを示すことです。 これらのテストは、通常、パフォーマンス制限の限界までボリュームを増やすことができ、メディア レンダリング、AI/ML、大規模なコンピューティング ファームを利用して作業を実行するその他のワークロードを示しています。

高 I/OP スケールアウト ベンチマークの構成

これらのベンチマークでは、次のものが使われました。

• Ultra パフォーマンス レベルを使用し 1 TiB のデータセットを含む 1 つの Azure NetApp Files 100 TiB 通常ボリューム
• FIO (randrepeat=0 の設定あり/なし)
• 4 KiB と 8 KiB のブロック サイズ
• RHEL 9.3 を実行している 6 台の D32s_v5 仮想マシン
• NFSv3
• 手動 QoS
• マウント オプション: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

高スループット スケールアウト ベンチマークの構成

これらのベンチマークでは、次のものが使われました。

• Ultra パフォーマンス レベル FIO (randrepeat=0 の設定あり/なし) を使用し 1 TiB のデータセットを含む 1 つの Azure NetApp Files 通常ボリューム
• FIO (randrepeat=0 の設定あり/なし)
• 64 KiB と 256 KiB のブロック サイズ
• RHEL 9.3 を実行している 6 台の D32s_v5 仮想マシン
• NFSv3
• 手動 QoS
• マウント オプション: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

並列ネットワーク接続 (nconnect) ベンチマークの構成

これらのベンチマークでは、次のものが使われました。

• Ultra パフォーマンス レベルを使用し 1 TiB のデータセットを含む 1 つの Azure NetApp Files 通常ボリューム
• FIO (randrepeat=0 の設定あり/なし)
• 4 KiB と 64 KiB の wsize/rsize
• RHEL 9.3 を実行する 1 つの D32s_v4 仮想マシン
• NFSv3 (nconnect あり/なし)
• マウント オプション: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

スケールアップ ベンチマーク テスト

スケールアップ テストの目的は、1 つのクライアントで同じボリュームへの複数の TCP 接続に対して同時ワークロードを生成するジョブの数をスケールアップする (増やす) ときの、Azure NetApp Files ボリュームのパフォーマンスを示すことです (nconnect などを使用)。

nconnect を使わないと、クライアントは十分な IO またはネットワーク スループットを生成できないため、これらのワークロードはボリュームの最大パフォーマンスを限界まで高めることができません。 一般に、これらのテストは、メディア レンダリング、データベース、AI/ML、一般的なファイル共有などのワークロードで、1 人のユーザーのエクスペリエンスがどのようになる可能性があるかを示します。

高 I/OP スケールアウトのベンチマーク

以下のベンチマークは、次のものを使う高 I/OP ワークロードで Azure NetApp Files が達成するパフォーマンスを示します。

• 32 クライアント
• 4 KiB と 8 KiB のランダムな読み取りと書き込み
• 1 TiB のデータセット
• 読み取り/書き込み比率: 100%:0%、90%:10%、80%:20% など
• ファイル システム キャッシュがある場合とない場合 (FIO で randrepeat=0 を使用)

詳しくは、テスト手法に関する記事をご覧ください。

結果: 4 KiB、ランダム、クライアント キャッシュあり

このベンチマークでは、FIO はデータをランダム化する randrepeat オプションなしで実行されました。 したがって、予測できない量のキャッシュが発生しました。 この構成では、IO スタック全体を利用してキャッシュなしで実行されたテストより、全体的なパフォーマンスの数値が若干向上します。

次のグラフのテストでは、Azure NetApp Files の通常ボリュームが、このベンチマークの間に、約 130,000 回の純粋な 4 KiB のランダム書き込みから、約 460,000 回の純粋な 4 KiB のランダム読み取りまで処理できることを示しています。 実行ごとに 10% だけ調整されたワークロードの読み取り/書き込み混合。

読み取り/書き込み混合 I/OP の書き込み負荷が大きくなると、総 I/OPS は減少します。

結果: 4 KiB、ランダム、クライアント キャッシュなし

このベンチマークの FIO は、データのランダム化を randrepeat=0 に設定して実行され、パフォーマンスへのキャッシュの影響が減りました。 その結果、書き込み I/OPS は約 8% 減少し、読み取り I/OPS は約 17% 減少しましたが、これはストレージが実際に行えることのより典型的なパフォーマンス値を示します。

次のグラフのテストでは、Azure NetApp Files の通常ボリュームが、約 120,000 回の純粋な 4 KiB のランダム書き込みから、約 388,000 回の純粋な 4 KiB のランダム読み取りまで処理できることを示しています。 実行ごとに 25% だけ調整されたワークロードの読み取り/書き込み混合。

読み取り/書き込み混合 I/OP の書き込み負荷が大きくなると、総 I/OPS は減少します。

結果: 8 KiB、ランダム、クライアント キャッシュなし

読み取りと書き込みのサイズを大きくすると、各操作で送信できるデータが増えるので、総 I/OPS は少なくなります。 8 KiB の読み取りと書き込みのサイズは、最新のアプリケーションが使うものをより正確にシミュレートするために使われました。 たとえば、多くの EDA アプリケーションは、8 KiB の読み取りと書き込みを利用します。

このベンチマークでの FIO は、データのランダム化を randrepeat=0 にして実行され、クライアントのキャッシュの影響が減りました。 次のグラフのテストでは、Azure NetApp Files の通常ボリュームが、約 111,000 回の純粋な 8 KiB のランダム書き込みから、約 293,000 回の純粋な 8 KiB のランダム読み取りまで処理できることを示しています。 実行ごとに 25% だけ調整されたワークロードの読み取り/書き込み混合。

読み取り/書き込み混合 I/OP の書き込み負荷が大きくなると、総 I/OPS は減少します。

並べて比較する

キャッシュがパフォーマンス ベンチマーク テストに与える影響がわかるよう、次のグラフでは、キャッシュ メカニズムを使った場合と使わない場合の、4 KiB テストの合計 I/OPS を示します。 図に示すように、キャッシュを使うと、かなり一貫した傾向として I/OPS のパフォーマンスは若干向上します。

特定のオフセット、ランダム読み取り/書き込みワークロードのストリーミング: 並列ネットワーク接続を使用したスケールアップ テスト (nconnect)

次に示すのは、単一のクライアント、4 KiB のランダム ワークロード、1 TiB のデータセットを使用する高 I/OP ベンチマークのテストです。 生成される混合ワークロードでは、毎回異なる I/O 深度が使われます。 単一クライアント ワークロードのパフォーマンスを高めるため、nconnect マウント オプションを使って、nconnect マウント オプションを使わないクライアント マウントと比較して並列性を向上させました。

ストレージへのパスを 1 つだけ提供する標準 TCP 接続を使うと、マウント ポイントごとにさらに多くの TCP 接続を利用できる場合 (nconnect を使う場合など) より、1 秒あたりの合計操作数が少なくなります。 nconnect を使うと、操作の合計待ち時間は一般に短くなります。 また、これらのテストは、キャッシュを意図的に回避するために randrepeat=0 で実行されています。 このオプションについて詳しくは、テスト手法に関する記事をご覧ください。

結果: 4 KiB、ランダム、nconnect あり/なし、キャッシュなし

次のグラフは、nconnect を使用した場合と使用しない場合の 4 KiB の読み取りと書き込みを並べて比較し、nconnect を使った場合に見られるパフォーマンスの向上 (全体的な I/OPS の増加、待ち時間の短縮) がよくわかるようにしたものです。

高スループットのベンチマーク

以下のベンチマークは、高スループット ワークロードで Azure NetApp Files が達成するパフォーマンスを示します。

高スループット ワークロードは、シーケンシャル性が高く、多くの場合、読み取り/書き込みが多く、メタデータは少なくなります。 一般に、I/OPS よりスループットの方が重要です。 これらのワークロードでは、通常、より大きな読み取り/書き込みサイズ (64K から 256K) が使われ、ペイロードが大きいほど処理に時間がかかるため、小さい読み取り/書き込みサイズよりも待ち時間が長くなります。

高スループット ワークロードの例には次のものが含まれます。

• メディア リポジトリ
• ハイ パフォーマンス コンピューティング
• AI/ML/LLP

次に示すのは、64 KiB と 256 KiB 両方のシーケンシャル ワークロードと 1 TiB のデータセットを使用する高スループット ベンチマークのテストです。 生成される混合ワークロードでは、一度に設定される割合が減少し、さまざまな読み取り/書き込み比率 (たとえば、100%:0%、90%:10%、80%:20% など) を使ったときに期待できることが示されます。

結果: 64 KiB シーケンシャル I/O、キャッシュあり

このベンチマークの FIO は、キャッシュをより積極的に設定するループ ロジックを使って実行したため、予測できないキャッシュ量が結果に影響を与えました。 その結果、キャッシュなしで実行されたテストより、全体的なパフォーマンスの数値が若干向上します。

次のグラフのテストでは、Azure NetApp Files の通常ボリュームは、約 4,500 MiB/秒の純粋なシーケンシャル 64 KiB 読み取りから、約 1,600 MiB/秒の純粋なシーケンシャル 64 KiB 書き込みまでを処理できることが示されています。 ワークロードの読み取り/書き込みの混合比は、実行ごとに 10% だけ調整されました。

結果: 64 KiB シーケンシャル I/O、キャッシュなし

このベンチマークの FIO は、キャッシュをあまり積極的に設定しないループ ロジックを使って実行しました。 クライアント キャッシュは結果に影響しませんでした。 この構成では、書き込みパフォーマンスの数値は若干向上しますが、キャッシュを使わないテストよりも読み取りの数は少なくなります。

次のグラフのテストでは、Azure NetApp Files の通常ボリュームは、約 3,600 MiB/秒の純粋なシーケンシャル 64 KiB 読み取りから、約 2,400 MiB/秒の純粋なシーケンシャル 64 KiB 書き込みまでを処理できることが示されています。 50/50 の混合比のテストでは、純粋なシーケンシャル読み取りワークロードと同等の合計スループットが示されました。

ワークロードの読み取り/書き込みの混合比は、実行ごとに 25% だけ調整されました。

結果: 256 KiB シーケンシャル I/O、キャッシュなし

このベンチマークの FIO は、キャッシュをあまり積極的に設定しないループ ロジックを使って実行したため、キャッシュは結果に影響しませんでした。 この構成では、書き込みパフォーマンスの数値は 64 KiB テストよりも若干低くなりますが、キャッシュなしでの同じ 64 KiB テストの実行よりも読み取りの数は増えます。

次のグラフのテストでは、Azure NetApp Files の通常ボリュームは、約 3,500 MiB/秒の純粋なシーケンシャル 256 KiB 読み取りから、約 2,500 MiB/秒の純粋なシーケンシャル 256 KiB 書き込みまでを処理できることが示されています。 50/50 の混合比のテストでは、合計スループットのピークは、純粋なシーケンシャル読み取りワークロードより高い値を示しました。

ワークロードの読み取り/書き込みの混合比は、実行ごとに 25% だけ増やして調整されました。

並べて比較

キャッシュがパフォーマンス ベンチマーク テストに与える影響がよくわかるよう、次のグラフでは、キャッシュ メカニズムを使った場合と使わない場合の、64 KiB テストの合計 MiB/秒を示します。 キャッシュを使うと、通常、書き込みより読み取りの向上の方が大きいため、合計 MiB/秒の初期パフォーマンスがわずかに向上します。 読み取り/書き込みの混合比率が変わると、キャッシュなしの合計スループットの方が、クライアント キャッシュを利用する結果より高くなります。

並列ネットワーク接続 (nconnect)

次に示すのは、単一のクライアント、64 KiB のランダム ワークロード、1 TiB のデータセットを使用する高 I/OP ベンチマークのテストです。 生成される混合ワークロードでは、毎回異なる I/O 深度が使われます。 単一クライアント ワークロードのパフォーマンスを高めるため、nconnect マウント オプションを利用して、nconnect マウント オプションを使わないクライアント マウントと比較して並列性を向上させました。 これらのテストは、キャッシュなしでのみ実行されました。

結果: 64 KiB、シーケンシャル、キャッシュなし、nconnect あり/なし

次に示すのは、1 つのクライアント上の NFSv3 マウントにおいて、操作の並列化 (nconnect) がある場合とない場合での、4 KiB チャンクを読み書きするときのスケールアップ テストの結果です。 このグラフは、I/O の深度が大きくなるほど、I/OPS も増えることを示しています。 ただし、ストレージへのパスを 1 つだけ提供する標準 TCP 接続を使うと、マウント ポイントごとにさらに多くの TCP 接続を利用できる場合より、1 秒あたりの合計操作数が少なくなります。 さらに、nconnect を使うと、操作の合計待ち時間は一般に短くなります。

並べて比較 (nconnect あり/なし)

次のグラフは、nconnect を使用した場合と使用しない場合の 64 KiB シーケンシャル読み取りと書き込みを並べて比較し、nconnect を使った場合に見られるパフォーマンスの向上 (全体的なスループットの増加、待ち時間の短縮) がよくわかるようにしたものです。

詳細

• テスト方法