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