エージェントレス型移行アーキテクチャ

この記事では、Azure Migrate のエージェントレス移行方法を使用して VMware 仮想マシン (VM) を移行する場合のレプリケーションの概念について説明します。

レプリケーション プロセス

エージェントレス レプリケーション オプションは、VMware スナップショットと VMware 変更ブロック追跡 (CBT) テクノロジを使用して VM ディスクからデータをレプリケートすることで機能します。 次のブロック図は、Azure Migrate を使用して VM を移行するときに必要な手順を示しています。

VM のレプリケーションを構成すると、最初のレプリケーション フェーズが実行されます。 このフェーズでは、Azure Migrate が VM スナップショットを取得します。 その後、サービスは、スナップショット ディスクからターゲット サブスクリプション内のマネージド ディスクにデータの完全コピーをレプリケートします。

VM の初期レプリケーションが完了すると、レプリケーション プロセスは増分レプリケーション (差分レプリケーション) フェーズに移行します。 このフェーズでは、最後に完了したレプリケーション サイクルの開始以降に発生したデータ変更がレプリケートされ、レプリカ マネージド ディスクに書き込まれます。 プロセスのこの部分では、レプリケーションが VM 上の変更と同期されます。

Azure Migrate では、VMware CBT テクノロジを使用して、レプリケーション サイクル間の変更を追跡します。 レプリケーション サイクルの開始時に、Azure Migrate は VM スナップショットを取得します。 サービスは CBT を使用して、現在のスナップショットと最後に正常にレプリケートされたスナップショットの間の変更を取得します。 VM のレプリケーションを同期するために、前の完了したレプリケーション サイクル以降に変更されたデータのみがレプリケートされます。各レプリケーション サイクルの最後にスナップショットがリリースされ、Azure Migrate によって VM のスナップショット統合が実行されます。

レプリケートする VM で移行操作を実行すると、オンデマンド差分レプリケーション サイクルによって、最後のレプリケーション サイクル以降の残りの変更がレプリケートされます。 オンデマンド サイクルが完了すると、Azure Migrate は、VM に対応するレプリカ マネージド ディスクを使用して Azure に VM を作成します。

移行をトリガーする前に、オンプレミスの VM をシャットダウンする必要があります。 VM をシャットダウンすると、移行中にデータが失われるのを防ぐことができます。

移行が成功し、Azure で VM が再起動されたら、必ず VM のレプリケーションを停止してください。 レプリケーションを停止すると、データ レプリケーション中に作成された中間ディスク (シード ディスク) が削除されます。 その後、これらのディスクのストレージ トランザクションに関連する追加料金が発生しないようにします。

レプリケーション サイクル

レプリケーション サイクルは、オンプレミス環境から Azure マネージド ディスクにデータを転送する定期的なプロセスです。 完全なレプリケーション サイクルは、次の手順で構成されます。

1. VM に関連付けられている各ディスクの VMware スナップショットを作成します。
2. Azure のログ ストレージ アカウントにデータをアップロードします。
3. スナップショットを解放します。
4. VMware ディスクを統合します。

ディスクが統合された後、サイクルが完了します。

レプリケーションのコンポーネント

Azure Migrate アプライアンスには、レプリケーションを担当する次 のオンプレミス コンポーネントがあります。

• データ レプリケーション エージェント
• ゲートウェイ エージェント

次の表は、VMware VM 移行のエージェントレスメソッドを使用するときに作成される Azure コンポーネントをまとめたものです。

必要なアクセス許可

レプリケーションを初めて開始する場合、ログインユーザーは次のロールを持っている必要があります。

• Azure Migrate プロジェクトのリソース グループとターゲット リソース グループの所有者または共同作成者およびユーザー アクセス管理者

後続のレプリケーションでは、ログイン ユーザーに次のロールが必要です。

• Azure Migrate プロジェクトのリソース グループとターゲット リソース グループの所有者または共同作成者

