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