Azure Site Recovery に関する一般的な質問

Site Recovery は、リージョン間の Azure VM のレプリケーション、オンプレミスの仮想マシンと物理サーバーの Azure へのレプリケーション、およびオンプレミスのマシンのセカンダリ データセンターへのレプリケーションを調整および自動化することで、ビジネス継続性とディザスター リカバリー (BCDR) 戦略に貢献します。 詳細については、こちらを参照してください。

いいえ。Azure Site Recovery では、仮想マシンで実行されている Docker ワークロードはサポートされていません。 Site Recovery でこれらの仮想マシンを保護するには、Docker がインストールされているディスクを除外します。

データの整合性を確保するために Site Recovery ではさまざまな対策が講じられます。 HTTPS プロトコルを使用して、すべてのサービス間にセキュリティで保護された接続が確立されます。 これにより、すべてのマルウェアまたは外部エンティティによるデータの改ざんがなくなります。 もう 1 つの対策として、チェックサムを使用します。 ソースとターゲット間のデータ転送は、それらの間でのデータのチェックサムを計算することによって実行されます。 これにより、転送されるデータの整合性が保たれます。

Azure は永続的な MAC アドレスをサポートしていないため、MAC ベースのライセンス モデルを持つソフトウェアは、オンプレミスから Azure への移行にもディザスター リカバリーにも使用できません。

いいえ。現在、Azure Site Recovery ではエフェメラル ディスクはサポートされていません。

Microsoft Azure Recovery Services エージェントは、Site Recovery サービスの構成と登録、およびすべてのコンポーネントの正常性の監視に使用されます。 このコンポーネントは、Azure Site Recovery オンプレミス インフラストラクチャ全体の基本的な構成要素の 1 つです。 これは、オンプレミス サイトから別の Azure リージョンにワークロードをレプリケートし、障害時に Azure にフェールオーバーするのに役立ちます。

はい。Site Recovery は、専用および共有のインフラストラクチャ モデルの両方をサポートしています。

いいえ。 テナント ID は匿名のままです。 テナントは Site Recovery ポータルにアクセスする必要はありません。 ポータルを操作するのは、サービス プロバイダーの管理者だけです。

Azure にレプリケートする場合、アプリケーション データは Site Recovery サービスではなく、Azure ストレージに送信されます。 データは、転送中に暗号化され (HTTPS)、暗号化された状態のまま Azure に残ります。

いいえ。 Azure の請求関係は、サービス プロバイダーとの直接的な関係です。 サービス プロバイダーは、そのテナントに対して固有の請求書を生成する必要があります。

いいえ、データはご使用のサブスクリプション内の Azure Storage にレプリケートされます。 テスト フェールオーバー (ディザスター リカバリー訓練) または実際のフェールオーバーを実行すると、Site Recovery により、サブスクリプションで仮想マシンが自動的に作成されます。

はい。

Azure パック、クラウド プラットフォーム システム、および System Center ベース (Hyper 2012 以降) のデプロイメントがサポートされています。 詳細情報 をご覧ください。

いいえ、Hyper-V 仮想マシンのみを Azure にレプリケートできます。

Site Recovery 料金の詳細をご確認ください。

Site Recovery を使用している間は、料金計算ツールを利用してコストを見積もることができます。

コストの詳細な見積もりのためには、VMware または Hyper-V に対してデプロイ プランナー ツールを実行し、コスト見積もりレポートを使用します。

はい。Site Recovery を使って仮想マシンをレプリケートする場合、キャッシュ ストレージ アカウントの使用量に対して追加料金が発生します。 レプリカ ストレージの種類がマネージド ディスクまたはアンマネージド ディスクの場合、キャッシュ ストレージ アカウントのコストは変わりません。

はい。 保護されたインスタンスはすべて、最初の 31 日間は Azure Site Recovery の料金が発生しません。 たとえば、過去 6 か月間に 10 個のインスタンスを保護していて、11 番目のインスタンスを Azure Site Recovery に接続した場合、最初の 31 日間は 11 番目のインスタンスに対する変更はありません。 最初の 10 個のインスタンスは、既に 31 日間を超えて保護されているので、継続して Azure Site Recovery の料金が発生します。

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

ディザスター リカバリー訓練に関するコストが別途かかることはありません。 テスト フェールオーバー後に仮想マシンが作成されると、以降はコンピューティングの料金がかかります。

