この記事では、Azure Blob Storage 上のネットワーク ファイル システム バージョン 3 (NFS 3.0) のベンチマーク テストの推奨事項と結果について説明します。 NFS 3.0 は主に Linux 環境で使用されるため、この記事では Linux ツールのみに焦点を当てています。 多くの場合、他のオペレーティング システムを使用できますが、ツールやコマンドが変更される可能性があります。
概要
ストレージ パフォーマンス テストは、さまざまなストレージ サービスを評価および比較するために行われます。 これを実行する方法は多数ありますが、最も一般的な方法は次の 3 つです。
- 標準の Linux コマンド (通常は
cpまたはdd) を使用します。 -
fio、vdbench、iorなどのパフォーマンス ベンチマーク ツールを使用します。 - 運用環境で使用される実際のアプリケーションを使用します。
どの方法を使用する場合でも、環境内の他の潜在的なボトルネックを理解し、結果に影響を与えないことを確認することが常に重要です。 たとえば、書き込みパフォーマンスを測定するときは、ソース ディスクが予想される書き込みパフォーマンスと同じ速度でデータを読み取ることができることを確認する必要があります。
読み取りパフォーマンスにも同じ原則が適用されます。 これらのテストでは、RAM ディスクを使用できるのが理想的です。 ネットワーク スループットと CPU 使用率に関して同様の考慮事項を作成する必要があります。
標準の Linux コマンドを使用します。 この方法は、パフォーマンス ベンチマーク テストで最も簡単ですが、最も推奨が最も少ない方法でもあります。 この方法は、すべての Linux 環境にツールが存在し、ユーザーが使い慣れているため、簡単です。 結果は、ストレージのパフォーマンスだけでなく、多くの側面が影響を与えるため、慎重に分析する必要があります。 通常使用される 2 つのコマンド:
-
cpコマンドは、ソースから宛先ストレージ サービスに 1 つ以上のファイルをコピーし、操作を完全に完了するまでの時間を測定します。 このコマンドは、ダイレクト IO ではなくバッファー処理を実行し、バッファー サイズ、オペレーティング システム、スレッド モデルに依存します。 一方、一部の実際のアプリケーションは、同様の動作をし、場合によっては適切なユース ケースを表します。 -
ddコマンドはシングル スレッドです。 大規模な帯域幅テストでは、結果は 1 つの CPU コアの速度によって制限されます。 複数のコマンドを同時に実行して異なるコアに割り当てることは可能ですが、その手法ではテストと集計の結果が複雑になります。 また、一部のパフォーマンス ベンチマーク ツールよりも実行がはるかに簡単です。
-
パフォーマンス ベンチマーク ツールを使用します。 このメソッドは、さまざまなストレージ サービスを比較するために一般的に使用される合成パフォーマンス テストを表します。 ツールは、使用可能なクライアント リソースを使用してストレージのスループットを最大化するように適切に設計されています。 ほとんどのツールは構成可能であり、実際のアプリケーション (少なくとも単純なアプリケーション) を模倣できます。 実際のアプリケーションを模倣するには、アプリケーションの動作とそのストレージ パターンの理解に関する詳細情報が必要です。
実際のアプリケーションを使用します。 この方法は、ユーザーがストレージ サービス上で実行している実際のワークロードのパフォーマンスを測定するため、常に最適です。 この方法は、運用環境のレプリカとユーザーがシステムに適切な負荷を生成する必要があるため、多くの場合、実用的ではありません。 一部のアプリケーションには負荷生成機能があり、パフォーマンス ベンチマークに使用する必要があります。
| テスト方法 | 利点 | 短所 |
|---|---|---|
| Standard Linux コマンド | -簡単。 - 任意の Linux プラットフォームで使用できます。 - ツールに関する知識。 |
- パフォーマンス テスト用に設計されていません。 - 構成できません。 - 多くの場合、CPUコアに制約されています。 |
| パフォーマンス ベンチマーク ツール | - パフォーマンス テスト用に最適化されています。 - 非常に構成可能。 - 単純なマルチノード テスト。 |
実際のテストを設定するのは複雑です。 |
| 実際の応用 | - 正確なユーザー エクスペリエンスを提供します。 | - 多くの場合、ユーザーはテストを実行します。 - 運用環境のレプリカが必要です。 - 主観的な可能性があります。 |
パフォーマンス テストに実際のアプリケーションを使用するのが最適なオプションですが、テストのセットアップが簡単なため、パフォーマンス ベンチマーク ツールを使用するのが最も一般的な方法です。 NFS 3.0 を使用して Azure Blob Storage でパフォーマンス テストを実行するための推奨設定を示します。
ヒント
ほとんどのパフォーマンス テスト方法は、単一クライアントのパフォーマンスに重点を置きます。 スケールアウト テストを実行するには、マルチクライアント テスト ( fio や vdbenchなど) を調整できるパフォーマンス ベンチマーク ツールを使用します。 カスタム オーケストレーション レイヤーを構築することもできます。
仮想マシンのサイズを選択する
パフォーマンス テストを適切に実行するには、最初の手順として、テストで使用する仮想マシン (VM) のサイズを正しく設定します。 VM は、パフォーマンス ベンチマーク ツールを実行するクライアントとして機能します。 このテストの VM サイズを選択する際に最も重要な側面は、使用可能なネットワーク帯域幅です。 選択した VM が大きいほど、より優れた結果を得ることができます。 Azure でテストを実行する場合は、 汎用 VM のいずれかを使用することをお勧めします。
NFS 3.0 を使用してストレージ アカウントを作成する
VM を選択したら、テストで使用するストレージ アカウントを作成する必要があります。 詳細なガイダンスについては、「 ネットワーク ファイル システム (NFS) 3.0 プロトコルを使用した Blob Storage のマウント」を参照してください。 テストする前に、 Azure Blob Storage の NFS 3.0 のパフォーマンスに関する考慮事項 を読み取うことをお勧めします。
その他の考慮事項
- NFS 3.0 エンドポイントを持つ VM とストレージ アカウントは、同じリージョンに存在する必要があります。
- テスト アプリケーションを実行している VM は、実行中の他のサービスが結果に影響を与えないことを確認するために、テストにのみ使用する必要があります。
- マウント NFS 3.0 エンドポイントでは、信頼性の高いアクセスのために AzNFS マウント ヘルパー クライアントを使用する必要があります。
パフォーマンス ベンチマークの実行
Linux 環境では、いくつかのパフォーマンス ベンチマーク ツールを使用できます。 これらのいずれも使用して、パフォーマンスを評価できます。 推奨されるアプローチは、フレキシブル I/O (FIO) テスターと共有します。 FIO は、Linux ディストリビューションごとに、または ソース コードとして、標準パッケージ マネージャーを通じて利用できます。 多くのテスト シナリオで使用できます。
この記事では、Azure Storage に推奨されるシナリオについて説明します。 その他のカスタマイズとさまざまなパラメーターについては、 FIO のドキュメントを参照してください。
テストには次のパラメーターが使用されます。
| ワークロード | メトリック | ブロック サイズ | スレッド数 | I/O 深度 | ファイル サイズ | nconnect |
ダイレクト IO |
|---|---|---|---|---|---|---|---|
| 逐次 | Bandwidth | 1 メビバイト (MiB) | 8 | 1024 | 10 GiB | 16 | イエス |
| 逐次 | IOPS | 4 KiB | 8 | 1024 | 10 GiB | 16 | イエス |
| ランダム | IOPS | 4 KiB | 8 | 1024 | 10 GiB | 16 | イエス |
テストのセットアップは、クライアント VM の種類 が D32ds_v5 でファイル サイズが 10 GB の米国東部リージョンで行われました。 すべてのテストは 100 回実行され、結果には平均値が表示されます。 Standard ストレージ アカウントと Premium ストレージ アカウントでテストが行われました。 2 種類のストレージ アカウントの違いの詳細については、「ストレージ アカウント の概要」を参照してください。
シーケンシャル帯域幅の測定
読み取り帯域幅
fio --name=seq_read_bw --ioengine=libaio --directory=/mnt/test_folder --direct=1 --blocksize=1M --readwrite=read --filesize=10G --end_fsync=1 --numjobs=8 --iodepth=1024 --runtime=60 --group_reporting --time_based=1
書き込み帯域幅
fio --name=seq_write_bw --ioengine=libaio --directory=/mnt/test_folder --direct=1 --blocksize=1M --readwrite=write --filesize=10G --end_fsync=1 --numjobs=8 --iodepth=1024 --runtime=60 --group_reporting --time_based=1
結果
シーケンシャル IOPS の測定
IOPS の読み取り
fio --name=seq_read_iops --ioengine=libaio --directory=/mnt/test_folder --direct=1 --blocksize=4K --readwrite=read --filesize=10G --end_fsync=1 --numjobs=8 --iodepth=1024 --runtime=60 --group_reporting --time_based=1
書き込み IOPS
fio --name=seq_write_iops --ioengine=libaio --directory=/mnt/test_folder --direct=1 --blocksize=4K --readwrite=write --filesize=10G --end_fsync=1 --numjobs=8 --iodepth=1024 --runtime=60 –group_reporting –time_based=1
結果
注
シーケンシャル IOPS テストの結果には、1 秒あたりの要求に対 するストレージ アカウントの制限 を超える値が表示されます。 IOPS はクライアント側で測定されます。 値が大きいのは、サービスの最適化とテストのシーケンシャルな性質が原因です。
ランダム IOPS を測定する
"IOPS を読む"
fio --name=rnd_read_iops --ioengine=libaio --directory=/mnt/test_folder --direct=1 --blocksize=4K --readwrite=randread --filesize=10G --end_fsync=1 --numjobs=8 --iodepth=1024 --runtime=60 --group_reporting --time_based=1
書き込み IOPS
fio --name=rnd_write_iops --ioengine=libaio --directory=/mnt/test_folder --direct=1 --blocksize=4K --readwrite=randwrite --filesize=10G --end_fsync=1 --numjobs=8 --iodepth=1024 --runtime=60 –group_reporting –time_based=1
結果
注
完全性を得るためのランダム テストの結果が追加されます。 Blob Storage 上の NFS 3.0 エンドポイントは、ランダムな書き込みワークロードのストレージ サービスとしてお勧めしません。