一般的な質問:Azure から Azure へのディザスター リカバリー

この記事では、Azure Site Recovery サービスを使用した Azure VM の別の Azure リージョンへのディザスター リカバリーについてよく寄せられる質問に回答します。

全般

Site Recovery の価格

Azure VM のディザスター リカバリーのコストについて学習します。

Free レベルのしくみを教えてください。

Site Recovery で保護されるすべてのインスタンスは、保護を開始してから 31 日間は無料になります。 この期間が経過すると、各インスタンスは料金の詳細にまとめられた料金で保護されます。 Azure 料金計算ツールを使用してコストを見積もることができます。

最初の 31 日間に、その他の Azure 料金は発生しますか?

はい。 Azure Site Recovery では、最初の 31 日間、インスタンスは無料で保護されますが、Azure Storage、ストレージ トランザクション、データ転送については料金が発生する場合があります。 復旧された VM からも、Azure のコンピューティングの料金が発生する場合があります。

Azure VM ディザスター リカバリーの使用を開始するにはどうすればよいですか?

  1. Azure VM ディザスター リカバリー アーキテクチャを理解する
  2. サポート要件を確認する
  3. Azure VM のディザスター リカバリーを設定する
  4. テスト フェールオーバーでディザスター リカバリーのテストを実行する
  5. セカンダリ Azure リージョンへの完全フェールオーバーを実行する
  6. セカンダリ リージョンからプライマリ リージョンにフェールバックする

ターゲット リージョンの容量を確保するにはどうすればよいですか?

十分なインフラストラクチャ容量が確保されるよう、Site Recovery チームと Azure 容量管理チームが計画を立てます。 フェールオーバーを開始するときに、これらのチームは、Site Recovery によって保護される VM インスタンスがターゲット リージョンにデプロイされるようにするための支援も行います。

レプリケーション

ディスク暗号化が有効になっている VM をレプリケートできますか?

はい。 Site Recovery では、Azure Disk Encryption (ADE) が有効になっている VM のディザスター リカバリーがサポートされています。 レプリケーションを有効にすると、Azure では、必要なすべてのディスク暗号化キーとシークレットがユーザー コンテキストでソース リージョンからターゲット リージョンにコピーされます。 自分に必要なアクセス許可がない場合、セキュリティ管理者がスクリプトを利用し、キーとシークレットをコピーできます。

  • Site Recovery では、Windows を実行している Azure VM で ADE がサポートされています。
  • Site Recovery は次をサポートします。
    • ADE バージョン 0.1。Microsoft Entra ID を必要とするスキーマがあります。
    • ADE バージョン 1.1。Microsoft Entra ID は必要ありません。 バージョン 1.1 の場合、Microsoft Azure VM にはマネージド ディスクが必要です。
    • 拡張スキーマの詳細について、詳細を確認してください

暗号化された VM のレプリケーションの有効化について、詳細を確認します

その他の暗号化フィーチャーのサポートについては、 サポート マトリックス を参照してください。

別のリソース グループから Automation アカウントを選択できますか?

レプリケートされた Azure VM で実行されている Mobility Service 拡張機能の更新を Site Recovery が管理できるようにすると、Azure Automation アカウントを使用して (Azure サービスによって使用される) グローバル Runbook がデプロイされます。 Site Recovery が作成する Automation アカウントを使用するか、既存の Automation アカウントを使用するように選択することができます。

現在、ポータルでは、コンテナーと同じリソース グループ内の Automation アカウントのみを選択できます。 PowerShell を使って、別のリソース グループから Automation アカウントを選択できます。 自動更新の有効化の詳細について、詳細を確認してください

コンテナー リソース グループに含まれていない顧客の Automation アカウントを使用している場合、既定の Runbook を削除できますか?

はい、不要な場合は削除できます。

別のサブスクリプションに VM をレプリケートできますか?

はい、同じ Microsoft Entra テナント内で任意のサブスクリプションに Azure VM をレプリケートできます。 VM のディザスター リカバリーを有効にした場合、既定では、表示されるターゲット サブスクリプションはソース VM のものになります。 ターゲット サブスクリプションを変更でき、その他の設定 (リソース グループ、仮想ネットワークなど) は、選択したサブスクリプションから自動的に設定されます。

