Azure Stack Hub の仮想マシンのディザスター リカバリー

この記事では、Azure Stack Hub でホストされている仮想マシン (VM) 上で実行されているワークロードのディザスター リカバリーに最適化されたアプローチを提供するソリューションのアーキテクチャおよび設計上の考慮事項について説明します。

アーキテクチャ

このアーキテクチャの Visio ファイルをダウンロードします。

ワークフロー

ここで提案するソリューションのクラウド コンポーネントには、次のサービスが含まれます。

• このソリューションに含まれるすべてのクラウド リソースをホストする Azure サブスクリプション。

• その Azure サブスクリプションに関連付けられた Microsoft Entra ID テナント。Microsoft Entra セキュリティ プリンシパルの認証を行って、Azure リソースへのアクセスを認可します。

• Azure Recovery Services コンテナー。Azure Stack Hub デプロイをホストとするオンプレミス データセンターに最も近い Azure リージョンに置かれます。

  注意

  オンプレミス データセンターに最も近い Azure リージョンの選択は、この記事で紹介するサンプル シナリオ固有の決定です。 ディザスター リカバリーの観点から言えば、運用環境がホストされている場所からより離れた Azure リージョンを選択するのが得策です。 ただし、これは、リージョンのデータ フィードの待ち時間を最小限に抑える必要性や、データ所在地の要件を満たす必要性など、他の要因によって決定される場合があります。

• Azure Recovery Services コンテナーをホストする Azure リージョンにオンプレミスのデータセンターを接続する Azure ExpressRoute 回線。プライベート ピアリングと Microsoft ピアリングを使用して構成されます。 前者によって、フェールオーバー後の待ち時間の要件が確実に満たされます。 後者の目的は、オンプレミスのワークロードと Azure のフェールオーバー サイトとの間で変更をレプリケートするのに要する時間を最小限に抑えることです。

• BLOB を保持する Azure Storage アカウント。これらの BLOB には、保護対象の Azure Stack Hub VM のオペレーティング システム ボリュームとデータ ボリュームのレプリケーションによって作成される VHD ファイルが格納されます。 これらの VHD ファイルは、フェールオーバー後に自動的にプロビジョニングされる Azure VM のマネージド ディスクのソースとなります。

• ディザスター リカバリー環境をホストする Azure 仮想ネットワーク。 運用環境のワークロード (ロード バランサーやネットワーク セキュリティ グループなどのコンポーネントを含む) をホストする Azure Stack Hub の仮想ネットワーク環境を正確に反映する形で構成されます。 通常、この仮想ネットワークは、ワークロードレベルの復旧を支援するために、ExpressRoute 接続を介して Azure Stack Hub の仮想ネットワークに接続されます。

  注意

  回復ポイントの目標 (RPO) 要件がそれほど厳しくないシナリオでは、サイト間 VPN 接続で十分な場合もあります。

• テスト フェールオーバー用に分離された Azure 仮想ネットワーク。運用環境のワークロード (ロード バランサーやネットワーク セキュリティ グループなどのコンポーネントを含む) をホストする Azure Stack Hub の仮想ネットワーク環境を正確に反映する形で構成されます。

ここで提案するソリューションのオンプレミス コンポーネントには、次のサービスが含まれます。

• 接続型デプロイ モデルの Azure Stack Hub 統合システム。 このシステムは、最新の更新プログラム (2020 年 9 月時点では 2002) が適用され、お客様のオンプレミス データセンター内に配置されます。

• Azure Stack Hub サブスクリプション、およびこのソリューションのすべてのオンプレミス VM をホストする 1 つの仮想ネットワークまたは複数のピアリングされた仮想ネットワーク。

• Windows Server 2016 または 2012 R2 Azure Hub Stack VM 上で実行される Azure Site Recovery の構成サーバーとプロセス サーバー。 これらのサーバーは、Azure Recovery Services コンテナーとの通信、およびレプリケーション トラフィックのルーティング、最適化、暗号化を管理します。

  注意

  既定では、1 つの構成サーバーに 1 つのプロセス サーバーがホストされます。 大量のレプリケーション トラフィックに対応するために、専用のプロセス サーバーをデプロイすることができます。

• 保護の対象となる Azure Stack Hub VM。 これらは、Windows Server、CentOS、Ubuntu オペレーティング システムのサポート対象バージョンを実行します。

• 保護対象 VM で実行されている Site Recovery Mobility Service ("モビリティ エージェント" とも呼ばれます)。 これは、ローカル ディスクへの変更を追跡し、それらをレプリケーション ログに記録して、そのログをプロセス サーバーにレプリケートします。 プロセス サーバーは、それらをターゲットの Azure Storage アカウントにルーティングします。 このログは、指定した Azure Storage アカウントに格納されている BLOB を使用して実装されるマネージド ディスクの復旧ポイントを作成するために使用されます。

コンポーネント

• Microsoft Entra ID
• Azure Virtual Network
• Azure Recovery Services
• Azure ExpressRoute
• Azure Blob Storage
• Azure Stack Hub

代替

Azure Stack Hub VM ベースのワークロードでディザスター リカバリー機能を実現する方法は、この記事で取り上げる推奨ソリューションだけではありません。 その他の手段を選ぶこともできます。その例を次に示します。

• 別の Azure Stack Hub スタンプへのフェールオーバー。 データセンターやサイトの機能不全への保護対策として、もう 1 つの Azure Stack Hub デプロイを使用して、ディザスター リカバリー プロビジョニングを実現することができます。 ユーザーは、プライマリとセカンダリの場所を使用して、アクティブ/パッシブ構成でアプリケーションを 2 つの環境にデプロイできます。 重要度の低いワークロードについては、セカンダリの場所にある未使用の容量を使用して、アプリケーションをバックアップからオンデマンドで復元できる場合もあります。 また、復旧サイトを別のデータセンターに実装し、そこで Site Recovery を使用して、そのリカバリー サイトのレプリカを Azure にプロビジョニングすることもできます。 Azure でフェールオーバー サイトとして Site Recovery を使用することが実現可能なソリューションであるかどうかは、いくつかの要因によって決まります。 そうした要因の例としては、政府の規制、企業のポリシー、待ち時間の要件が挙げられます。

  注意

  2020 年 7 月現在、Site Recovery はこのシナリオをサポートしていません。つまり、実装するには、パートナーまたは社内開発のソリューションを使用する必要があります。

