クラシックから、最新化された VMware ディザスター リカバリーに移行する

この記事では、クラシックから最新化された保護アーキテクチャへの VMware レプリケーションの移行に関するアーキテクチャ、必要なインフラストラクチャ、FAQ に関する情報を提供します。 この移行機能を使用すると、レプリケートされたアイテムを構成サーバーから Azure Site Recovery レプリケーション アプライアンスに正常に移動できます。 この移行はスマート レプリケーション メカニズムによって誘導されます。このメカニズムでは、重要でないレプリケートされたアイテムに対しては完全な初期レプリケーションは再実行されず、差分データのみが移動されます。

注意

  • 物理サーバーの最新化されたアーキテクチャへの移動は、まだサポートされていません。  
  • プライベート エンドポイントが有効な Recovery Services コンテナーにレプリケートされたマシンの移行は、まだサポートされていません。   
  • 復旧計画は移行されないため、最新化された Recovery Services コンテナーでもう一度作成する必要があります。

アーキテクチャ

VMware マシンのレプリケートされたアイテムの移行に関連するコンポーネントを次の表にまとめます。

コンポーネント 要件
クラシック Recovery Services コンテナー内のレプリケートされたアイテム クラシック アーキテクチャと正常な構成サーバーを使用して保護される 1 つ以上のレプリケートされたアイテムです。

レプリケートされたアイテムは、重大でない状態である必要があり、バージョン 9.50 以降で実行されているモビリティ エージェントを使用してオンプレミスから Azure にレプリケートしなければなりません。
レプリケートされたアイテムによって使用される構成サーバー レプリケートされたアイテムによって使用される構成サーバーは重大でない状態である必要があり、そのコンポーネントは最新バージョン (9.50 以降) にアップグレードする必要があります。
最新化されたエクスペリエンスを備えた Recovery Services コンテナー 最新化されたエクスペリエンスを備えた Recovery Services コンテナーです。
正常な Azure Site Recovery レプリケーション アプライアンス すべてのコンポーネントが最新バージョン (9.50 以降) にアップグレードされている、重要でない Azure Site Recovery レプリケーション アプライアンスです。これによりオンプレミス のマシンを検出できます。 正確な必要バージョンは次のとおりです。

プロセス サーバー: 9.50
プロキシ サーバー: 1.35.8419.34591
Recovery Services エージェント: 2.0.9249.0
レプリケーション サービス: 1.35.8433.24227

必要なインフラストラクチャ

レプリケートされたアイテムを正常に移行するには、次のことを確認します。

  • 最新化されたエクスペリエンスを使用した Recovery Services コンテナーです。  

    注意

    新しく作成された Recovery Services コンテナーでは、既定で最新化されたエクスペリエンスがオンになります。 クラシック エクスペリエンスに切り替えることができますが、いったん実行したら、もう一度切り替えることはできません。  

  • コンテナーに正常に登録された Azure Site Recovery レプリケーション アプライアンスとそのすべてのコンポーネントは、重大でない状態です。  
  • アプライアンスのバージョンは 9.50 以降である必要があります。 詳細なバージョンの説明については、こちらをご確認ください。
  • オンプレミスの検出を正常に行うために、既存のレプリケートされたマシンが存在する vCenter Server または vSphere ホストの詳細がアプライアンスに追加されます。  

前提条件

インフラストラクチャの準備

クラシック アーキテクチャから最新化されたアーキテクチャに移行する前に、次のことを確認してください。

従来の Recovery Services コンテナーを準備する

移行する予定のレプリケートされたアイテムに対して、次のことを確認します。

  • Recovery Services コンテナーで MSI が有効になっていません。
  • レプリケートされたアイテムが、構成サーバーを介してレプリケートする VMware マシンです。
  • レプリケーションが、アンマネージド ストレージ アカウントではなく、マネージド ディスクに対して行われています。
  • オンプレミスから Azure へのレプリケーションが行われており、レプリケートされたアイテムがフェールオーバーまたはフェールバック状態ではありません。
  • レプリケートされたアイテムが、Azure からオンプレミスにデータをレプリケートしていません。 
  • 初期レプリケーションは進行中ではなく、既に完了しています。  
  • レプリケートされたアイテムが ‘再同期’ 状態ではありません。 
  • 構成サーバーのバージョンが 9.50 以降で、その正常性は重大でない状態です。 
  • 構成サーバーに正常なハートビートがあります。 
  • ソース マシンにインストールされているモビリティ サービス エージェントのバージョンは 9.50 以降です。 
  • このレプリケートされたアイテムでは、プライベート エンドポイントは使用されません。  
  • レプリケートされたアイテムの正常性が重大でない状態であるか、復旧ポイントが正常に作成されています。 

