この記事は、Azure Stack Hub にデプロイされたユーザーがデプロイした IaaS 仮想マシン (VM) のデータ保護とディザスター リカバリー戦略の策定に役立つガイドとして使用します。
データ損失とダウンタイムの延長から保護するには、ユーザー アプリケーションとそのデータのバックアップ復旧またはディザスター リカバリー計画を実装します。 各アプリケーションは、組織の包括的なビジネス継続性とディザスター リカバリー (BC/DR) 戦略の一部として評価する必要があります。
IaaS VM の保護に関する考慮事項
ロールと責任
まず、保護と回復のコンテキストで、アプリケーションの所有者とオペレーターに起因する役割と責任を明確に理解していることを確認します。
ユーザーは VM を保護する責任があります。 オペレーターは、Azure Stack Hub をオンラインで正常に保つ責任があります。 Azure Stack Hub には、インフラストラクチャ サービスから内部サービス データをバックアップするサービスが含まれており、ユーザー作成の VM、ユーザーまたはアプリケーション データを含むストレージ アカウント、ユーザー データベースなどのユーザー データは含 まれません 。
| アプリケーション所有者/アーキテクト | Azure Stack Hub オペレーター |
|---|---|
| - アプリケーション アーキテクチャをクラウド設計の原則に合わせます。 - 必要に応じて従来のアプリケーションを最新化し、クラウド環境用に準備します。 - application. の許容可能な RTO と RPO を定義する- 保護する必要があるアプリケーション リソースとデータ リポジトリを特定します - アプリケーション アーキテクチャと顧客の要件に最適なデータとアプリケーションの回復方法を実装します。 |
- 組織のビジネス継続性とディザスター リカバリーの目標を特定します。 - 組織の 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 時間のデータが失われる可能性があります。
もう 1 つのメトリックは 平均復旧時間 (MTTR) です。これは、障害が発生した後にアプリケーションを復元するのにかかる平均時間です。 MTTR は、システムの経験値です。 MTTR が RTO を超えると、定義された RTO 内でシステムを復元できないため、システムの障害によって許容できないビジネス中断が発生します。
保護オプション
バックアップと復元
アプリケーションとデータセットをバックアップすると、データの破損、誤った削除、または災害によるダウンタイムから迅速に復旧できます。 IaaS VM ベースのアプリケーションの場合、ゲスト内エージェントを使用して、ボリュームに格納されているアプリケーション データ、オペレーティング システムの構成、およびデータを保護できます。
ゲスト内エージェントを使用したバックアップ
ゲスト OS エージェントを使用して VM をバックアップするには、通常、オペレーティング システムの構成、ファイル/フォルダー、ディスク、アプリケーション バイナリ、またはアプリケーション データのキャプチャが含まれます。
エージェントからアプリケーションを回復するには、VM を手動で再作成し、オペレーティング システムをインストールし、ゲスト エージェントをインストールする必要があります。 その時点で、データはゲスト OS に復元することも、アプリケーションに直接復元することもできます。
停止した VM のディスク スナップショットを使用したバックアップ
バックアップ製品は、停止した VM に接続されている IaaS VM 構成とディスクを保護できます。 Azure Stack Hub API と統合されたバックアップ製品を使用して、VM 構成をキャプチャし、ディスク スナップショットを作成します。 アプリケーションの計画的なダウンタイムが可能な場合は、バックアップ ワークフローを開始する前に VM が停止状態になっていることを確認してください。
VM を実行するためのディスク スナップショットを使用したバックアップ
Von Bedeutung
現在、ポータルからのディスク スナップショットの使用は、実行中の状態の VM ではサポートされていません。 実行中の VM に接続されているディスクのスナップショットを作成すると、パフォーマンスが低下したり、VM 内のオペレーティング システムまたはアプリケーションの可用性に影響を与えたりする可能性があります。 ストレージ RP 増分スナップショット機能と統合するバックアップ ベンダー ソリューションを使用するか、計画されたダウンタイムがオプションでない場合はゲスト内エージェントを使用してアプリケーションを保護することをお勧めします。
スケール セットまたは可用性セット内の VM
一時的なリソースと見なされるスケール セットまたは可用性グループ内の VM は、特にアプリケーションがステートレスである場合は、VM レベルでバックアップしないでください。 スケール セットまたは可用性セットにデプロイされたステートフル アプリケーションの場合は、アプリケーション データ (記憶域プール内のデータベースやボリュームなど) を保護することを検討してください。
レプリケーション/手動フェールオーバー
最小限のデータ損失または最小限のダウンタイムを必要とするアプリケーションの場合、ゲスト OS またはアプリケーション レベルでデータ レプリケーションを有効にして、データを別の場所にレプリケートできます。 Microsoft SQL Server などの一部のアプリケーションでは、レプリケーションがネイティブにサポートされています。 アプリケーションがレプリケーションをサポートしていない場合は、ゲスト OS のソフトウェアを使用してディスクをレプリケートするか、ゲスト OS にエージェントとしてインストールするパートナー ソリューションを使用できます。
この方法では、アプリケーションは 1 つのクラウドにデプロイされ、データはオンプレミスまたは 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 も実行しているため、復元時の運用エクスペリエンスの一貫性が得られます。 |
| VM を別の Azure Stack Hub インスタンスにレプリケート/フェールオーバーする | 推奨 | フェールオーバーの場合は、アプリの長時間のダウンタイムを回避できるように、2 つ目の Azure Stack Hub クラウドを完全に運用する必要があります。 |
| VM を Azure または信頼されたサービス プロバイダーに直接レプリケート/フェールオーバーする | 推奨 | データのプライバシーと規制の要件を満たす限り、データをグローバル Azure または信頼できるサービス プロバイダーにレプリケートできます。 サービス プロバイダーも Azure Stack Hub を実行しているのが理想的です。そのため、フェールオーバー後の運用エクスペリエンスの一貫性が得られます。 |
| 同じ Azure Stack Hub にバックアップ ターゲットをデプロイします。このターゲットは、同じバックアップ ターゲットによって保護されているすべてのアプリケーションもホストします。 | スタンドアロン ターゲット: バックアップ データを外部にレプリケートするターゲット 推奨されません: 推奨 |
バックアップ アプライアンスを Azure Stack Hub にデプロイすることを選択した場合 (運用復元を最適化するために)、すべてのデータが外部バックアップの場所に継続的にコピーされるようにする必要があります。 |
| Azure Stack Hub ソリューションがインストールされているのと同じラックに物理バックアップ アプライアンスをデプロイする | サポートされていません | 現時点では、元のソリューションに含まれていないラック スイッチの上部に他のデバイスを接続することはできません。 |
復元された IaaS VM に関する考慮事項
バックアップからマシンを復元した後、VM にいくつかの変更を加える必要があります。 これらには次のものが含まれます。
-
[MAC アドレス]
仮想ネットワーク アダプターは、新しい MAC アドレスを取得します。 元の MAC アドレスを保持する方法はありません。 -
IPアドレス
VM に静的 IP が内部的に設定されている場合は、仮想ネットワーク アダプターの内部 IP を元の IP と一致するように設定できます。 VNET に、IP アドレスが使用されている可能性がある外部環境への S2S VPN があるかどうかを検討する必要がある場合があります。 -
不要なアーティファクト
VM が VMware vSphere などの別のプラットフォームにバックアップされている場合は、追加の手順に従って、ソースから不要な成果物をクリーンアップする必要があります。
次のステップ
この記事では、Azure Stack Hub にデプロイされたユーザー VM を保護するための一般的なガイドラインを示しました。 Azure サービスを使用してユーザー VM を保護する方法については、次を参照してください。