• バックアップと復元。 アプリケーションとデータセットをバックアップすることで、データの破損、偶発的な削除、局所的な停止などによるダウンタイムから迅速に復旧できます。 Azure Stack Hub VM ベースのアプリケーションでは、ゲスト内エージェントを使用して、アプリケーション データ、オペレーティング システムの構成、ボリュームに格納されているデータを保護できます。 ゲスト OS エージェントを使用した VM のバックアップには、通常、オペレーティング システムの構成、ファイル、フォルダー、ボリューム、アプリケーション バイナリ、アプリケーション データのキャプチャが含まれます。 エージェントからアプリケーションを復旧するには、VM を再作成し、その後、オペレーティング システムとゲスト エージェントをインストールする必要があります。 その時点で、ゲスト OS にデータを復元することができます。

• ディスクのスナップショットのバックアップ。 スナップショットを使用して、Azure Stack Hub VM の構成と、停止状態の VM にアタッチされているディスクをキャプチャすることができます。 このプロセスでは、VM 構成をキャプチャし、ディスク スナップショットを作成するために、Azure Stack Hub API と統合されたバックアップ製品が必要です。

  注意

  2020 年 7 月現在、実行中の VM のディスク スナップショットを使用する機能はサポートされていません。 実行中の VM にアタッチされているディスクのスナップショットを作成すると、VM 内のオペレーティング システムまたはアプリケーションのパフォーマンスが低下したり、可用性に影響を与えたりする場合があります。

• 同じデータセンターで外部のバックアップ ソリューションを使用して VM のバックアップと復元を行った後、別の場所にバックアップをレプリケートします。 こうすることで、Azure Stack Hub VM を同じ Azure Stack Hub インスタンス、別のインスタンス、または Azure に復元できます。

シナリオの詳細

Azure Stack Hub には自己復旧機能が備わっており、コンポーネントの局所的な障害が関係するシナリオの範囲内であれば自動的に修復することができます。 しかし、サーバー ラックまたはサイトレベルの障害に波及する停止など、大規模な障害にはさらに別の考慮事項が必要となります。 VM ベースのユーザー ワークロードに対する事業継続とディザスター リカバリーの戦略には、そうした考慮事項を含める必要があります。 また、この戦略では、ワークロードの復旧とは別に、Azure Stack インフラストラクチャの復旧についても考慮する必要があります。

従来からあるオンプレミスのワークロード復旧ソリューションは、フェールオーバー サイトとして別のオンプレミス拠点を使用する場合には特に、構成が複雑でコストがかかり、保守するために多くの労力を要するうえに、自動化も困難です。 Microsoft は、クラウドとオンプレミスのコンポーネントを組み合わせた代替ソリューションを推奨しています。これにより、回復性があり、パフォーマンスベースの高度に自動化された簡単な方法でコスト効率の高いディザスター リカバリー戦略を実装して管理し、セキュリティを確保できます。 このソリューションの中核となる要素は、フェールオーバー サイトが Azure に存在する Site Recovery です。

考えられるユース ケース

Site Recovery で Azure をフェールオーバー サイトとして使用することにより、前述の欠点はすべて排除されます。 その機能を使用することで、物理サーバーと仮想サーバーの両方を保護することができます。それらのサーバーが Microsoft Hyper-V や VMware ESXi の仮想化プラットフォームで実行されていてもかまいません。 同じ機能を使用して、Azure Stack Hub VM で実行されているワークロードの復旧を容易にすることもできます。

コア機能

Site Recovery は、次の 2 つの機能セットを提供することで、物理および仮想コンピューターの保護を容易にするディザスター リカバリー ソリューションです。

• 運用場所とディザスター リカバリーの場所との間で、コンピューター ディスクに対する変更をレプリケートする
• この 2 つの拠点間で実行されるフェールオーバーとフェールバックのオーケストレーションを行う

Site Recovery には、次の 3 種類のフェールオーバーが用意されています。

• フェールオーバーをテストする。 このフェールオーバーにより、データの損失や運用環境への影響を招くことなく、隔離された環境内で Site Recovery の構成を検証できます。
• 計画されたフェールオーバーです。 データの損失を招くことなく、ディザスター リカバリーを開始することができます。通常、予定されたダウンタイムの一環として実施されます。
• 計画されていないフェールオーバーです。 万一、計画外の機能停止によってプライマリ サイトの可用性に支障が生じたりデータの損失リスクが生じたりした場合に、最後の手段として用いられます。

Site Recovery では、2 つのオンプレミス サイト間でのフェールオーバーとフェールバック、2 つの Azure リージョン間でのフェールオーバーとフェールバック、サード パーティ プロバイダーのクラウドからの移行など、いくつかのシナリオがサポートされています。 ただし、この記事では、Azure Storage への Azure Stack Hub VM のレプリケーションと、Azure Stack Hub スタックと Azure リージョン間での VM のフェールオーバーとフェールバックに重点を置きます。

Site Recovery のアーキテクチャとそのコンポーネントの詳細は、次のようなさまざまな条件によって異なります。

• 保護するコンピューターの種類 (物理コンピューターか仮想コンピューターか)。
• 仮想環境の場合、保護対象の仮想マシンをホストするハイパーバイザーの種類 (Hyper-V か、VMware ESXi か)。
• Hyper-V 環境の場合、Hyper-V ホストの管理への System Center Virtual Machine Manager (SCVMM) の使用。

Azure Stack Hub でのアーキテクチャは、物理コンピューターに適用可能なアーキテクチャと同等です。 これは特に驚くことではありません。どちらの場合も、Site Recovery では、ハイパーバイザーへの直接アクセスによって得られる利点をないからです。 ローカル ディスクに対する変更を追跡してレプリケートするメカニズムは、保護の対象となるオペレーティング システムの方に実装されています。

これを実現するために、Site Recovery では Site Recovery Mobility Service ("モビリティ エージェント" とも呼ばれます) が使用されます。これは、Site Recovery ベースの保護スコープに登録する各 VM に自動的にデプロイされます。 それぞれの保護対象 VM では、ローカルにインストールされたモビリティ エージェントのインスタンスが、オペレーティング システムとデータ ディスクに対する変更を絶えず監視し、プロセス サーバーに転送します。 ただし、保護対象 VM から生じるレプリケーション トラフィックのフローを最適化して管理するために、Site Recovery では、別個の VM 上で実行される追加のコンポーネント セットが実装されます。これは構成サーバーと呼ばれます。

構成サーバーは、Site Recovery コンテナーとの通信を調整し、データのレプリケーションを管理します。 構成サーバーはさらに、"プロセス サーバー" と呼ばれるコンポーネントをホストします。プロセス サーバーがゲートウェイとしての役割を果たしながら、レプリケーション データを受け取り、キャッシュと圧縮によってデータを最適化し、暗号化したうえで Azure Storage に転送します。 事実上、構成サーバーは、Site Recovery と、Azure Stack Hub 上で実行されている保護対象 VM との間の統合ポイントとして機能します。 構成サーバーをデプロイし、それを Azure Recovery Services コンテナーに登録することで、その連携が実現されます。