最新化された Recovery Services コンテナー準備する

最新化されたアーキテクチャのセットアップでは、次のことを確認します。

  • 最新化されたアーキテクチャのセットアップに使用される Recovery Services コンテナーは、クラシック コンテナーと同じ地域の場所にあります。  
  • Azure Site Recovery レプリケーション アプライアンスは、バージョン 9.50 以降でオンプレミスにデプロイされます。 
  • アプライアンスがコンテナーに正常に登録されました。  
  • アプライアンスとそのすべてのコンポーネントが重大でない状態であり、アプライアンスに正常なハートビートがあります。 
  • vCenter Server のバージョンは、最新化されたアーキテクチャでサポートされています。 
  • ソース マシンの vCenter Server の詳細がアプライアンスに追加されます。 
  • Linux ディストリビューションのバージョンは、最新化されたアーキテクチャでサポートされています。 詳細については、こちらを参照してください
  • Windows Server のバージョンは、最新化されたアーキテクチャでサポートされています。 詳細については、こちらを参照してください

移行の合計時間を計算する

レプリケートされたアイテムをクラシック コンテナーから最新化されたコンテナーに移行するのに必要な合計時間は、アイテムのレプリケーションの状態とディスク サイズによって異なります。

State 最新化されたコンテナーに移行する時間
レプリケートされたアイテムの保護状態が正常であり、最後の復旧ポイントが 50 分未満の間に作成された 移行が 1 ~ 2 時間で完了する
レプリケートされたアイテムの保護状態が正常ではないか、最後の復旧ポイントが 50 分以上前に作成された 移行時間はディスク サイズによって異なる

マシンの保護状態が正常でない場合は、次の数式を使用してマシンの正確な時間を計算します。

移行時間 = 1 時間 + 45 秒/GiB

コンピューターの構成 移行時間
サイズが 256 GiB のディスクを 2 台搭載した 1 台のマシン ~ 4 時間 15 分

[両方のディスクが同時に移行されます]
サイズが 256 GiB のディスクを 2 台ずつ搭載した 10 台のマシン ~ 4 時間 15 分

[すべての VM とそのディスクが同時に移行されます]
サイズが 512 GiB のディスクを 4 台搭載した 1 台のマシン ~ 7 時間 30 分

[両方のディスクが同時に移行されます]
サイズが 512 GiB のディスクを 4 台ずつ搭載した 10 台のマシン ~ 7 時間 30 分

[すべての VM とそのディスクが同時に移行されます]

同じ式を使用すて移行にかかる時間が計算され、ポータルに表示されます。

必要なインフラストラクチャを定義する方法

クラシックから最新化されたアーキテクチャにマシンを移行する場合は、必要なインフラストラクチャが最新化された Recovery Services コンテナーに既に登録されていることを確認する必要があります。 必要なインフラストラクチャを定義するには、レプリケーション アプライアンスのサイズ設定と容量の詳細を参照してください。

原則として、クラシック Recovery Services コンテナー内のプロセス サーバーの数と同じ数のレプリケーション アプライアンスを設定する必要があります。 クラシック コンテナーに 1 つの構成サーバーと 4 つのプロセス サーバーがある場合は、最新化された Recovery Services コンテナーに 4 つのレプリケーション アプライアンスを設定する必要があります。

価格

Site Recovery ライセンス料金は、すべての復旧ポイントの保持期間が終わるまで、クラシック コンテナーで引き続き請求されます。 すべての復旧ポイントがクリーンアップされると、クラシック コンテナーの価格設定も停止します。 すべての復旧ポイントの保持期間が終わると、レプリケートされたアイテムは、システムによってトリガーされるレプリケーション消去操作を介して自動的に削除されます。

Site Recovery では、最初の復旧ポイントが生成され、古いコンテナーがクリーンアップされた後にのみ、最新化されたコンテナー内のレプリケートされたアイテムに対するライセンス料金の請求が開始されます。 クラシック コンテナーに残っている無料試用版の期間がある場合は、最新化されたコンテナーに同じ情報が渡されます。 価格設定は、この試用期間が経過した後にのみ、最新化されたコンテナーで開始されます。

注意

