Storage Mover のデプロイには、いくつかのAzure リソースが関係しています。 この記事では、これらの各リソース、その使用方法、および移行ニーズを表現するためのベスト プラクティスについて説明します。
概要
Azure Storage Mover では、エージェントベースの移行ワークロードとエージェントレス移行ワークロードの両方がサポートされます。 エージェント ベースのワークロードの場合、移行エージェント VM はソース ストレージの近くの環境で実行されます。 エージェントレス ワークロードの場合、移行エージェント VM は必要ありません。
クラウド サービスは、両方のワークロードの種類に対して移行オーケストレーションと管理を提供します。 エージェント ベースのワークロードについては、 Storage Mover エージェントのデプロイ と エージェント登録 に関する記事を参照してください。
Storage Mover では、エージェントベースの移行ワークロードとエージェントレス移行ワークロードがサポートされます。 この記事で説明するリソース階層は両方のワークロードの種類に適用されますが、移行エージェント リソースはエージェント ベースのワークロードにのみ必要です。
ストレージムーバー リソース
ストレージ ムーバー リソースは、選択したリソース グループにデプロイする最上位レベルのサービス リソースの名前です。 サービスと移行のすべての側面は、このリソースから制御されます。 ほとんどの場合、最大の移行でも、単一のストレージ ムーバー リソースをデプロイするだけで十分です。
すべてのリソースが同じストレージ ムーバー インスタンスに自分のホームを見つけた場合は、エージェントを利用して移行を管理できます。
移行エージェントは、1 つのストレージ ムーバーにのみ登録できます。
リソースをデプロイするときは、サブスクリプションを Microsoft.StorageMover と Microsoft.HybridCompute のリソース プロバイダーに登録します。 また、移行に関する制御メッセージとメタデータが格納されるリージョンも割り当てます。 Storage Mover リソース自体は、データの移行に直接責任を負いません。 エージェント ベースのワークロードの場合、移行エージェントはソースからデータをコピーし、Azure Storage内のターゲットに直接送信します。 エージェントレス ワークロードの場合、Storage Mover はデプロイされた移行エージェント VM を必要とせずに移行を調整します。 エージェント ベースのワークロードの場合、ソース、エージェント、ターゲット ストレージの間の近接性は、ストレージ ムーバー リソースの場所よりも移行のパフォーマンスにとって重要です。
移行エージェント
Storage Mover は、エージェントベースのワークロードとエージェントレス ワークロードをサポートするハイブリッド サービスです。 移行エージェントは、エージェント ベースのワークロードに使用されます。 移行エージェントは、ネットワーク内で実行される仮想マシンです。 これは、リソース グループにデプロイしたストレージ ムーバー リソースを親リソースとして持つリソースの名前でもあります。
エージェントレス ワークロードを計画している場合は、移行エージェント リソースをスキップできます。
複数の移行エージェント VM をデプロイし、それぞれを一意の名前で同じストレージ ムーバー リソースに登録できます。 別の場所に移行のニーズがある場合は、移行するソース ストレージに非常に近い移行エージェントを用意することをお勧めします。
エージェントは、登録後にストレージ ムーバーに表示されます。 登録により、選択したストレージ ムーバー リソースとの信頼関係が作成されます。 この信頼により、Azure ポータル、Azure PowerShell、またはAzure CLIを使用して、クラウド サービスから移行関連のすべての側面を管理できます。
Tip
移行エージェントとターゲット ストレージの間の近接性とネットワーク品質Azure、移行の初期段階での移行速度を決定します。 デプロイしたストレージ ムーバー リソースのリージョンは、パフォーマンスの役割を果たしていません。
Note
ワークロードのダウンタイムを最小限に抑えるために、ソースからターゲットに複数回コピーすることを決定できます。 後でコピーを実行すると、移行速度は、多くの場合、移行エージェントがファイルをコピーする必要があるかどうかを評価できる速度によって影響を受けます。 つまり、エージェント上のローカルコンピューティングリソースとメモリリソースは、ネットワーク品質よりも移行速度にとって重要になる可能性があります。
移行プロジェクト
プロジェクトを使用して、大規模なクラウド移行を、状況に適した、より小さく管理しやすい単位に整理します。
移行の最小単位は、1 つのターゲットに移行する 1 つのソースの内容として定義できますが、データ センターの移行が簡単になることはほとんどありません。 多くの場合、複数のソースが 1 つのワークロードをサポートしており、ワークロードをAzureの新しいクラウド ストレージの場所にタイムリーにフェールオーバーするために一緒に移行する必要があります。
別の例では、1 つのソースを複数のターゲットの場所に分割する必要がある場合もあります。 逆にすることもできます。複数のソースを、Azure内の同じターゲットの場所のサブパスに結合する必要があります。
ソースをプロジェクトにグループ化しても、すべてのソースを並列で移行する必要はありません。 実行する内容と実行するタイミングを制御できます。 この記事の残りのセクションでは、このようなきめ細かい制御を可能にするその他のリソースについて説明します。
Tip
必要に応じて、プロジェクトに説明を追加できます。 説明は、プロジェクトの追加情報を追跡するのに役立ちます。 別の場所で移行計画を既に作成している場合は、説明フィールドを使用して、このプロジェクトをプランにリンクできます。 また、それを使用して、後で同僚が必要とする可能性がある情報を記録することもできます。 すべてのストレージ ムーバー リソースに説明を追加でき、各説明には最大 1024 文字を含めることができます。
ジョブ定義
ジョブ定義はプロジェクト内に含まれます。 ジョブ定義には、Azure で定義されたソースから定義されたターゲットへのコピーを次回開始するときに使用するソース、ターゲット、および移行設定が定義されています。
Important
ジョブ定義を作成した後は、ソースとターゲットの情報を変更できません。 ただし、移行設定はいつでも変更できます。 変更は実行中の移行ジョブには影響しませんが、次回移行ジョブを開始するときに有効になります。
既存のジョブ定義のソースとターゲットの情報の変更が許可されていないのは、すぐには論理的ではないようです。 たとえば、移行ソースとして 共有 A を定義し、複数のコピー操作を実行するとします。 また、移行ソースを Share B に変更するとします。この変更は、潜在的に危険な結果を招く可能性があります。
ミラーリング は、ターゲット内にソースの "ミラー" イメージを作成する一般的な移行設定です。 この設定をこの例に適用すると、コピー操作が Share B からのファイルの移行を開始するときに、共有A のファイルがターゲットで削除される可能性があります。間違いを防ぎ、ジョブ実行履歴の整合性を維持するために、プロビジョニングされたジョブ定義のソースまたはターゲットを編集することはできません。 ソース、ターゲット、およびオプションのサブパス情報は、ジョブ定義の作成時にロックされます。 同じターゲットを再利用するが、別のソース (またはその逆) を使用する場合は、新しいジョブ定義を作成する必要があります。
ジョブ定義には、過去のコピー実行とその結果の履歴も保持されます。
ジョブ実行
ジョブ定義を開始すると、新しいリソース (ジョブ実行リソース) が暗黙的に作成されます。 ジョブ定義には、ストレージ ムーバー サービスがコピーを開始するために必要なすべての情報が含まれています。 一般的な移行では、ソースからターゲットに複数回コピーできます。 ジョブ定義を開始するたびに、その内容はジョブ実行として記録されます。
ジョブ実行は、ジョブ定義をスナップショットしたものです。 移行ランタイムは、選択したワークロードの種類に対してジョブ実行を実行します。 エージェント ベースのワークロードの場合、選択した移行エージェントが実行を実行します。 エージェントレス ワークロードの場合、サービスは実行を調整します。
Important
移行設定を変更しても、実行中の移行ジョブには影響しません。 ジョブの実行を開始すると、選択した移行ランタイムがジョブ定義のスナップショットを取得して実行します。 ジョブ実行は変更できません。 唯一のオプションは、キャンセルすることです。
ジョブ実行には、状態、進行状況、およびコピー結果の情報が含まれます。 ジョブ実行に関する最も重要な情報は、ジョブ実行リソース自体のプロパティとして見つかります。 エージェント ベースのワークロードとエージェントレス ワークロードの両方が、サービスを介してジョブ実行テレメトリを出力します。
Azure Monitor サービスは、追加情報と移行結果を出力します。
- メトリック は数値であり、時間の経過と同時に記録されます。 これらは、Azure Monitor サービスを使用してプロットできます。 一部の選択されたメトリックは、ポータルでジョブ定義/ジョブ実行を管理するときにも直接使用できます。
- コピー ログ は省略可能です。 有効にすると、すべてのジョブ実行に独自のコピー ログがあります。 コピーできないソースでエージェントが検出した名前空間項目ごとにログ エントリが生成されます。
Important
メトリック情報は既定で使用できますが、コピー ログを有効にするにはオプトインする必要があります。 これは、ストレージ ムーバー リソースの作成の一環として、また後で行うこともできます。 コピー ログが有効になっているかどうかを確認するか、詳細を管理する場合は、ストレージ ムーバー リソースのAzure ポータル ページの Diagnostic 設定 メニューを使用できます。
エンドポイント
移行には、適切に定義されたソースとターゲットの場所が必要です。 エンドポイントという用語はネットワークでよく使用されますが、ここではストレージの場所を詳細に説明します。 エンドポイントには、ストレージの場所へのパスと追加情報が含まれます。
エンドポイント リソースは 1 つだけ存在しますが、エンドポイントの種類に応じて、個々のエンドポイントのプロパティが異なる場合があります。 たとえば、NFS 共有、SMB 共有、Azure Storage BLOB コンテナー エンドポイントには、それぞれ根本的に異なる情報が必要です。
エンドポイントは、ジョブ定義の作成で使用されます。 ソースまたはターゲットとして使用できるのは特定の種類のエンドポイントに限られます。 Azure Storage Mover の概要に関する記事の「Supported sources and targets」セクションを参照してください。
エンドポイントは最上位のストレージ ムーバー リソースに親され、異なるジョブ定義間で再利用できます。
次のステップ
Azure Storage Mover デプロイに関連するリソースを理解したら、概念実証デプロイを開始します。 これらの記事は、次に読むのにおすすめです。