Site Recovery を構成する過程では、運用環境を正確に反映する形で、目的とするディザスター リカバリー環境を定義します。たとえば仮想ネットワーク、ロード バランサー、ネットワーク セキュリティ グループなどのインフラストラクチャ コンポーネントがあります。 この構成には、レプリケーション ポリシーも含まれます。レプリケーション ポリシーは、復旧の機能を決定付けるもので、次のパラメーターから成ります。

• [RPO しきい値] 。 この設定は、実現したい回復ポイントの目標を表します。これにより、Site Recovery でクラッシュ整合性復旧ポイント スナップショットが生成される頻度が決定されます。 その値がレプリケーションの頻度に影響することはありません。レプリケーションは継続的に実行されるためです。 Site Recovery で現在提供されている有効な RPO が、指定したしきい値を超えた場合、Site Recovery はアラートを生成し、必要に応じて電子メールによる通知を生成します。 Site Recovery によって、クラッシュ整合性復旧ポイント スナップショットが 5 分ごとに生成されます。

  注意

  クラッシュ整合性スナップショットでは、スナップショットが作成されたときにディスクに存在していたデータがキャプチャされます。 メモリの内容は含まれません。 実際上、クラッシュ整合スナップショットでは、オペレーティング システムやローカルにインストールされたアプリのデータ整合性が保証されません。

• 復旧ポイントのリテンション期間。 この設定は、各復旧ポイント スナップショットのリテンション期間 (時間) を表します。 保護対象 VM は、リテンション期間内であれば、どの復旧ポイントにでも復旧できます。 Site Recovery では、Premium パフォーマンス レベルの Azure Storage アカウントにレプリケートされた VM について、最大 24 時間のリテンション期間がサポートされます。 Standard パフォーマンス レベルの Azure Storage アカウントを使用している場合、リテンション期間は 72 時間に制限されます。

• アプリ整合性スナップショットの頻度。 この設定によって、Site Recovery でアプリケーション整合性スナップショットが生成される頻度 (時間) が決定されます。 アプリ整合性スナップショットは、保護対象 VM で実行されているアプリケーションのポイントインタイム スナップショットを表します。 アプリ整合性スナップショットは 12 個に制限されます。 Windows Server が実行されている VM の場合、Site Recovery ではボリューム シャドウ コピー サービス (VSS) が使用されます。 また、Site Recovery では、Linux のアプリ整合性スナップショットもサポートされます。ただし、そのためにはカスタム スクリプトを実装する必要があります。 このスクリプトは、アプリ整合性スナップショットを適用する際にモビリティ エージェントによって使用されます。

  注意

  Linux が実行されている Azure Stack Hub VM のアプリ整合性スナップショットの実装について詳しくは、「Site Recovery に関する一般的な質問」を参照してください。

保護対象として指定した Azure Stack Hub VM の各ディスクのデータは、Azure Storage 内の対応するマネージド ディスクにレプリケートされます。 このディスクには、ソース ディスクのコピーのほか、すべての復旧ポイントのクラッシュ整合性スナップショットとアプリ整合性スナップショットが格納されます。 Azure VM は、保護対象 Azure Stack Hub VM のレプリカとしての役割を果たします。フェールオーバーの過程で、Azure VM にマネージド ディスクをアタッチするときに、使用する復旧ポイントのクラッシュ コンシステント スナップショットまたはアプリ整合性スナップショットを選択することになります。

日常的な事業運営がなされている間は、保護対象ワークロードは Azure Stack Hub VM 上で実行され、そのディスクに対する変更が、モビリティ エージェント、プロセス サーバー、構成サーバー間の相互作用を通じて、指定した Azure Storage アカウントに絶えずレプリケートされます。 テスト、計画、または計画外のフェールオーバーを開始すると、Site Recovery では、対応する Azure Stack Hub VM のディスクのレプリカを使用して、Azure VM が自動的にプロビジョニングされます。

手動による手順と自動化された手順を含む復旧計画を作成することでフェールオーバーのオーケストレーションを行うこともできます。 後者を実装するには、カスタム PowerShell スクリプト、PowerShell ワークフロー、または Python 2 スクリプトで構成される Azure Automation Runbook を使用できます。

プライマリ サイトが再び利用できる状態になったら、レプリケーションの方向を反転する機能が Site Recovery にはあります。これにより、データの損失を生じることなく最小限のダウンタイムでフェールバックを実行することができます。 ただし Azure Stack Hub では、このアプローチが利用できません。 フェールバックを実行するためには、Azure VM のディスク ファイルをダウンロードして、それらを Azure Stack Hub にアップロードし、既存の VM または新しい VM にアタッチする必要があります。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。

Azure Stack Hub には、そのインフラストラクチャがもともと備えている回復性によって、ワークロードの可用性が高まる効果があります。 この回復性によって、Site Recovery で保護される Azure Stack Hub VM と、オンプレミスの Site Recovery インフラストラクチャの必須コンポーネント (構成サーバーとプロセス サーバーを含む) の高可用性が確保されます。

同様に、Site Recovery インフラストラクチャのクラウドベースのコンポーネントが備える回復性を使用することもできます。 既定では、Azure Recovery Services は geo 冗長です。つまりその構成は、定義済みのリージョン ペアを構成する Azure リージョンに自動的にレプリケートされます。 必要とされる回復性がローカル冗長で十分な場合、レプリケーション設定をローカル冗長に変更することもできます。 ただし、保護対象の項目がコンテナーに含まれている場合、このオプションは変更できないので注意してください。 同じ回復性オプションは、Standard パフォーマンス レベルの Azure Storage アカウントでも使用できますが、いつでも変更することができます。

この回復性のレベルは、ワークロード保護の範囲を拡張するソリューションを設計して実装することで、さらに向上できます。 これは、Site Recovery によって提供される付加価値です。 Azure Stack Hub 上で実行される Site Recovery のコンテキストでは、ワークロードの可用性について、主に次の 2 つの側面を詳しく吟味する必要があります。

• Azure へのフェールオーバー
• Azure Stack Hub へのフェールバック