可用性ゾーン内の VM を別のリージョンにレプリケートすることはできますか?

はい、可用性ゾーン内の VM を別の Azure リージョンにレプリケートすることができます。

非ゾーンの VM を同じリージョン内のゾーンにレプリケートすることはできますか?

これはサポートされていません。

ゾーン VM を同じリージョンの別のゾーンにレプリケートすることはできますか?

このサポートは、いくつかのリージョンに制限されています。 詳細については、こちらを参照してください

レプリケーションからディスクを除外できますか?

はい、PowerShell を使用して、レプリケーションを設定するときにディスクを除外できます。 ディスクの除外の詳細については、こちらをご覧ください。

レプリケートされた VM に追加された新しいディスクをレプリケートできますか?

マネージド ディスクがあるレプリケートされた VM では、新しいディスクを追加し、それらに対するレプリケーションを有効にすることができます。 新しいディスクを追加すると、レプリケートされた VM に、VM 上の 1 つ以上のディスクで保護が使用できることを示す警告メッセージが表示されます。

  • 追加されたディスクのレプリケーションを有効にすると、初回のレプリケーション後に警告は表示されなくなります。
  • ディスクのレプリケーションを有効にしない場合、この警告を無視できます。
  • ディスクが追加された VM をフェールオーバーする場合、レプリケーション ポイントには回復に使用できるディスクが表示されます。 たとえば、ディスクが 1 つある VM に 2 つ目のディスクを追加する場合、追加する前に作成されたレプリケーション ポイントでは、"1/2 台のディスク" と表示されます。

Site Recovery では、レプリケートされた VM からディスクを "ホット リムーブ" できません。 VM ディスクを削除する場合は、VM のレプリケーションを無効にしてから再度有効にする必要があります。

どのくらいの頻度で Azure にレプリケートできますか?

Azure VM を別の Azure リージョンにレプリケートするときは、レプリケーションは継続的に行われます。 プロセスの詳細を確認する。

リージョン内で非ゾーンの仮想マシンをレプリケートできますか。

Site Recovery を使用し、リージョン内で非ゾーンの仮想マシンをレプリケートすることはできません。 ただし、ゾーンのあるマシンを、同じリージョン内の別のゾーンにレプリケートできます。

VM インスタンスを任意の Azure リージョンにレプリケートできますか?

任意の 2 つのリージョン間で VM をレプリケートして、復旧できます。

Site Recovery にはインターネット接続が必要ですか?

いいえ、ただし、VM には Site Recovery の URL と IP 範囲へのアクセスが必要です。 詳細については、こちらを参照してください

リソース グループ間で階層化されたアプリケーションをレプリケートできますか?

はい、アプリをレプリケートし、別のリソース グループにディザスター リカバリー構成を保持することは可能です。

たとえば、異なるリソース グループにアプリが 3 つの層 (アプリケーション/データベース/Web) を持つ場合、すべての層を保護するためにレプリケーションを 3 回有効にする必要があります。 Site Recovery によって、3 つの層が 3 つの異なるリソース グループにレプリケートされます。

リソース グループとの間でストレージ アカウントを移動できますか?

いいえ、これはサポートされていません。 ストレージ アカウントを別のリソース グループに誤って移動し、元のリソース グループを削除した場合は、古いリソース グループと同じ名前で新しいリソース グループを作成し、そのストレージ アカウントをこのリソース グループに移動できます。

Replication policy

レプリケーション ポリシーとは何ですか?

レプリケーション ポリシーでは、復旧ポイントの保持履歴と、アプリ整合性スナップショットの頻度が定義されています。 Site Recovery では、次のように既定のレプリケーション ポリシーが作成されます。

  • 復旧ポイントを 1 日間保持します。
  • アプリ一貫性スナップショットは無効化され、デフォルトでは作成されません。

レプリケーション設定については、こちらを参照してください

