Azure Stack VM を Azure にレプリケートする

注意

この記事では、間もなくサポート終了 (EOL) 状態になる Linux ディストリビューションである CentOS について説明します。 適宜、使用と計画を検討してください。 詳細については、「CentOS のサポート終了に関するガイダンス」を参照してください。

この記事では、Azure Site Recovery サービスを使用して、Azure への Azure Stack VM のディザスター リカバリーを設定する方法について説明します。

Site Recovery は、事業継続とディザスター リカバリー (BCDR) 戦略に貢献します。 想定内または想定外の障害が発生したときに、このサービスを使って、VM ワークロードが引き続き利用可能な状態を維持できるようにします。

• Site Recovery は、Azure ストレージへの VM のレプリケーションの調整と管理を行います。
• プライマリ サイトで障害が発生したときに、Site Recovery を使用して Azure にフェールオーバーします。
• フェールオーバーするとすぐに、格納されたデータから Azure VM が作成され、ユーザーはそれらの Azure VM 上で稼働しているワークロードに引き続きアクセスできます。
• すべてが再稼働したら、Azure VM をプライマリ サイトにフェールバックし、Azure ストレージへのへのレプリケーションを再び開始できます。

この記事では、次のことについて説明します。

• ステップ 1:Azure Stack VM をレプリケーションできるように準備する。 VM が Site Recovery の要件を満たしていることを確認し、Site Recovery モビリティ サービスをインストールする準備をします。 このサービスは、レプリケートする各 VM 上にインストールされます。
• 手順 2:Recovery Services コンテナーを設定する。 Site Recovery 用のコンテナーを設定し、レプリケートするものを指定します。 Site Recovery のコンポーネントとアクションが構成され、コンテナーで管理されます。
• ステップ 3:ソース レプリケーション環境を設定する。 Site Recovery 構成サーバーを設定します。 構成サーバーは、Site Recovery が必要とするすべてのコンポーネントを実行する単一の Azure Stack VM です。 構成サーバーを設定した後、それをコンテナーに登録します。
• 手順 4:レプリケーション先の環境を設定する。 使用する Azure アカウント、Azure ストレージ アカウント、およびネットワークを選択します。 レプリケーション中に、VM データが Azure ストレージにコピーされます。 フェールオーバーされた後、Azure VM は、指定されたネットワークに参加します。
• 手順 5:レプリケーションを有効にする。 レプリケーション設定を構成し、VM のレプリケーションを有効にします。 モビリティ サービスは、レプリケーションが有効になっている場合に VM にインストールされます。 Site Recovery によって VM の初回のレプリケーションが実行された後、継続するレプリケーションが開始されます。
• 手順 6:ディザスター リカバリーのテストを実行する。フェールオーバーの実行後に、訓練を行って、レプリケーションが想定したように動作することを確認します。 訓練を開始するには、Site Recovery でテスト フェールオーバーを実行します。 テスト フェールオーバーが運用環境に影響を与えることはありません。

これらの手順を完了したうえで、必要なときに Azure への完全フェールオーバーを実行できます。

アーキテクチャ

場所	コンポーネント	詳細
構成サーバー	単一 Azure Stack VM 上で実行されます。	サブスクリプションごとに、構成サーバー VM を設定します。 この VM は、次の Site Recovery コンポーネントを実行します。 - 構成サーバー: オンプレミスと Azure の間の通信を調整し、データのレプリケーションを管理します。 - プロセス サーバー: レプリケーション ゲートウェイとして機能します。 レプリケーション データを受信し、そのデータをキャッシュ、圧縮、暗号化によって最適化して、Azure ストレージに送信します。 レプリケートする VM が後述する制限を超えている場合は、別のスタンドアロン プロセス サーバーを設定できます。 詳細については、こちらを参照してください。
モビリティ サービス	レプリケートする各 VM 上にインストールされます。	この記事の手順では、レプリケーションが有効な場合はモビリティ サービスが自動的にインストールされるように VM アカウントを準備します。 サービスを自動的にインストールしない場合、使用できる他の方法は多数あります。 詳細については、こちらを参照してください。
Azure	Azure 内に、Recovery Services コンテナー、ストレージ アカウント、および仮想ネットワークが必要です。	レプリケートされたデータはストレージ アカウントに格納されます。 Azure VM は、フェールオーバーの発生時に Azure ネットワークに追加されます。

レプリケーションは、次のように動作します。