回復ポイントの目標 (RPO) と目標復旧時間 (RTO) を軸としたディザスター リカバリー戦略を立てる際には、この両方の側面を考慮する必要があります。 RTO と RPO は、組織内の事業区分ごとに規定された継続性要件を表します。 RPO が意味するのは、データの可用性に影響するインシデントの発生後に許容できる最大データ損失を表す時間です。 RTO が意味するのは、事業機能の可用性に影響するインシデントの発生後、その事業機能を復帰させるために必要な時間として許容できる最大時間です。

Azure へのフェールオーバー

Site Recovery をベースに Azure Stack Hub VM を保護する場合、可用性に関する考慮事項の中核となるのは、Azure へのフェールオーバーです。 ワークロードの可用性を最大限に高めるためには、フェールオーバー戦略で、データの損失リスク (RPO) の最小化とフェールオーバー時間 (RTO) の最小化の両方のニーズに対応する必要があります。

データの損失リスクを最小化するには、次の点を考慮する必要があるでしょう。

• スケーラビリティとパフォーマンスの考慮事項に従って、スループットを最大化すると共に、レプリケーション トラフィックの待ち時間を最小化する。 詳細については、この記事の次のセクションを参照してください。
• データベース ワークロードについては、アプリ整合性復旧ポイントの頻度を増やす (復旧ポイントは 1 時間あたり最大 1 つまで)。 アプリ整合性復旧ポイントは、アプリ整合性スナップショットから作成されます。 アプリ整合性スナップショットでは、ディスク上とメモリ内のアプリ データがキャプチャされます。 このアプローチは、データの損失リスクが最小となる一方、大きな欠点が 1 つあります。 アプリ整合性スナップショットを作成するためには、ボリューム シャドウ コピー サービス (Windows の場合) またはカスタム スクリプト (Linux の場合) を使用して、ローカルにインストールされたアプリを休止する必要があります。 特にリソース使用率が高い場合、このキャプチャ プロセスによって、パフォーマンスが低下する可能性があります。 データベース以外のワークロードの場合、アプリ整合性スナップショットの頻度を低く設定することはお勧めしません。

フェールオーバー時間を最小限に抑える主な方法として、Site Recovery の復旧計画の使用が挙げられます。 復旧計画は、保護されるサーバーのフェールオーバーの順序を定義することによって、プライマリ サイトとセカンダリ サイトとの間でフェールオーバーを指揮するものです。 計画は、手動の手順や自動化タスクを追加することによってカスタマイズできます。 プロセスの一貫性と正確性を確保すること、そしてプロセスを繰り返し実行できるようにすること、また自動化できるようにすることが、その目的です。

復旧計画を作成するときは、保護されるサーバーをフェールオーバー用の復旧グループに割り当てます。 各グループ内のサーバーは、同時にフェールオーバーされます。 これを利用すれば、フェールオーバー プロセスを、より小さく管理しやすい単位に分割することができます。この単位は、外部依存関係によらずフェールオーバーできる一連のサーバーということになります。

フェールオーバー時間を最小化するには、復旧計画を作成する過程で、次の作業を行う必要があります。

• 同時にフェールオーバーする Azure Stack Hub VM のグループを定義する。
• Azure Stack Hub VM のグループ間の依存関係を定義して、最適なフェールオーバー順序を決める。
• 可能であればフェールオーバー タスクを自動化する。
• 必要に応じて、手動によるカスタム アクションを追加する。

アプリ固有のプロパティをキャプチャしたければ、復旧計画を定義し、復旧グループを作成します。 例として、SQL Server ベースのバックエンド、ミドルウェア コンポーネント、Web フロントエンドを含む従来の 3 層構造のアプリを考えてみましょう。 復旧計画を作成する場合、それぞれの層のサーバーの起動順序を制御できます。具体的には、SQL Server インスタンスを実行するサーバーをまずオンライン状態にし、ミドルウェア層のサーバーをオンライン状態にした後、Web フロントエンドをホストするサーバーを参加させます。 この順序であれば、最後のサーバーが起動した時点で、アプリは確実に動作します。 これは、3 つの復旧グループにそれぞれの層のサーバーを追加して復旧計画を作成すれば実現できます。

フェールオーバーと起動順序の制御に加え、復旧計画にはアクションを追加することもできます。 一般に、アクションには次の 2 種類があります。

• 自動。 このアクションには、次の 2 種類のタスクのいずれかを含んだ Azure Automation Runbook が使用されます。
  • Azure リソースのプロビジョニングと構成。たとえば、パブリック IP アドレスを作成して、Azure VM にアタッチされたネットワーク インターフェイスに関連付けます。
  • フェールオーバー後にプロビジョニングされた Azure VM 内で実行されるオペレーティング システムとアプリケーションの構成の変更。
• 手動。 このアクションは自動化をサポートせず、主に文書化を目的として復旧計画に追加されます。

Azure Stack Hub へのフェールバック

Site Recovery ベースのシナリオでは、フェールバックが適切に実装されていれば、データの損失は発生しません。 つまりフェールオーバー戦略の中心となるのは、フェールバック時間 (RTO) の最小化です。 ただし、前述したように、Azure Stack Hub へのフェールバック時に復旧計画を使用することはできません。 その代わりに、フェールバックには次の手順が含まれます。

1. ディザスター リカバリー環境の Azure VM を停止し、割り当てを解除します。
2. ダウンロードする VM にアタッチされた各マネージド ディスクの URI パラメーターを特定します。
3. 前の手順で特定した URI パラメーターによって識別される仮想ハード ディスク (VHD) ファイルをオンプレミス環境にダウンロードします。
4. Azure Stack Hub に VHD ファイルをアップロードします。
5. アップロードした VHD を新しい Azure Stack Hub VM または既存の Azure Stack Hub VM にアタッチします。
6. Azure Stack Hub VM を起動します。

フェールバック時間を最小化するための最適なアプローチは、それを自動化することです。

ワークロード固有の考慮事項

Site Recovery は、SharePoint、Exchange、SQL Server、Active Directory Domain Services (AD DS) など、Windows Server ベースのアプリやロールと統合されます。 これにより、次の機能を使用して、アプリレベルの保護と復旧を実装できます。

• SQL Server AlwaysOn 可用性グループ、Exchange データベース可用性グループ (DAG)、AD DS レプリケーションなど、アプリレベルのレプリケーション テクノロジとの連携
• 単層アプリケーションまたは多層アプリケーションに対するアプリ整合性スナップショット
• 豊富な自動化ライブラリ。運用環境ですぐに使えるアプリケーション固有のスクリプトが用意されています。これらのスクリプトをダウンロードして、復旧計画に統合することができます。

