次の方法で共有


VMware から Azure へのディザスター リカバリー アーキテクチャ - 最新化

この記事では、最新化された VMware または物理マシンの保護エクスペリエンスを使用して、オンプレミスの VMware サイトと Azure の間の VMware 仮想マシン (VM) のディザスター リカバリー レプリケーション、フェールオーバー、および復旧をデプロイする場合に使用するアーキテクチャとプロセスについて説明します。

注意

ASR レプリケーション アプライアンスを設定する場合は、必ず新しい Recovery Services コンテナーを作成してください。 既存のコンテナーを使用しないでください。

クラシック アーキテクチャの Azure Site Recovery のアーキテクチャについては、この記事を参照してください。

アーキテクチャ コンポーネント

次の表と図は、Azure への VMware VM または物理マシンのディザスター リカバリーに使用するコンポーネントの概要を示したものです。

VMware から Azure へのアーキテクチャ

コンポーネント 要件 詳細
Azure Azure サブスクリプション、キャッシュの Azure Storage アカウント、マネージド ディスク、Azure ネットワーク。 オンプレミスの VM からレプリケートされたデータは、Azure ストレージに格納されます。 オンプレミスから Azure へのフェールオーバーを実行すると、そのレプリケートされたデータで Azure VM が作成されます。 Azure VM は、作成時に Azure 仮想ネットワークに接続します。
Azure Site Recovery レプリケーション アプライアンス これは、Azure Site Recovery オンプレミス インフラストラクチャ全体の基本的な構成要素です。

アプライアンス内のすべてのコンポーネントは、レプリケーション アプライアンスと連携します。 このサービスは、保護されたマシンの正常性、データ レプリケーション、自動更新の監視など、すべてのエンドツーエンドの Site Recovery アクティビティを監視します。
アプライアンスでは、次のようなさまざまな重要なコンポーネントをホストします。

プロキシ サーバー: このコンポーネントは、クラウドのモビリティ エージェントと Site Recovery サービス間のプロキシ チャネルとして機能します。 これにより、復旧ポイントを生成するために運用ワークロードからの他のインターネット接続が不要になります。

検出された項目: このコンポーネントは、vCenter の情報を収集し、クラウドの Azure Site Recovery 管理サービスと連携します。

再保護サーバー: このコンポーネントは、再保護操作とフェールバック操作中に Azure とオンプレミスのマシンの間で調整を行います。

プロセス サーバー: このコンポーネントは、Azure に送信される前のデータのキャッシュおよび圧縮に使用されます。

レプリケーション アプライアンスについて、および複数のレプリケーション アプライアンスを使用する方法についての詳細を確認してください。

Recovery Service エージェント: このコンポーネントは、Site Recovery サービスの構成と登録、およびすべてのコンポーネントの正常性の監視に使用されます。

Site Recovery プロバイダー: このコンポーネントは、再保護を容易にするために使用されます。 ソース マシンの別の場所の再保護と元の場所の再保護が識別されます。

レプリケーション サービス: このコンポーネントは、ソースの場所から Azure にデータをレプリケートするために使用されます。
VMware サーバー VMware VM は、オンプレミス vSphere ESXi サーバーでホストされています。 ホストの管理には vCenter サーバーをお勧めします。 Site Recovery のデプロイ中には、VMware サーバーを Recovery Services コンテナーに追加します。
レプリケートされたマシン レプリケートする各 VMware VM にモビリティ サービスがインストールされます。 Mobility Service の自動インストールを許可することをお勧めします。 または、サービスを手動でインストールすることもできます。

送信ネットワーク接続を設定する

Site Recovery を期待どおりに動作させるためには、環境でレプリケートが可能になるように、送信ネットワーク接続を変更する必要があります。

Note

Site Recovery では、ネットワーク接続を制御するための認証プロキシの使用をサポートしていません。

URL に対する送信接続

アウトバウンド接続を制御するために URL ベースのファイアウォール プロキシを使用している場合、以下の URL へのアクセスを許可してください。

