Azure Site Recovery で VM 保護を有効にする

ターゲット環境とソース環境が構成されたら、(ソースからターゲットへの) VM の保護の有効化を開始できます。 すべての構成は、Site Recovery コンテナー自体のターゲット環境で行われます。

前提条件

Site Recovery コンテナーで保護する各 VM のレプリケーション ポリシーを構成できます。 これらの VM はソース環境にあり、特定のリソース グループ構造、仮想ネットワーク、パブリック IP、NSG を構成しました。

Site Recoveryは、すべての VM データ自体をレプリケートするのに役立ちますが、開始する前に、次の前提条件が満たされていることを確認してください。

• ターゲット ネットワーク接続が構成されています。

• ターゲット仮想ネットワークが構成されます。ここで、フェールオーバーが発生すると、保護された各 VM が接続されます。

• ターゲット ユーザー サブスクリプションには、フェールオーバーの可能性があるすべての VM に対して十分なコンピューティング クォータ割り当てがあります。

• これらの仮想ネットワークは、ソース ネットワークと同じ方法で構成することも、ディザスター リカバリーの計画と目標に応じて異なる設計にすることができます。

• 保護する特定のワークロードに対して、新しいパブリック IP とプライベート IP が期待どおりに動作することを確認します (フェールオーバーが発生した場合、フェールオーバーされた VM にはターゲット環境の IP が含まれます)。

• 目的のリソース グループ構成が作成されます。

• レプリケーションを構成するときは、リソース グループを作成することもできますが、運用環境では、名前付けポリシーと構造に従って事前に作成する必要があります。

• エンタープライズ ポリシーに従って、適切な RBAC が割り当てられ、タグ付けが設定されていることを確認します。

• "キャッシュ ストレージ アカウント" が作成され、使用可能になります。

• "キャッシュ ストレージ アカウント" は、レプリケーション プロセスで使用される一時的なストレージ アカウントです。

  注意

  このストレージ アカウントのスコープは複雑であり、 Hyper-V VM ディザスター リカバリーの計画容量に関 する記事では、これらの概念を明確にしています。 Azure Stack Hub 上の Azure Site Recoveryについては、容量計画に関する記事を参照してください。

レプリケーションを有効にする

ターゲット環境の Azure Stack Hub ユーザー ポータルで、Site Recovery コンテナーを開き、[ワークロードの保護] を選択します。

構成したアプライアンスを選択し、正常であることをチェックします。

その後、ブレードでソース環境とソース サブスクリプションを選択するように求められます。 構成したユーザー (または SPN) がアクセスできるすべての Azure Stack Hub ユーザー サブスクリプションが表示されます。

ソース ワークロードを含むサブスクリプションを選択し、保護を有効にする予定の VM を選択します。 一度に最大 10 台の VM を保護できます。 大規模なデプロイを可能にする PowerShell スクリプトを使用できます。

Azure Site Recovery は、VM に接続されているすべてのディスクをレプリケートします。 このバージョンでは、すべてのディスクが保護されています。

次の手順で、ターゲット環境の構成を選択します。 この構成には、VM が接続するネットワークと、使用するキャッシュ ストレージ アカウントが含まれます。 レプリケーション ポリシーを構成するには、PowerShell を使用する必要があります。 カスタマイズ プロセスの開始に役立つスクリプトを使用できます。

選択した構成を確認し、レプリケーションを有効にします。

レプリケーションの進行状況を確認し、設定を編集する

Site Recovery コンテナーの [レプリケートされたアイテム] ブレードで、レプリケーションを有効にした各 VM を確認できます。

これらの項目を選択すると、現在の状態を表示したり、保護された項目の設定を編集したり、テスト フェールオーバーなどのアクションをトリガーしたりできます。

保護された VM のさまざまな状態を理解する

VM が保護され、データがレプリケートされたら、次のタスクを実行できます。

• テスト フェールオーバーの実行:

  • テスト フェールオーバーを実行して、データの損失やダウンタイムなしで、レプリケーションとディザスター リカバリー戦略を検証できます。 テスト フェールオーバーは、実行中のレプリケーションや運用環境に影響ありません。 テスト フェールオーバーは、特定の VM または複数の VM を含む復旧計画で実行できます。