いいえ。Site Recovery は、レプリケートされたデータをインターセプトすることも、仮想マシンまたは物理サーバーでの実行内容に関するどのような情報を持つこともありません。 レプリケーション データは、オンプレミスの Hyper-V ホスト、VMware ハイパーバイザー、物理サーバーと Azure Storage またはセカンダリ サーバーとの間でやり取りされます。 Site Recovery には、これらのデータをインターセプトする能力はありません。 レプリケーションとフェールオーバーを調整するために必要なメタデータのみが、Site Recovery サービスに送信されます。

Site Recovery は ISO 27001:2013、27018、HIPAA、DPA の認証を受けており、SOC2 および FedRAMP JAB の評価が進行中です。

はい。 リージョンに Site Recovery コンテナーを作成すると、レプリケーションとフェールオーバーを有効にし、調整するために必要なすべてのメタデータが、そのリージョンの地理的境界内に維持されます。

Azure に仮想マシンと物理サーバーをレプリケートする場合には、転送中の暗号化と (Azure での) 保管データの暗号化の両方がサポートされます。

はい。Azure から Azure へのサイトの回復のシナリオでは、TLS 1.2 プロトコルが既定で適用されます。

レプリケートされたアイテムにインストールされているモビリティ エージェントは、TLS 1.2 でのみプロセス サーバーと通信します。 ただし、構成サーバーから Azure への通信と、プロセス サーバーから Azure への通信は、TLS 1.1 または 1.0 で行うことができます。 設定したすべての構成サーバーとプロセス サーバーに TLS 1.2 を適用するには、ガイダンスに従ってください。

Azure Site Recovery のマイクロサービス間のすべての通信は、TLS 1.2 プロトコルで発生します。 Site Recovery は、システム (OS) で構成されたセキュリティ プロバイダーを使用し、使用可能な最新の TLS プロトコルを使用します。 ユーザーは、レジストリで TLS 1.2 を明示的に有効にする必要があり、その後、Site Recovery はサービスとの通信に TLS 1.2 を使い始めます。

[Identity](ID) 設定に移動して、Recovery Services コンテナーのマネージド ID を切り替えることができます。 コンテナーが Microsoft Entra ID に登録されたら、ストレージ アカウントに移動して、以下のロールの割り当てをコンテナーに指定することができます。

• Resource Manager ベースのストレージ アカウント (Standard タイプ):
  • Contributor
  • ストレージ BLOB データ共同作成者
• Resource Manager ベースのストレージ アカウント (Premium タイプ):
  • Contributor
  • ストレージ BLOB データ所有者
• 従来のストレージ アカウント:
  • Classic Storage Account Contributor
  • 従来のストレージ アカウント キー オペレーターのサービス ロール

キャッシュ ストレージ アカウントは、マネージド ID ではサポートされていません。

Azure Site Recovery では、ソース OS 外のソース仮想マシンの変更は追跡されません。 たとえば、Azure から Azure へのレプリケーションを使っていて、ソース仮想マシンのサイズを変更した場合、ソース仮想マシンのサイズの変更はターゲット仮想マシンにレプリケートされません。

• Azure 仮想マシン: Site Recovery は、サポート対象の Azure 仮想マシンで実行されているすべてのワークロードをレプリケートできます。
• Hyper-V 仮想マシン: Site Recovery は、Hyper-V 仮想マシンで実行されているすべてのワークロードを保護できます。
• 物理サーバー:Site Recovery は、Windows または Linux が実行されている物理サーバーを保護できます。
• VMware 仮想マシン: Site Recovery は、VMware 仮想マシンで実行されているすべてのワークロードを保護できます。

Site Recovery を使用すると、サポートされている仮想マシンまたは物理サーバーで実行されているほとんどのワークロードを保護できます。 また、アプリケーションに対応したレプリケーションもサポートしているため、アプリをインテリジェントな状態に復元できます。 Site Recovery は、SharePoint、Exchange、Dynamics、SQL Server、Active Directory などの Microsoft アプリケーションと統合し、Oracle、SAP、IBM、Red Hat などの主要なベンダーと緊密に連携します。 詳細情報 を参照してください。

はい。 ブランチ オフィスでのレプリケーションとフェールオーバーを調整するために Site Recovery を使用すると、1 か所ですべてのブランチ オフィスのワークロードの統一されたオーケストレーションとビューが得られます。 ブランチ オフィスに出向くことなく、フェールオーバーを容易に実行し、本社からすべてのブランチのディザスター リカバリーを管理できます。