クラッシュ整合性復旧ポイントとは何ですか?

クラッシュ整合性復旧ポイントには、スナップショットの作成中にサーバーから電源コードが引き抜かれたときのディスク上のデータが含まれます。 これには、スナップショットの作成時にメモリ内にあったものは一切含まれません。

現在、ほとんどのアプリでは、クラッシュ整合性スナップショットから十分に復旧できます。 クラッシュ整合性復旧ポイントは通常、データベースのないオペレーティング システムや、ファイル サーバー、DHCP サーバー、プリント サーバーなどのアプリにとっては十分です。

Site Recovery では、5 分ごとにクラッシュ整合性復旧ポイントが自動的に作成されます。

アプリケーション整合性復旧ポイントとは何ですか?

アプリ整合性復旧ポイントは、アプリ整合性スナップショットから作成されます。 ここでは、クラッシュ整合性スナップショットと同じデータがキャプチャされ、メモリ内のデータと処理中のすべてのトランザクションが追加でキャプチャされます。

追加コンテンツのため、アプリ整合性スナップショットは最も複雑となり、時間がかかります。 アプリ整合性の復旧ポイントは、データベース オペレーティング システムや、SQL Server などのアプリで推奨されます。 Windows の場合、アプリ整合性スナップショットでは、ボリューム シャドウ コピー サービス (VSS) が使用されます。

アプリ整合性復旧ポイントはパフォーマンスに影響しますか?

アプリ整合性復旧ポイントではメモリとプロセス内のすべてのデータがキャプチャされるため、キャプチャが頻繁になる場合は、ワークロードが既にビジー状態のときにパフォーマンスに影響を与える可能性があります。 データベース以外のワークロードについては、あまり頻繁にはキャプチャしないことをお勧めします。 データベース ワークロードの場合でも、1 時間で十分です。

アプリ整合性復旧ポイントを生成するための最小間隔はどれくらいですか?

Site Recovery では、アプリ整合性復旧ポイントを最小間隔の 1 時間で作成できます。

Linux VM でアプリ整合性レプリケーションを有効にすることはできますか?

はい。 Linux 用モビリティ エージェントは、アプリ整合性のためのカスタム スクリプトをサポートしています。 エージェントでは、pre オプションと post オプションを使用したカスタム スクリプトが使用されます。 詳細情報

復旧ポイントはどのように生成されて保存されますか?

Site Recovery で復旧ポイントを生成する方法を理解するため、例を使ってみましょう。

  • レプリケーション ポリシーでは、復旧ポイントが 1 日間保持され、アプリ整合性のスナップショットが 1 時間ごとに取得されます。
  • Site Recovery では、5 分ごとにクラッシュ整合性復旧ポイントが作成されます。 この頻度は変更できません。
  • Site Recovery では、2 時間後に復旧ポイントが取り除かれて、1 時間に 1 つの復旧ポイントが保存されます。

そのため、最新の 2 時間では、図に示すように、24 のクラッシュ整合性ポイントと 2 つのアプリ整合性ポイントから選択できます。

List of generated recovery points

過去のどの時点まで遡って復旧できますか?

使用できる最も古い復旧ポイントは、マネージド ディスクでは 15 日、アンマネージド ディスクでは 3 日です。

復旧ポイントはどのように取り除かれますか?

クラッシュ整合性復旧ポイントは、5 分ごとに生成されます。 アプリ整合性スナップショットは、ユーザーが入力した頻度に基づいて生成されます。 2 時間を過ぎると、ユーザーが入力したリテンション期間に基づいて復旧ポイントが取り除かれます。 以下がこのシナリオです。

入力されたリテンション期間 排除のメカニズム
0 日 復旧ポイントは保存されません。 最新のポイントにのみフェールオーバーできます
1 日 最新の 2 時間を過ぎると 1 時間に 1 つの復旧ポイントが保存されます
2 から 7 日 最新の 2 時間を過ぎると 2 時間に 1 つの復旧ポイントが保存されます
8 から 15 日 7 日間は、最新の 2 時間を過ぎると 2 時間に 1 つの復旧ポイントが保存されます。 その後は、4 時間に 1 つの復旧ポイントが保存されます。