上記のロールに加えて、ログインユーザーにはサブスクリプション レベルで次のアクセス許可が必要です: Microsoft.Resources/subscriptions/resourceGroups/read。

データ整合性

オンプレミス ディスク (ソース ディスク) と Azure (ターゲット ディスク) 内のレプリカ ディスクの間のデータ整合性を確保するために、レプリケーション サイクルごとに 2 つの段階があります。

レプリケーションの検証

最初のステージでは、ソース ディスクで変更されたすべてのセクターがターゲット ディスクにレプリケートされることを検証します。 ビットマップを使用して検証を実行します。

ソース ディスクは 512 バイトのセクターに分割されます。 ソース ディスク内のすべてのセクターは、ビットマップ内のビットにマップされます。 データ レプリケーションが開始されると、Azure Migrate は、レプリケートする必要があるソース ディスク内のすべての変更されたブロック (差分サイクル) のビットマップを作成します。 同様に、データがターゲットの Azure ディスクに転送されると、Azure Migrate によってビットマップが作成されます。

データ転送が正常に完了すると、クラウド サービスは 2 つのビットマップを比較して、変更されたブロックを見逃さなかったことを確認します。 ビットマップ間に不一致がある場合、サイクルは失敗したと見なされます。 すべてのサイクルが再同期されるため、不一致は次のサイクルで修正されます。

レプリケートされたデータを確認する

2 番目のステージでは、Azure ディスクに転送されるデータが、ソース ディスクからレプリケートされたデータと同じであることを確認します。

アップロードされたすべての変更されたブロックは、ログ ストレージ アカウントに BLOB として書き込まれる前に圧縮および暗号化されます。 Azure Migrate は、圧縮前にこのブロックのチェックサムを計算します。 このチェックサムは、圧縮されたデータと共にメタデータとして格納されます。

展開時に、Azure Migrate はデータのチェックサムを計算し、ソース環境で計算されたチェックサムと比較します。 不一致がある場合、データは Azure ディスクに書き込まれず、サイクルは失敗と見なされます。 すべてのサイクルが再同期されるため、不一致は次のサイクルで修正されます。

セキュリティ

Azure Migrate アプライアンスは、データをアップロードする前にデータを圧縮して暗号化します。 データは、HTTPS と TLS 1.2 以降を使用するセキュリティで保護された通信チャネル経由で送信されます。 さらに、Azure Storage は、クラウドに永続化されるときにデータを自動的に暗号化します (保存時の暗号化)。

レプリケーションの状態

VM がレプリケーション (データ コピー) を受け取ると、いくつかの状態が考えられます。

• キューに登録された初期レプリケーション: 他の VM がレプリケーションまたは移行中にオンプレミスのリソースを使用している可能性があるため、VM はレプリケーションまたは移行のためにキューに入れられます。 リソースが解放されると、この VM が処理されます。
• 初期レプリケーションの進行中: VM は初期レプリケーション用にスケジュールされています。
• 初期レプリケーション: VM の初期レプリケーションが進行中です。 VM が初期レプリケーション中の場合、テスト移行と運用移行を続行することはできません。 この段階では、レプリケーションの停止のみが可能です。
• 初期レプリケーション (x%): 初期レプリケーションはアクティブであり、表示された割合で進行しています。
• 差分同期: VM では最後のレプリケーション サイクル以降の残りのデータ チャーンをレプリケートする差分レプリケーション サイクルが実行されている可能性があります。
• 進行中の一時停止: VM はアクティブな差分レプリケーション サイクルを実行しており、一時停止しています。
• 一時停止: レプリケーション サイクルは一時停止されています。 レプリケーションを再開する操作を実行することで、レプリケーション サイクルを再開できます。
• キューに登録された再開: 他の VM が現在オンプレミスリソースを使用しているため、VM はレプリケーションを再開するためにキューに入れられます。
• 進行中の再開 (x%): VM のレプリケーション サイクルが再開され、表示された割合で進行しています。
• レプリケーションの停止進行中: レプリケーションのクリーンアップが進行中です。 レプリケーションを停止すると、レプリケーション中に作成された中間マネージド ディスク (シード ディスク) が削除されます。 レプリケーションの停止の詳細については、 この記事の後半で説明します。
• 移行の完了が進行中: 移行のクリーンアップが進行中です。 移行を完了すると、レプリケーション中に作成された中間マネージド ディスク (シード ディスク) が削除されます。 レプリケーションの完了の詳細については、 この記事の後半で説明します。
• – VM が正常に移行されたとき、またはレプリケーションを停止すると、状態がダッシュに変わります。 移行を完了するかレプリケーションを停止し、操作が正常に完了すると、VM はレプリケートマシンの一覧から削除されます。 VM は、レプリケーション ウィザードの仮想マシンのタブにあります。