はい、Site Recovery では Azure リージョン間での Azure 仮想マシンのディザスター リカバリーがサポートされます。 Azure 仮想マシンのディザスター リカバリーに関する一般的な質問を確認します。 同じ大陸の 2 つの Azure リージョン間でレプリケートしたい場合、Azure から Azure へのディザスター リカバリー オファリングを使用してください。 構成サーバーまたはプロセス サーバー、ExpressRoute 接続を設定する必要はありません。

Site Recovery では、オンプレミスの VMware 仮想マシンのディザスター リカバリーをサポートします。 VMware 仮想マシンのディザスター リカバリーに関する一般的な質問を確認します。

はい、Site Recovery では、オンプレミスの Hyper-V 仮想マシンのディザスター リカバリーをサポートします。 Hyper-V 仮想マシンのディザスター リカバリーに関する一般的な質問を確認します。

はい、Site Recovery では、Windows および Linux を実行しているオンプレミスの物理サーバーの Azure へのディザスター リカバリーをサポートします。 Azure へのディザスター リカバリーについての要件を確認します。 フェールオーバー後、物理サーバーは Azure で仮想マシンとして実行されます。 Azure からオンプレミスの物理サーバーへのフェールバックは、現在サポートされていません。 VMware 仮想マシンにのみフェールバックできます。

いいえ。Azure Site Recovery では、保護された仮想マシンがホストされている Recovery Services コンテナーの移動はサポートされていません。

Azure Site Recovery は、パブリック エンドポイント経由で Azure ストレージ アカウントまたはマネージド ディスクにデータをレプリケートします。 ただし、レプリケーションはサイト間 VPN 経由でも実行できます。 組織はサイト間 VPN 接続を使用して、既存のネットワークを Azure に、または Azure ネットワークを相互に接続できます。 サイト間 VPN は、インターネット上の IPSec トンネリングを介して行われ、Azure の既存のオンプレミス エッジ ネットワーク機器およびネットワーク アプライアンス (Azure Virtual Private Network (VPN) ゲートウェイなどのネイティブ機能または Check Point CloudGaurd、Palo Alto NextGen Firewall などのサードパーティ オプション) を使います。

• パブリック インターネット経由の Microsoft Edge へのプライベート接続
• プライベート エンドポイントを使用したセキュリティが構成された Recovery Services コンテナー
• 顧客のプライベート仮想ネットワーク接続経由のレプリケーション
• "将来の状態" への簡単な移行
• SLA なし、待機時間が長期化する可能性
• オンプレミスの VPN デバイスが使用可能であることが必須

Microsoft のパートナーである Riverbed は、Azure Site Recovery の使用に関する詳細なガイダンスを提供しています。 Riverbed のソリューション ガイドを確認してください。

はい。ExpressRoute を使用してオンプレミスの仮想マシンを Azure にレプリケートできます。

• Azure Site Recovery は、パブリック エンドポイント経由で Azure Storage にデータをレプリケートします。 Site Recovery レプリケーションに ExpressRoute を使用するには、Microsoft ピアリングを設定するか、既存のパブリック ピアリング (新しい回線では非推奨) を使用する必要があります。
• Microsoft ピアリングは、レプリケーション用に推奨されるルーティング ドメインです。
• レプリケーションは、コンテナーでプライベート エンドポイントが有効になっている場合にのみ、プライベート ピアリング経由でサポートされます。
• VMware マシンまたは物理マシンを保護する場合は、構成サーバーのネットワーク要件も満たしている必要があります。 Site Recovery レプリケーションを調整する場合、構成サーバーが特定の URL に接続する必要があります。 この接続には ExpressRoute は使用できません。
• 仮想マシンが Azure 仮想ネットワークにフェールオーバーされた後は、その Azure 仮想ネットワークで設定されたプライベート ピアリングを使って、それらにアクセスできます。

ストレージ アカウントをターゲット ストレージとして使うことは、Azure Site Recovery ではサポートされていません。 マネージド ディスクは、マシンのターゲット ストレージとして使用することをお勧めします。 マネージド ディスクでは、データ回復性のために LRS 型のみがサポートされています。

• Hyper-V: Hyper-V 仮想マシンは 30 秒 (Premium Storage を除く)、または 5 分ごとにレプリケートできます。
• Azure 仮想マシン、VMware 仮想マシン、物理サーバー: レプリケーションの頻度はここでは関係ありません。 レプリケーションは継続的です。