URL 詳細
portal.azure.com Azure Portal に移動します。
*.windows.net
*.msftauth.net
*.msauth.net
*.microsoft.com
*.live.com
*.office.com
Azure サブスクリプションへのサインイン用。
*.microsoftonline.com アプライアンスが Azure Site Recovery と通信するための Microsoft Entra アプリを作成します。
management.azure.com アプライアンスが Azure Site Recovery サービスと通信するための Microsoft Entra アプリを作成します。
*.services.visualstudio.com 内部監視に使用するアプリ ログをアップロードします。
*.vault.azure.net Azure Key Vault でシークレットを管理します。 注: レプリケートするマシンからこれにアクセスできることを確認します。
aka.ms "aka" リンクへのアクセスを許可します。 Azure Site Recovery アプライアンスの更新に使用されます。
download.microsoft.com/download Microsoft ダウンロードからのダウンロードを許可します。
*.servicebus.windows.net アプライアンスと Azure Site Recovery サービスの間の通信。
*.discoverysrv.windowsazure.com Azure Site Recovery 検出サービスの URL に接続します。
*.hypervrecoverymanager.windowsazure.com Azure Site Recovery マイクロサービスの URL に接続します。
*.blob.core.windows.net ターゲット ディスクを作成するために使用される Azure ストレージにデータをアップロードします。
*.backup.windowsazure.com 保護サービスの URL - Azure でレプリケートされたディスクを処理および作成するために Azure Site Recovery によって使用されるマイクロサービス。
*.prod.migration.windowsazure.com オンプレミスの資産を検出します。

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

  1. VM に対してレプリケーションを有効にした場合、指定したレプリケーション ポリシーを使用して、Azure Storage への最初のレプリケーションが開始されます。 次のことを考慮してください。

    • VMware VM の場合、レプリケーションは、VM 上で実行されているモビリティ サービス エージェントを使用しているブロックレベル (ほぼ連続的) です。
    • 任意のレプリケーション ポリシー設定が適用されます。
      • [RPO しきい値] 。 この設定は、レプリケーションには影響しません。 これは監視に役立ちます。 現在の RPO が指定したしきい値の上限を超えた場合、イベントが発生し、必要に応じて電子メールが送信されます。
      • [復旧ポイントのリテンション期間] 。 この設定は、中断が発生したときに、どこまで戻るかを時間で指定します。 最大リテンション期間は 15 日です。
      • [App-consistent snapshots](アプリ整合性スナップショット) 。 アプリ整合性スナップショットは、アプリのニーズに応じて 1 から 12 時間ごとに取得できます。 スナップショットは標準の Azure BLOB スナップショットです。 VM 上で実行されているモビリティ エージェントでは、この設定に従って VSS スナップショットが要求され、レプリケーション ストリームのアプリケーション整合性ポイントとして特定の時点がブックマークされます。

      Note

      復旧ポイントのリテンション期間を長くすると、より多くの復旧ポイントを保存する必要が生じ、ストレージ コストに影響する可能性があります。

  2. トラフィックは、インターネット経由で Azure Storage のパブリック エンドポイントにレプリケートされます。 別の方法として、Azure ExpressRoute と Microsoft ピアリングを使用できます。 オンプレミス サイトから Azure へのサイト間仮想プライベート ネットワーク (VPN) を介したトラフィックのレプリケートは、プライベート エンドポイントを使用する場合にのみサポートされます。

  3. 初期レプリケーション操作により、レプリケーションを有効にした時点のマシン上のデータ全体が確実に Azure に送信されます。 初回のレプリケーションの終了後、Azure への差分変更のレプリケーションが開始されます。 マシンに対する追跡された変更は、プロセス サーバーに送信されます。

  4. 通信は、次のように行われます。

    • VM が、レプリケーション管理のために、受信ポート HTTPS 443 上でオンプレミスのアプライアンスと通信します。
    • VM によって、受信ポート HTTPS 9443 でレプリケーション データがアプライアンスに送信されます。 このポートは変更可能です。
    • アプライアンスでレプリケーション データが受信され、データの最適化、暗号化が行われ、アウトバウンド ポート 443 経由で Azure ストレージに送信されます。
  5. レプリケーション データ ログは、まず Azure のキャッシュ ストレージ アカウントに記録されます。 これらのログは処理され、データは Azure マネージド ディスク (asrseeddisk と呼ばれます) に保存されます。 復旧ポイントはこのディスク上に作成されます。

