次の方法で共有


Azure Government と Public のリージョン間で Azure 仮想マシンを移動する

こちらで説明されているように、既存の仮想マシンの可用性を高めたり管理を容易にしたりするため、またはガバナンス上の理由から、Azure Government とパブリック リージョンの間で IaaS 仮想マシンを移動することが必要になる場合があります。

Azure Site Recovery サービスを使用して、ビジネス継続性およびディザスター リカバリー (BCDR) の目的でオンプレミス マシンや Azure 仮想マシンのディザスター リカバリーを管理および調整する他に、Azure 仮想マシンをセカンダリ リージョンに移動するためにも Site Recovery を使用できます。

このチュートリアルでは、Azure Site Recovery を使用して Azure Government とパブリック リージョンの間で Azure 仮想マシンを移動する方法を説明します。 これを応用すれば、属しているクラスターが地理的に異なるリージョン ペア間で仮想マシンを移動することもできます。 このチュートリアルでは、次の作業を行う方法について説明します。

  • 前提条件を確認する
  • ソース仮想マシンを準備する
  • ターゲット リージョンを準備する
  • ターゲット リージョンにデータをコピーする
  • 構成をテストする
  • 移動を実行する
  • ソース リージョンのリソースを破棄する

重要

このチュートリアルでは、Azure Government とパブリック リージョンの間、または Azure 仮想マシンの通常のディザスター リカバリー ソリューションでサポートされていないリージョン ペア間で、Azure Site Recovery を使用して Azure 仮想マシンを移動する方法について説明します。 ソース リージョンとターゲット リージョンのペアがサポート対象である場合、移動については、こちらのドキュメントを参照してください。 可用性セット内の仮想マシンを別のリージョンのゾーン固定仮想マシンに移動することで可用性を向上させることが要件である場合は、こちらのチュートリアルを参照してください。

重要

この方法を使用して、サポート対象外のリージョン ペア間で DR を構成することはお勧めしません。これらのペアは、データの待ち時間を考慮して定義されますが、これが DR のシナリオではきわめて重要になるためです。

前提条件を確認する

Note

このシナリオのアーキテクチャとコンポーネントを理解している。 Azure 仮想マシンの移動は、このアーキテクチャを使用し、仮想マシンを物理サーバーとして扱うことによって行います。

  • すべてのコンポーネントのサポート要件を確認する。

  • レプリケートするサーバーが Azure VM 要件に準拠していること。

  • レプリケートする各サーバーにモビリティ サービスを自動インストールするためのアカウントを準備します。

  • Azure でターゲット リージョンにフェールオーバーした後は、ソース リージョンに対して直接フェールバックを実行できません。 ターゲットに戻るようにもう一度レプリケーションを設定する必要があります。

Azure アカウントのアクセス許可を確認する

仮想マシンを Azure にレプリケートするアクセス許可がお使いの Azure アカウントに与えられていることを確認します。

Azure ネットワークをセットアップ

ターゲット Azure ネットワークを設定します。

  • Azure 仮想マシンは、フェールオーバー後に作成されたときに、このネットワークに配置されます。
  • ネットワークは、Recovery Services コンテナーと同じリージョンにある必要があります。

Azure Storage アカウントの設定

Azure ストレージ アカウントを設定します。

  • Site Recovery は、オンプレミスのマシンを Azure Storage にレプリケートします。 Azure 仮想マシンは、フェールオーバーの発生後にストレージから作成されます。
  • ストレージ アカウントは、Recovery Services コンテナーと同じリージョンに存在する必要があります。

ソース仮想マシンを準備する

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

モビリティ サービスは、レプリケートする各サーバーにインストールする必要があります。 サーバーのレプリケーションを有効にすると、Site Recovery がこのサービスを自動的にインストールします。 自動的にインストールするには、Site Recovery でサーバーへのアクセスに使用するアカウントを準備する必要があります。

  • ドメイン アカウントまたはローカル アカウントを使用できます。
  • Windows 仮想マシンの場合、ドメイン アカウントを使用していなければ、次のようにしてローカル マシンでのリモート ユーザー アクセス制御を無効にします。 無効にするには、レジスタで、HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System の下に、値 1 を指定した DWORD エントリの LocalAccountTokenFilterPolicy を追加します。
  • CLI からレジストリ エントリを追加して、設定を無効にするには、次のように入力します: REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1.
  • Linux の場合、アカウントは、ソース Linux サーバーの root である必要があります。

