次の方法で共有

Azure Stack Hub にデプロイされた VM の保護

  • [アーティクル]

この記事は、ユーザーによって Azure Stack Hub にデプロイされた IaaS 仮想マシン (VM) に対するデータ保護とディザスター リカバリー戦略を策定するためのガイドとして使用してください。

データ損失や長期のダウンタイムから保護するために、ユーザー アプリケーションとそのデータのバックアップと回復またはディザスター リカバリー計画を実装します。 各アプリケーションは、組織の包括的なビジネス継続性およびディザスター リカバリー (BC/DR) 戦略の一環として評価する必要があります。

IaaS VM の保護に関する考慮事項

ロールと責任

まず、保護と復旧に関連して、アプリケーションの所有者とオペレーターに帰属するロールと責任について明確に理解していることを確認します。

ユーザーには VM を保護する責任があります。 オペレーターには、Azure Stack Hub をオンラインかつ正常な状態に保つ責任があります。 Azure Stack Hub には、インフラストラクチャ サービスから内部サービス データをバックアップするサービスが含まれていますが、ユーザーが作成した VM、ユーザーまたはアプリケーション データを持つストレージ アカウント、ユーザー データベースなどのユーザー データは含まれていません。

アプリケーションの所有者/アーキテクト Azure Stack Hub オペレーター
- アプリケーション アーキテクチャをクラウド設計の原則に合わせます。
- 必要に応じて従来のアプリケーションを最新化して、クラウド環境に備えます。
- アプリケーションの許容される RTO と RPO を定義します。
- 保護する必要があるアプリケーション リソースとデータ リポジトリを特定します。
- アプリケーション アーキテクチャと顧客の要件に最適なデータとアプリケーションの回復方法を実装します。		 - organizationのビジネス継続性とディザスター リカバリーの目標を特定します。
- organizationの BC/DR 目標を満たすのに十分な Azure Stack Hub インスタンスをデプロイします。
- アプリケーション/データ保護インフラストラクチャを設計して運用する。
- マネージド ソリューションまたは保護サービスへのセルフサービス アクセスを提供します。
- アプリケーションの設計を理解し、保護戦略を推奨するには、アプリケーションの所有者またはアーキテクトと協力してください。
- サービスの復旧とクラウドの回復のためにインフラストラクチャのバックアップを有効にします。

ソースとターゲットの組み合わせ

データセンターまたはサイトの停止から保護する必要があるユーザーは、別の Azure Stack Hub や Azure を使用して、高可用性や迅速な回復を実現することができます。 ユーザーは、プライマリとセカンダリの場所を使用して、アクティブ/アクティブまたはアクティブ/パッシブの構成でアプリケーションを 2 つの環境にデプロイできます。 重要度の低いワークロードについては、ユーザーはセカンダリの場所の容量を使用して、アプリケーションをバックアップからオンデマンドで復元することができます。

1 つまたは複数の Azure Stack Hub クラウドをデータセンターにデプロイできます。 壊滅的な災害を乗り切るために、少なくとも 1 つの Azure Stack Hub クラウドを別のデータセンターにデプロイすることで、ワークロードをフェールオーバーし、予期しないダウンタイムを最小限に抑えることができます。 Azure Stack Hub が 1 つしかない場合は、Azure パブリック クラウドを復旧クラウドとして使用することを検討してください。 アプリケーションをどこで実行できるかは、政府の規制、企業のポリシー、および厳格な待機時間の要件によって決まります。 アプリケーションごとに適切な回復場所を柔軟に決定することができます。 たとえば、あるサブスクリプションのアプリケーションが別のデータセンターにデータをバックアップし、別のサブスクリプションのアプリケーションが Azure パブリック クラウドにデータをレプリケートするように設定できます。

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

アプリケーション所有者は、アプリケーションと組織で許容できるダウンタイムとデータ損失の量を判断することに主に責任があります。 許容できるダウンタイムと許容できるデータ損失を定量化することで、災害による組織への影響を最小限に抑える回復計画を作成できます。 各アプリケーションについて、次の点を考慮してください。

  • 目標復旧時間 (RTO)
    RTO は、インシデントの発生後に、アプリを使用不可状態にすることができる最大許容時間です。 たとえば、RTO が 90 分の場合、災害発生から 90 分以内にアプリを実行状態に復元できなければならないことを意味します。 RTO を短くする場合は、リージョンの障害から保護するために、2 つ目のデプロイをスタンバイ状態で継続的に実行します。
  • 目標復旧時点 (RPO)
    RPO は、障害発生時に許容できるデータ損失の最大期間です。 たとえば、1 時間ごとにバックアップされる単一データベースにデータを格納していて、他のデータベースへのレプリケーションがない場合、最大 1 時間のデータを失う可能性があります。

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