ポートを使用した VMware から Azure へのデータ フロー

再同期プロセス

  1. 初期レプリケーション中または差分変更の転送中に、ソース マシンとプロセス サーバーの間か、またはプロセス サーバーと Azure の間でネットワーク接続の問題が発生する場合があります。 どちらの場合も、直ちに Azure へのデータ転送の失敗につながることがあります。
  2. データ整合性の問題を回避し、データ転送コストを最小限に抑えるために、Site Recovery はマシンを再同期としてマークします。
  3. マシンはまた、ソース マシンと Azure に格納されているデータの間の整合性を維持するために、次のような状況でも再同期としてマークされる場合があります
    • マシンで強制シャットダウンが実行された場合
    • マシンでディスクのサイズ変更 (ディスク サイズの 2 TB から 4 TB への変更) などの構成変更が実行された場合
  4. 再同期では、Azure に差分データのみを送信します。 オンプレミスと Azure の間のデータ転送は、ソース マシンと Azure に格納されているデータの間のデータのチェックサムを計算することによって最小限に抑えられます。
  5. 既定では、再同期は業務時間外に自動的に実行するようにスケジュールされます。 既定の業務時間外の再同期を待ちたくない場合は、VM を手動で再同期できます。 これを行うには、Azure portal に移動し、[VM] >[再同期] を選択します。
  6. 既定の再同期が業務時間外に失敗し、手動介入が必要になった場合、エラーは Azure portal の特定のマシンで生成されます。 エラーを解決し、手動で再同期をトリガーできます。
  7. 再同期が完了した後、差分変更のレプリケーションが再開されます。

Replication policy

Azure VM レプリケーションを有効にするときに、既定で Site Recovery によって、次の表に示す既定の設定で新しいレプリケーション ポリシーが作成されます。

ポリシーの設定 詳細 [Default]
復旧ポイントの保持期間 Site Recovery で復旧ポイントを保持する長さを指定します 1 日
アプリ整合性スナップショットの頻度 Site Recovery でアプリ整合性スナップショットを取得する頻度 無効

レプリケーション ポリシーの管理

次のように既定のレプリケーション ポリシーの設定を変更および管理できます。

  • レプリケーションを有効にするときに、設定を変更できます。
  • レプリケーションを有効にしようとしているときに、新しいレプリケーション ポリシーを作成または編集できます。

マルチ VM 整合性

複数の VM を一緒にレプリケートし、フェールオーバー時のクラッシュ整合性とアプリ整合性の各復旧ポイントをそれらで共有している必要がある場合は、レプリケーション グループにまとめることができます。 マルチ VM 整合性はワークロードのパフォーマンスに影響を与えるので、すべてのマシン間で整合性を必要とする 4 つのワークロードを実行している VM にのみ使用する必要があります。

スナップショットと復旧ポイント

復旧ポイントは、特定の時点で取得された VM のディスクのスナップショットから作成されます。 VM をフェールオーバーするときは、復旧ポイントを使用してターゲットの場所に VM を復元します。

フェールオーバーでは、通常、破損やデータ損失なしで VM が起動し、オペレーティング システムおよび VM で実行されるアプリについて VM のデータが一貫していることが必要です。 これは、作成されるスナップショットの種類に依存します。

Site Recovery では、次のようにスナップショットが作成されます。

  1. Site Recovery では、既定でデータのクラッシュ整合性スナップショットが作成され、ユーザーが頻度を指定するとアプリ整合性スナップショットが作成されます。
  2. 復旧ポイントはスナップショットから作成されて、レプリケーション ポリシーでの保持期間の設定に従って保存されます。