ターゲット リージョンを準備する

  1. Azure サブスクリプションによって、ディザスター リカバリーに使用されるターゲット リージョンに仮想マシンを作成できることを確認します。 サポートに連絡して、必要なクォータを有効にしてください。

  2. サブスクリプションに、ソース仮想マシンと一致するサイズの仮想マシンをサポートするための十分なリソースがあることを確認します。 Site Recovery を使用してターゲットにデータをコピーする場合、ターゲット仮想マシンには、同じサイズ (または可能な限り近いサイズ) が選択されます。

  3. ソース ネットワーク レイアウトから特定されたすべてのコンポーネントについてターゲット リソースを作成します。 これは、ターゲット リージョンへの切り替え後、ソースにあったすべての機能を仮想マシンに確保するうえで重要となります。

    Note

    ソース仮想マシンのレプリケーションを有効にすると、Azure Site Recovery によって仮想ネットワークが自動的に検出されて作成されます。または、自分でネットワークを事前に作成しておき、レプリケーションを有効にするユーザー フローの中で仮想マシンに割り当てることもできます。 ただし、その他のリソースについては、ターゲット リージョンに手動で作成する必要があります。

    ソース仮想マシンの構成に基づいて、自分にとって意味があり、最もよく使用されるネットワーク リソースを作成するには、次のドキュメントを参照してください。

    その他のネットワーク コンポーネントについては、ネットワークに関するドキュメントを参照してください。

  4. ターゲット リージョンへの最終的な切り替えを行う前に構成をテストしたい場合は、ターゲット リージョンに手動で非運用ネットワークを作成します。 運用環境への影響が最小限で済むため、この方法をお勧めします。

ターゲット リージョンにデータをコピーする

以下の手順では、Azure Site Recovery を使用してターゲット リージョンにデータをコピーする方法を説明しています。

任意のリージョン (ソース リージョンを除く) にコンテナーを作成します。

  1. Azure Portal>Recovery Services にサインインします。
  2. [リソースの作成]>[管理ツール]>[バックアップおよびサイトの回復] の順にクリックします。
  3. [名前] に、フレンドリ名 ContosoVMVault を指定します。 複数のサブスクリプションがある場合は、適切なものを選択します。
  4. リソース グループ ContosoRG を作成します。
  5. Azure リージョンを指定します。 サポートされているリージョンを確認するには、Azure Site Recovery の価格の詳細に関するページでご利用可能な地域をご覧ください。
  6. [Recovery Services コンテナー] で、 [概要]>[ConsotoVMVault]>[+ レプリケート] の順にクリックします。
  7. [To Azure](Azure へ)>[非仮想化/その他] の順に選択します。

仮想マシンを検出するよう構成サーバーを設定します。

構成サーバーをセットアップしてコンテナーに登録し、仮想マシンを検出します。

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

  2. 構成サーバーの準備が整っていない場合、[構成サーバーを追加する] オプションを使用できます。

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

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

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

    サーバーの追加ページのスクリーンショット。

構成サーバーのコンテナーへの登録

開始する前に次の作業を行います。

時間の精度を検証する

構成サーバー マシンのシステム クロックがタイム サーバーと同期していることを確認します。 これは一致している必要があります。 15 分進んでいるか遅れている場合は、セットアップが失敗する可能性があります。

接続を検証する

コンピューターが、環境に基づいて次の URL にアクセスできることを確認します。

Name 商用の URL 政府機関の URL 説明
Microsoft Entra ID login.microsoftonline.com login.microsoftonline.us アクセス制御と ID 管理に使用。
Backup *.backup.windowsazure.com *.backup.windowsazure.us レプリケーション データの転送と調整に使用。
レプリケーション *.hypervrecoverymanager.windowsazure.com *.hypervrecoverymanager.windowsazure.us レプリケーション管理操作と調整に使用。
ストレージ *.blob.core.windows.net *.blob.core.usgovcloudapi.net レプリケートされたデータを格納するストレージ アカウントへのアクセスに使用。
テレメトリ (オプション) dc.services.visualstudio.com dc.services.visualstudio.com テレメトリに使用されます。
時刻同期 time.windows.com time.nist.gov すべてのデプロイでシステム時刻とグローバル時刻の間の時刻同期を確認するために使用されます。

IP アドレス ベースのファイアウォール規則では、HTTPS (443) ポートの上に示されているすべての Azure URL への通信が許可される必要があります。 IP 範囲を簡略化および制限するために、URL フィルタリングを実行することをお勧めします。

  • 商用 IP - Azure データセンターの IP 範囲と HTTPS (443) ポートを許可します。 Microsoft Entra ID、バックアップ、レプリケーション、およびストレージ URL をサポートするために、サブスクリプションの Azure リージョンの IP アドレス範囲を許可します。
  • Government IP - Microsoft Entra ID、バックアップ、レプリケーション、およびストレージ URL をサポートするために、すべての USGov リージョン (バージニア、テキサス、アリゾナ、およびアイオワ) の Azure Government データセンターの IP 範囲と HTTPS (443) ポートを許可します。