保護オプション

バックアップと復元

アプリケーションとデータセットをバックアップすることで、データの破損、偶発的な削除、災害などによるダウンタイムから迅速に復旧できます。 IaaS VM ベースのアプリケーションでは、ゲスト内エージェントを使用して、アプリケーション データ、オペレーティング システムの構成、およびボリュームに格納されているデータを保護できます。

ゲスト内エージェントを使用したバックアップ

ゲスト OS エージェントを使用した VM のバックアップには、通常、オペレーティング システムの構成、ファイル/フォルダー、ディスク、アプリケーション バイナリ、またはアプリケーション データのキャプチャが含まれます。

エージェントからアプリケーションを復旧するには、手動で VM を再作成し、オペレーティング システムをインストールして、ゲスト エージェントをインストールする必要があります。 その時点で、データをゲスト OS に復元することも、アプリケーションに直接復元することもできます。

停止した VM のディスク スナップショットを使用したバックアップ

バックアップ製品では、停止した VM に接続されている IaaS VM の構成とディスクを保護できます。 Azure Stack Hub API と統合されたバックアップ製品を使用して、VM 構成をキャプチャし、ディスク スナップショットを作成します。 アプリケーションの計画的ダウンタイムが可能な場合は、バックアップ ワークフローを開始する前に、VM が停止状態になっていることを確認してください。

実行中の VM のディスク スナップショットを使用したバックアップ

重要

現在、ポータルからのディスク スナップショットの使用は、実行中の状態の VM ではサポートされていません。 実行中の VM に接続されているディスクのスナップショットを作成すると、パフォーマンスが低下したり、VM 内のオペレーティング システムやアプリケーションの可用性に影響したりすることがあります。 ストレージ RP 増分スナップショット機能と統合するバックアップ ベンダー ソリューションを使用するか、計画されたダウンタイムがオプションではない場合はゲスト内エージェントを使用してアプリケーションを保護することをお勧めします。

スケールセットまたは可用性セット内の VM

一時的なリソースと見なされるスケールセットまたは可用性グループ内の VM は、特にアプリケーションがステートレスである場合は、VM レベルでバックアップしないでください。 スケールセットまたは可用性セットにデプロイされたステートフル アプリケーションの場合は、アプリケーション データ (たとえば、記憶域プール内のデータベースまたはボリューム) を保護することを検討してください。

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

データ損失またはダウンタイムを最小限にすることが必要なアプリケーションでは、データ レプリケーションをゲスト OS またはアプリケーション レベルで有効にして、データを別の場所にレプリケートすることができます。 Microsoft SQL Server などの一部のアプリケーションでは、レプリケーションがネイティブにサポートされています。 アプリケーションでレプリケーションがサポートされていない場合は、ゲスト OS のソフトウェアを使用してディスクをレプリケートするか、ゲスト OS にエージェントとしてインストールされるパートナー ソリューションを使用することができます。

この方法を使用すると、アプリケーションはあるクラウドにデプロイされ、データはオンプレミスの別のクラウドまたは Azure にレプリケートされます。 フェールオーバーがトリガーされた場合は、ターゲット内のアプリケーションを起動し、レプリケートされたデータにアタッチしてから、要求の処理を開始する必要があります。

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

許容できるダウンタイムが数秒または数分のみであるステートレス アプリケーションの場合、高可用性構成を検討してください。 高可用性アプリケーションは、すべてのインスタンスが要求を処理できるアクティブ/アクティブ トポロジ内の複数の場所にデプロイされるように設計されています。 ローカル ハードウェア障害に備えて、Azure Stack Hub インフラストラクチャでは、2 つのトップ オブ ラック スイッチを使用して物理ネットワークで高可用性が実装されます。 コンピューティング レベルの障害に備えて、Azure Stack Hub ではスケール ユニット内の複数のノードが使用されており、VM は自動でフェールオーバーされます。 VM レベルでは、ノードの障害によってアプリケーションが停止しないように、可用性セットのスケール セットまたは VM をご利用いただけます。 同じアプリケーションを、同じ構成のセカンダリの場所にデプロイする必要があります。 アプリケーションをアクティブ/アクティブにするには、ロード バランサーまたは DNS を使用して、使用可能なすべてのインスタンスに要求を送信します。