• テスト フェールオーバーでは、ターゲット VM を作成することで、(ソースからターゲットへの) この VM のフェールオーバーがシミュレートされます。 テスト フェールオーバーを行うときは、次の操作を選択できます。

  • フェールオーバー先の復旧ポイント:

    • 最新の復旧ポイント (最も低い RPO): このオプションは、最初にSite Recovery サービスに送信されたすべてのデータを処理して、フェールオーバーする前に各 VM の復旧ポイントを作成します。 フェールオーバー後に作成された VM では、フェールオーバーがトリガーされたときにすべてのデータがSite Recoveryにレプリケートされるため、このオプションでは最も低い RPO (目標復旧ポイント) が提供されます。
    • 最新の処理済み (最小 RTO): プラン内のすべての VM を、Site Recoveryによって処理された最新の復旧ポイントにフェールオーバーします。 特定の VM の最新の復旧ポイントを参照するには、VM 設定の [Latest Recovery Points] (最新の回復ポイント) を確認します。 このオプションを使用すると、未処理のデータの処理に時間がかからないため、RTO (目標復旧時間) を低くできます。
    • 最新のアプリ整合性: プラン内のすべての VM を、Site Recoveryによって処理された最新のアプリケーション整合性復旧ポイントにフェールオーバーします。 特定の VM の最新の復旧ポイントを参照するには、VM 設定の [Latest Recovery Points] (最新の回復ポイント) を確認します。
    • カスタム: 特定の VM を特定の復旧ポイントにフェールオーバーするには、このオプションを使用します。

  • この時点でネットワークを選択することはできません。 テスト フェールオーバー ネットワークは、保護された VM ごとに構成されます。 変更する必要がある場合は、保護された VM のプロパティに戻り、[ 表示または編集] を選択します。

    

• テスト フェールオーバーは、フェールオーバー時のアプリケーションの動作をチェックするのに役立ちます。 ただし、ソース VM がまだ実行されている可能性があります。 テスト フェールオーバーを実行するときは、この動作を考慮する必要があります。

  注意

  Azure Site Recoveryは、テスト フェールオーバーを実行するときに VM を完全にレプリケートします。 VM は、ソース環境とターゲット環境の両方で実行されます。 アプリの動作に影響を与える可能性があるため、これを考慮する必要があります。

• テスト フェールオーバーが完了したら、[ テスト フェールオーバーのクリーン] を選択できます。 このオプションを選択すると、テスト フェールオーバー VM とすべてのテスト リソースが削除されます

  

• フェールオーバー:

  • ソース環境で問題が発生した場合は、VM をターゲット環境にフェールオーバーすることを選択できます。

    

  • フェールオーバー プロセスを開始するときに、 フェールオーバーを開始する前にマシンをシャットダウンできます。 このオプションでは、VM 全体がソースからターゲットに移動されるため、このオプションを選択する前に、ソース VM をシャットダウンする必要があります。

    注意

    過去 180 日間にテスト フェールオーバーが行われなかった場合は、実際のフェールオーバーの前に実行することをお勧Site Recovery。 テスト フェールオーバーを使用してレプリケーションの検証をスキップすると、データが失われたり、予期しないダウンタイムが発生したりする可能性があります。

  • フェールオーバー プロセスが完了したら、フェールオーバー プロセスを完全に完了するために変更をコミットする必要があります。 最初にコミットしない場合、再保護を試みると、再保護アクションによって最初にコミットがトリガーされ、再保護が続行されます (したがって、両方の操作が必要であるため、時間がかかります)。

  • ソース環境が正常に戻ったら、"フェールバック" プロセスを開始できます。 このプロセスは、次の 2 つの手順で実行されます。

    • 再保護を実行して、データをソースにレプリケートし直します。
    • データが完全にレプリケートされたら、計画フェールオーバーを実行してリソースを初期環境に戻します。

    これらの各フェーズで必要な考慮事項の一覧については、次のセクションをチェックできます。

  注意

  現時点では、保護の再有効化はサポートされていません (フェールバック プロセス後)。 保護を無効にし、エージェントを削除してから、この VM の保護を再度有効にする必要があります。 このプロセスは自動化でき、作業の開始に役立つスクリプトが用意されています。

Azure Site Recovery VM 拡張機能をアンインストールする

設計上、Azure Site Recovery 拡張機能をアンインストールしても、その VM 内で実行されるモビリティ サービスは削除されません。 これにより、将来の保護がブロックされ、その VM の保護を再度有効にするには手動の手順が必要になります。

Azure Site Recovery VM 拡張機能を削除した後、その VM 内で実行されるモビリティ サービスをアンインストールする必要があります。 これを行うには、「Mobility Serviceをアンインストールする」の手順を参照してください。

