Azure Storage Mover リソース階層について

Storage Mover のデプロイには、いくつかの Azure リソースが関係しています。 このアーティクルでは、これらの各リソース、それらの使用方法、および移行のニーズを表現するためのベスト プラクティスについて説明します。

概要

Azure Storage Mover はハイブリッド クラウド サービスです。 ハイブリッド サービスには、クラウド サービス コンポーネントとインフラストラクチャ コンポーネントの両方があります。 サービス管理者は、企業環境でインフラストラクチャ コンポーネントを実行します。 Storage Mover の場合、そのハイブリッド コンポーネントは移行エージェントで構成されます。 エージェントは、ソース ストレージの近くのホストにデプロイされ、実行される仮想マシンです。 エージェントとそのデプロイ方法の詳細については、 Storage Mover エージェントのデプロイ に関するアーティクルを参照してください。

エージェント登録プロセスを除き、移行のすべての側面はクラウド サービスから管理されます。 エージェント登録プロセスの詳細については、 エージェント登録 に関する記事を参照してください。

ストレージ ムーバー リソース

ストレージ ムーバー リソースは、選択したリソース グループにデプロイする最上位レベルのサービス リソースの名前です。 サービスと移行のすべての側面は、このリソースから制御されます。 ほとんどの場合、1 つのストレージ ムーバー リソースをデプロイするだけで、最大の移行でも十分です。

すべてのリソースが、同じストレージ ムーバー インスタンス内にある場合は、エージェントの活用や移行の管理をより効率的に実行できます。

移行エージェントは、1 つのストレージ ムーバーにのみ登録できます。

リソースをデプロイすると、サブスクリプションが Microsoft.StorageMover および Microsoft.HybridCompute リソース プロバイダーに登録されます。 また、移行に関する制御メッセージとメタデータが格納されるリージョンも割り当てます。 Storage Mover リソース自体が直接、データを移行するわけではありません。 代わりに、移行エージェントがソースからデータをコピーし、Azure Storage 内のターゲットに直接送信します。 ほとんどの作業をエージェントが行うため、移行のパフォーマンスにとっては、ソース、エージェント、ターゲット ストレージの間の近接性が、ストレージ ムーバー リソースの場所よりも重要です。

移行エージェント

Storage Mover はハイブリッド サービスであり、移行を容易にするために 1 つ以上の移行エージェントを利用します。 エージェントは、ネットワーク内で実行される仮想マシンです。 また、リソース グループにデプロイしたストレージ ムーバー リソースの親となるリソースの名前でもあります。

複数の移行エージェント VM をデプロイし、それぞれを一意の名前で同じストレージ ムーバー リソースに登録できます。 移行のニーズが異なる場所にある場合は、移行するソース ストレージの近くに移行エージェントを配置することをお勧めします。

エージェントは、登録後にストレージムーバーに表示されます。 登録により、登録時に選択したストレージ ムーバー リソースとの信頼関係が作成されます。 この信頼により、Azure portal、Azure PowerShell、または Azure CLI を使用して、移行に関連するすべての側面をクラウド サービスから管理できます。

ヒント

移行エージェントと Azure のターゲット ストレージの間の近接性とネットワーク品質によって、移行の初期段階での移行速度が決まります。 デプロイしたストレージ ムーバー リソースのリージョンは、パフォーマンスの役割を果たしていません。

Note

ワークロードのダウンタイムを最小限に抑えるために、ソースからターゲットに複数回コピーすることを決定できます。 後でコピーを実行すると、多くの場合、移行速度は、ファイルをコピーする必要があるかどうかを移行エージェントが評価できる速度によって影響を受けます。 つまり、エージェント上のローカルコンピューティングリソースとメモリリソースは、ネットワーク品質よりも移行速度にとってより重要になる可能性があります。

移行プロジェクト

プロジェクトを使用すると、大規模なクラウド移行を、状況に応じて、より小さく、管理しやすい単位に整理できます。

移行の最小単位は、1 つのターゲットに移動する 1 つのソースの内容として定義できますが、データセンターの移行が、それほど単純であることは稀です。 多くの場合、複数のソースが 1 つのワークロードをサポートしており、ワークロードを Azure の新しいクラウド ストレージの場所にタイムリーにフェールオーバーするために一緒に移行する必要があります。

別の例では、1 つのソースを複数のターゲットの場所に分割する必要がある場合もあります。 逆の方法も可能です。この場合は、複数のソースを、Azure 内の同じターゲットの場所のサブパスに結合する必要があります。

ソースをプロジェクトにグループ化しても、すべてのソースを並列に移行する必要はありません。 何をいつ実行するかは、自分でコントロールできます。 この記事の残りのセクションでは、このようなきめ細かい制御を可能にするその他のリソースについて説明します。

ヒント

必要に応じて、プロジェクトに説明を追加できます。 説明は、プロジェクトの追加情報を追跡するのに役立ちます。 別の場所で移行プランを既に作成している場合は、説明フィールドを使用して、このプロジェクトをプランにリンクできます。 また、それを使用して、後で同僚が必要とする可能性がある情報を記録することもできます。 すべてのストレージ ムーバー リソースに説明を追加でき、各説明には最大 1024 文字を含めることができます。

