VMware から Azure へのディザスター リカバリー アーキテクチャ - クラシック
この記事では、Azure Site Recovery サービスを使用して、オンプレミスの VMware サイトと Azure の間の VMware 仮想マシン (VM) のディザスター リカバリー レプリケーション、フェールオーバー、および復旧をデプロイする場合に使用するアーキテクチャとプロセスについて説明します - クラシック。
モダン アーキテクチャの詳細については、この記事を参照してください。
アーキテクチャ コンポーネント
次の表と図は、Azure への VMware VM または物理マシンのディザスター リカバリーに使用するコンポーネントの概要を示したものです。
| コンポーネント | 要件 | 詳細 |
|---|---|---|
| Azure | Azure サブスクリプション、キャッシュの Azure Storage アカウント、マネージド ディスク、Azure ネットワーク。 | オンプレミスの VM からレプリケートされたデータは、Azure ストレージに格納されます。 オンプレミスから Azure へのフェールオーバーを実行すると、そのレプリケートされたデータで Azure VM が作成されます。 Azure VM は、作成時に Azure 仮想ネットワークに接続します。 |
| 構成サーバー マシン | 単一のオンプレミス マシン。 ダウンロードした OVF テンプレートからデプロイできる VMware VM として実行することをお勧めします。 マシンは、構成サーバー、プロセス サーバー、マスター ターゲット サーバーなど、オンプレミスのすべての Site Recovery コンポーネントを実行します。 |
構成サーバー: オンプレミスと Azure の間の通信を調整し、データのレプリケーションを管理します。 プロセス サーバー:構成サーバーに既定でインストールされます。 レプリケーション データを受信し、そのデータをキャッシュ、圧縮、暗号化によって最適化して、Azure Storage に送信します。 また、プロセス サーバーは、レプリケートする VM への Azure Site Recovery モビリティ サービスのインストールや、オンプレミスのマシンの自動検出も行います。 デプロイの拡大に合わせて、増大するレプリケーション トラフィックの処理を実行する独立したプロセス サーバーを追加できます。 マスター ターゲット サーバー:構成サーバーに既定でインストールされます。 Azure からのフェールバック中にレプリケーション データを処理します。 大規模なデプロイでは、フェールバック用に別のマスター ターゲット サーバーを追加できます。 |
| VMware サーバー | VMware VM は、オンプレミス vSphere ESXi サーバーでホストされています。 ホストの管理には vCenter サーバーをお勧めします。 | Site Recovery のデプロイ中には、VMware サーバーを Recovery Services コンテナーに追加します。 |
| レプリケートされたマシン | レプリケートする各 VMware VM にモビリティ サービスがインストールされます。 | プロセス サーバーから自動的にインストールできるようにすることをお勧めします。 また、サービスを手動でインストールしたり、Configuration Manager などの自動デプロイ方法を使用したりすることができます。 |
送信ネットワーク接続を設定する
Site Recovery を期待どおりに動作させるためには、環境でレプリケートが可能になるように、送信ネットワーク接続を変更する必要があります。
Note
クラシック アーキテクチャを使用する VMware または物理マシンの Site Recovery では、認証プロキシを使用してネットワーク接続を制御することはサポートされていません。 最新化されたアーキテクチャを使用する場合は、同じことがサポートされます。
URL に対する送信接続
アウトバウンド接続を制御するために URL ベースのファイアウォール プロキシを使用している場合、以下の URL へのアクセスを許可してください。
| 名前 | 商用 | 政府 | 説明 |
|---|---|---|---|
| ストレージ | *.blob.core.windows.net |
*.blob.core.usgovcloudapi.net |
ソース リージョンのキャッシュ ストレージ アカウントに、VM からデータが書き込まれるよう許可します。 |
| Microsoft Entra ID | login.microsoftonline.com |
login.microsoftonline.us |
Site Recovery サービス URL に対する承認と認証を提供します。 |
| レプリケーション | *.hypervrecoverymanager.windowsazure.com |
*.hypervrecoverymanager.windowsazure.us |
VM と Site Recovery サービスの通信を許可します。 |
| Service Bus | *.servicebus.windows.net |
*.servicebus.usgovcloudapi.net |
VM による Site Recovery の監視および診断データの書き込みを許可します。 |
オンプレミスの Azure Site Recovery インフラストラクチャと Azure サービスの間の通信用にフィルター処理される URL の完全な一覧については、前提条件に関する記事のネットワーク要件セクションを参照してください。
レプリケーション プロセス
VM に対してレプリケーションを有効にした場合、指定したレプリケーション ポリシーを使用して、Azure Storage への最初のレプリケーションが開始されます。 次のことを考慮してください。
- VMware VM の場合、レプリケーションは、VM 上で実行されているモビリティ サービス エージェントを使用しているブロックレベル (ほぼ連続的) です。
- 任意のレプリケーション ポリシー設定が適用されます。
- [RPO しきい値] 。 この設定は、レプリケーションには影響しません。 これは監視に役立ちます。 現在の RPO が指定したしきい値の上限を超えた場合、イベントが発生し、必要に応じて電子メールが送信されます。
- [復旧ポイントのリテンション期間] 。 この設定は、中断が発生したときに、どこまで戻るかを時間で指定します。 最大保持期間は、マネージド ディスクで 15 日です。
- [App-consistent snapshots](アプリ整合性スナップショット) 。 アプリ整合性スナップショットは、アプリのニーズに応じて 1 から 12 時間ごとに取得できます。 スナップショットは標準の Azure BLOB スナップショットです。 VM 上で実行されているモビリティ エージェントでは、この設定に従って VSS スナップショットが要求され、レプリケーション ストリームのアプリケーション整合性ポイントとして特定の時点がブックマークされます。
Note
復旧ポイントのリテンション期間を長くすると、より多くの復旧ポイントを保存する必要が生じ、ストレージ コストに影響する可能性があります。
トラフィックは、インターネット経由で Azure Storage のパブリック エンドポイントにレプリケートされます。 別の方法として、Azure ExpressRoute と Microsoft ピアリングを使用できます。 オンプレミス サイトから Azure へのサイト間仮想プライベート ネットワーク (VPN) を介したトラフィックのレプリケートはサポートされていません。
初期レプリケーション操作により、レプリケーションを有効にした時点のマシン上のデータ全体が確実に Azure に送信されます。 初回のレプリケーションの終了後、Azure への差分変更のレプリケーションが開始されます。 マシンに対する追跡された変更は、プロセス サーバーに送信されます。
通信は、次のように行われます。
- VM は、レプリケーション管理のために、受信ポート HTTPS 443 でオンプレミスの構成サーバーと通信します。
- 構成サーバーは、送信ポート HTTPS 443 経由で Azure によるレプリケーションを調整します。
- VM は、受信ポート HTTPS 9443 でレプリケーション データを (構成サーバー マシン上で実行されている) プロセス サーバーに送信します。 このポートは変更可能です。
- プロセス サーバーは、レプリケーション データを受信し、データを最適化して暗号化し、アウトバウンド ポート 443 経由で Azure ストレージに送信します。
レプリケーション データ ログは、まず Azure のキャッシュ ストレージ アカウントに記録されます。 これらのログは処理され、データは Azure Managed Disk (Azure Site Recovery シード ディスクと呼ばれます) に保存されます。 復旧ポイントはこのディスク上に作成されます。
再同期プロセス
- 初期レプリケーション中または差分変更の転送中に、ソース マシンとプロセス サーバーの間か、またはプロセス サーバーと Azure の間でネットワーク接続の問題が発生する場合があります。 どちらの場合も、直ちに Azure へのデータ転送の失敗につながることがあります。
- データ整合性の問題を回避し、データ転送コストを最小限に抑えるために、Site Recovery はマシンを再同期としてマークします。
- マシンはまた、ソース マシンと Azure に格納されているデータの間の整合性を維持するために、次のような状況でも再同期としてマークされる場合があります。
- マシンで強制シャットダウンが実行された場合
- マシンでディスクのサイズ変更 (ディスク サイズの 2 TB から 4 TB への変更) などの構成変更が実行された場合
- 再同期では、Azure に差分データのみを送信します。 オンプレミスと Azure の間のデータ転送は、ソース マシンと Azure に格納されているデータの間のデータのチェックサムを計算することによって最小限に抑えられます。
- 既定では再同期は業務時間外に自動的に実行するようにスケジュールされます。 既定の業務時間外の再同期を待ちたくない場合は、VM を手動で再同期できます。 これを行うには、Azure portal に移動し、[VM] >[再同期] を選択します。
- 既定の再同期が業務時間外に失敗し、手動介入が必要になった場合、エラーは Azure portal の特定のマシンで生成されます。 エラーを解決し、手動で再同期をトリガーできます。
- 再同期が完了した後、差分変更のレプリケーションが再開されます。
レプリケーション ポリシーの管理
- レプリケーションを有効にするときに、レプリケーション ポリシーの設定をカスタマイズできます。
- いつでもレプリケーション ポリシーを作成でき、レプリケーションを有効にするときに適用することができます。
マルチ VM 整合性
複数の VM を一緒にレプリケートし、フェールオーバー時にクラッシュ整合性復旧ポイントとアプリ整合性復旧ポイントを共有する場合は、レプリケーション グループにまとめることができます。 マルチ VM 整合性はワークロードのパフォーマンスに影響を与えるので、すべてのマシン間で整合性を必要とするワークロードを実行している VM にのみ使用する必要があります。
スナップショットと復旧ポイント
復旧ポイントは、特定の時点で取得された VM のディスクのスナップショットから作成されます。 VM をフェールオーバーするときは、復旧ポイントを使用してターゲットの場所に VM を復元します。
フェールオーバーでは、通常、破損やデータ損失なしで VM が起動し、オペレーティング システムおよび VM で実行されるアプリについて VM のデータが一貫していることが必要です。 これは、作成されるスナップショットの種類に依存します。
Site Recovery では、次のようにスナップショットが作成されます。
- Site Recovery では、既定でデータのクラッシュ整合性スナップショットが作成され、ユーザーが頻度を指定するとアプリ整合性スナップショットが作成されます。
- 復旧ポイントはスナップショットから作成されて、レプリケーション ポリシーでの保持期間の設定に従って格納されます。
一貫性
次の表で、整合性の種類について説明します。
クラッシュ整合性
| 説明 | 詳細 | 推奨 |
|---|---|---|
| クラッシュ整合性スナップショットでは、スナップショットが作成されたときにディスクに存在していたデータがキャプチャされます。 メモリ内のものは含まれません。 スナップショットが作成された瞬間に 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 で実行されているアプリのパフォーマンスに影響します。 |
フェールオーバーとフェールバックのプロセス
レプリケーションがセットアップされ、ディザスター リカバリーの訓練 (フェールオーバーのテスト) を実行してすべてが期待どおりに動作することを確認したら、必要に応じて、フェールオーバーとフェールバックを実行できます。
単一のマシンをフェールオーバーするか、復旧計画を作成して複数の VM を同時にフェールオーバーします。 単一のマシンのフェールオーバーと比較した復旧計画の利点を次に示します。
- アプリのすべての VM を 1 つの復旧プランに含めることで、アプリの依存関係をモデル化できます。
- スクリプト、Azure Runbook、手動操作を行うための一時停止を追加できます。
最初のフェールオーバーをトリガーするには、Azure VM から、ワークロードへのアクセスを開始するようコミットします。
プライマリ オンプレミス サイトが再び使用可能になったら、フェールバックを実行する準備を行うことができます。 フェールバックするためには、次のものを含むインフラストラクチャをセットアップする必要があります。
- Azure 上の一時的なプロセス サーバー:Azure からフェールバックするには、Azure からのレプリケーションを処理するプロセス サーバーとして機能する Azure VM を設定します。 この VM は、フェールバックの完了後に削除できます。
- VPN 接続:フェールバックするには、Azure ネットワークからオンプレミス サイトへの VPN 接続 (または ExpressRoute) が必要です。
- 独立したマスター ターゲット サーバー:既定では、構成サーバーと共にオンプレミスの VMware VM にインストールされたマスター ターゲット サーバーによって、フェールバックが処理されます。 大量のトラフィックをフェールバックする必要がある場合は、その目的を果たすための独立したオンプレミスのマスター ターゲット サーバーをセットアップします。
- フェールバック ポリシー:ご利用のオンプレミスにもう一度レプリケートするには、フェールバック ポリシーが必要です。 このポリシーは、オンプレミスから Azure へのレプリケーション ポリシーを作成したときに自動的に作成されます。
コンポーネントが配置された後、フェールバックは、次の 3 つのアクションを実行します。
- ステージ 1:Azure VM が Azure からオンプレミスの VMware VM へのレプリケートを開始するように、Azure VM を再保護します。
- ステージ 2:オンプレミス サイトでフェールオーバーを実行します。
- ステージ 3:ワークロードがフェールバックしたら、オンプレミス VM のレプリケーションを再び有効にします。
次のステップ
VMware から Azure へのレプリケーションを有効にするには、このチュートリアルに従ってください。