他の状態

• 初期レプリケーションに失敗しました: VM の初期データをコピーできませんでした。 修復ガイダンスに従って解決してください。

• 修復保留中: レプリケーション サイクルに問題が発生しました。 リンクを選択すると、考えられる原因や修復するためのアクションを把握できます (該当する場合)。 VM のレプリケーションをトリガーしたときに [はい] を選択してレプリケーションを自動的に修復することを選択した場合、ツールによって修復が試みられます。 それ以外の場合は、VM を選択し、[ レプリケーションの修復] を選択します。

  [レプリケーションの自動修復] を選択しなかった場合、または修復手順が機能しなかった場合は、VM のレプリケーションを停止します。 VM 上の CBT をリセットし、レプリケーションを再構成します。

• キューに置かれたレプリケーションの修復: 他の VM がオンプレミスのリソースを使用しているため、VM はレプリケーション修復のためにキューに入れられます。 リソースが解放されると、VM は修復レプリケーションのために処理されます。

• 再同期 (x%): VM でデータの再同期が実行されています。 この再同期は、データ レプリケーション中に問題や不一致が発生した場合に発生する可能性があります。

• レプリケーションを停止できませんでした/complete migration failed (移行を完了できませんでした): リンクを選択して、考えられるエラーの原因や修復するためのアクションを把握してください (該当する場合)。

テスト移行または運用移行の状態

• テスト移行が保留中: VM は差分レプリケーション フェーズにあります。 テスト移行 (または運用移行) を実行できるようになりました。
• テスト移行のクリーンアップが保留中: テスト移行が完了したら、テスト移行のクリーンアップを実行して、Azure での課金を回避します。
• 移行の準備完了: VM は Azure に移行する準備ができています。
• 進行中の移行キュー: 他の VM がレプリケーション (または移行) 中にオンプレミスのリソースを使用しているため、VM は移行のためにキューに入れられます。 リソースが解放されると、VM が処理されます。
• テスト移行/移行の進行中: VM でテスト移行または運用移行が行われます。 リンクを選択して、進行中の移行ジョブを確認できます。
• 日付、タイムスタンプ: テスト移行または運用移行は、この日時に行われます。
• –: 初期レプリケーションが進行中です。 レプリケーション プロセスが差分同期 (増分レプリケーション) フェーズに移行した後で、テスト移行または運用移行を実行できます。

他の状態

• 情報付きで完了: テスト移行または運用移行ジョブが情報で完了しました。 リンクを選択すると、考えられる原因や修復するためのアクションに関して、最後の移行ジョブを確認できます (該当する場合)。
• 失敗: テスト移行または運用移行ジョブが失敗しました。 リンクを選択すると、考えられる原因や修復するためのアクションに関して、最後の移行ジョブを確認できます。

スケジュール ロジック

初期レプリケーションは、VM のレプリケーションを構成するときにスケジュールされます。 増分レプリケーション (差分レプリケーション) はそれに従います。

差分レプリケーション サイクルは、次のようにスケジュールされます。

• 最初の差分レプリケーション サイクルは、初期レプリケーション サイクルが完了した直後にスケジュールされます。