復旧不要

環境内の一部のアプリは、計画外のダウンタイムやデータ損失から保護する必要がない場合があります。 たとえば、開発やテストに使用される VM は、通常、復旧する必要はありません。 アプリケーションまたはデータセットの保護なしで済ませるかどうかは自由に決めることができます。

Azure Stack Hub のデプロイに関する重要な考慮事項を次に示します。

推奨 説明
データ センターに既にデプロイされている外部バックアップ ターゲットに VM をバックアップ/復元する 推奨 既存のバックアップ インフラストラクチャと運用スキルを活用します。 追加の VM インスタンスをすぐに保護できるように、バックアップ インフラストラクチャのサイズを必ず設定します。 バックアップ インフラストラクチャが、ソースに近接する場所にないことを確認します。 VM は、ソース Azure Stack Hub、セカンダリ Azure Stack Hub インスタンス、または Azure に復元できます。
Azure Stack Hub 専用の外部バックアップ ターゲットに VM をバックアップおよび復元する 推奨 新しいバックアップ インフラストラクチャを購入することも、Azure Stack Hub 専用のバックアップ インフラストラクチャをプロビジョニングすることもできます。 バックアップ インフラストラクチャが、ソースに近接する場所にないことを確認します。 VM は、ソース Azure Stack Hub、セカンダリ Azure Stack Hub インスタンス、または Azure に復元できます。
グローバル Azure または信頼できるサービス プロバイダーに VM を直接バックアップ/復元する 推奨 データのプライバシーと規制の要件を満たすことができるのであれば、グローバル Azure または信頼できるサービス プロバイダーにバックアップを保存できます。 復元時の運用エクスペリエンスの一貫性を得るために、サービス プロバイダーも Azure Stack Hub を実行しているのが理想的です。
別の Azure Stack Hub インスタンスに VM をレプリケートまたはフェールオーバーする 推奨 フェールオーバーの場合、アプリの長時間のダウンタイムを回避できるように、2 つ目の Azure Stack Hub クラウドを完全に稼働させる必要があります。
Azure または信頼できるサービス プロバイダーに VM を直接レプリケート/フェールオーバーする 推奨 データのプライバシーと規制の要件を満たすことができるのであれば、グローバル Azure または信頼できるサービス プロバイダーにデータをレプリケートできます。 フェールオーバー後の運用エクスペリエンスの一貫性を得るために、サービス プロバイダーも Azure Stack Hub を実行しているのが理想的です。
同一のバックアップ ターゲットによって保護されているすべてのアプリケーションをホストする同じ Azure Stack Hub 上にバックアップ ターゲットを配置します。 スタンドアロン ターゲット: 非推奨
バックアップ データを外部にレプリケートするターゲット: 推奨		 (操作の復元の最適化のために) Azure Stack Hub にバックアップ アプライアンスをデプロイする場合は、すべてのデータが外部のバックアップの場所に継続的にコピーされるようにする必要があります。
Azure Stack Hub ソリューションがインストールされている同じラックに物理バックアップ アプライアンスを配置する サポートされていません 現時点では、元のソリューションに含まれていない他のデバイスを、トップ オブ ラック スイッチに接続することはできません。

復元された IaaS VM に関する考慮事項

バックアップからマシンを復元した後、VM にいくつかの変更を行う必要があります。 これには以下が含まれます。

  • MAC アドレス
    仮想ネットワーク アダプターは、新しい MAC アドレスを取得します。 元の MAC アドレスのままにする方法はありません。
  • IP アドレス (IP address)
    お使いの VM に静的 IP が内部的に設定されている場合は、仮想ネットワーク アダプターでの内部 IP を、元のものと一致するように設定できます。 IP アドレスが使用されている可能性がある外部環境への S2S VPN が VNET にある場合、考慮することが必要になる場合があります。
  • 不要な成果物
    VM が VMware vSphere などの異なるプラットフォームでバックアップされた場合は、追加の手順に従って、ソースから不要な成果物をクリーンアップする必要があります。

次のステップ

この記事では、Azure Stack Hub にデプロイされたユーザー VM を保護するための一般的なガイドラインについて説明しました。 Azure サービスを使用してユーザー VM を保護する方法については、次を参照してください。