注意

その VM の保護を再度有効にする予定の場合は、前の手順に従った後、Azure Site Recoveryを使用して保護を追加する前に、必ず VM を再起動してください。

考慮事項

通常の操作では、次の情報は必要ありません。 ただし、これらのメモは、バックグラウンドで行われるプロセスをより深く理解するのに役立ちます。

状態ごとに、いくつかの考慮事項があります。

• 再保護:

  • 初期ソース サブスクリプション、初期リソース グループ、および初期プライマリ NIC の仮想ネットワーク/サブネットがまだプライマリ スタンプに存在することを確認します。 この情報は、PowerShell を使用して保護された項目から取得できます。

    Get-AzResource -ResourceID "/subscriptions/<subID>/resourceGroups/<RGname>/providers/Microsoft.DataReplication/replicationVaults/<vaultName>/protectedItems/<vmName>"
    

    次の図は、このコマンドからの出力例を示しています。

    

  • Linux VM に対して再保護を実行する前に、再保護する Linux VM でSite Recovery サービスの証明書が信頼されていることを確認してください。 この信頼により、再保護が必要なSite Recovery サービスへの VM 登録のブロックが解除されます。

    Ubuntu/Debian VM の場合:

    sudo cp /var/lib/waagent/Certificates.pem /usr/local/share/ca-certificates/Certificates.crt
    
    sudo update-ca-certificates
    

    Red Hat VM の場合:

    sudo update-ca-trust force-enable
    
    sudo cp /var/lib/waagent/Certificates.pem /etc/pki/ca-trust/source/anchors/
    
    sudo update-ca-trust extract
    

  • Site Recovery アプライアンス VM に十分なデータ ディスク スロットがあることを確認します。 再保護用のレプリカ ディスクは、アプライアンスに接続されます (詳細については、容量計画チェック)。

  • 再保護プロセス中は、再保護がトリガーされるとソース VM (ソース スタンプに sourceAzStackVirtualMachineId を含む) がシャットダウンされ、その VM に接続されている OS ディスクとデータ ディスクがデタッチされ、古いディスクである場合はレプリカ ディスクとしてアプライアンスにアタッチされます。 OS ディスクは、サイズ 1 GB の一時 OS ディスクに置き換えられます。

  • 再保護でディスクをレプリカとして再利用できるが、アプライアンス VM とは別のサブスクリプションにある場合でも、新しいディスクはアプライアンスと同じサブスクリプションとリソース グループに作成され、新しいディスクをアプライアンスに接続できるようになります。

  • 再保護手動再同期はパブリック プレビューではサポートされていないため、アプライアンスのアタッチされたデータ ディスクは手動で変更、アタッチ、デタッチ、変更しないでください (既知の問題に関する記事を参照)。 レプリカ ディスクが削除された場合、再保護を回復できません。

• フェールバック (計画フェールオーバー): 再保護された項目をターゲット スタンプからソース スタンプにフェールバックします。

  • 初期ソース サブスクリプション、初期リソース グループ、および初期プライマリ NIC の仮想ネットワーク/サブネットがまだソース スタンプに存在することを確認します。 この情報は、PowerShell を使用して保護された項目から取得できます。
  • ソース スタンプの sourceAzStackVirtualMachineId を持つ VM は、レプリカ ディスクと新しく作成された NIC (存在しない場合) で作成されます。または、レプリカ OS ディスクとデータ ディスク (存在する場合) に置き換えられます。
  • プライマリ スタンプに ソースAzStackVirtualMachineId を持つ VM が存在する場合、それに接続されているすべてのディスクはデタッチされますが、削除されず、NIC は同じままです。
  • プライマリ スタンプにソースAzStackVirtualMachineId を持つ VM が存在し、アプライアンス VM とは別のサブスクリプションにある場合、新しいディスクは、アプライアンスからデタッチされたレプリカのフェールバック VM と同じサブスクリプションとリソース グループに作成され、新しいディスクをフェールバック VM にアタッチできるようにします。

• フェールオーバー/フェールバックが完了したことをコミットします。 フェールバックがコミットされた後、復旧スタンプのフェールオーバー VM が削除されます。

• Azure Site Recovery リソース プロバイダーをアンインストールすると、それらのターゲット Azure Stack Hub スタンプで作成されたすべてのコンテナーも削除されます。 これは Azure Stack Hub オペレーター アクションであり、ユーザーに対する警告やアラートは発生しません。

次の手順

Azure Site Recovery の概要