セットアップを実行する

ローカル管理者として統合セットアップを実行し、構成サーバーをインストールします。 プロセス サーバーとマスター ターゲット サーバーも既定で構成サーバーにインストールされます。

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

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

    統合セットアップの [開始する前に] 画面のスクリーンショット。

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

    統合セットアップの [Third Party Software License]\(サードパーティ製ソフトウェア ライセンス\) 画面のスクリーンショット。

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

    統合セットアップの [登録] 画面のスクリーンショット。

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

    • マシンで現在セットアップされているプロキシを使用して接続する場合は、 [プロキシ サーバーを使用して Azure Site Recovery に接続する] を選択します。
    • プロバイダーから直接接続するように指定する場合は、 [プロキシを使用せずに直接 Azure Site Recovery に接続する] を選択します。
    • 既存のプロキシで認証が必要な場合、またはプロバイダー接続にカスタム プロキシを使用する場合は、 [Connect with custom proxy setting](カスタム プロキシ設定を使用して接続する) を選択して、アドレス、ポート、資格情報を指定します。 統合セットアップの [インターネット設定] 画面のスクリーンショット。
  6. [前提条件の確認] では、インストールを実行できることを確認するためのチェックが実行されます。 グローバル時刻の同期チェックに関する警告が表示された場合は、システム クロックの時刻 ( [日付と時刻] 設定) がタイム ゾーンと同じであることを確認します。

    統合セットアップの [前提条件の確認] 画面のスクリーンショット。

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

    統合セットアップの [MySQL Configuration]\(MySQL の構成\) 画面のスクリーンショット。

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

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

    統合セットアップの [インストール場所] 画面のスクリーンショット。

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

    統合セットアップの [ネットワークの選択] 画面のスクリーンショット。

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

    統合セットアップの [概要] 画面のスクリーンショット。

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

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

レプリケーションのターゲット設定を構成する

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

  1. [インフラストラクチャの準備]>[ターゲット] の順にクリックし、使用する Azure サブスクリプションを選択します。

  2. [ターゲット設定] タブで、次を行います。

    1. [サブスクリプション] で、使用する Azure サブスクリプションを選択します。
    2. [フェールオーバー後のデプロイ モデル] で、ターゲット デプロイ モデルを指定します。
  3. Site Recovery によって、互換性のある Azure ストレージ アカウントとネットワークが 1 つ以上あるかどうかが確認されます。 ターゲット設定ページのスクリーンショット。

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

  1. 新しいレプリケーション ポリシーを作成するには、 [Site Recovery インフラストラクチャ]>[レプリケーション ポリシー]>[+ レプリケーション ポリシー] の順にクリックします。
  2. [レプリケーション ポリシーの作成] で、ポリシー名を指定します。
  3. [RPO しきい値] で、復旧ポイントの目標 (RPO) の上限を指定します。 この値で、データの復旧ポイントを作成する頻度を指定します。 継続的なレプリケーションがこの制限を超えると、アラートが生成されます。
  4. [復旧ポイントの保持期間] で、各復旧ポイントのリテンション期間の長さ (時間単位) を指定します。 レプリケートされた仮想マシンは期間内のどのポイントにも復旧できます。 Premium Storage にレプリケートされたマシンでは最大 24 時間のリテンション期間がサポートされ、Standard Storage の場合は 72 時間です。
  5. [アプリ整合性スナップショットの頻度]で、アプリケーション整合性スナップショットを含む復旧ポイントの作成頻度 (分単位) を指定します。 [OK] をクリックしてポリシーを作成します。 レプリケーション ポリシー ページのスクリーンショット。

このポリシーは自動的に構成サーバーに関連付けられます。 既定でフェールバックの照合ポリシーが自動的に作成されます。 たとえば、レプリケーション ポリシーが rep-policy の場合、フェールバック ポリシー rep-policy-failback が作成されます。 このポリシーは、Azure からフェールバックを開始するまで使用されません。

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

  • レプリケーションを有効にすると、Site Recovery がモビリティ サービスをインストールします。
  • サーバーのレプリケーションを有効にすると、変更が反映されてポータルに表示されるまで 15 分以上かかる場合があります。
  1. [アプリケーションをレプリケートする]>[ソース] の順にクリックします。

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

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

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

  5. [ターゲット] で、フェールオーバー後に Azure 仮想マシンを作成するサブスクリプションとリソース グループを選択します。 Azure で使用するデプロイ モデル (クラシックまたはリソース管理) を選択します。

  6. データのレプリケーションに使用する Azure Storage アカウントを選択します。

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

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

  9. [物理マシン][+物理マシン] をクリックします。 名前と IP アドレスを指定します。 レプリケートするマシンのオペレーティング システムを選択します。 サーバーを検出し、一覧表示するのに数分かかります。

    警告

    移動する Azure 仮想マシンの IP アドレスを入力する必要があります

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

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

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