1. コンテナーで、レプリケーション元とレプリケーション先の指定、構成サーバーの設定、レプリケーション ポリシーの作成、およびレプリケーションの有効化を行います。
2. モビリティ サービスがマシンにインストールされ (プッシュ インストールを使用している場合)、マシンは、レプリケーション ポリシーに従ってレプリケーションを開始します。
3. サーバー データの最初のコピーが Azure ストレージにレプリケートされます。
4. 初回のレプリケーションの終了後、Azure への差分変更のレプリケーションが開始されます。 マシンの追跡された変更は .hrl ファイルに保持されます。
5. 構成サーバーは、Azure とのレプリケーション管理を調整します(ポート HTTPS 443 送信)。
6. プロセス サーバーは、ソース マシンからデータを受信し、そのデータを最適化して暗号化し、Azure ストレージに送信します (ポート 443 送信)。
7. レプリケートされるマシンは、レプリケーション管理のために、構成サーバーと通信します (ポート HTTPS 443 受信)。 マシンは、レプリケーション データをプロセス サーバーに送信します (ポート HTTPS 9443 受信 - 変更可能)。
8. トラフィックは、インターネット経由で Azure ストレージのパブリック エンドポイントにレプリケートされます。 また、Azure ExpressRoute のパブリック ピアリングを使用できます。 オンプレミス サイトから Azure へのサイト間 VPN を介したトラフィックのレプリケートはサポートされていません。

前提条件

このシナリオをセットアップするために必要なものを次に示します。

要件	詳細
Azure サブスクリプション アカウント	Azure サブスクリプションをお持ちでない場合は、無料アカウントを作成してください。
Azure アカウントのアクセス許可	使用する Azure アカウントには、次を実行するためのアクセス許可が必要です。 - Recovery Services コンテナーを作成する - このシナリオで使用する仮想マシンをリソース グループと仮想ネットワーク内に作成する - 指定したストレージ アカウントに書き込む 以下の点に注意してください。 \- アカウントを作成した場合は、作成者がサブスクリプションの管理者となり、すべてのアクションを実行できます。 - 既存のサブスクリプションを使用するが、管理者でない場合は、管理者に依頼して所有者アクセス許可または共同作成者アクセス許可を割り当ててもらう必要があります。 - さらに詳細なアクセス許可が必要な場合は、こちらの記事をご覧ください。
Azure Stack VM	テナント サブスクリプション内に、Site Recovery 構成サーバーとしてデプロイされる Azure Stack VM が必要です。

構成サーバーの前提条件

物理サーバー レプリケーションに使用する構成/プロセス サーバーの要件

コンポーネント	要件
ハードウェアの設定
CPU コア数	8
RAM	16 GB
ディスクの数	3、OS ディスク、プロセス サーバーのキャッシュ ディスク、フェールバック用リテンション ドライブを含みます
ディスクの空き領域 (プロセス サーバー キャッシュ)	600 GB
ディスクの空き領域 (リテンション ディスク)	600 GB
ソフトウェアの設定
オペレーティング システム	Windows Server 2012 R2 Windows Server 2016
オペレーティング システムのロケール	英語 (en-us)
Windows Server の役割	これらの役割を有効にしないでください。 - Active Directory Domain Services - インターネット インフォメーション サービス - Hyper-V
グループ ポリシー	これらのグループ ポリシーを有効にしないでください。 - コマンド プロンプトへのアクセス禁止。 - レジストリ編集ツールへのアクセス禁止。 - ファイル添付の信頼ロジック。 - スクリプト実行の有効化。 詳細情報
IIS	- 既存の Web サイトが存在しない - ポート 443 でリッスンしている既存の Web サイト/アプリケーションが存在しない - 匿名認証を有効にする - FastCGI 設定を有効にする
IP アドレスの種類	静的
アクセスの設定
MYSQL	構成サーバーには MySQL がインストールされている必要があります。 手動でインストールするか、またはデプロイ中に Site Recovery でインストールすることができます。 Site Recovery でインストールする場合は、マシンが http://cdn.mysql.com/archives/mysql-5.5/mysql-5.5.37-win32.msi に到達できることを確認してください。
URL	構成サーバーは、次の URL にアクセスする必要があります (直接またはプロキシ経由)。 Microsoft Entra ID: login.microsoftonline.com; login.microsoftonline.us; *.accesscontrol.windows.net レプリケーション データ転送: *.backup.windowsazure.com、*.backup.windowsazure.us レプリケーション管理: *.hypervrecoverymanager.windowsazure.com、*.hypervrecoverymanager.windowsazure.us、https://management.azure.com、*.services.visualstudio.com ストレージ アクセス: *.blob.core.windows.net、*.blob.core.usgovcloudapi.net 時刻同期: time.nist.gov、time.windows.com テレメトリ (オプション): dc.services.visualstudio.com
ファイアウォール	IP アドレスベースのファイアウォール規則で Azure の URL への通信を許可する必要があります。 IP 範囲を簡略化および制限するために、URL フィルタリングの使用をお勧めします。 商用 IP: - Azure データセンターの IP の範囲と HTTPS (443) ポートを許可します。 - 米国西部の IP アドレス範囲を許可します (Access Control と Identity Management に使用されます)。 - Microsoft Entra ID、バックアップ、レプリケーション、およびストレージに必要な URL をサポートするために、サブスクリプションの Azure リージョンの IP アドレス範囲を許可します。 政府機関向け IP: - Azure Government データセンターの IP の範囲と HTTPS (443) ポートを許可します。 - Microsoft Entra ID、バックアップ、レプリケーション、ストレージに必要な URL をサポートするために、すべての US Gov リージョン (バージニア、テキサス、アリゾナ、アイオワ) の IP アドレス範囲を許可します。
Port	443 を許可 (コントロール チャネルのオーケストレーション) 9443 を許可 (データ転送)