拡張またはチェーン レプリケーションはサポートされていません。 フィードバック フォーラムでこの機能を要求してください。

これはサポートされていません。 フィードバック フォーラムでこの機能を要求してください。

これは、Azure portal を使用して VMware 仮想マシンと Hyper-V 仮想マシンを Azure にレプリケートする場合にサポートされます。

Hyper-V 仮想マシンをレプリケートする場合、および Azure に VMware 仮想マシンと物理マシンをレプリケートする場合、ダイナミック ディスクがサポートされます。 オペレーティング システム ディスクはベーシック ディスクである必要があります。

はい。 帯域幅の調整の詳細については、次の記事を参照してください。

• VMware 仮想マシンと物理サーバーをレプリケートするためのキャパシティ プランニング
• Azure に Hyper-V 仮想マシンをレプリケートするためのキャパシティ プランニング

はい。 Linux オペレーティング システム用の Azure Site Recovery では、アプリの整合性を保つためのアプリケーション カスタム スクリプトがサポートされています。 アプリの整合性を保つときに、Azure Site Recovery モビリティ エージェントによって、プリオプションとポストオプションを含むカスタム スクリプトが使用されます。 それを有効にする手順は次のとおりです。

1. マシンに root としてサインインします。

2. Azure Site Recovery Mobility Agent のインストール場所にディレクトリを変更します。 既定値は "/usr/local/ASR" です。
   # cd /usr/local/ASR

3. インストール場所の下にある "VX/scripts" にディレクトリを変更します。
   # cd VX/scripts

