クラシックから、最新化された VMware ディザスター リカバリーに移行する
この記事では、クラシックから最新化された保護アーキテクチャへの VMware または物理マシンのレプリケーションの移行に関するアーキテクチャ、必要なインフラストラクチャ、FAQ に関する情報を提供します。 この移行機能を使用すると、レプリケートされたアイテムを構成サーバーから Azure Site Recovery レプリケーション アプライアンスに正常に移動できます。 この移行はスマート レプリケーション メカニズムによって誘導されます。このメカニズムでは、重要でないレプリケートされたアイテムに対しては完全な初期レプリケーションは再実行されず、差分データのみが移動されます。
注意
復旧計画は移行されないため、最新化された 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 コンテナーを作成し、エクスペリエンスがクラシックに切り替えられていないことを確認します
- Azure Site Recovery レプリケーション アプライアンスをデプロイします。
- 検出が正常に実行されるように、オンプレミス マシンの vCenter Server の詳細をアプライアンスに追加します。
従来の Recovery Services コンテナーを準備する
移行する予定のレプリケートされたアイテムに対して、次のことを確認します。
- レプリケートされたアイテムは、構成サーバーを介してレプリケートする VMware または物理マシンです。
- レプリケーションが、アンマネージド ストレージ アカウントではなく、マネージド ディスクに対して行われています。
- オンプレミスから Azure へのレプリケーションが行われており、レプリケートされたアイテムがフェールオーバーまたはフェールバック状態ではありません。
- レプリケートされたアイテムが、Azure からオンプレミスにデータをレプリケートしていません。
- 初期レプリケーションは進行中ではなく、既に完了しています。
- レプリケートされたアイテムが ‘再同期’ 状態ではありません。
- 構成サーバーのバージョンが 9.50 以降で、その正常性は重大でない状態です。
- 構成サーバーに正常なハートビートがあります。
- ソース マシンにインストールされているモビリティ サービス エージェントのバージョンは 9.50 以降です。
- MSI が有効になっている Recovery Services コンテナーがサポートされています。
- プライベート エンドポイントが有効になっている Recovery Services コンテナーがサポートされています。
- レプリケートされたアイテムの正常性が重大でない状態であるか、復旧ポイントが正常に作成されています。
最新化された 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 を維持する必要がなくなりました。 |
| サード パーティ製ツールである MySQL も設定する必要があります。 | サード パーティ製ツールへの依存関係を削除しました。 |
最新化されたアーキテクチャに移行する必要があるマシンは何ですか?
構成サーバーを使用してレプリケートされるすべての 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 整合性グループとも呼ばれるレプリケーション グループに存在するレプリケートされたアイテムを移行するにはどうすればよいですか?
レプリケーション グループの一部であるレプリケートされたアイテムはすべて一緒に移行されます。 レプリケーション グループの選択によってすべてを選択するか、すべてをスキップすることができます。 レプリケーション グループ内の一部のマシンで移行プロセスが失敗したにもかかわらず、他のマシンでは成功した場合、失敗したレプリケートされたアイテムに対してクラシック エクスペリエンスへのロールバックが実行され、それらのアイテムの移行プロセスをもう一度トリガーできます。
パブリック エンドポイントを使用した従来のセットアップを、プライベート エンドポイントを使用した最新のセットアップに移行できますか?
いいえ。パブリック エンドポイントを使用した従来のディザスター リカバリーのセットアップは、最新のパブリック エンドポイントのセットアップにのみ移行できます。 非プライベート エンドポイントからプライベート エンドポイントへの移行はサポートされていませんが、プライベート エンドポイントからプライベート エンドポイントへの移行はサポートされています。