構成/プロセス サーバーのサイズ要件

CPU	[メモリ]	キャッシュ ディスク	データの変更率	レプリケートされたマシン
8 vCPU 2 ソケット * 4 コア @ 2.5 GHz	16GB	300 GB	500 GB 以下	100 台未満のマシン
12 vCPU 2 ソケット * 6 コア @ 2.5 GHz	18 GB	600 GB	500 GB ～ 1 TB	100 ～ 150 台のマシン
16 vCPU 2 ソケット * 8 コア @ 2.5 GHz	32 GB	1 TB (テラバイト)	1 ～ 2 TB	150 ～ 200 台のマシン

手順 1:Azure Stack VM を準備する

オペレーティング システムの確認

VM を実行中のオペレーティング システムが、表にまとめられているもののいずれかであることを確認します。

オペレーティング システム	詳細
64 ビット Windows	Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012、Windows Server 2008 R2 (SP1 以降)
CentOS	5.2 から 5.11、6.1 から 6.9、7.0 から 7.3
Ubuntu	14.04 LTS サーバー、16.04 LTS サーバー。 サポートされているカーネルを確認してください。

モビリティ サービスのインストールを準備する

レプリケートするすべての VM にモビリティ サービスがインストールされている必要があります。 レプリケーションが有効な場合に、プロセス サーバーによってサービスを VM 上に自動的にインストールできるようにするために、VM の設定を確認します。

Windows マシン

• レプリケーションを有効にする VM との間のネットワーク接続が必要であり、マシン上でプロセス サーバーが実行されている必要があります (既定では、これは構成サーバー VM です)。
• レプリケーションを有効にするマシンに対して管理者権限 (ドメインまたはローカル) を持つアカウントが必要です。
  • このアカウントは、Site Recovery を設定するときに指定します。 レプリケーションが有効になっている場合、プロセス サーバーは、このアカウントを使用してモビリティ サービスをインストールします。
  • このアカウントは、Site Recovery がプッシュ インストールとモビリティ サービスの更新を行うためにのみ使用されます。
  • ドメイン アカウントを使用しない場合は、VM のリモート ユーザー アクセス コントロールを無効にする必要があります。
    • レジストリ内に DWORD 値 LocalAccountTokenFilterPolicy under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System を作成します。
    • 値を 1 に設定します。
    • コマンド プロンプトで、次を入力します。REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1.
• レプリケートする VM 上の Windows ファイアウォールで、ファイルとプリンターの共有、および WMI を許可します。
  • これを行うには、wf.mscを実行して、Windows ファイアウォール コンソールを開きます。 [受信の規則]>[新しい規則] を右クリックします。 [定義済み] を選択し、一覧から [ファイルとプリンターの共有] を選択します。 ウィザードを完了し、接続を許可することを選択して [終了] を選択します。
  • ドメイン コンピューターの場合は、 GPO を使用してこれを行うことができます。