• 次の差分レプリケーション サイクルは、次のロジックに従ってスケジュールされます: min[max[1 hour, (<Previous delta replication cycle time>/2)], 12 hours]。

  つまり、次の差分レプリケーションは、1 時間以内と 12 時間以内にスケジュールされます。 たとえば、VM が差分レプリケーション サイクルに 4 時間かかる場合、次の差分レプリケーション サイクルは次の 1 時間ではなく 2 時間でスケジュールされます。

  注

  スケジュール ロジックは、初期レプリケーションの完了後に異なります。 最初のデルタ サイクルは、初期レプリケーションが完了した直後にスケジュールされます。 後続のサイクルは、スケジュール ロジックに従います。

• 移行をトリガーすると、移行前に VM に対してオンデマンド (フェールオーバー前) の差分レプリケーション サイクルが発生します。

優先順位付け

レプリケーションのさまざまな段階での VM の優先順位付けを次に示します。

• 進行中の VM レプリケーションは、スケジュールされたレプリケーション (新しいレプリケーション) よりも優先されます。
• オンデマンド (フェールオーバー前) の差分レプリケーション サイクルの優先度が最も高く、その後に最初のレプリケーション サイクルが続きます。 差分レプリケーション サイクルの優先度は最も低くなります。

移行操作をトリガーするたびに、VM のオンデマンド レプリケーション サイクルがスケジュールされます。 他の進行中のレプリケーションは、リソースを競合している場合は待機する必要があります。

制約

次の制約は、記憶域ネットワークの IOPS 制限を超えないようにするのに役立ちます。

• 各 Azure Migrate アプライアンスでは、並列で 52 個のディスクのレプリケーションがサポートされています。
• 各 ESXi ホストは、8 個のディスクをサポートします。 すべての ESXi ホストには 32 MB の NFC バッファーがあります。 そのため、ホスト上で 8 つのディスクをスケジュールできます。 (各ディスクは、インシデント対応とディザスター リカバリーのために最大 4 MB のバッファーを使用します)。
• 各データストアは、最大で 15 のディスク スナップショットを持つことができます。 唯一の例外は、15 を超えるディスクが VM に接続されている場合です。

スケールアウト レプリケーション

Azure Migrate では、500 台の VM の同時レプリケーションがサポートされています。 300 を超える VM をレプリケートする予定の場合は、スケールアウト アプライアンスをデプロイする必要があります。 スケールアウト アプライアンスは Azure Migrate プライマリ アプライアンスに似ていますが、Azure へのデータ転送を容易にするゲートウェイ エージェントのみで構成されます。

次の図は、スケールアウト アプライアンスを使用する際に推奨される方法を示しています。

プライマリ アプライアンスを構成した後はいつでもスケールアウト アプライアンスをデプロイできますが、300 台の VM が同時にレプリケートされるまでは必要ありません。 300 台の VM が同時にレプリケートされている場合は、スケールアウト アプライアンスをデプロイして続行する必要があります。

レプリケーションの停止または移行の完了

レプリケーションを停止すると、レプリケーション中に作成された中間マネージド ディスク (シード ディスク) が削除されます。 レプリケーションを停止できるのは、アクティブなレプリケーション中のみです。 [ 移行の完了 ] を選択すると、VM の移行後にレプリケーションを停止できます。

レプリケーションを再度有効にすることで、レプリケーションが停止されている VM をレプリケートできます。 VM を移行した場合は、レプリケーションと移行をもう一度再開できます。

ベスト プラクティスとして、VM が Azure に正常に移行された後は、常に移行を完了する必要があります。 この方法により、中間マネージド ディスク (シード ディスク) 上のストレージ トランザクションに対して追加料金が発生しないようにします。

場合によっては、レプリケーションの停止に時間がかかります。 その理由は、レプリケーションを停止するたびに、進行中のレプリケーション サイクルが完了し (VM が差分同期中の場合のみ)、成果物が削除されるためです。