また、アプリ整合性スナップショットは、上記の表に記載された期間に基づいて取り除かれます。これは、入力されたアプリ整合性スナップショットの頻度がそれより低い場合でも行われます。

Site Recovery で 1 日を過ぎても復旧ポイントを生成できない場合はどうなりますか?

レプリケーション ポリシーが 1 日であり、Site Recovery で 1 日を過ぎても復旧ポイントを生成できない場合、古い復旧ポイントが残ります。 Site Recovery は、新しいポイントが生成された場合、最も古いポイントのみを置き換えます。 新しい復旧ポイントができるまで、リテンション期間に到達した後も古いポイントはすべて残ります。

レプリケーションを有効にした後で、レプリケーション ポリシーを変更できますか?

はい。 コンテナー >>>> で、ポリシーを選択して編集します。 変更は既存のポリシーにも適用されます。

すべての復旧ポイントが VM の完全なコピーですか?

生成される最初の復旧ポイントには、完全なコピーがあります。 それ以降の復旧ポイントでは、差分変更が保持されます。

復旧ポイントのリテンション期間の増加によってストレージ コストが増加しますか?

はい。 たとえば、リテンション期間を 1 日から 3 日に増やした場合、Site Recovery により追加の 2 日分の復旧ポイントが保存されます。 追加された時間によって、ストレージの変更が発生します。 以前は、1 日間、1 時間ごとに復旧ポイントを保存していました。 現在では、3 日間、2 時間ごとに復旧ポイントを保存しています。 復旧ポイントの排除に関する説明を参照してください。 そのため、追加で 12 の復旧ポイントが保存されます。 単なる例として、1 つの復旧ポイントに 10 GB の差分変更が含まれ、GB あたりのコストが 0.16 ドル/月の場合、1 か月あたり 1.60 ドル * 12 の追加料金が発生します。

マルチ VM 整合性

マルチ VM 整合性とは何ですか?

マルチ VM 整合性によって、レプリケートされた仮想マシン間で復旧ポイントに整合性が確保されます。

  • マルチ VM 整合性を有効にすると、Site Recovery によってオプションが有効なすべてのマシンのレプリケーション グループが作成されます。
  • レプリケーション グループのマシンをフェールオーバーすると、それらのマシン間でクラッシュ整合性復旧ポイントとアプリ整合性復旧ポイントが共有されます。

マルチ VM 整合性を有効にする方法については、こちらを参照してください

レプリケーション グループ内の 1 つの VM をフェールオーバーできますか?

いいえ。 マルチ VM 整合性を有効にすると、アプリがレプリケーション グループ内のすべての VM に依存関係を持つと推測され、単一の VM フェールオーバーは許可されません。

1 つのグループでまとめてレプリケートできる VM の数はいくつですか?

レプリケーション グループ内の 16 個の VM をまとめてレプリケートできます。

どのようなときにマルチ VM 整合性を有効にする必要がありますか?

マルチ VM 整合性では CPU が集中的に消費されるので、これを有効にすると、ワークロードのパフォーマンスに影響する場合があります。 VM が同じワークロードを実行していて、複数のマシン間に整合性を持たせる必要がある場合にのみ有効にしてください。 たとえば、2 個の SQL Server インスタンスと 2 個の Web サーバーがアプリケーション内にある場合、SQL Server インスタンスに対してのみマルチ VM 整合性を有効にします。

レプリケートされている VM をレプリケーション グループに追加できますか?

VM のレプリケーションを有効にすると、新しいレプリケーション グループまたは既存のグループに追加できます。 既にレプリケートされている VM をグループに追加することはできません。

[フェールオーバー]

ターゲット リージョンの容量を確保するにはどうすればよいですか?

最善の作業量ベースで十分なインフラストラクチャ容量が確保されるよう、Site Recovery チームと Azure キャパシティマネジメントチームが計画を立てます。 フェールオーバーを開始するとき、Site Recovery によって保護される VM インスタンスがターゲット リージョンにデプロイできるよう、チームも支援します。

