次の方法で共有

Azure Site Recovery を使用した容量計画

組織として、計画的および計画外の停止中にデータの安全性、アプリの可用性、ワークロードをオンラインで維持するビジネス継続性とディザスター リカバリー (BCDR) 戦略を採用することが不可欠です。

Azure Site Recovery on Azure Stack Hub では、プライマリ サイトからセカンダリの場所への仮想マシン (VM) ワークロードのレプリケーションを通じて、組織のデータの安全性、アプリケーションの可用性、障害時のワークロードをサポートできるサービスを提供します。 たとえば、プライマリ サイトで停止が発生した場合は、セカンダリの場所にフェールオーバーしてアプリにアクセスします。 プライマリ サイトが再び実行されるとすぐに、そのサイトにフェールバックできます。 詳細については、「 Site Recovery について」を参照してください。

2 つの Azure Stack Hub スタンプ間で VM のレプリケーションを有効にするには、次の 2 つの環境を構成します。

  • ソース 環境:
    • テナント VM が実行されている Azure Stack Hub スタンプ。
  • ターゲット 環境:
    • Azure Site Recovery リソース プロバイダーが実行される場所。

2 つの Azure Stack Hub スタンプにわたる VM のレプリケーションのスナップショット。

ビジネス継続性とディザスター リカバリー計画の成功に不可欠な要素は、キャパシティ プランニングです。 容量計画中に考慮すべきいくつかの要因があります。

  • 保護する特定のワークロードの目標復旧時間 (RTO) と目標復旧ポイント (RPO)。

  • ワークロードとアプリケーションの特性:

    • 各 VM 内でデータが変更される頻度。
    • 生成または削除されるデータの量
    • アプリケーション設計の外観とその他の要素はどのようになっていますか?

  • VM のサイズ、ディスクの数、および各 VM が他の VM にどのように関連付けられているか。

    • 複数の VM を必要とするソリューションの場合は、それらの VM を開始する必要がある順序を理解してください。

  • ソース環境とターゲット環境の間のネットワーク帯域幅。 このコンポーネントは、RPO に影響を与える可能性があります。

これらの各点は重要であり、BCDR 計画を構築する際に大きな影響を及ぼします。

次のセクションでは、Azure Site Recovery の観点から考慮すべき主なポイントを示します。 各 BCDR プランは異なり、保護する予定のワークロードの詳細に基づいています。 したがって、この一覧は包括的ではありません。

ソースに関する考慮事項

ソース環境では、Azure Stack Hub によって Azure Site Recovery VM アプライアンスが実行されます。 VM は、Azure Stack Hub ユーザー サブスクリプションで実行される Standard_DS4_v2 (8 vCPU、28 Gb メモリ、32 個のデータ ディスク) VM です。

ソース環境では、次の領域を考慮してください。

  • クォータ:

    • Azure Site Recovery VM アプライアンスを作成するための十分なクォータが必要です。 プラン全体に応じて、1 つ以上必要です。

  • Azure Site Recovery VM アプライアンスのストレージ:

    • Azure Site Recovery VM アプライアンス自体には、その VM サイズによって定義されたデータ要件があります。

    • 容量を計画するときは、アプライアンス VM にフェールバックと再保護メカニズムを実行するための十分なストレージがあることを確認します。

      注

      ストレージの制限がある場合、フェールバックと再保護はエラー "内部エラーが発生しました " というメッセージで失敗する可能性があります。 ユーザーは、アプライアンスのイベント ログを確認して、実際の Azure Resource Manager エラーを確認する必要があります。 詳細については、「 Azure Site Recovery の既知の問題」を参照してください。

  • 帯域幅:

    • 初期レプリケーションでは、高帯域幅の使用量が生成されます。
    • 各 VM の変更は、レプリケーション ポリシーとアプリケーションの種類に応じてレプリケートされます。

ターゲットに関する考慮事項

ターゲット環境では、容量計画について考慮すべき 2 つの要素があります。

  • Azure Site Recovery サービスの要件: ワークロードを必ずしも保護することなく、Azure Site Recovery を実行するために使用される量。

  • 保護されたワークロードに関する要件。

ターゲット環境では、ソース (コンテナーごとに 1 つのアプライアンス) から VM を保護するために、Site Recovery アプライアンスごとに 1 つの Azure Site Recovery コンテナーを作成する必要があります。 これは容量の観点から見た制限ではありませんが、環境全体の設計を計画する際には考慮する必要があります。

Azure Site Recovery RP リソース

Azure Stack Hub に Azure Site Recovery をインストールするには、Site Recovery リソース プロバイダー (RP) をインストールする必要があります。