Linux マシン

• Linux コンピューターとプロセス サーバーの間にネットワーク接続が存在することを確認します。
• レプリケーションを有効にするマシンに、ソース Linux サーバーの root ユーザーであるアカウントが必要です。
  • このアカウントは、Site Recovery を設定するときに指定します。 レプリケーションが有効になっている場合、プロセス サーバーは、このアカウントを使用してモビリティ サービスをインストールします。
  • このアカウントは、Site Recovery がプッシュ インストールとモビリティ サービスの更新を行うためにのみ使用されます。
• ソース Linux サーバーの /etc/hosts ファイルに、ローカル ホスト名を、すべてのネットワーク アダプターに関連付けられた IP アドレスにマップするエントリが存在することを確認します。
• レプリケート対象のコンピューターに最新の openssh、openssh-server、openssl の各パッケージをインストールします。
• SSH (Secure Shell) が有効になっており、ポート 22 で実行中であることを確認します。
• 以下の手順で、sshd_config ファイルで SFTP サブシステムとパスワード認証を有効にします。

  1. これを行うには、root としてサインインします。

  2. /etc/ssh/sshd_config ファイルで、PasswordAuthentication で始まる行を見つけます。 この行のコメントを解除し、値を yes に変更します。

  3. Subsystem で始まる行を見つけ、その行のコメントを解除します。

     

  4. sshd サービスを再起動します。

VM のプライベート IP アドレスをメモする

レプリケートするマシンごとに、IP アドレスを見つけます。

1. Azure Stack ポータルで、VM をクリックします。

2. [リソース] メニューで、 [ネットワーク インターフェイス] をクリックします。

3. プライベート IP アドレスをメモします。

   

手順 2:コンテナーを作成し、レプリケーションの目標を選択する

1. Azure portal で、 [リソースの作成]>[管理ツール]>[Backup and Site Recovery (OMS)] の順に選択します。

2. [名前] ボックスに、コンテナーを識別する表示名を入力します。

3. [リソース グループ] で、リソース グループを作成するか選択します。 ここでは、contosoRG を使用しています。

4. [場所] に、Azure リージョンを入力します。 [西ヨーロッパ] を使います。

5. ダッシュボードから資格情報コンテナーにすばやくアクセスするには、 [ダッシュボードにピン留めする]>[作成] の順に選択します。

   

   新しい資格情報コンテナーは、 [ダッシュボード]>[すべてのリソース] と、メインの [Recovery Services コンテナー] ページに表示されます。

レプリケーションの目標を選ぶ

1. [Recovery Services コンテナー]> コンテナー名を指定します。 ここでは、ContosoVMVault を使用しています。

2. [作業の開始] で、[Site Recovery] を選択します。 次に、 [インフラストラクチャの準備] を選択します。

3. [保護の目標]>[マシンのある場所] で、 [オンプレミス] を選びます。

4. [マシンをどこにレプリケートしますか] で、 [To Azure](Azure) を選びます。

5. [マシンは仮想化されていますか?] で、 [非仮想化/その他] を選択します。 [OK] をクリックします。

   

手順 3:ソース環境をセットアップする

構成サーバー マシンを設定してコンテナーに登録し、レプリケートするマシンを検出します。

1. [インフラストラクチャの準備] 、>[ソース] の順にクリックします。

2. [ソースの準備] で、 [+ 構成サーバー] をクリックします。

   

3. [サーバーの追加] で、[サーバーの種類] に [構成サーバー] が表示されていることを確認します。

4. Site Recovery 統合セットアップ インストール ファイルをダウンロードします。

5. コンテナー登録キーをダウンロードします。 統合セットアップを実行する際には、登録キーが必要です。 キーは生成後 5 日間有効です。

   

Azure Site Recovery 統合セットアップを実行する

構成サーバーをインストールして登録するには、構成サーバーとして使用する VM に RDP 接続し、統合セットアップを実行します。

開始する前に、クロックが VM 上のタイム サーバーと同期していることを確認します。 時間がローカル時間から 5 分以上ずれている場合、インストールは失敗します。

次に、構成サーバーをインストールします。

1. 統合セットアップ インストール ファイルを実行します。

2. [開始する前に] で [Install the configuration server and process server](構成サーバーとプロセス サーバーをインストールする) を選択します。

   

3. [Third-Party Software License (サードパーティ製ソフトウェア ライセンス)] で、 [同意する] をクリックして MySQL をダウンロードし、インストールします。

   