ある時点で、クラシックまたは最新化されたコンテナーのどちらか 1 つのコンテナーのみが使用されることで価格設定が発生します。

FAQ

マシンを最新化されたアーキテクチャに移行する必要がある理由

最終的には、クラシック アーキテクチャは非推奨になるため、それぞれ最新化されたアーキテクチャを使用していることを確認する必要があります。 次の表は、マシンのディザスター リカバリーを有効にする正しいオプションを選択できるようにするための 2 つのアーキテクチャの比較を示しています。

クラシック アーキテクチャ 最新化されたアーキテクチャ [新規]
オンプレミスのデータを検出するために必要な複数のセットアップ。 検出サービスを使用したオンプレミス データ センターの一元的な検出
初期オンボードに必要なさまざまな手順。 成果物の作成を自動化してオンボード エクスペリエンスを簡素化し、必要な入力を減らすための既定値を導入しました。
手動でダウンロードしたファイルを利用してクラウド コンテキストを取得します。 アプライアンスの設定時にクラウド コンテキストを取得するためのレプリケーション キーを導入しました
単純なレプリケーション有効化プロセスに必要なさまざまな手順。 必要な入力の数を減らし、各ブレードを再定義することで、レプリケーションの有効化エクスペリエンスを簡素化しました。
構成サーバーは、引き続きさまざまなコンポーネントの広範なセットアップを備えたオンプレミスのインフラストラクチャです。 すべてのコンポーネントを Azure ホスト型マイクロサービスに変換してアプライアンスを強化しました。 これにより、アプライアンスのスケーリング、監視、トラブルシューティングが簡素化されます。
Azure for Linux マシンでのスケールアウト プロセス サーバーとマスター ターゲット サーバーの必要性は、要件の妨げとなります。 プロセス サーバーとマスター ターゲット サーバーを個別に維持する必要がなくなりました
認証に静的なパスフレーズが使用されており、定期的なパスワード ローテーションという顧客のビジネス要件が妨げられていました。 より安全で、顧客のセキュリティ上の問題を解決する証明書ベースの認証が導入されました。
アップデート バージョンへのアップグレードは手動で行う必要があり、面倒なプロセスです。 アプライアンス コンポーネントと Mobility Service の両方に対して自動アップグレードが導入されました。
構成サーバーは高可用性を備えていないため、破綻する危険性があります。 回復性を確保するためにアプライアンスの高可用性を実装しました。
ルート資格情報は、エラーのないアップグレード エクスペリエンスを確保するために定期的に更新する必要があります。 自動アップグレードを実行するためのマシンのルート資格情報を維持する必要がなくなりました
接続を維持するには、構成サーバーに静的 IP アドレスを割り当てる必要があります。 アプライアンスとオンプレミスのマシンの間に FQDN ベースの接続が導入されました。
サイト間 VPN または ExpressRoute が有効になっている仮想ネットワークのみを使用する必要があります。 レプリケーションの反転のためにサイト間 VPN または ExpressRoute を維持する必要がなくなりました。

最新化されたアーキテクチャに移行する必要があるマシンは何ですか?

構成サーバーを使用してレプリケートされるすべての VMware マシンは、最新化されたアーキテクチャに移行する必要があります。 現時点では、VMware マシンのサポートがリリースされています。  

最新化された Recovery Services コンテナーはどこで作成する必要がありますか?

最新化された Recovery Services コンテナーは、クラシック コンテナーと同じリージョンとテナントに存在する必要があります。 これは任意のサブスクリプションまたはリソース グループの一部にすることができます。  

移行が実行されている間、レプリケーションは続行されますか?

いいえ、移行の進行中は、レプリケーションがしばらく中断されます。 この間は、クラシック Recovery Services コンテナーで最後に作成された復旧ポイントをフェールオーバーに使用できるようになります。 移行が完了すると、最新化された Recovery Services コンテナーに新しい復旧ポイントが生成されます。  

移行操作が完了としてマークされるのはいつですか?

移行操作は、最新化された Recovery Services コンテナーで最初の復旧ポイントが正常に作成された場合にのみ完了としてマークされます。 

移行が完了すると、クラシック Recovery Services コンテナーからどのような操作を実行できますか? 

移行後に実行できるのは、フェールオーバーを実行し、クラシック コンテナーからのレプリケーションを無効にすることのみです。 以前のコンテナーで復旧ポイントを使用できるようになるまでは、クラシック コンテナーを介してフェールオーバー操作を実行できます。

