ベンチマーク結果
次に、ベンチマーク結果を調べて、前のユニットで説明したパフォーマンスに関するヒントを検証します。 具体的には、EDA の実稼働に似たワークロードをシミュレートするために、SPEC SFS ベンチマーク スイートを使用して複数のスレッドを生成する方法について重点的に説明します。 また、FIO の結果を示して、パフォーマンスに関するプラクティスを調べます。
2 つのベンチマーク ツールの概要
SPEC SFS スイートは、EDA の標準的な業界ベンチマークです。 一般的な EDA ワークロードは、機能フェーズと物理フェーズで構成されます。 機能フェーズでは、主にランダム I/O とファイルシステム メタデータ操作が実行されます。 物理フェーズでは、大きいブロックのシーケンシャルな読み取りおよび書き込みが行われます。
FIO は I/O ツールであり、一貫性のあるランダムまたはシーケンシャルな読み取りと書き込みの負荷を生成して、ストレージ ターゲットの IOPS とスループットをベンチマークできます。
Azure NetApp Files のボリュームの種類
Azure NetApp Files には、クラウド データ ストレージ用にプロビジョニングできるボリュームとして、通常のボリュームと大きなボリュームの 2 種類が用意されています。 この 2 つのボリュームの種類の主な違いを以下の表に示します。 この表をガイダンスとして使用して、ワークロードに適したボリュームの種類を選択してください。
| なし | 通常のボリューム | 大きなボリューム |
|---|---|---|
| 最小容量 | 100 GiB | 50 TiB |
| 最大キャパシティ | 100 TiB | 500 TiB |
| サポートされている最小のサービス レベル | Standard | Standard |
| 観察された最大スループット | 4,500 MiB/秒 | 10,240 MiB/秒 |
| 観察された最大読み取り IOPS | 最大 200,000 | 最大 700,000 |
| 観察された最大書き込み IOPS | 最大 135,000 | 最大 474,000 |
SPEC EDA ツールのベンチマーク結果 (通常のボリューム)
このセクションのグラフは、I/O と待機時間の曲線を示しています。 パフォーマンスに関する次のプラクティスについて、いくつかの組み合わせが調べられます。
nocto,actimeo=600sysctl tunednconnect=16
上記の 3 つのプラクティスをすべ適用した場合、1 秒あたりの I/O 操作の数が増加し、低遅延 (1 ミリ秒未満) が維持されます。
次のグラフは、このワークロードの種類の場合は、NFSv3 のパフォーマンスの方が NFSv4.1 よりもはるかに優れていることを示しています。
次のグラフは、rsize=wsize=262144(256 K) のパフォーマンスが、他の設定よりも優れていることを示しています。
SPEC EDA ツールのベンチマーク結果 (大きなボリューム)
パフォーマンスしきい値のテストは、次の構成で SPEC SFS ベンチマークを使用して、単一の大きなボリュームで実施されました。
| 構成のタイプ | 設定 |
|---|---|
| オペレーティング システム | RHEL 9.3 / RHEL 8.7 |
| インスタンスの種類 | D16s_v5 |
| インスタンス数 | 10 |
| マウント オプション | nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8 |
テストでは、SPEC SFS ベンチマークを使用した大きなボリュームのパフォーマンス機能を、Azure NetApp Files の通常のボリュームと比較しました。
| シナリオ | 2 ミリ秒での I/O レート | 2 ミリ秒での MiB/秒 |
|---|---|---|
| 1 つの通常ボリューム | 39,601 | 692 |
| 1 つの大容量ボリューム | 652,260 | 10,030 |
FIO ツールのベンチマーク結果 (通常のボリューム)
次の FIO コマンドはそれぞれ、IOPS とスループットをベンチマークします。
// FIO commands to benchmark IOPS:
// 8K Random Reads
fio --name=8krandomreads --rw=randread --direct=1 --ioengine=libaio --bs=8k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting
// 8K Random Writes
fio --name=8krandomwrites --rw=randwrite --direct=1 --ioengine=libaio --bs=8k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting
// FIO commands to benchmark throughput:
// 64K Sequential Reads
fio --name=64kseqreads --rw=read --direct=1 --ioengine=libaio --bs=64k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting
// 64K Sequential Writes
fio --name=64kseqwrites --rw=write --direct=1 --ioengine=libaio --bs=64k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting
次の 2 つのグラフは、nocto,actimeo=600、nconnect=16、sysctl がチューニング済みの場合、Azure NetApp Files がより高い IOPS とスループットを実現できることを示しています。
FIO ツールのベンチマーク結果 (大きなボリューム)
このセクションでは、FIO ベンチマークを使用した単一の大きなボリュームのパフォーマンスしきい値について説明します。 テストは次の構成で実行されました。
| コンポーネント | 構成 |
|---|---|
| Azure VM サイズ | E32s_v5 |
| Azure VM エグレス帯域幅の制限 | 2,000 MiB/秒 (2GiB/秒) |
| オペレーティング システム | RHEL 8.4 |
| 大容量ボリュームのサイズ | 101 TiB Ultra (10,240 MiB/秒のスループット) |
| マウント オプション | hard,rsize=65536,wsize=65536,vers=3 注: 262144 と 65536 の両方を使用すると、同様のパフォーマンス結果が得られます。 |
256 KiB シーケンシャル ワークロード (MiB/秒)
グラフは、256 KiB のシーケンシャル ワークロードと 1 TiB のワーキング セットを表しています。 これは、約 8,518 MiB/秒の純粋なシーケンシャル書き込みから約 9,970 MiB/秒の純粋なシーケンシャル読み取りまでの範囲で単一の Azure NetApp Files 大容量ボリュームが処理できることを示しています。
8 KiB ランダム ワークロード (IOPS)
グラフは、8 KiB のランダム ワークロードと 1 TiB のワーキング セットを表します。 このグラフは、Azure NetApp Files 大容量ボリュームが、約 474,000 回の純粋なランダム書き込みから約 709,000 回の純粋なランダム読み取りまでの範囲で処理できることを示しています。