4. root ユーザーの実行アクセス許可を設定した "customscript.sh" という名前の bash シェル スクリプトを作成します。
   a. このスクリプトでは、"--pre" と "--post" (二重ダッシュに注意してください) のコマンドライン オプションをサポートする必要があります。
   b. プリオプションを使用してスクリプトを呼び出すときに、アプリケーションの入出力を凍結し、ポストオプションを使用して呼び出すときに、アプリケーションの入出力を凍結解除する必要があります。
   c. サンプル テンプレート -
   

   # cat customscript.sh
   

    #!/bin/bash

    if [ $# -ne 1 ]; then
        echo "Usage: $0 [--pre | --post]"
        exit 1
    elif [ "$1" == "--pre" ]; then
        echo "Freezing app IO"
        exit 0
    elif [ "$1" == "--post" ]; then
        echo "Thawed app IO"
        exit 0
    fi

5. アプリの整合性を必要とするアプリケーションの pre と post の手順で、凍結と凍結解除の入力/出力コマンドを追加します。 これらを指定する別のスクリプトを追加し、pre と post オプションを使用して "customscript.sh" から呼び出すこともできます。

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

• 復旧ポイントの保持履歴は 1 日です。
• アプリ整合性スナップショットはありません。

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

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

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

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

これらの追加コンテンツのため、アプリケーション整合性スナップショットは最も複雑となり、時間がかかります。 アプリケーション整合性の復旧ポイントは、SQL Server などのデータベース オペレーティング システムで推奨されます。

アプリケーション整合性復旧ポイントの場合、メモリに入っているデータと処理中のデータがすべてキャプチャされます。 復旧ポイントでそのデータがキャプチャされるため、アプリケーションを停止する目的で、ボリューム シャドウ コピー サービスなどのフレームワークが Windows で必要になります。 キャプチャ プロセスが頻繁に行われる場合、ワークロードが既にビジー状態であれば、パフォーマンスに影響が出ることがあります。 データベース以外のワークロードの場合、アプリ整合性復旧ポイントの頻度を低く設定しないことをお勧めします。 データベース ワークロードの場合であっても、1 時間で十分です。

Site Recovery では、アプリケーション整合性復旧ポイントを 1 時間という最小の頻度で作成できます。

Site Recovery で復旧ポイントを生成する方法を理解するため、レプリケーション ポリシーの例を見てみましょう。 このレプリケーション ポリシーの復旧ポイントには １ 日の保持期間が設定されており、アプリ整合性スナップショットは 1 時間おきに作成されます。

Site Recovery では、5 分ごとにクラッシュ整合性復旧ポイントが作成されます。 この頻度は変更できません。 最後の 2 時間については、24 のクラッシュ整合性ポイントと 2 つのアプリ整合性ポイントから選択できます。 時間が経過すると、2 時間を経過した復旧ポイントは Site Recovery によってすべて取り除かれ、1 時間に 1 つの復旧ポイントのみが最大その日の 24 時間まで保存されます。

次のスクリーンショットはこの例を示したものです。 スクリーンショットでは次のようになっています。

• 最後の 2 時間以内では、5 分ごとに復旧ポイントがあります。

• 最後の 2 時間を超えると、Site Recovery では復旧ポイントが毎時間に 1 つだけ保持されます。

  

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

いいえ、以前のすべての復旧ポイントが Site Recovery によって保持されます。 復旧ポイントの保持期間に基づき、Site Recovery では、新しいポイントが生成された場合にのみ、最も古いポイントが置換されます。 問題のために、Site Recovery では新しい復旧ポイントを生成できません。 新しい復旧ポイントができるまで、保持期間に到達した後も古いポイントはすべて残ります。

[Site Recovery コンテナー]>[Site Recovery インフラストラクチャ]>[レプリケーション ポリシー] の順に移動します。 編集するポリシーを選択し、変更内容を保存します。 変更は既存のすべてのレプリケーションにも適用されます。

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

はい、保持期間を 1 日から 3 日に増やすと、Site Recovery により追加の 2 日分の復旧ポイントが保存されます。 保持期間を 1 日から 3 日に増やすことで、保存する必要がある追加の復旧ポイントが 12 個あるため、追加の時間にはストレージ料金が発生します。 たとえば、1 つの復旧ポイントで 10 GB の差分変更があったとき、GB あたりのコストが 1 か月 $0.16 であるとします。 追加料金は 1 か月あたり $1.60 × 12 になります。

Azure 仮想マシンには、セキュリティで保護されたインターネット接続、サイト間 VPN、または Azure ExpressRoute 経由でアクセスできます。 接続するにはさまざまこと準備する必要があります。 詳細情報。

Azure は復元するように設計されています。 Site Recovery は、Azure SLA に従って、既にセカンダリ Azure データセンターにフェールオーバーする機能を備えています。 これが発生した場合には、お客様のメタデータとコンテナーは、お客様が選択したコンテナーと同じリージョン内に保持されます。

セカンダリ サイトから計画外のフェールオーバーをトリガーすることができます。 Site Recovery は、フェールオーバーを実行するためにプライマリ サイトからの接続を必要としません。

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

自動化する場合は、オンプレミスの Orchestrator または Operations Manager を使用して仮想マシンのエラーを検出し、SDK を使用してフェールオーバーをトリガーします。

• リカバリー プランについての詳細をお読みください。
• フェールオーバーについての詳細をお読みください。
• VMware 仮想マシンと物理サーバーのフェールバックについては、こちらを参照してください

はい。alternate location recovery (別の場所への復旧) を使用すると、Azure から別のホストにフェールバックできます。

• VMware 仮想マシン用
• Hyper-V 仮想マシン用

ソースの場所からターゲットの場所へのマシンのフェールオーバーが完了したら、3 つのオプションを選択できます。 3 つの目的はそれぞれ異なります。

1. [移行の完了] は、ソースの場所にはもう戻らないことを意味します。 ターゲット リージョンへの移行はこれで完了です。 [移行の完了] をクリックすると、内部的には [コミット]、[レプリケーションの無効化] の順にトリガーされます。
2. [コミット] は、これがレプリケーション プロセスの終了ではないことを意味します。 レプリケーション項目はすべての構成と共に保持されるため、後で [再保護] を実行して、マシンのレプリケーションをソース リージョンに戻すことができます。
3. [レプリケーションの無効化] を選択すると、レプリケーションが無効になり、関連するすべての構成が削除されます。 ターゲット リージョンの既存のマシンには影響しません。

はい。 REST API、PowerShell、Azure SDK のいずれかを使用して、Site Recovery ワークフローを自動化することができます。 PowerShell を使用した Site Recovery のデプロイについて、現在サポートされているシナリオは次のとおりです。

• VMM クラウドの Hyper-V 仮想マシンを Azure PowerShell Resource Manager にレプリケートする
• VMM なしの Hyper-V 仮想マシンを Azure PowerShell Resource Manager にレプリケートする
• PowerShell Resource Manager を使用して Azure へ VMware をレプリケートする

いいえ。AzureRM モジュールの提供終了は、Site Recovery の自動更新のしくみには影響しません。 内部 Runbook に変更は必要なく、代わりに使用される REST API は、Automation アカウントで意図したとおりに機能し続けます。

新しい更新プログラムに関する詳細を確認し、ロールアップ情報を取得してください。

次のステップ

• Azure Site Recovery の概要