追加したサーバーを監視する目的で、サーバーの最終検出時刻を [構成サーバー] の >[前回のアクセス] で確認できます。 定期検出を待たずにマシンを追加するには、構成サーバーを強調表示し (クリックしないでください)、 [更新] をクリックします。

構成をテストする

  1. コンテナーに移動し、 [設定]>[レプリケートされたアイテム] で、ターゲット リージョンに移動する仮想マシンをクリックし、 [+ テスト フェールオーバー] アイコンをクリックします。

  2. [テスト フェールオーバー] で、フェールオーバーに使用する復旧ポイントを選択します。

    • [最後に処理された時点]: Site Recovery サービスで処理された最新の復旧ポイントに仮想マシンをフェールオーバーします。 タイム スタンプが表示されます。 このオプションを使用すると、データの処理に時間がかからないため、低い RTO (Recovery Time Objective: 回復時刻の目標) を提示します。
    • [最新のアプリ整合性]: このオプションは、すべての仮想マシンを最新のアプリ整合性の復旧ポイントにフェールオーバーします。 タイム スタンプが表示されます。
    • Custom:任意の復旧ポイントを選択します。
  3. Azure 仮想マシンの移動先となるターゲット Azure 仮想ネットワークを選択し、構成をテストします。

    重要

    テスト フェールオーバーには、仮想マシンの最終的な移動先となる運用環境のネットワーク (レプリケーションを有効にしたときに設定されたもの) ではなく、別個の Azure 仮想マシン ネットワークを使用することをお勧めします。

  4. 移動テストを開始するには、 [OK] をクリックします。 進行状況を追跡するには、仮想マシンをクリックしてそのプロパティを開きます。 また、>[設定]>[ジョブ]>[Site Recovery ジョブ] で、テスト フェールオーバー ジョブをクリックすることもできます。

  5. フェールオーバーの完了後、レプリカの Azure 仮想マシンは、Azure portal の >[仮想マシン] に表示されます。 仮想マシンが実行中で、適切なサイズであること、また、適切なネットワークに接続されていることを確認してください。

  6. 移動テストの過程で作成した仮想マシンを削除する場合は、[レプリケートされたアイテム] の [テスト フェールオーバーのクリーンアップ] をクリックします。 [メモ] を使用して、テストに関連する観察結果をすべて記録し、保存します。

ターゲット リージョンへの移動を実行して確認する

  1. コンテナーに移動し、 [設定]>[レプリケートされたアイテム] で仮想マシンをクリックして、 [フェールオーバー] をクリックします。
  2. [フェールオーバー][最新] を選択します。
  3. [フェールオーバーを開始する前にマシンをシャットダウンします] を選択します。 Site Recovery は、フェールオーバーを開始する前にソース仮想マシンをシャットダウンしようとします。 仮にシャットダウンが失敗したとしても、フェールオーバーは続行されます。 フェールオーバーの進行状況は [ジョブ] ページで確認できます。
  4. ジョブが完了したら、ターゲット Azure リージョンに仮想マシンが正しく表示されることを確認します。
  5. [レプリケートされた項目] の仮想マシンを右クリックし >[コミット] します。 これでターゲット リージョンへの移動プロセスは完了です。 コミット ジョブが完了するまでお待ちください。

ソース リージョンのリソースを破棄する

  • 仮想マシンに移動します。 [レプリケーションの無効化] をクリックします。 この操作で仮想マシンのデータをコピーするプロセスは停止します。

    重要

    これは、ASR レプリケーションの請求を避けるうえで重要な手順となります。

ソース リソースを再利用する予定がない場合は、次の一連の手順に進んでください。

  1. ソース仮想マシンを準備する」の手順 4 で特定した該当するネットワーク リソースをソース リージョンからすべて削除します
  2. 対応するストレージ アカウントをソース リージョンから削除します。

次のステップ

このチュートリアルでは、Azure 仮想マシンを別の Azure リージョンに移動しました。 次には、移動した仮想マシンのディザスター リカバリーを構成できます。