ジョブ定義

ジョブ定義はプロジェクトに含まれています。 ジョブ定義では、定義されたソースから Azure で定義されたターゲットへのコピーを次回開始するときに使用するソース、ターゲット、および移行設定について説明します。

重要

ジョブ定義が作成された後は、ソースとターゲットの情報を変更できません。 ただし、移行設定はいつでも変更できます。 変更は、実行中の移行ジョブには影響しませんが、次回に移行ジョブを開始するときに有効になります。

既存のジョブ定義のソースとターゲットの情報の変更が許可されていないのは、すぐには論理的ではないようです。 たとえば、共有 A を移行ソースとして定義し、複数のコピー操作を実行するとします。 また、移行ソースを 共有 B に変更するとします。この変更は、危険な結果をもたらす可能性があります。

ミラーリングは、ソースの "ミラー" イメージをターゲット内に作成する、一般的な移行設定です。 この設定を、この例に適用すると、コピー操作により共有 B からのファイルの移行が開始されると、共有 A のファイルがターゲットで削除される場合があります。間違いを防ぎ、ジョブ実行履歴の整合性を維持するには、プロビジョニングされたジョブ定義のソースとターゲットをいずれも編集しないでください。 ソース、ターゲット、およびそのオプションのサブパス情報は、ジョブ定義の作成時にロックされます。 同じターゲットを再利用するが、別のソースを使用する (またはその逆の) 場合は、新しいジョブ定義を作成する必要があります。

ジョブ定義では、過去のコピー実行とその結果の履歴も保持されます。

ジョブ実行

ジョブ定義を開始すると、新しいリソース (ジョブ実行リソース) が暗黙的に作成されます。 ジョブ定義には、ストレージ ムーバー サービスがコピーを開始するために必要なすべての情報が含まれています。 一般的な移行では、ソースからターゲットに複数回コピーする場合があります。 ジョブ定義を開始するたびに、ジョブ実行に記録されます。

ジョブの実行はジョブ定義のスナップショットであり、選択した移行エージェントに渡されます。 その後、エージェントは、ソース、ターゲット、および前に定義した移行を完了するために従う必要のある移行動作に関する必要なすべての情報を取得します。

重要

移行設定を変更しても、実行中の移行ジョブには影響しません。 ジョブの実行を開始すると、ジョブ定義のスナップショットが作成され、移行エージェントで実行されます。 ジョブ実行を変更することはできません。唯一のオプションは、ジョブの実行を取り消す方法です。

ジョブの実行には、状態、進行状況の情報、および結果情報のコピーがあります。 ジョブ実行に関する最も重要な情報は、ジョブ実行リソース自体のプロパティとして表示されます。 移行エージェントにはカスタム テレメトリ チャネルがあり、この情報をジョブ実行リソースに直接格納できます。

エージェントは、Azure Monitor サービスを通じて追加情報と移行結果も出力します。

• メトリック は、時間の経過に伴って記録される数値です。 これらは、Azure Monitor サービスを使用してプロットできます。 一部の選択されたメトリックは、ポータルでジョブ定義/ジョブの実行を管理するときにも直接使用できます。
• コピー ログ は省略可能です。 有効にした場合、すべてのジョブ実行には独自のコピー ログが作成されます。 コピーできないソースでエージェントが検出した名前空間項目ごとにログ エントリが生成されます。

重要

メトリック情報は既定で使用できますが、コピー ログを有効にするには、オプトインする必要があります。 これは、ストレージ ムーバー リソースの作成の一環として行うことも、後で行うこともできます。 コピー ログが有効になっているかどうかを確認する場合、または詳細を管理する場合は、ストレージ ムーバー リソースの Azure portal ページの [診断設定] メニューを使用できます。

エンドポイント

移行には、適切に定義されたソースとターゲットの場所が必要です。 エンドポイントという用語はネットワークでよく使用されますが、ここではストレージの場所を詳細に説明します。 エンドポイントには、ストレージの場所へのパスと追加情報が含まれています。

エンドポイント リソースは 1 つだけ存在しますが、エンドポイントの種類に応じて、個々のエンドポイントのプロパティが異なる場合があります。 たとえば、NFS 共有エンドポイント、SMB 共有エンドポイント、Azure Storage BLOB コンテナー エンドポイントにはそれぞれ、根本的に異なる情報が必要です。

エンドポイントは、ジョブ定義の作成に使用されます。 ソースまたはターゲットとしてそれぞれ特定の種類のエンドポイントのみを使用できます。 Azure Storage Mover の概要に関するアーティクルの「サポートされるソースとターゲット」セクションを参照してください。

エンドポイントは最上位のストレージ ムーバー リソースが親となり、異なるジョブ定義間で再利用できます。

次のステップ

Azure Storage Mover デプロイに関連するリソースを理解したら、概念実証デプロイを開始することをお勧めします。 これらの記事は良い、次の読み取り:

• サブスクリプションにストレージ ムーバー リソースをデプロイします。
• Azure Storage Mover エージェントVM をデプロイします。