4. [登録] で、コンテナーからダウンロードした登録キーを選択します。

   

5. [インターネット設定] で、構成サーバーで実行されているプロバイダーがインターネット経由で Azure Site Recovery に接続する方法を指定します。 必要な URL へのアクセスが許可されていることを確認してください。

   • マシンで現在セットアップされているプロキシを使用して接続する場合は、 [プロキシ サーバーを使用して Azure Site Recovery に接続する] を選択します。
   • プロバイダーから直接接続するように指定する場合は、 [プロキシを使用せずに直接 Azure Site Recovery に接続する] を選択します。
   • 既存のプロキシで認証が必要な場合、またはプロバイダー接続にカスタム プロキシを使用する場合は、 [Connect with custom proxy setting](カスタム プロキシ設定を使用して接続する) を選択して、アドレス、ポート、資格情報を指定します。

6. [前提条件の確認] では、インストールを実行できることを確認するためのチェックが実行されます。 グローバル時刻の同期チェックに関する警告が表示された場合は、システム クロックの時刻 ( [日付と時刻] 設定) がタイム ゾーンと同じであることを確認します。

   

7. [MySQL Configuration (MySQL の構成)] で、インストールする MySQL サーバー インスタンスにログオンするための資格情報を作成します。

   

8. Azure Stack VM または物理サーバーをレプリケートする場合は、 [環境の詳細] で [いいえ] を選択します。

9. [インストール場所] で、バイナリをインストールしキャッシュを格納する場所を選択します。 選択するドライブには使用可能なディスク領域が 5 GB 以上必要ですが、600 GB 以上の空き領域があるキャッシュ ドライブを使用することをお勧めします。

   

10. [ネットワークの選択] で、最初に、モビリティ サービスの検出とソース マシンへのプッシュ インストールのために組み込みプロセス サーバーによって使用される NIC を選択し、次に、構成サーバーによって Azure との接続に使用される NIC を選択します。 既定では、ポート 9443 がレプリケーション トラフィックの送受信用に使用されます。このポート番号は、実際の環境の要件に合わせて変更できます。 ポート 9443 に加え、ポート 443 も開きます。このポートは、Web サーバーがレプリケーション操作を調整するために使用されます。 ポート 443 はレプリケーション トラフィックの送受信用に使用しないでください。

    

11. [概要] で情報を確認し、 [インストール] をクリックします。 インストールが完了すると、パスフレーズが生成されます。 このパスフレーズは、レプリケーションを有効にするときに必要になるので、コピーしてセキュリティで保護された場所に保管してください。

    

登録が完了すると、コンテナーの [設定]>[サーバー] ブレードに、サーバーが表示されます。

Note

構成サーバーは、コマンド ラインからインストールすることもできます。 詳細については、こちらを参照してください。

アカウント名がポータルに表示されるまでに 15 分以上かかることがあります。 すぐに更新するには [Configuration Servers](構成サーバー)>サーバー名>[Refresh Server](サーバーの更新) をクリックします。

手順 4:ターゲット環境をセットアップする

ターゲット リソースを選択して確認します。

1. [インフラストラクチャの準備]>[ターゲット] で、使う Azure サブスクリプションを選びます。
2. ターゲットのデプロイ モデルを指定します。
3. Site Recovery によって、互換性のある Azure ストレージ アカウントとネットワークが 1 つ以上あるかどうかが確認されます。 それらが見つからない場合、ウィザードを完了するには、少なくとも 1 つのストレージ アカウントと仮想ネットワークを作成する必要があります。

手順 5:レプリケーションを有効にする

レプリケーション ポリシーを作成する

1. [インフラストラクチャの準備]>[レプリケーションの設定] をクリックします。

2. [レプリケーション ポリシーの作成] で、ポリシー名を指定します。

3. [RPO しきい値] で、復旧ポイントの目標 (RPO) の上限を指定します。

   • 設定時間に従って、レプリケートされたデータの復旧ポイントが作成されます。
   • この設定はレプリケーションには影響しません (レプリケーションは連続しています)。 それは、復旧ポイントが作成されずにしきい値の上限に達した場合にアラートを発行するだけです。

4. [復旧ポイントのリテンション期間] で、各復旧ポイントがどれだけ長く保持されるかを指定します。 レプリケートされた VM は、指定された期間内の任意のポイントの状態に復旧できます。

