次の方法で共有

Azure Stack Hub にデプロイされた VM を保護する - ラグド

この記事は、ユーザーが Azure Stack Hub にデプロイする仮想マシン (VM) を保護するための計画を策定するためのガイドとして使用します。

データ損失と計画外のダウンタイムから保護するには、Azure Stack Hub 上の VM ベースのアプリケーションのデータ保護とディザスター リカバリー計画を実装します。 実装される保護計画は、ビジネス要件とアプリケーションの設計によって異なります。 この計画は、組織の包括的なビジネス継続性とディザスター リカバリー (BC/DR) 戦略によって確立されたフレームワークに従う必要があります。

アプリケーションの回復目標

組織がアプリケーションごとに許容できるダウンタイムとデータ損失の量を決定します。 ダウンタイムとデータ損失を定量化することで、組織に対する災害の影響を最小限に抑える復旧計画を作成できます。 アプリケーションごとに、次の点を考慮してください。

  • 目標復旧時間 (RTO)
    RTO は、インシデント後にアプリを使用できない最大許容時間です。 たとえば、RTO が 90 分の場合、障害発生から 90 分以内にアプリを実行中の状態に復元できる必要があります。 RTO が低い場合は、リージョンの停止から保護するために、2 つ目のデプロイをスタンバイ状態で継続的に実行し続けることができます。

  • 目標復旧時点 (RPO)
    RPO は、障害発生時に許容されるデータ損失の最大期間です。 たとえば、1 時間ごとにバックアップされ、他のデータベースへのレプリケーションがない 1 つのデータベースにデータを格納すると、最大 1 時間のデータが失われる可能性があります。

評価を実施して、各アプリケーションの RTO と RPO を定義します。

考慮すべきもう 1 つの重要なメトリックは 、平均復旧時間 (MTTR) です。これは、障害が発生した後にアプリケーションを復元するのにかかる平均時間です。 MTTR は、システムの経験値です。 MTTR が RTO を超えた場合、システムの障害により、定義された RTO 内でシステムを復元できないため、許容できないビジネス中断が発生します。

IaaS VM の保護オプション

バックアップと復元

VM ベースのアプリの最も一般的な保護スキームは、バックアップ ソフトウェアを使用することです。 通常、VM のバックアップには、オペレーティング システム、オペレーティング システムの構成、アプリケーション バイナリ、VM 内に含まれる永続的なアプリケーション データが含まれます。 バックアップは、ゲスト OS のエージェントを使用して、アプリケーション、OS、またはファイル システム/ボリュームをキャプチャすることによって作成されます。 もう一つの方法はエージェントレスであり、Azure Stack Hub API との統合を利用して VM の構成情報を読み取り、VM に接続されているディスクのスナップショットを取得することです。 Azure Stack Hub では、ハイパーバイザーからの直接バックアップはサポートされていないことに注意してください。

バックアップ戦略の計画

バックアップ戦略を計画し、スケール要件を定義するには、保護する必要がある VM インスタンスの数を定量化することから始めます。 システム内のすべての VM をバックアップすることは、アプリケーションを保護するための最も効果的な方法ではない可能性があります。 Azure Stack Hub では、スケール セットまたは可用性セット内の VM を VM レベルでバックアップしないでください。 これらの VM は一連の VM をスケールインまたはスケールアウトできるため、エフェメラルと見なされます。永続化する必要があるデータは、データベースやオブジェクト ストアなどの別のリポジトリに格納するのが理想的です。 スケールアウト アーキテクチャにデプロイされたアプリケーションに、永続化および保護する必要があるデータが含まれている場合は、アプリケーションによって提供されるネイティブ機能を使用するか、エージェントに依存することによって、アプリケーション レベルのバックアップが必要になります。

Azure Stack 上の VM をバックアップするための重要な考慮事項:

  • 分類
    • ユーザーが VM バックアップを選択するモデルを考えてみましょう。
    • アプリケーションの優先順位またはビジネスへの影響に基づいて、復旧サービス レベル アグリーメント (SLA) を定義します。
  • スケール
    • 多数の新しい VM をオンボーディングする場合 (バックアップが必要な場合) は、時間差バックアップを検討してください。
    • バックアップ データを効率的にキャプチャして送信できるバックアップ製品を評価して、ソリューションのリソース コンテンツを最小限に抑えます。
    • 増分バックアップまたは差分バックアップを使用してバックアップ データを効率的に格納するバックアップ製品を評価して、環境内のすべての VM での完全バックアップの必要性を最小限に抑えます。
  • 復元
    • バックアップ製品では、仮想ディスク、既存の VM 内のアプリ データ、または VM リソース全体と関連する仮想ディスクを復元できます。 必要な復元スキームは、アプリの復元方法によって異なります。 たとえば、VM または VM のセット全体を復元する代わりに、テンプレートから SQL サーバーを再デプロイしてからデータベースを復元する方が簡単な場合があります。

レプリケーション/手動フェールオーバー

復旧をサポートする別の方法は、別の環境にデータをレプリケートすることです。 データのスコープは、データベース レプリケーションなどのアプリケーション、エージェントを使用したゲスト OS のオペレーティング システム、または Azure Stack Hub API と統合することで VM レベルで行うことができます。 障害が発生した場合は、セカンダリ ロケーションへのフェールオーバーが必要です。 フェールオーバーは、SQL 可用性グループの場合や、エージェントまたはクラスター テクノロジを使用したゲスト OS レベル、または保護製品を使用した VM レベルで、アプリケーションによってネイティブに処理できます。

高可用性/自動フェールオーバー

ノード間で高可用性を実現するために、高可用性をネイティブにサポートするアプリケーションまたはクラスター ソフトウェアに依存するアプリケーションは、1 つの Azure Stack Hub 内の VM のグループ全体または複数の Azure Stack Hub インスタンスにデプロイできます。 いずれの場合も、アプリケーション トラフィックが正しくルーティングされるようにするには、一定のレベルの負荷分散が必要です。 この構成では、アプリケーションは障害から自動的に回復できます。 ローカルハードウェア障害の場合、Azure Stack Hub インフラストラクチャは、物理インフラストラクチャに高可用性とフォールト トレランスを実装します。 コンピューティング レベルの障害の場合、Azure Stack Hub は N-1 構成でスケール ユニット内の複数のノードを使用します。 VM レベルでは、可用性とスケール セットは、ノード レベルのアンチアフィニティを保証するために、スケール ユニット内の各ノードを障害ドメインとしてモデル化し、ノードの障害が分散アプリケーションを停止しないようにします。

保護なし

一部のアプリケーションには、永続化する必要があるデータがない場合があります。 たとえば、開発とテストに使用される VM は通常、復旧する必要はありません。 もう 1 つの例は、障害が発生した場合に CI/CD パイプラインから再デプロイできるステートレス アプリケーションです。 VM を不必要に保護しないように、保護を必要としないアプリケーションを特定することが重要です。

パートナー製品