Azure Storage Mover のスケールとパフォーマンスのターゲット
ストレージ移行サービスのパフォーマンスは、移行の重要な側面です。 この記事ではパフォーマンス テストの結果を共有しますが、Azure Storage Mover は新しいサービスであるため、実際のエクスペリエンスは異なる場合があります。
スケール ターゲット
Azure Storage Mover は、 サポートされているソースから Azure でサポートされているターゲットに 移行された 1 億個の名前空間項目 (ファイルとフォルダー) でテストされます。
テスト方法
Azure Storage Mover はハイブリッド クラウド サービスです。 ハイブリッド サービスには、クラウド サービス コンポーネントと、サービスの管理者が企業環境で実行するインフラストラクチャ コンポーネントがあります。 Storage Mover の場合、そのハイブリッド コンポーネントは移行エージェントで構成されます。 エージェントは仮想マシンであり、ソース ストレージの近くのホストで実行されます。
エージェントのみが、パフォーマンス テストに関連するサービスの一部です。 プライバシーとパフォーマンスに関する問題を省略するために、データは Storage Mover エージェントから Azure のターゲット ストレージに直接移動されます。 制御メッセージとテレメトリ メッセージのみがクラウド サービスに送信されます。
パフォーマンス ベースライン
これらのテスト結果は、理想的な条件下で作成されます。 これらは、Storage Mover サービスとエージェントが直接影響を与えることができるコンポーネントのベースラインとして意図されています。 ソース デバイス、ディスク、およびネットワーク接続の違いは、このテストでは考慮されません。 実際のパフォーマンスは異なります。
SMB マウントから Azure ファイル共有への移行のテストは、次のように実行されました。
次の表では、SMB マウントから Azure ファイル共有へのパフォーマンス テスト結果を生成したテスト環境の特性について説明します。
| テスト番号 | 不正解です。 ファイル数 | ファイルの合計の重み | ファイル サイズ | フォルダー構造 |
|---|---|---|---|---|
| 1 | 1,200 万 | 12 GB | 各 1 KB | 12 個のフォルダーと、そのそれぞれに 10,000 個のファイルを含む 100 個のサブフォルダー |
| 2 | 30 | 20 GB | 1 個のフォルダー | |
| 3 | 100 万 | 100 GB | 各 100 KB | 1,000 個のフォルダーと、そのそれぞれに 1,000 個のファイル |
| 4 | 1 | 4 TB | ||
| 5 | 1 億 1700 万 | 117 GB | 各 1 KB | 117 個のフォルダーと、そのそれぞれに 10,000 個のファイルを含む 100 個のサブフォルダー |
| 6 | 1 | 1 TB (テラバイト) | ||
| 7 | 330 万 | 45 GB | 各 13 KB | 200,000 個のフォルダーと、そのそれぞれに 16\17 個のファイル |
| 8 | 5 千万 | 1 TB (テラバイト) | 各 20 KB | 2,940,000 個のフォルダーと、そのそれぞれに 17 個のファイル |
| 9 | 1 億 | 2 TB | 各 20 KB | 5,880,000 個のフォルダーと、そのそれぞれに 17 個のファイル |
さまざまなエージェント リソース構成が SMB エンドポイントでテストされました。
最小仕様: 4 CPU / 8 GB RAM 2.7 GHz の 4 つの仮想 CPU コアと 8 GiB のメモリ (RAM) が、Azure Storage Mover エージェントの最小仕様です。
テスト番号 実行時間 スキャン時間 6 16 分 42 秒 1.2 秒 7 55 分 4 秒 1 分 17 秒 8 9 ブート仕様: 8 CPU / 16 GB RAM 2.7 GHz の 8 つの仮想 CPU コアと 16 GiB のメモリ (RAM) が、Azure Storage Mover エージェントの最小仕様です。
結果: Standard ストレージ アカウント
テスト番号 実行時間 スキャン時間 1 15 時間 59 分 2 時間 36 分 34 秒 2 1 分 54 秒 3.34 秒 3 1 時間 19 分 27 秒 57.62 秒 4 1 時間 5 分 57 秒 2.89 秒 結果: 大きなファイルが有効になっている Standard ストレージ アカウント
テスト番号 実行時間 スキャン時間 1 3 時間 51 分 31 秒 41 分 45 秒 5 25 時間 47 分 23 時間 35 分 6 11 分 11 秒 0.7 秒 7 55 分 10 秒 1 分 3 秒 8 9 結果: Premium ストレージ アカウント
テスト番号 実行時間 スキャン時間 1 2 時間 35 分 14 秒 24 分 46 秒 5 23 時間 34 分 21 時間 34 分
エージェントのデプロイに関する記事で、移行スコープに推奨されるエージェント リソースを確認します。
移行のパフォーマンスが異なる理由
基本的に、ネットワークの品質と、ファイル、フォルダー、およびそのメタデータを処理する機能は、移行の速度に影響します。
ネットワークとコンピューティングの 2 つのコア領域全体で、いくつかの側面が影響を受けます。
- 移行シナリオ
空のターゲットへのコピーは、コンテンツを含むターゲットと比較して高速です。 この動作は、移行エンジンがコピーの判断を行うために、ソースだけでなくターゲットも評価する必要があるためです。 - 名前空間の項目数
1 GiB の小さなファイルを移行する場合、1 GiB の大きなファイルを移行するよりも時間がかかります。 - 名前空間のシェイプ
ワイド フォルダー階層は、狭いディレクトリ構造や深いディレクトリ構造よりも並列処理に役立ちます。 また、ファイルとフォルダーの比率もロールをプレイします。 - 名前空間のチャーン
同じソースから同じターゲットへの 2 つのコピー実行の間に変更されたファイル、フォルダー、およびメタデータの数。 - Network
- ソースエージェントと移行エージェントの間の帯域幅と待機時間
- Azure の移行エージェントとターゲットの間の帯域幅と待機時間
- 移行エージェント リソース
メモリの量 (RAM)、コンピューティング コアの数、および使用可能な容量であっても、移行エージェントのローカル ディスク容量は、移行速度に大きな影響を与える可能性があります。 より多くのコンピューティング リソースは、特に移行で大量の小さなファイルを処理する必要がある場合に、使用可能な帯域幅の使用率を最適化するのに役立ちます。
たとえば、従来の移行では、移行するストレージに依存するワークロードのダウンタイムを最小限に抑える戦略が必要です。 Azure Storage Mover では、このような戦略がサポートされています。 これは、コンバージデントの n パス移行と呼ばれます。
この戦略では、ソースからターゲットに複数回コピーします。 これらのコピーの反復中、ソースはワークロードへの読み取りと書き込みに引き続き利用できます。 最後のコピーの反復の直前に、ソースをオフラインにします。 最後のコピーは、これまでに作成した最初のコピーと言うよりも速く完了し、直前のコピーと同じくらいの時間がかかることが予想されます。 最後のコピーの後、ワークロードがフェールオーバーされ、Azure の新しいターゲット ストレージが使用され、再び使用が可能になります。
ソースからターゲットへの最初のコピー中は、ターゲットが空である可能性が高く、すべてのソース コンテンツはターゲットに移動する必要があります。 その結果、最初のコピーは、使用可能なネットワーク リソースによって最も制約される可能性があります。
移行の終了に向けて、ソースをターゲットに既に数回コピーした場合、最後のコピー以降に変更されたファイル、フォルダー、およびメタデータはごくわずかになります。 この最後のコピー イテレーションでは、ソースとターゲットの各ファイルを比較して、更新する必要があるかどうかを確認します。必要なコンピューティング リソースが増え、ネットワーク リソースは少なくなります。 このような後期段階の移行でのコピー実行は、多くの場合、コンピューティングの制約が高くなります。 Storage Mover エージェントのリソース割り当てを適切に行うことがますます重要になります。
次のステップ
次の記事は、Azure Storage Mover のデプロイの成功に役立ちます。