たとえば、レプリケートされたアイテムの保持期間が 72 時間 (3 日間) の場合、クラシック コンテナーの最新の復旧ポイントは、移行後処理の成功後も引き続き 72 時間 (3 日間) 使用できます。 規定された時間が経過すると、Azure Site Recovery ではレプリケートされたアイテムに対するレプリケーション消去操作をトリガーし、関連するすべてのストレージと課金の原因となるアイテムのクリーンアップを実行します。

移行操作の進行中にマシンに障害が発生した場合はどうなりますか?

移行が進行中のレプリケートされたアイテムは、最後の復旧ポイントの保持期間が終わるまで、クラシック Recovery Services コンテナーを介したフェールオーバー操作を引き続きサポートします。 フェールオーバー操作を実行しようとした場合、移行操作よりも優先度が高くなります。 移行のジョブは中止されます。 レプリケートされたアイテムが確実に移行されるようにするには、後で移行操作をもう一度トリガーする必要があります。  

注意

レプリケートされたアイテムのコンピューティングとネットワークのプロパティは、移行の進行中に更新できます。 ただし、最新化された Recovery Services コンテナーに変更がレプリケートされない場合があります。

クラシックから最新化されたコンテナーに一度に移行できるマシンの数を教えてください。

ポータルを介して最大 10 台のマシンを一度に移行できます。  

新しいコンテナーで使用する仮想ネットワーク、ストレージ アカウント、レプリケーション ポリシーを再作成する必要がありますか?

いいえ、以前に使用されていたのと同じリソースは、最新化されたコンテナーでも既定で使用されます。 それらは、レプリケートされたアイテムの [コンピューティングとネットワーク] ブレードからいつでも変更できます。 リソースが引き続き必要なアクセス権を保持するようにする必要があります。  

レプリケーション ポリシーは最新化されたコンテナーにどのように移行されますか?

前提条件として、Site Recovery ではまず、クラシック コンテナーに存在するのと同じ構成で、最新化されたコンテナーにレプリケーション ポリシーを作成します。 そのため、レプリケートされたアイテムが移行される場合は、まずそれに関連付けられているポリシーが最新化されたコンテナーに作成されてから、移行が行われます。 変更された値は最新化されたコンテナーに反映されないため、移行がトリガーされた後にクラシック コンテナーでレプリケーション ポリシーの構成を変更しないことをお勧めします。 この操作は、移行がトリガーされる前に行う必要があります。

最新化されたコンテナーで作成されたレプリケーション ポリシーの名前は、最新化されたコンテナーで変更されます。 これには、最新化された Recovery Services コンテナーのリソース グループ名とコンテナー名がプレフィックスとして付けられます。 そのため、コンテナーの名前が contoso-modern-vault で、コンテナーのリソース グループが contoso-rg であるとすると、ポリシー名がクラシック コンテナーで "default replication policy" である場合、最新化されたコンテナーでは "default replication policy contoso-modern-vault_contoso-rg" になります。

クラシック コンテナーでの移行中または移行後にレプリケーション ポリシーを編集できますか?

レプリケーション ポリシーのレプリカが既に最新化されたコンテナーに作成されている場合、クラシック コンテナー内のポリシーに対する変更は、最新化されたコンテナーに反映されません。

そのため、ポリシーを使用してレプリケートされるレプリケートされたアイテムが 10 個あり、そのうちの 5 つを最新化されたエクスペリエンスに移行することにした場合、移行が開始される前にポリシーのコピーが作成されます。 ここで、残りの 5 個のアイテムの移行を実行する前に、クラシック コンテナー内のポリシーに変更が加えられた場合、最新化されたコンテナーのポリシーは更新されません。 これらの構成変更を最新化されたコンテナーでも実行する必要があります。

マルチ VM 整合性グループとも呼ばれるレプリケーション グループに存在するレプリケートされたアイテムを移行するにはどうすればよいですか?

レプリケーション グループの一部であるレプリケートされたアイテムはすべて一緒に移行されます。 レプリケーション グループの選択によってすべてを選択するか、すべてスキップすることができます。 レプリケーション グループ内の一部のマシンで移行が失敗し、他のマシンでは成功した場合、失敗したレプリケートされたアイテムに対してクラシック エクスペリエンスへのロールバックが実行され、失敗したアイテムの移行をもう一度トリガーできます。

次の手順

クラシックから最新化された VMware ディザスター リカバリーに移行する方法