5. [アプリ整合性スナップショットの頻度] で、アプリ整合性スナップショットの作成頻度を指定します。

   • アプリ整合性スナップショットは、VM 内のアプリケーション データのポイントインタイム スナップショットです。
   • ボリューム シャドウ コピー サービス (VSS) によって、スナップショットが作成されたとき、VM 上のアプリが整合性のある状態に維持されます。

6. [OK] を選択してポリシーを作成します。

展開の計画を確認する

現時点では、この手順は省略できます。 [デプロイ計画] のドロップダウン リストで [はい、完了しました] をクリックします。

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

手順 1:マシンの準備に示されているすべてのタスクを完了していることを確認します。 次のようにレプリケーションを有効にします。

1. [アプリケーションをレプリケートする]>[ソース] を選択します。

2. [ソース] で、構成サーバーを選択します。

3. [マシンの種類] で、 [物理マシン] を選択します。

4. プロセス サーバー (構成サーバー) を選択します。 次に、 [OK] をクリックします

5. [ターゲット] で、フェールオーバー後に VM を作成するサブスクリプションとリソース グループを選択します。 フェールオーバーされた VM で使用するデプロイ モデルを選択します。

6. レプリケートされたデータを格納する Azure ストレージ アカウントを選択します。

7. フェールオーバー後に作成された Azure VM が接続する Azure ネットワークとサブネットを選択します。

8. 保護の対象として選択したすべてのマシンにネットワーク設定を適用する場合は、 [選択したマシン用に今すぐ構成します。] を選択します。 マシンごとに Azure ネットワークを個別に選択する場合は、 [後で構成する] を選択します。

9. [物理マシン] で [+物理マシン] をクリックします。 レプリケートする各マシンの名前、IP アドレス、OS の種類を指定します。

   • マシンの内部 IP アドレスを使用します。
   • パブリック IP アドレスを指定した場合、レプリケーションが正しく動作しないことがあります。

10. [プロパティ]>[プロパティの構成] で、モビリティ サービスをマシンに自動的にインストールするためにプロセス サーバーが使用するアカウントを選択します。

11. [レプリケーションの設定]>[レプリケーション設定の構成] で、正しいレプリケーション ポリシーが選択されていることを確認します。

12. [レプリケーションを有効にする] をクリックします。

13. 保護の有効化ジョブの進行状況を、 [設定]>[ジョブ]>[Site Recovery ジョブ] で追跡します。 保護の最終処理ジョブが実行されると、マシンはフェールオーバーできる状態になります。

Note

VM のレプリケーションを有効にすると、Site Recovery がモビリティ サービスをインストールします。

変更が反映されてポータルに表示されるまで 15 分以上かかる場合があります。

追加する VM を監視するには、 [構成サーバー]>[最後の使用] で VM の最終検出時刻を確認します。 定期検出を待たずに VM を追加するには、構成サーバーを強調表示し (選択しないでください)、 [更新] を選択します。

手順 6:ディザスター リカバリー訓練を実行する

Azure へのテスト フェールオーバーを実行して、すべて想定どおりに動作していることを確認します。 このフェールオーバーが運用環境に影響を与えることはありません。

マシンのプロパティを確認する

テスト フェールオーバーを実行する前に、マシンのプロパティで、マシンが Azure の要件を満たしていることを確認します。 次のように、プロパティを表示して変更できます。

1. [保護されているアイテム] で、[レプリケートされたアイテム]> VM の順にクリックします。

2. [レプリケートされたアイテム] ウィンドウには、VM 情報、正常性状態、および最新の使用可能な復旧ポイントの概要が表示されます。 [プロパティ] をクリックすると、詳細が表示されます。

3. [コンピューティング] と [ネットワーク] の設定で、必要に応じて設定を変更します。

   • Azure VM 名、リソース グループ、ターゲット サイズ、可用性セット、およびマネージド ディスクの設定を変更できます。
   • ネットワーク設定も、表示して変更できます。 これらには、フェールオーバー後に Azure VM が参加するネットワーク/サブネットと、VM に割り当てられた IP アドレスが含まれます。

4. [ディスク] で、VM のオペレーティング システム ディスクとデータ ディスクに関する情報を確認します。

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

テスト フェールオーバーを実行すると、次の処理が発生します。

1. フェールオーバーを実行するために必要なすべての条件が満たされていることを確認する前提条件チェックが実行されます。