または、ワークロード固有のレプリケーション メカニズムを使用して、サイトレベルの回復性を確保することもできます。 これは、AD DS ドメイン コントローラー、SQL Server、Exchange (いずれもネイティブでレプリケーションをサポート) のディザスター リカバリーを導入する際によく使用される方法です。 そのためには、これらのワークロードのホストとなる Azure VM をディザスター リカバリー環境にプロビジョニングする必要があり、コストがかさみますが、次のようなメリットが得られます。

• フェールオーバーとフェールバックの所要時間が短縮される
• ワークロードレベルのフェールオーバーが簡素化され、サイトレベルのフェールオーバーが不要なシナリオにも対応できる

セキュリティ

ハイブリッドのシナリオで VM ベースのユーザー ワークロードに対するディザスター リカバリーを管理するためには、セキュリティに関してさらに別の考慮事項が必要となります。 それらの考慮事項は、次のカテゴリに分けることができます。

• 転送中の暗号化。 たとえば、保護された Azure Stack Hub VM、オンプレミスの Site Recovery コンポーネント、クラウドベースの Site Recovery コンポーネント間の通信などがあります。

  • 保護対象 VM にインストールされるモビリティ エージェントは、TLS (トランスポート層セキュリティ) 1.2 を使用して、絶えずプロセス サーバーと通信を行います。
  • 構成サーバーから Azure への通信と、プロセス サーバーから Azure への通信は、TLS 1.1 または 1.0 で行うことができます。 ハイブリッド接続のセキュリティのレベルを高めるためには、TLS 1.2 の使用を強制することを検討してください。

  注意

  TLS 1.2 を使用した暗号化の構成について詳しくは、「トランスポート層セキュリティ (TLS) のレジストリ設定」と「Windows の WinHTTP における既定の安全なプロトコルとして TLS 1.1 および TLS 1.2 を有効化する更新プログラム」を参照してください。

• 保存時の暗号化。 たとえば、ディザスター リカバリー サイトの Azure Storage と Azure VM が該当します。

  • Azure Storage は、すべてのストレージ アカウントについて、256 ビットの Advanced Encryption Standard を使用した暗号化が保存時に適用され、また、Federal Information Processing Standards 140-2 に準拠しています。 暗号化は自動的に有効となり、無効にすることはできません。 既定では、Microsoft によって管理されるキーが暗号化に使用されますが、ユーザーは、Azure Key Vault に格納された独自のキーを使用することもできます。
  • Azure VM のマネージド ディスクは、"Azure Managed Disks のサーバー側暗号化" とプラットフォーム マネージド暗号化キーを使用して自動的に暗号化されます。そのスナップショットにも、この暗号化が適用されます。

加えて、Site Recovery によってレプリケートされたディスクの内容をホストする Azure Storage アカウントに対して、制限付きアクセスを強制できます。 そのためには、Recovery Services コンテナーのマネージド ID を有効にし、Azure Storage アカウント レベルで、そのマネージド ID を次の Azure RBAC (Azure ロールベースのアクセス制御) ロールに割り当てます。

• Resource Manager ベースのストレージ アカウント (Standard パフォーマンス レベル):
  • Contributor
  • ストレージ BLOB データ共同作成者
• Resource Manager ベースのストレージ アカウント (Premium パフォーマンス レベル):
  • 共同作成者
  • ストレージ BLOB データ所有者

Azure Recovery Services コンテナーには、その内容をさらに保護するメカニズムが用意されています。たとえば、次の保護機能があります。

• Azure RBAC。 最小限の特権の原則に基づく責任の委任と分離が可能となります。 Site Recovery に関しては、その操作へのアクセスを制限する次の 3 つの組み込みロールがあります。
  • Site Recovery 共同作成者。 このロールには、Azure Recovery Services コンテナーでの Site Recovery の操作を管理するために必要なすべてのアクセス許可が付与されます。 ただし、このロールのユーザーが、コンテナーの作成や削除、他のユーザーへのアクセス権の割り当てを行うことはできません。 このロールは、Azure Stack Hub テナントのディザスター リカバリーを有効にして管理できるディザスター リカバリー管理者に最も適しています。
  • Site Recovery オペレーター。 この役割には、フェールオーバーとフェールバックの操作を実行して管理するアクセス許可があります。 このロールのユーザーは、レプリケーションの有効化または無効化、コンテナーの作成または削除、新しいインフラストラクチャの登録、他のユーザーへのアクセス権の割り当てを行うことはできません。 このロールは、実際の障害状況やそのシミュレーションにおいて、アプリケーション所有者および IT 管理者から指示されて、Azure Stack Hub VM をフェールオーバーできる、ディザスター リカバリー オペレーターに最も適しています。
  • Site Recovery 閲覧者。 このロールには、Site Recovery のすべての管理操作を追跡するためのアクセス許可が付与されます。 このロールは、保護された Azure Stack Hub VM の状態を監視し、必要な場合にサポート チケットの発行を担当する IT スタッフに最も適しています。
• Azure のリソース ロック。 読み取り専用ロックおよび削除ロックを作成して Site Recovery コンテナーに割り当てることで、不注意や悪意によってコンテナーが変更または削除されるリスクを軽減できます。
• 論理的な削除。 論理的な削除の目的は、不注意による削除や悪意による削除からコンテナーとそのデータを保護することです。 論理的な削除では、削除された内容の保持期間として 14 日間が追加され、その期間内であればデータを回復することができます。 コンテナーの内容が保持される追加の 14 日間に、コストは発生しません。 論理的な削除は既定で有効になっています。
• セキュリティに気を配る必要のある操作の保護。 Azure Recovery Services コンテナーでは、保護を無効にするなど、セキュリティに気を配る必要のある操作が試行されたときに、追加の認証レイヤーを有効にすることができます。 この特別な検証によって、そのような操作を実行しているのが、許可されているユーザーであるという確証が得られます。
• 疑わしいアクティビティの監視とアラート。 Azure Recovery Services には、コンテナーの操作に関して、セキュリティに気を配る必要のあるイベントを監視し、アラートを生成する機能が組み込まれています。

コスト最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

この記事で説明した Site Recovery ベースのディザスター リカバリー ソリューションのコストを検討する際には、オンプレミスとクラウドベースの両方のコンポーネントを考慮に入れる必要があります。 オンプレミス コンポーネントの価格は、Azure Stack Hub の価格モデルによって決まります。 Azure と同様、Azure Stack Hub には従量課金体系が用意されていて、マイクロソフト エンタープライズ契約およびクラウド ソリューション プロバイダー プログラムを通じて利用することができます。 この体系には、各 Windows Server VM の月額料金が含まれています。 既存の Windows Server ライセンスを使用できる場合は、コストをベース VM の価格にまで大幅に削減できます。 ただし、Site Recovery を使用する場合に必要となる Azure Stack Hub VM は通常、テナントあたり 1 つのみです。この VM は、テナント固有の構成サーバーを実装するために必要となります。

