次の方法で共有

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

  • [アーティクル]

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

Azure Stack Hub 上の Azure Site Recoveryは、プライマリ サイトからセカンダリの場所への仮想マシン (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 データ ディスク) です。

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

  • Quota:

    • 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を実行するために消費される量。

  • 保護されたワークロードの要件。

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

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 が割り当てられています。

サービス 仮想コア メモリ ディスク サイズ
Azure Site Recovery 12 42 GB 1.4 TB

注意

これらのリソースは、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 * 250s) があるとします。 キャッシュ ストレージ アカウントは、通常、ディスクあたり数 KB から 500 MB です。

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

    重要

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

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

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

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

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

構成

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

結果

サポートされているディスクの数 スループットの合計 合計 OPS Bottleneck
68 136 MB/秒 68 storage
60 120 MB/秒 2048 storage
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)。

    • ランダムな間隔 (少なくとも 1 時間に 2 回) で生成される各 VM は、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