チャーンの影響

次のサイクルをスケジュールする前に、データを可能な限りフォールドできるようにすることで、各レプリケーション サイクルのデータ転送量を最小限に抑えることができます。 エージェントレス レプリケーションでは日付が折りたたまれるため、チャーン レートよりチャーン パターンが重要です。 ファイルが繰り返し書き込まれる場合、そのレートはあまり影響を与えません。 ただし、セクターが 1 つおきに書き込まれるパターンでは、次回のサイクルでチャーンが高くなります。

現在の差分レプリケーション サイクルでデータ変更頻度が高いために遅延が発生した場合、後続のサイクルの開始が遅れる可能性があります。 特定のディスクにレプリケートするデータの量が多いほど、復旧ポイントの作成に必要な期間が長くなります。 その結果、最終的な移行サイクルには時間がかかります。 この状況により、ソース VM のシャットダウン 期間が延長されます。

データストアの使用可能な容量を超える程度にスナップショット サイズが増加した場合 (チャーン パターンにより)、データストアの領域が不足するリスクがあります。 この状況は運用環境のワークロードに悪影響を及ぼす可能性があり、ソース VM が応答しなくなる可能性があります。

このリスクを軽減するには、データストアのサイズを事前に増やすことをお勧めします。 同時にレプリケートする複数の VM が、使用可能な容量が少ないデータストアにディスクがある場合は、リソースの競合を回避するために、一度に 1 つの VM を移行することをお勧めします。

レプリケーションの管理

調整

NetQosPolicyを使用して、レプリケーション帯域幅を増減できます。 AppNamePrefixで使用するNetQosPolicy値はGatewayWindowsService.exe。

Azure Migrate アプライアンスからのレプリケーション トラフィックを調整するには、アプライアンスで次の例のようなポリシーを作成します。 このポリシーは、Azure Migrate アプライアンスからレプリケートするすべての VM に同時に適用されます。

New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB

サンプル スクリプトを使用して、スケジュールに基づいてレプリケーション帯域幅を増減することもできます。

ブラックアウト期間

Azure Migrate には、レプリケーションを続行しない時間間隔を指定するために使用できる構成ベースのメカニズムが用意されています。 この間隔は 、ブラックアウト ウィンドウと呼ばれます。 ブラックアウト期間の必要性は、ソース環境がリソースに制約されている場合や、レプリケーションを営業時間外にのみ実行する場合など、複数のシナリオで発生する可能性があります。

アプライアンスのブラックアウトウィンドウを指定するには、GatewayDataWorker.jsonでC:\ProgramData\Microsoft Azure\Configファイルを作成または更新します。 一般的なファイルの形式は次のとおりです。

{
    
    "BlackoutWindows": "List of blackout windows"
    
}

ブラックアウト ウィンドウの一覧は、|形式のパイプ区切り (<DayOfWeek>;<StartTime>;<Duration>) 文字列です。 日数、時間、分単位で期間を指定できます。 たとえば、ブラックアウト ウィンドウを次のように指定できます。

{
    
    "BlackoutWindows": "Monday;7:00;7h | Tuesday;8:00;1d7h | Wednesday;16:00;1d | Thursday;18:00;5h | Friday;13:00;8m"
    
}

前の例の最初の値は、毎週月曜日の午前 7 時 (アプライアンスの時刻) から始まり、7 時間続くブラックアウト 期間を示しています。

これらの内容で GatewayDataWorker.json を作成または更新した後、これらの変更を有効にするには、アプライアンス上のゲートウェイ サービスを再起動する必要があります。

スケールアウト シナリオでは、プライマリ アプライアンスとスケールアウト アプライアンスは、それぞれ個別にブラックアウト期間に従います。 ベストプラクティスとして、複数のアプライアンス間でこの期間を同じにすることをお勧めします。

関連コンテンツ

• VMware VM を Azure に移行する (エージェントレス)