フェールオーバーは自動で行われますか。

フェールオーバーは自動では行われません。 ポータルで 1 回クリックするだけでフェールオーバーを開始できます。または PowerShell を使用してフェールオーバーをトリガーすることもできます。

フェールオーバー後にパブリック IP アドレスを保持できますか?

運用アプリのパブリック IP アドレスは、フェールオーバー後に保持できません。

フェールオーバー プロセスの一環としてワークロードを起動するとき、Azure パブリック IP アドレス リソースをワークロードに割り当てる必要があります。 リソースはターゲット リージョンで使用可能である必要があります。 Azure パブリック IP アドレス リソースは手動で割り当てるか、復旧計画で自動化できます。 フェールオーバー後にパブリック IP アドレスを設定する方法については、こちらを参照してください

フェールオーバー後にプライベート IP アドレスを保持できますか?

はい。 既定では、Azure VM のディザスター リカバリーを有効にすると、Site Recovery によって、ソース リソースの設定に基づいてターゲット リソースが作成されます。 Azure VM が静的 IP アドレスで構成されている場合、Site Recovery は、使用中でなければ同じ IP アドレスをターゲット VM にプロビジョニングしようとします。 フェールオーバー後の IP アドレスの保持については、こちらを参照してください

フェールオーバー後に VM に新しい IP アドレスが割り当てられるのはなぜですか?

Site Recovery では、フェールオーバー時に IP アドレスの指定が試みられます。 別の VM がそのアドレスを使っている場合、Site Recovery では次の使用可能な IP アドレスがターゲットとして設定されます。

仮想ネットワークのネットワーク マッピングと IP アドレス指定の設定については、こちらを参照してください

"最新" の復旧ポイントとは何ですか?

最新 (最も低い RPO) 復旧ポイント オプションでは、目標復旧ポイント (RPO) が最も低い状態になります。 これは、Site Recovery サービスに送信されたすべてのデータを最初に処理して、各 VM の復旧ポイントを作成してから、それにフェールオーバーします。 最初に、ターゲットの場所にある Site Recovery サービスに送信されたすべてのデータを処理して適用し、処理したデータを使用して復旧ポイントを作成しようとします。 ただし、フェールオーバーがトリガーされた時点で、処理を待機している Site Recovery サービスにアップロードされたデータがない場合、Azure Site Recovery はいかなる処理も実行しないため、新しい復旧ポイントは作成されません。 このシナリオでは、代わりに、以前に処理された復旧ポイントのみを使用してフェールオーバーします。

"最新" の復旧ポイントは、フェールオーバー RTO に影響しますか?

はい。 Site Recovery では、フェールオーバー前に保留中のすべてのデータが処理されるので、このオプションは他のオプションよりも目標復旧時間 (RTO) が高くなります。

"最後に処理があった時点" の復旧オプションとは何ですか?

"最後に処理があった時点" オプションでは、次のことが行われます。

  1. Site Recovery によって最後に処理された復旧ポイントに、すべての VM をフェールオーバーします。 このオプションを使用すると、未処理のデータの処理に時間がかからないため、RTO を低くできます。

プライマリ リージョンで予期しない障害が発生した場合はどうすればよいですか?

フェールオーバーを開始できます。 Site Recovery では、フェールオーバーを実行するためにプライマリ リージョンからの接続を必要としません。

VM フェールオーバーの RTO とは何ですか?

Site Recovery の RTO SLA は 2 時間です。 ほとんどの場合、Site Recovery によって数分以内に VM がフェールオーバーされます。 RTO を計算するにはフェールオーバー ジョブを確認します。ここでは、VM を起動するまでにかかった時間が示されます。

復旧計画

復旧計画とは何ですか?

Site Recovery での復旧計画は、VM のフェールオーバーと復旧を調整します。 これは、復旧を常に正確で、繰り返し可能、さらに自動化されるようにするのに役立ちます。 その後、次の処理を実行します。

  • 一緒にフェールオーバーする VM のグループを定義します。
  • アプリケーションが正確に起動するように、VM 間の依存関係を定義します。
  • VM フェールオーバー以外のタスクに対するカスタム手動アクションのオプションを使用して、復旧を自動化します。