Azure に関連した料金は、次のリソースの使用から発生します。

• Azure Recovery Services。 この価格は、保護の対象となるインスタンスの数によって決まります。 最初の 31 日間は、すべての保護されたインスタンスで Site Recovery の料金が発生しないことに注意してください。

• Azure Storage です。 この価格は、次の要素の組み合わせによって決まります。

  • パフォーマンス レベル
  • 格納データの量
  • 送信データ転送の量
  • 実行される操作の量と種類 (Standard パフォーマンス レベルのみ)
  • データの冗長性 (Standard パフォーマンス レベルのみ)

• Azure ExpressRoute。 価格は、次の 2 つのモデルのいずれかに基づきます。

  • 無制限のデータ。 このモデルは月額料金を含んでいます (すべての受信および送信データ転送を含む)。
  • 従量制課金データ。 このモデルは月額料金を含んでいます。受信データ転送はすべて無料で、送信データ転送は GB 単位で課金されます。

  注意

  この評価には、サード パーティの接続プロバイダーから提供される物理接続のコストは含まれません。

• Azure VM。 Azure VM の価格は、次の 2 つの要素の組み合わせによって決まります。

  • コンピューティング コスト。 VM サイズとその稼働時間、オペレーティング システムのライセンス モデルによってコストが決まります。
  • マネージド ディスクのコスト。 ディスク サイズとパフォーマンス レベルによってコストが決まります。

  注意

  ハイドレーションのおかげで、通常の業務中は Azure VM を実行する必要がない点に注意してください。ワークロードは Azure Stack Hub で実行されているため、Site Recovery ベースの実装に伴うコンピューティング コストは大幅に削減されます。特に、従来のディザスター リカバリー ソリューションと比べるとその差は歴然です。

  注意

  リソースの価格は、Azure リージョンごとに異なります。

  注意

  価格の詳細については、「Azure の価格」を参照してください。

オペレーショナル エクセレンス

オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスの重要な要素の概要」を参照してください。

Site Recovery をベースとする Azure Stack Hub VM のディザスター リカバリーの管理容易性に関する主な考慮事項は次のとおりです。

• Azure Stack Hub への Site Recovery の実装
• フェールオーバーとフェールバックの手順
• 役割と責任の委任
• DevOps

Azure Stack Hub への Site Recovery の実装

小規模から中規模のシングルテナント環境で Azure Stack Hub に Site Recovery を実装するには、Azure portal で、Recovery Services コンテナーのグラフィカル インターフェイスに表示される手動のプロビジョニング プロセスに従います。 マルチテナント環境では、通常、テナントごとに別個の構成サーバー VM と別個の Recovery Services コンテナーをセットアップする必要があるため、導入プロセスの一部自動化を検討するとよいでしょう。 また、「モビリティ エージェントをプッシュ インストールできるようソース マシンを準備する」で説明されている手順に従って、モビリティ エージェントのデプロイを自動化することもできます。

フェールオーバーとフェールバックの手順

フェールオーバーの管理を省力化するために、保護の対象となるすべてのワークロードについて復旧計画を導入することを検討してください。 詳細については、この記事の「信頼性」セクションを参照してください。 フェールバック手順の管理を最適化するための推奨事項も紹介されています。

役割と責任の委任

Recovery を使用して Azure Stack Hub VM ベースのワークロードのディザスター リカバリーを計画して実装するには、通常、関係者の連携が必要となります。

• Azure Stack Hub オペレーターは、Azure Stack Hub のインフラストラクチャを管理します。包括的なディザスター リカバリー ソリューションを導入し、それらのリソースをテナントに提供するうえで必要な十分なコンピューティング、ストレージ、ネットワーク リソースを確保します。 また、アプリケーションとデータの所有者とも連携し、Azure Stack Hub にワークロードをデプロイするための最適なアプローチを判断します。
• ハイブリッド ディザスター リカバリー ソリューションを導入するために必要な Azure リソースは、Azure 管理者が管理します。
• Microsoft Entra リソース (Azure リソースのプロビジョニング、構成、管理に使われるユーザー オブジェクトとグループ オブジェクトを含む) は、Microsoft Entra 管理者が管理します。
• Azure Stack Hub テナントの IT スタッフは、フェールオーバーとフェールバックなど、Site Recovery の設計、実装、管理を行います。
• Azure Stack Hub のユーザーはそのワークロードについて、RPO と RTO の要件を規定し、ディザスター リカバリーを導入するためのリクエストを申請する必要があります。

保護と復旧に関連して、アプリケーションの所有者とオペレーターに帰属する役割と責任を明確に周知させる必要があります。 ユーザーには VM を保護する責任があります。 オペレーターには、Azure Stack Hub インフラストラクチャの運用状態に対する責任があります。

DevOps

Site Recovery を使用した VM レベルの復旧の構成は、主に IT 運用の責任になりますが、包括的なディザスター リカバリー戦略に組み入れる必要がある DevOps 固有の考慮事項もいくつかあります。 Azure Stack Hub は、IaC (Infrastructure-as-Code、コードとしてのインフラストラクチャ) 導入を支援し、VM ベースのアプリケーションやサービスをはじめとするさまざまなワークロードの自動デプロイを実現します。 この機能を使用することで、Site Recovery ベースのディザスター リカバリー シナリオのプロビジョニングを効率化し、マルチ テナント シナリオの初期設定を簡略化できます。

たとえば、同じ Azure Resource Manager テンプレートを使用して、VM ベースのワークロードを収容するために必要なすべてのネットワーク リソースを 1 回の連係した操作で Azure Stack Hub スタンプにプロビジョニングし、目的のアプリケーションを実現することができます。 ディザスター リカバリー サイトをプロビジョニングする際にも、それと同じテンプレートを使用して、対応する一連のリソースを Azure にプロビジョニングすることが可能です。 2 つの環境に違いを設けたければ、それぞれのケースで異なる値をテンプレート パラメーターに指定するだけで済みます。

パフォーマンス効率

パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。

Site Recovery を Azure Stack Hub にデプロイする計画を立てる場合、構成サーバーとプロセス サーバーに割り当てられる処理、ストレージ、ネットワーク リソースの量を検討する必要があります。 デプロイ後、処理やストレージの要件の変化に対応するために、Site Recovery コンポーネントをホストする Azure Stack Hub VM の推定サイズを調整することが必要な場合もあります。 サイズ調整には、基本的に 3 つの選択肢があります。