2. フェールオーバーでは、指定された復旧ポイントを使用してデータが処理されます。

   • 最後に処理があった時点:マシンは、Site Recovery によって処理された最新の復旧ポイントにフェールオーバーします。 タイム スタンプが表示されます。 このオプションを使用すると、データの処理に時間がかからないため、RTO (目標復旧時間) が低くなります。
   • 最新のアプリ整合性:マシンは、最新のアプリ整合性の復旧ポイントにフェールオーバーします。
   • Custom:フェールオーバーで使用する復旧ポイントを選択します。

3. 処理されたデータを使用して、Azure VM が作成されます。

4. テスト フェールオーバーは、訓練中に作成された Azure VM を自動的にクリーンアップできます。

次のように VM のテスト フェールオーバーを実行します。

1. [設定]>[レプリケートされたアイテム] で、VM >[+ テスト フェールオーバー] をクリックします。
2. このチュートリアルでは、 [最後に処理があった時点] 復旧ポイントの使用を選択します。
3. [テスト フェールオーバー] で、ターゲットの Azure ネットワークを選択します。
4. [OK] をクリックすると、フェールオーバーが開始されます。
5. VM をクリックしてそのプロパティを開いて、進行状況を追跡します。 または、"コンテナー名">[設定]>[ジョブ]>[Site Recovery ジョブ] で、 [テスト フェールオーバー] ジョブをクリックします。
6. フェールオーバーの完了後、レプリカの Azure VM は、Azure portal >[仮想マシン] に表示されます。 VM が適切なサイズであること、適切なネットワークに接続されていること、実行されていることを確認します。
7. これで、Azure 内のレプリケートされた VM に接続できるはずです。 詳細については、こちらを参照してください。
8. テスト フェールオーバー中に作成された VM を削除するには、VM で [テスト フェールオーバーのクリーンアップ] をクリックします。 [メモ] で、テスト フェールオーバーに関連する観察結果をすべて記録して保存します。

フェールオーバーとフェールバック

レプリケーションを設定し、訓練を実行してすべてが動作していることを確認した後、必要に応じてマシンを Azure にフェールオーバーできます。

フェールオーバー後に Azure 内のマシンに接続する場合は、フェールオーバーの実行を開始する前に、接続するための準備を行います。

その後、次のように、テスト フェールオーバーを実行します。

1. [設定]>[レプリケートされたアイテム] で、[マシン] >[フェールオーバー] をクリックします。
2. 使用する復旧ポイントを選択します。
3. [テスト フェールオーバー] で、ターゲットの Azure ネットワークを選択します。
4. [フェールオーバーを開始する前にマシンをシャットダウンします] を選択します。 この設定によって、Site Recovery は、フェールオーバーを開始する前に、ソース マシンをシャットダウンしようとします。 ただし、シャットダウンが失敗した場合でも、フェールオーバーは続行されます。
5. [OK] をクリックすると、フェールオーバーが開始されます。 フェールオーバーの進行状況は [ジョブ] ページで確認できます。
6. フェールオーバーの完了後、レプリカの Azure VM は、Azure portal >[仮想マシン] に表示されます。 フェールオーバー後に接続するように準備していた場合は、VM が適切なサイズであること、適切なネットワークに接続されていること、実行されていることを確認します。
7. VM を検証した後、 [コミット] をクリックして、フェールオーバーを終了します。 これにより、使用可能なすべての復旧ポイントが削除されます。

警告

進行中のフェールオーバーを取り消さないでください: フェールオーバーが開始される前に、VM のレプリケーションが停止されます。 進行中のフェールオーバーをキャンセルすると、フェールオーバーは停止しますが、VM が再びレプリケートされることはありません。

Azure Stack にフェールバックする

プライマリ サイトが再稼働したら、Azure から Azure Stack にフェールバックできます。 これを行うには、こちらに記載されている手順に従います。

まとめ

この記事では、Azure Stack VM を Azure にレプリケートしました。 レプリケーションできるようにした後、ディザスター リカバリー訓練を実行して、Azure へのフェールオーバーが想定どおりに動作することを確認しました。 この記事には、Azure への完全フェールオーバーを実行する手順と Azure Stack へのフェールバック手順も含まれています。

次のステップ

フェールバック後、VM を再び保護し、Azure へのレプリケートを再び開始できます。 これを行うには、この記事の手順を繰り返します。