注

Microsoft.SiteRecovery-1.2301.2216.2287 では、Azure Stack Hub 上の Azure Site Recovery では、依存関係として Event Hubs は必要ありません。

Azure Stack Hub に Azure Site Recovery をインストールする 3 つのサービスのスクリーンショット。

このサービスは Azure Stack Hub 管理者サブスクリプションで作成され、Azure Stack Hub 自体によって管理されるため、構成は必要ありません。 ただし、他のサービスと同様に、これらのリソースはメモリ、ストレージを消費し、特定の vCPU が割り当てられています。

Service 仮想コア 記憶 ディスク サイズ
Azure Site Recovery (アジュールサイトリカバリー) 18 64 GB 384 GB

注

これらのリソースは、Azure Stack Hub の管理側の Azure Stack Hub サービスです。 インストールされると、プラットフォームはこれらのリソースを管理します。

保護されたワークロード

BCDR 計画を作成するときは、保護されたワークロードのすべての側面を考慮してください。 次の一覧は完全ではなく、開始点として扱う必要があります。

  • VM サイズ、ディスクの数、ディスク サイズ、IOPS、データチャーン、作成された新しいデータ。

  • ネットワーク帯域幅に関する考慮事項:

    • 差分レプリケーションに必要なネットワーク帯域幅。
    • Azure Site Recovery がソース環境から取得できる、ターゲット環境でのスループットの量。
    • 一度にバッチ処理する VM の数。 この数は、指定された時間内に初期レプリケーションを完了するための推定帯域幅に基づいています。
    • 特定の帯域幅に対して実現できる RPO。
    • 低い帯域幅がプロビジョニングされている場合の目的の RPO への影響。

  • ストレージに関する考慮事項:

    • 初期レプリケーションに必要なデータ量。
    • これらの期間中に、保持される復旧ポイントの数と、保護された VM ごとにデータがどのように増加するか。
    • ユーザーが十分な割り当てを行えるように、ターゲットの Azure Stack Hub ユーザー サブスクリプションに割り当てる必要があるクォータの数。
    • レプリケーション用のキャッシュ ストレージ アカウント。

  • コンピューティングに関する考慮事項:

    • フェールオーバーが発生すると、ターゲットの Azure Stack Hub ユーザー サブスクリプションで VM が開始されます。 これらの VM リソースを開始するには、十分なクォータ割り当てを行う必要があります。
    • VM の保護中に、保護された VM がソース環境でアクティブになっている場合、ターゲット環境で vCPU やメモリなどの VM 関連リソースは使用されません。 これらのリソースは、テスト フェールオーバーなどのフェールオーバー プロセス中にのみ関連します。

Azure Stack Hub 上の Azure Site Recovery のスコープについては、特に使用されるキャッシュ ストレージ アカウントの計算の開始点を次に示します。

  1. フェールオーバーがある場合は、通常の操作中に、レプリケートされたディスクの数に平均 RPO を乗算します。 たとえば、(2 MB * 250 秒) があるとします。 キャッシュ ストレージ アカウントは、通常、ディスクあたり数 KB から 500 MB です。

  2. 最悪のシナリオが発生した場合、フェールオーバーがある場合は、1 日の平均 RPO でレプリケートされたディスクの数を乗算します。

    Von Bedeutung

    Azure Site Recovery の一部が機能していないが、他の部分が動作している場合は、Azure Site Recovery がタイムアウトを決定する前に、ストレージ アカウントに最大 1 日の差分が存在する可能性があります。

  3. 新しい VM にフェールバックします。 各バッチのディスク サイズの合計を計算します。

    • ターゲットが空のディスクであるため、ターゲット VM を適用するには、ディスク全体をキャッシュ ストレージ アカウントにコピーする必要があります。
    • 関連するデータはコピー後に削除されますが、すべてのディスク サイズの合計でピーク使用量が表示される可能性があります。

保護しようとしているソリューションの詳細に基づいて BDCR プランを作成します。

次の表は、環境で実行されるテストの例です。 この分析情報を使用して、独自のアプリケーションのベースラインを取得できますが、各ワークロードは異なります。

コンフィギュレーション

ブロック サイズ スループット/ディスク
2 MB 2 MB/秒
64 KB 2 MB/秒
8 KB 1 MB/秒
8 KB 2 MB/秒

結果

サポートされているディスクの数 スループットの合計 合計 OPS Bottleneck
68 136 MB/秒 68 ストレージ
六十 120 MB/秒 2048 ストレージ
28 28 MB/秒 3584 Azure Site Recovery の CPU とメモリ
16 32 MB/秒 4096

注