• 垂直スケーリングを実施する。 これには、構成サーバー (プロセス サーバーを含む) のホストとなる Azure Stack Hub VM のプロセッサ、メモリ、ディスク リソースのサイズや種類を変更することが含まれます。 リソース要件の見積もりには、次の表の情報を使用してください。

  表 1:構成サーバーとプロセス サーバーのサイズ要件

  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 台のマシン

• 水平スケーリングを実施する。 これには、保護対象 Azure Stack Hub VM の処理の需要に合わせて、プロセス サーバーがインストールされる Azure Stack Hub VM をプロビジョニングしたりプロビジョニング解除したりすることが含まれます。 一般に、ソース マシンが 200 台を超えるまでデプロイメントをスケーリングする必要がある場合や、合計日次変更率が 2 テラバイト (TB) を超える場合は、レプリケーション トラフィックの処理のために追加のプロセス サーバーが必要です。 追加のプロセス サーバーの数と構成を見積もる方法については、「プロセス サーバーのサイズの推奨事項」を参照してください。

• レプリケーション ポリシーを変更する。 これには、レプリケーション ポリシー (特にアプリ整合性スナップショット) のパラメーターを変更することが含まれます。

ネットワークの観点からは、さまざまな方法で、レプリケーション トラフィックに使用できる帯域幅を調整することができます。

• VM サイズを変更する。 ネットワークの最大帯域幅は、Azure Stack Hub VM のサイズによって決まります。 ただし、帯域幅の保証はないことに注意してください。 その代わり、VM は、そのサイズに規定された上限まで、使用可能な帯域幅を利用することができます。

• アップリンクのスイッチを交換する。 Azure Stack Hub システムは、さまざまなハードウェア スイッチをサポートしており、アップリンク速度には、いくつかの選択肢があります。 Azure Stack Hub クラスター ノードはそれぞれ、フォールト トレランスを目的に、Top-of-Rack スイッチへのアップリンクを 2 つ備えています。 アップリンクの半分は、重要なインフラストラクチャ用に割り当てられます。 その残りが、Azure Stack Hub のサービスとすべてのユーザー トラフィック用に共有された容量となります。 より高い速度でデプロイされたシステムは、レプリケーション トラフィックに使用できる帯域幅もそれだけ大きくなります。

  注意

  第 2 のネットワーク アダプターをサーバーに接続することでネットワーク トラフィックを分離することはできますが、Azure Stack Hub VM では、インターネットに向かうすべての VM トラフィックが同じアップリンクを共有します。 仮想ネットワーク アダプターを追加しても、物理トランスポート レベルではトラフィックが分離されません。

• Azure へのネットワーク接続のスループットを変更する。 大量のレプリケーション トラフィックに対応するには、Azure Stack Hub 仮想ネットワークと Azure Storage との間の接続に Azure ExpressRoute と Microsoft ピアリングを使用することを検討してください。 Azure ExpressRoute は、接続プロバイダーが提供するプライベート接続を介して、オンプレミスのネットワークを Microsoft クラウドに拡張します。 50 メガビット/秒 (Mbps) から 100 ギガビット/秒まで、さまざまな帯域幅の ExpressRoute 回線が用意されています。

  注意

  Azure Stack Hub シナリオへの Azure ExpressRoute の導入について詳しくは、「Azure ExpressRoute を使用して Azure Stack Hub を Azure に接続する」を参照してください。

• プロセス サーバー上のレプリケーション トラフィックのスロットリングを変更する。 プロセス サーバーをホストする VM 上のレプリケーション トラフィックに使用される帯域幅は、Microsoft Azure Recovery Services エージェントのグラフィカル インターフェイスから制御できます。 サポートされる機能として、たとえば、512 Kbps (キロビット数/秒) から 1,023 Mbps の範囲で帯域幅の値を調整することで、業務時間内と業務時間外の制限を設定することができます。 同じ構成は、Set-OBMachineSetting PowerShell コマンドレットを使用して適用することもできます。

• プロセス サーバーで保護対象 VM ごとに割り当てられたネットワーク帯域幅を変更する。 この設定を行うには、HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\Replication キー内の UploadThreadsPerVM エントリの値を変更します。 この値は、既定では 4 に設定されますが、使用できるネットワーク帯域幅に余裕があれば 32 に増やすこともできます。

このシナリオのデプロイ

前提条件

推奨ソリューションを実現するためには、次の前提条件を満たす必要があります。

• 次のような Site Recovery コンポーネントのすべてのクラウド コンポーネントをプロビジョニングおよび管理するのに十分なアクセス許可を持つ Azure サブスクリプションへのアクセス。

  • Azure Recovery Services コンテナー。Azure Stack Hub 運用環境のディザスター リカバリー サイトとして指定した Azure リージョンに置かれます。
  • Azure Storage アカウント。Azure Stack Hub VM からレプリケートされたディスクの内容をホストします。
  • ディザスター リカバリー環境を表す Azure 仮想ネットワーク。計画フェールオーバーまたは計画外のフェールオーバーの後、ハイドレートされた Azure VM がこの仮想ネットワークに接続されます。
  • テスト環境を表す隔離された Azure 仮想ネットワーク。テスト フェールオーバーの後、ハイドレートされた Azure VM がこの仮想ネットワークに接続されます。
  • オンプレミス環境、Azure 仮想ネットワーク、Azure Storage アカウントをつなぐ Azure ExpressRoute ベースの接続。Azure Storage アカウントは、保護対象 Azure Stack Hub VM のディスクからレプリケートされた内容を含む VHD ファイルのコピーをホストするために使用されます。

• Azure Stack Hub ユーザー サブスクリプション。 個々の Site Recovery 構成サーバーによって保護される Azure Stack Hub VM はすべて、同じ Azure Stack Hub ユーザー サブスクリプションに属している必要があります。

• Azure Stack Hub 仮想ネットワーク。 すべての保護対象 VM は、プロセス サーバー コンポーネントをホストする VM (既定では、構成サーバーの VM) に直接接続できる必要があります。