一貫性

次の表で、整合性の種類について説明します。

クラッシュ整合性

説明 詳細 推奨
クラッシュ整合性スナップショットでは、スナップショットが作成されたときにディスクに存在していたデータがキャプチャされます。 メモリ内のものは含まれません。

スナップショットが作成された瞬間に VM がクラッシュしたり、電源コードがサーバーから抜かれたりした場合にディスク上に存在していたデータと同じものが含まれます。

クラッシュ整合性では、オペレーティング システムや VM 上のアプリのデータ整合性は保証されません。
Site Recovery では、既定で 5 分ごとにクラッシュ整合性復旧ポイントが作成されます。 この設定を変更することはできません。

現在、ほとんどのアプリでは、クラッシュ整合性ポイントから十分に復旧できます。

クラッシュ整合性復旧ポイントは、通常、オペレーティング システム、および DHCP サーバーやプリント サーバーなどのアプリの複製に十分です。

アプリ整合性

説明 詳細 推奨
アプリ整合性復旧ポイントは、アプリ整合性スナップショットから作成されます。

アプリ整合性スナップショットには、クラッシュ整合スナップショット内のすべての情報に加えて、メモリ内のすべてのデータと進行中のトランザクションが含まれます。
アプリ整合性スナップショットでは、ボリューム シャドウ コピー サービス (VSS) が使用されます。

1) Azure Site Recovery では、コピーのみのバックアップ (VSS_BT_COPY) 方法が使用されます。これは、Microsoft SQL のトランザクション ログのバックアップ時刻およびシーケンス番号を変更しません。

2) スナップショットが開始されると、VSS によってボリュームでコピーオンライト (COW) 操作が実行されます。

3) COW を実行する前、VSS はマシン上のすべてのアプリに、メモリ常駐データをディスクにフラッシュする必要があることを通知します。

4) その後、VSS は、バックアップ/ディザスター リカバリー アプリ (このケースでは Site Recovery) にスナップショット データを読み取って続行することを許可します。
アプリ整合性スナップショットはユーザーが指定した頻度に従って作成されます。 この頻度は常に、復旧ポイントを保持するための設定より短くする必要があります。 たとえば、復旧ポイントを既定の設定の 24 時間を使用して保持する場合、頻度を 24 時間未満に設定する必要があります。

クラッシュ整合性スナップショットより複雑で、完了に時間がかかります。

レプリケーションが有効な VM で実行されているアプリのパフォーマンスに影響します。

フェールオーバーとフェールバックのプロセス

レプリケーションが設定され、ディザスター リカバリーの訓練 (フェールオーバーのテスト) を実行してすべてが期待どおりに動作することを確認したら、必要に応じて、フェールオーバーとフェールバックを実行できます。

  1. 単一のマシンに対してフェールオーバーを実行することも、復旧計画を作成して複数の VM を同時にフェールオーバーすることもできます。 単一のマシンのフェールオーバーと比較した復旧計画の利点を次に示します。

    • アプリのすべての VM を 1 つの復旧プランに含めることで、アプリの依存関係をモデル化できます。
    • スクリプト、Azure Runbook、手動操作を行うための一時停止を追加できます。
  2. 最初のフェールオーバーをトリガーするには、Azure VM から、ワークロードへのアクセスを開始するようコミットします。

  3. プライマリ オンプレミス サイトが再び使用可能になったら、フェールバックを実行する準備を行うことができます。 大量のトラフィックをフェールバックする必要がある場合は、新しい Azure Site Recovery レプリケーション アプライアンスを設定します。

    • ステージ 1:Azure VM が Azure からオンプレミスの VMware VM へのレプリケートを開始するように、Azure VM を再保護します。
    • ステージ 2:オンプレミス サイトでフェールオーバーを実行します。
    • ステージ 3:ワークロードがフェールバックしたら、オンプレミス VM のレプリケーションを再び有効にします。

次のステップ

VMware から Azure へのレプリケーションを有効にするには、このチュートリアルに従ってください。