8 Kb は、Azure Site Recovery がサポートするデータの最小ブロック サイズです。 8 Kb 未満の変更は 8 Kb として扱われます。

さらにテストするために、一貫した種類のワークロードを生成しました。たとえば、ディスクあたり最大 1 MB/秒の 8 KB のブロックで一貫したストレージ変更が行われます。 このシナリオは、実際のワークロードでは、変更が 1 日のさまざまな時間に発生する可能性がある場合や、さまざまなサイズのスパイクが発生する可能性があることを考えると、あり得ません。

これらのランダム パターンをレプリケートするために、次のシナリオもテストしました。

  • 同じ Azure Site Recovery VM アプライアンスを介して保護された 120 個の VM (80 Windows、40 Linux)。

    • 各 VM はランダムな間隔で、少なくとも 1 時間に 2 回、ランダムなデータブロックを生成し、5 つのファイルにまたがって合計 5 GB のデータを生成します。

    • Azure Site Recovery サービスの負荷が低から中の 120 台の VM すべてに対してレプリケーションが成功しました。

      注

      これらの数値はベースラインとしてのみ使用する必要があります。 これらは必ずしも直線的にスケーリングされるとは限りません。 同じ数の VM の別のバッチを追加すると、最初の VM よりも影響が少なくなる可能性があります。 結果は、使用されるワークロードの種類に大きく依存します。

計画とテストの方法

アプリケーションとソリューションのワークロードには、特定の目標復旧時間 (RTO) と目標復旧時点 (RPO) の要件があります。 効果的なビジネス継続性とディザスター リカバリー (BCDR) 設計では、ソリューション固有のメカニズムを使用するため、これらの要件を満たすプラットフォーム レベルの機能の両方を利用します。 BCDR 機能を設計するには、プラットフォーム ディザスター リカバリー (DR) の要件をキャプチャし、設計で次のすべての要因を考慮します。

  • アプリケーションとデータの可用性に関する要件:

    • 各ワークロードの RTO と RPO の要件。
    • アクティブ/アクティブおよびアクティブ/パッシブの可用性パターンに対するサポート。

  • パフォーマンスのためのコンポーネントの近接性を備えた、フェールオーバー用の複数リージョンデプロイのサポート。 停止時には、アプリケーションの操作において、機能が制限されたり、パフォーマンスが低下したりする可能性があります。

    注

    アプリケーションは、ネイティブに実行することがわかっているか、複数の Azure Stack Hub 環境で実行できる特定のコンポーネントを持っている可能性があります。 その場合は、Azure Site Recovery を使用して、この機能を持たないコンポーネントを含む VM のみをレプリケートできます。たとえば、フロントエンドまたはバックエンドの種類のソリューションで、Azure Stack Hub 環境全体にフロントエンドをデプロイできます。

  • 運用ネットワークと DR ネットワークで重複する IP アドレス範囲を使用することは避けてください。

    • IP アドレスが重複する運用ネットワークと DR ネットワークにはフェールオーバー プロセスが必要であり、アプリケーションのフェールオーバーが複雑化し、遅延するおそれがあります。 可能であれば、すべてのサイトへの同時接続を提供する BCDR ネットワーク アーキテクチャを計画します。

  • ターゲット環境のサイズ設定:

    • ソースとターゲットを 1:1 の方法で使用している場合は、ターゲット環境に少し多くのストレージを割り当てます。 これは、ディスク ブックマークの履歴が発生する方法が原因です。 この割り当ては、データへの変更のみが含まれるため、2 倍の増加ではありません。 データの種類と予想される変更、およびターゲットに 1.5 倍から 2 倍の記憶域を持つレプリケーション ポリシーによって、フェールオーバー プロセスに問題がないことを確認します。
    • ターゲットの Azure Stack Hub 環境を複数の Azure Stack Hub ソースのターゲットとすることを検討できます。 この場合は、全体的なコストを削減しますが、特定のワークロードがダウンしたときに何が起こるかを計画する必要があります。たとえば、どのソースに優先順位を付ける必要があります。
    • ターゲット環境を他のワークロードの実行に使用する場合は、BCDR プランにこれらのワークロードの動作を含める必要があります。 たとえば、ターゲット環境で開発/テスト VM を実行し、ソース環境で問題が発生した場合は、ターゲット上のすべての VM をオフにして、保護された VM を起動するための十分なリソースを確保できます。

BCDR をテストし、定期的に検証する必要があります。 これを行うには、テスト フェールオーバー プロセスを使用するか、ワークロード全体を移動してフローをエンドツーエンドで検証します。

次のステップ

Azure Stack Hub 上の Azure Site Recovery