シーケンス処理のしくみを教えてください。

復旧計画では、シーケンス処理のために VM のグループを 7 つまで作成できます。 グループは一度に 1 つずつフェールオーバーされるので、同じグループに含まれる VM は一緒にフェールオーバーされます。 詳細については、こちらを参照してください

復旧計画の RTO を検索するにはどうしたらよいですか?

復旧計画の RTO を確認するには、復旧計画のテスト フェールオーバーを実行します。 Site Recovery ジョブで、テスト フェールオーバーの期間を確認します。 このスクリーンショットの例では、SAPTestRecoveryPlan テスト フェールオーバー ジョブに 8 分 59 秒かかりました。

List jobs showing the duration of the test failover for RTO

復旧計画に Automation Runbook を追加できますか?

はい。 詳細については、こちらを参照してください

再保護とフェールバック

フェールオーバー後、セカンダリ リージョンの VM は自動的に保護されますか?

いいえ。 あるリージョンから別のリージョンに Azure VM をフェールオーバーすると、その VM はターゲット ディザスター リカバリー リージョン内で保護されていない状態で起動されます。 セカンダリ リージョン内の VM を再保護するには、プライマリ リージョンに戻ってレプリケーションを有効にします。

再保護すると、セカンダリ リージョンからプライマリにすべてのデータがレプリケートされますか?

一概には言えません。 ソース リージョンの VM が存在している場合、ソース ディスクとターゲット ディスクの間の変更のみが同期されます。 Site Recovery では、ディスクを変更点と比較した後、データが転送されます。 通常、このプロセスには数時間かかります。 詳細については、こちらを参照してください

フェールバックにはどのくらいの時間がかかりますか?

再保護後のフェールオーバーには、プライマリ リージョンからセカンダリ リージョンにフェールオーバーするときと大体同じ時間がかかります。

容量

ターゲット リージョンの容量を確保するにはどうすればよいですか?

最善の作業量ベースで十分なインフラストラクチャ容量が確保されるよう、Site Recovery チームと Azure キャパシティマネジメントチームが計画を立てます。 フェールオーバーを開始するとき、Site Recovery によって保護される VM インスタンスがターゲット リージョンにデプロイできるよう、チームも支援します。

Site RecoveryはCapacity Reservationと連動しますか?

はい、ディザスター リカバリーリージョンやゾーンで VM SKU のCapacity Reservation を作成し、ターゲット VM の Compute プロパティで構成することができます。 これを行うと、site recovery はフェールオーバーのために確保された容量を使用します。 詳細については、こちらを参照してください

なぜ、デスティネーション先でCapacity Reservationを使って容量を確保する必要があるのですか?

Site Recovery は、復旧リージョンで容量が利用できるように最善の努力をしますが、同じように保証するわけではありません。 Site Recovery の最善の作業量は、2時間の RTO の SLA によって支えられています。 ただし、さらなる保証と保証されたコンピューティング能力が必要な場合は、Capacity Reservationsを購入することをお勧めします

Site Recovery は予約インスタンスと連携しますか?

はい、ディザスター リカバリー リージョンで予約 Azure VM を購入することができます。Site Recovery のフェールオーバー操作でその VM が使用されます。 追加の構成は必要ありません。

Security

Site Recovery サービスにレプリケーション データが送信されますか。

いいえ、Site Recovery はレプリケートされたデータをインターセプトすることも、VM 上の実行内容に関するどのような情報を保持することもありません。 レプリケーションとフェールオーバーを調整するために必要なメタデータのみが、Site Recovery サービスに送信されます。

Site Recovery は ISO 27001:2013、27018、HIPAA、DPA 認定です。 このサービスは現在、SOC2 と FedRAMP JAB の評価を判定されている最中です。

Site Recovery はレプリケーションを暗号化しますか。

はい、転送中の暗号化と Azure に保存中の暗号化の両方がサポートされています。

次のステップ