• 構成サーバーとプロセス サーバーのホストとなる Azure Stack Hub Windows Server VM。 この VM は、保護の対象となる Azure Stack Hub VM と同じサブスクリプションに属し、なおかつ同じ仮想ネットワークにアタッチされている必要があります。 加えて、この VM は次の条件を満たしている必要があります。

  • Site Recovery 構成サーバーのソフトウェア要件とハードウェア要件に準拠していること。
  • 外部接続のネットワーク要件のドキュメントに従っていること。

  注意

  構成サーバーとプロセス サーバーに使用されるストレージとパフォーマンスの詳細な考慮事項については、このアーキテクチャの中で詳しく後述します。

  • 内部接続の要件を満たしていること。 特に、保護の対象となる Azure Stack Hub VM は、次のサーバーと通信できる必要があります。

    • TCP ポート 443 (HTTPS) 受信を経由する構成サーバー (レプリケーションの管理用)
    • TCP ポート 9443 を経由するプロセス サーバー (レプリケーション データの配信用)。

    注意

    プロセス サーバーで外部接続と内部接続の両方に使用されるポートは、Site Recovery 統合セットアップの実行時に、プロセス サーバーを構成する過程で変更することができます。

• サポートされているオペレーティング システムのいずれかを実行する、保護の対象となる Azure Stack Hub VM。Windows Server オペレーティング システムを実行する Azure Stack Hub VM を保護するには、次の作業を行う必要があります。

  • 管理者権限で Windows アカウントを作成します。 このアカウントは、これらの VM で Site Recovery を有効にするときに指定できます。 プロセス サーバーでは、このアカウントを使用して Site Recovery Mobility Service をインストールします。 ワークグループ環境では必ず、対象となる Windows Server オペレーティング システムのリモート ユーザー アクセス制御を無効にしてください。リモート ユーザー アクセス制御を無効にするには、HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System キーのレジストリ エントリ LocalAccountTokenFilterPolicy の DWORD 値を 1 に設定します。
  • Microsoft Defender ファイアウォールで [ファイルとプリンターの共有] と [Windows Management Instrumentation] ルールを有効にします。

• Linux オペレーティング システムを実行する Azure Stack Hub VM を保護するには、次の作業を行う必要があります。

  • root ユーザー アカウントを作成します。 このアカウントは、これらの VM で Site Recovery を有効にするときに指定できます。 プロセス サーバーでは、このアカウントを使用して Site Recovery Mobility Service をインストールします。
  • 最新の openssh、openssh-server、openssl の各パッケージをインストールします。
  • Secure Shell (SSH) ポート 22 を有効にして実行します。
  • セキュア FTP サブシステムとパスワード認証を有効にします。

基本的な実装手順

Azure Stack Hub に Site Recovery ベースのディザスター リカバリーを実装する作業は、大まかに次のステージで構成されます。

1. Site Recovery で保護される Azure Stack Hub VM を準備します。 VM が前のセクションで説明した Site Recovery の前提条件を確実に満たすようにします。

2. Azure Recovery Services コンテナーを作成して構成する。 Azure Recovery Services コンテナーのセットアップを行い、レプリケートの対象を指定します。 Site Recovery のコンポーネントとアクティビティが構成され、コンテナーを使用して管理されます。

3. ソース レプリケーション環境を設定する。 Site Recovery 統合セットアップのバイナリをインストールし、それをコンテナーに登録して、Site Recovery の構成サーバーとプロセス サーバーをプロビジョニングします。

   注意

   追加のプロセス サーバーを Azure Stack Hub VM に実装するには、Site Recovery 統合セットアップを再実行します。

4. レプリケーション先の環境を設定する。 ディザスター リカバリー サイトのホストとなる Azure リージョンで、Azure Storage アカウントと Azure 仮想ネットワークを新たに作成するか、既存の Azure Storage アカウントと Azure 仮想ネットワークを選択します。 レプリケーション中は、保護対象 Azure Stack Hub VM のディスクの内容が Azure Storage アカウントにコピーされます。 フェールオーバー中、Site Recovery によって、保護されている Azure Stack Hub VM のレプリカとして機能する Azure VM が自動的にプロビジョニングされ、Azure 仮想ネットワークに接続されます。

5. レプリケーションを有効にします。 レプリケーション設定を構成し、Azure Stack Hub VM のレプリケーションを有効にします。 レプリケーションが有効になる各 Azure Stack Hub VM に、モビリティ サービスが自動的にインストールされます。 Site Recovery により、定義されたポリシー設定に従って各 Azure Stack Hub VM のレプリケーションが開始されます。

6. テスト フェールオーバーを実行します。 レプリケーションが設定されたら、想定どおりにフェールオーバーが動作することを、テスト フェールオーバーを実行して確認します。

7. 計画フェールオーバーまたは計画外のフェールオーバーを実行する。 テスト フェールオーバーに成功したら、いつでも Azure に対して計画フェールオーバーまたは計画外のフェールオーバーを実施することができます。 フェールオーバーに含める Azure Stack Hub VM は自分で指定することができます。

8. フェールバックを実行する。 フェールバックを実行する準備が整ったら、障害の発生した Azure Stack Hub VM に対応する Azure VM を停止し、そのディスク ファイルをオンプレミス ストレージにダウンロードして、それらを Azure Stack Hub にアップロードし、既存の VM または新しい VM にアタッチします。

まとめ

結論として、Azure Stack Hub は、さまざまな点で他の仮想化プラットフォームとは一線を画した製品です。 したがって、そのワークロードのビジネス継続性戦略には特別な考慮事項が伴います。 Azure サービスを使用すると、この戦略の設計と実装を簡略化できます。 この記事では、Microsoft Site Recovery を使用して接続型デプロイ モデルで Azure Stack Hub VM ベースのワークロードを保護する方法について詳しく見てきました。 そのアプローチがユーザーにもたらす利点は、Azure Stack Hub の回復性と管理の容易性、そして、Azure クラウドのハイパースケールとグローバル プレゼンスです。

ここで取り上げたディザスター リカバリー ソリューションは、あくまで、Azure Stack Hub の VM ベースのワークロードに注目したものです。 これは全体的なビジネス継続性戦略の一部にすぎません。全体的なビジネス継続性戦略では、他のタイプの Azure Stack Hub ワークロードや、その可用性に影響を及ぼすシナリオも考慮する必要があります。

次の手順

製品ドキュメント:

• Site Recovery の概要
• Azure Stack Hub の概要
• Microsoft Entra Connect とは
• Azure BLOB Storage とは
• Azure ExpressRoute とは
• Azure Virtual Network とは

Microsoft Learn モジュール：

• Azure Stack Hub
• Microsoft Entra ID を構成する
• ストレージ アカウントの構成
• 仮想ネットワークを構成する
• Azure ExpressRoute を設計して実装する
• Azure でサイトの回復ソリューションを設計する

関連リソース

• ハイブリッド アーキテクチャの設計
• Azure Stack Hub 上のファイルとアプリケーションのバックアップ
• Hybrid Connections (ハイブリッド接続)
• リモートおよびローカル ブランチ ワーカー用ディザスター リカバリーを使用したハイブリッド ファイル共有