Azure NetApp Files 大容量ボリュームの Linux 用パフォーマンス ベンチマーク
この記事では、Linux のユース ケースに関連した、単一の Azure NetApp Files 大容量ボリュームのテスト済みパフォーマンス機能について説明します。 テストでは、1 台の仮想マシン (VM) と多数の仮想マシンに関連する、読み取りと書き込みのワークロードのスケールアウトとスケールアップの両方のシナリオについて調査しました。 大容量ボリュームのパフォーマンス エンベロープを把握すると、ボリュームのサイズ設定が容易になります。
テストの概要
Azure NetApp Files の大容量ボリューム機能では、3 つのサービス レベルが提供されており、それぞれにスループットの制限があります。 パフォーマンス ニーズの変化に応じて、サービス レベルを中断なくスケールアップまたはスケールダウンできます。
- Ultra サービス レベル: 12,800 MiB/秒
- Premium サービス レベル: 6,400 MiB/秒
- 標準サービス レベル: 1,600 MiB/秒
これらのテストでは、Ultra サービス レベルが使用されました。
シーケンシャル書き込み: これらのベンチマークでは、100% シーケンシャル書き込みの最大値は 8,500 MiB/秒でした。 (単一の大容量ボリュームの最大スループットは、サービスによって 12,800 MiB/秒に制限されるため、より多くの潜在的なスループットが可能です。)
シーケンシャル読み取り: これらのベンチマークでは、100% シーケンシャル読み取りの最大値は 12,761 MiB/秒でした。 (単一の大容量ボリュームの最大スループットは、12,800 MiB/秒に制限されます。この結果は、現時点で達成可能な最大スループットに近くなります。)
ランダム I/O: 同じ単一の大容量ボリュームでは、1 秒あたり 700,000 を超える操作が提供されます。
メタデータが多いワークロードは、大容量ボリュームの並列処理が促進されるため、Azure NetApp File 大容量ボリュームに有利です。 パフォーマンス上の利点は、VCS アプリケーションで一般的に行われるファイルの作成、リンク解除、ファイル名の変更が多いワークロードや、ファイル数が多い EDA ワークロードで顕著になります。 メタデータが多いワークロードのパフォーマンスの詳細については、「電子設計自動化に Azure NetApp Files を使用するメリット」を参照してください。
ストレージ ストレス テストとして設計された合成ワークロード ジェネレーターである FIO を使用して、これらのテスト結果が導かれました。 ストレージ パフォーマンス テストには基本的に 2 つのモデルがあります。
- スケールアウト コンピューティング。これは、複数の VM を使用して、単一の Azure NetApp Files ボリュームで可能な最大負荷を生成することを指します。
- スケールアップ コンピューティング。これは、大規模な VM を使用して、単一の Azure NetApp Files ボリューム上の 1 つのクライアントの上限をテストすることを指します。
Linux スケールアウト テスト
テストでは、スケールアウト時に単一の大容量ボリュームのパフォーマンスしきい値が観察され、次の構成で実行されました。
| コンポーネント | 構成 |
|---|---|
| Azure VM サイズ | E32s_v5 |
| Azure VM エグレス帯域幅の制限 | 2,000 MiB/秒 (2GiB/秒) |
| オペレーティング システム | RHEL 8.4 |
| 大容量ボリュームのサイズ | 101 TiB Ultra (12,800 MiB/秒のスループット) |
| マウント オプション | hard,rsize=65536,wsize=65536,vers=3 注: 262144 と 65536 の両方を使用すると、同様のパフォーマンス結果が得られます。 |
256 KiB シーケンシャル ワークロード (MiB/秒)
このグラフは、1 TiB ワーキング セットを使用して単一の大容量ボリュームに対する 12 台の仮想マシンの読み取りと書き込みを使用する 256 KiB のシーケンシャル ワークロードを表します。 このグラフは、約 8,518 MiB/秒の純粋なシーケンシャル書き込みから約 12,761 MiB/秒の純粋なシーケンシャル読み取りまでの範囲で単一の Azure NetApp Files 大容量ボリュームが処理できることを示しています。
8 KiB ランダム ワークロード (IOPS)
グラフは、8 KiB のランダム ワークロードと 1 TiB のワーキング セットを表します。 このグラフは、Azure NetApp Files 大容量ボリュームが、約 474,000 回の純粋なランダム書き込みから約 709,000 回の純粋なランダム読み取りまでの範囲で処理できることを示しています。
Linux スケールアップ テスト
スケールアウト テストは単一の大容量ボリュームの制限を見つけるために設計されていますが、スケールアップ テストは、上記の大容量ボリュームに対する単一インスタンスの上限を見つけるために設計されています。 Azure では、VM にネットワーク エグレスの制限を設定します。ネットワーク接続ストレージの場合は、書き込み帯域幅が VM ごとに制限されることを意味します。 これらのスケールアップ テストは、使用可能な帯域幅の上限が大きく、そのワークロードを実行するのに十分なプロセッサを備えている場合の機能を示しています。
このセクションのテストは、次の構成で実行されました。
| コンポーネント | 構成 |
|---|---|
| Azure VM サイズ | E104id_v5 |
| Azure VM エグレス帯域幅の制限 | 12,500 MiB/秒 (12.2 GiB/秒) |
| オペレーティング システム | RHEL 8.4 |
| 大容量ボリュームのサイズ | 101 TiB Ultra (12,800 MiB/秒のスループット) |
| マウント オプション | hard,rsize=65536,wsize=65536,vers=3 注: 262144 と 65536 の両方を使用すると、同様のパフォーマンス結果が得られます |
このセクションのグラフは、NFSv3 を使用したクライアント側マウント オプションの nconnect の結果を示しています。 詳細については、「Azure NetApp Files 用の Linux NFS マウント オプションのベスト プラクティス」を参照してください。
次のグラフでは、nconnect の利点を nconnect のない NFS マウント ボリュームの利点と比較します。 テストでは、FIO は、64 KiB のシーケンシャル ワークロードを使用して、米国東部 Azure リージョンの単一の E104id-v5 インスタンスからワークロードを生成しました。使用した I/O サイズは 256 で、これは、Azure NetApp Files で推奨される最大の I/O サイズであり、同等のパフォーマンス数が得られました。 詳細については、次のトピックを参照してください。 rsize および wsize
Linux の読み取りスループット
次のグラフは、約 10,000 MiB/秒の nconnect を使用した 256 KiB シーケンシャル読み取りを示しています。これは、nconnect を使用しない場合に到達するスループットの約 10 倍です。
10,000 MiB/秒は、E104id_v5 に接続されている 100 Gbps ネットワーク アダプター カードのライン レートとほぼ同じであることに注意してください。
Linux の書き込みスループット
次のグラフは、シーケンシャル書き込みを示しています。 nconnect を使用すると、6,600 MiB/秒のシーケンシャル書き込みに対して、nconnect を指定しないマウントの約 4 倍の観測可能なメリットが得られます。
Linux の読み取り IOPS
次のグラフは、nconnect を使用した最大 426,000 の読み取り IOPS の 8 KiB ランダム読み取りを示しています。これは、nconnect を使用しない場合の計測結果の約 7 倍です。
Linux の書き込み IOPS
次のグラフは、nconnect を指定した最大 405,000 回の書き込み IOPS の 8 KiB ランダム書き込みを示しています。この値は、nconnect を指定しない場合に測定される結果の約 7.2 倍です。
