ストレージ移行サービスのパフォーマンスは、移行の重要な側面です。 この記事では、パフォーマンス テストの結果を共有しますが、Azure Storage Mover は新しいサービスであるため、エクスペリエンスが異なる場合があります。
スケール ターゲット
Azure Storage Mover は、5 億個の名前空間項目 (ファイルとフォルダー) でテストされ、 サポートされているソースから Azure でサポートされているターゲットに移行されます 。
テスト方法
Azure Storage Mover はハイブリッド クラウド サービスです。 ハイブリッド サービスには、クラウド サービス コンポーネントと、サービスの管理者が企業環境で実行するインフラストラクチャ コンポーネントがあります。 Storage Mover の場合、そのハイブリッド コンポーネントは移行エージェントです。 エージェントは仮想マシンであり、ソース ストレージの近くのホストで実行されます。
エージェントのみが、パフォーマンス テストに関連するサービスの一部です。 プライバシーとパフォーマンスの問題を省略するために、データは Storage Mover エージェントから Azure のターゲット ストレージに直接移動されます。 制御メッセージとテレメトリ メッセージのみがクラウド サービスに送信されます。
パフォーマンス ベースライン
これらのテスト結果は理想的な条件下で作成されます。 これは、Storage Mover サービスとエージェントが直接影響を与えるコンポーネントのベースラインとして意図されています。 ソース デバイス、ディスク、およびネットワーク接続の違いは、このテストでは考慮されません。 実際のパフォーマンスは異なります。
SMB マウントから Azure ファイル共有テストへの移行は、次のように実行されました。
次の表では、SMB マウントから Azure ファイル共有へのパフォーマンス テスト結果を生成したテスト環境の特性について説明します。
| テスト番号。 | いいえ。 ファイルの数 | ファイルの合計の重み | ファイル サイズ | フォルダー構造 |
|---|---|---|---|---|
| 1 | 1,200 万 | 12 GB | 各 1 KB | 12 個のフォルダー(それぞれ 100 個のサブフォルダーに 10,000 個のファイルを含む) |
| 2 | 30 | 20 GB | 1 つのフォルダー | |
| 3 | 100 万 | 100 GB | 各 100 KB | 1,000 個のフォルダー、それぞれ 1,000 個のファイル |
| 4 | 1 | 4テラバイト (4 TB) | ||
| 5 | 1 億 1,700 万 | 117 GB | 各 1 KB | 117 個のフォルダー、それぞれに 10,000 個のファイルを含む 100 個のサブフォルダー |
| 6 | 1 | 1 TB (テラバイト) | ||
| 7 | 330 万 | 45 GB | 各 13 KB | 200,000 個のフォルダー、それぞれに 16\17 個のファイルが含まれています |
| 8 | 5,000 万 | 1 TB (テラバイト) | 各 20 KB | 2,940,000 個のフォルダー、それぞれに 17 個のファイルが含まれています |
| 9 | 1 億 | 2 TB（テラバイト） | 各 20 KB | 5,880,000 個のフォルダー、それぞれに 17 個のファイルが含まれています |
SMB エンドポイントでは、さまざまなエージェント リソース構成がテストされます。
Minspec: 4 CPU/ 8 GB RAM 4 仮想 CPU コア (それぞれ 2.7 GHz)、8 GiB のメモリ (RAM) が Azure Storage Mover エージェントの最小仕様です。
テスト番号。 [実行時間] スキャン時間 6 16 分、42 秒 1.2 秒 7 55 分、4 秒 1 分、17 秒 8 9 Bootspec: 8 CPU/ 16 GiB RAM 8 仮想 CPU コア (それぞれ 2.7 GHz)、16 GiB のメモリ (RAM) が Azure Storage Mover エージェントの最小仕様です。
結果: 標準ストレージ アカウント
テスト番号。 [実行時間] スキャン時間 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 つのコピー実行の間で変更されるファイル、フォルダー、およびメタデータの数。 -
ネットワーク
- ソースエージェントと移行エージェント間の帯域幅と待機時間
- Azure の移行エージェントとターゲットの間の帯域幅と待機時間
-
移行エージェントのリソース
メモリ (RAM)、コンピューティング コアの数、および移行エージェントで使用可能なローカル ディスク容量の量は、移行速度に大きな影響を与える可能性があります。 コンピューティング リソースが増えると、特に移行で大量の小さなファイルを処理する必要がある場合に、使用可能な帯域幅の使用率を最適化するのに役立ちます。
たとえば、従来の移行では、移行するストレージに依存するワークロードのダウンタイムを最小限に抑える戦略が必要です。 Azure Storage Mover では、 コンバージデント n パス移行と呼ばれるこの戦略がサポートされています。
この方法では、ソースからターゲットに複数回コピーします。 これらのコピーイテレーション中、ソースはワークロードに対する読み取りと書き込みに使用できます。 最後のコピーイテレーションの直前に、ソースをオフラインにします。 最終的なコピーは、最初に作成したコピーよりも速く完了し、直前のコピーと同程度の時間がかかると予想されます。 最終的なコピーの後、ワークロードはフェールオーバーされ、Azure の新しいターゲット ストレージが使用され、再び使用できるようになります。
ソースからターゲットへの最初のコピー中、ターゲットは空である可能性が高く、すべてのソース コンテンツがターゲットに移動する必要があります。 その結果、最初のコピーは、使用可能なネットワーク リソースによって最も制約される可能性があります。
移行の終了に向けて、ソースをターゲットに複数回コピーした後、最後のコピーの後に変更されるファイル、フォルダー、およびメタデータはごくわずかです。 この最後のコピーイテレーションでは、ソースとターゲットの各ファイルを比較して更新する必要があるかどうかを確認します。必要なコンピューティング リソースが増え、ネットワーク リソースが少なくなります。 移行のこの後期段階でのコピー実行は、多くの場合、コンピューティングの制約が高くなります。 Storage Mover エージェントの適切なリソース管理がますます重要になります。
次のステップ
次の記事は、Azure Storage Mover のデプロイの成功に役立ちます。