致命的なデータ損失からの復旧

Azure Stack Hub は、データセンターで Azure サービスを実行し、1 つのラックにインストールされているノードが 4 つ程度の小さい環境でも実行できます。 これに対し Azure は、40 を超えるリージョンで、各リージョンにある複数のデータセンターと複数のゾーンで実行されます。 ユーザー リソースは、複数のサーバーやラック、データセンター、リージョンにまたがることができます。 現在、Azure Stack Hub では、クラウド全体を 1 つのラックにしかデプロイできません。 この制限によって、自社データセンターでの致命的なイベントの危険や、製品の重大なバグによるエラーといった危険に、クラウドをさらしてしまうことになります。 障害が発生すると、Azure Stack Hub インスタンスはオフラインになります。 このデータはすべて、本質的に回復できるものではありません。

データ損失の根本原因によっては、インフラストラクチャ サービスを 1 つ修復するだけで済む場合もあれば、Azure Stack Hub インスタンス全体の復元が必要な場合もあります。 同じ場所や別の場所にある別のハードウェアに復元する必要がある場合もあります。

このシナリオでは、障害が発生し、プライベート クラウドを再デプロイする場合の、インストール全体の復旧に取り組みます。

シナリオ	データ損失	考慮事項
障害または製品のバグによって引き起こされた、致命的なデータ損失からの復旧	全インフラストラクチャ、ユーザー データ、アプリ データ	異なる OEM への復元が可能 異なる世代のハードウェアへの復元が可能 スケール ユニット数が異なるノードへの復元が可能 ユーザーのアプリとデータは、インフラストラクチャ データとは別に保護されている

Workflows

Azure Stack Hub を保護する過程は、インフラストラクチャとアプリおよびテナントのデータを別々にバックアップすることから始まります。 このドキュメントでは、インフラストラクチャを保護する方法について説明します。

すべてのデータが失われるという最悪の事態の場合、Azure Stack Hub の復旧とは、その Azure Stack Hub のデプロイに固有のインフラストラクチャ データとすべてのユーザー データを復元するプロセスを指します。

復元

致命的なデータ損失が発生しても、ハードウェアが引き続き使用できる場合は、Azure Stack Hub の再デプロイが必要になります。 再展開の際に、ストレージの場所と、バックアップのアクセスに必要な資格情報を指定できます。 このモードでは、復元の必要があるサービスを指定する必要はありません。 展開ワークフローの一部として、インフラストラクチャ バックアップ コントローラーによってコントロール プレーンの状態が挿入されます。

ハードウェアが使用不能になる障害が発生した場合、再デプロイは新しいハードウェアでのみ可能になります。 代替ハードウェアを注文してから、データセンターに到着するまでの間、再展開には数週間かかることがあります。 コントロール プレーン データの復元は、いつでも可能です。 ただし、再デプロイされたインスタンスのバージョンが、最後のバックアップで使用されたバージョンよりも 2 バージョン以上大きい場合、復元はできません。

展開モード	開始ポイント	終了ポイント
クリーン インストール	ベースライン ビルド	OEM が Azure Stack Hub をデプロイして、サポートされている最新のバージョンに更新します。
回復モード	ベースライン ビルド	OEM が回復モードで Azure Stack Hub をデプロイし、利用可能な最新のバックアップに従って、バージョンのマッチング要件を処理します。 OEM が最新のサポート バージョンに更新して、展開を完了します。

バックアップ内のデータ

Azure Stack Hub では、クラウド回復モードというタイプのデプロイがサポートされます。 このモードは、障害や製品のバグによってソリューションが回復不能になったときに Azure Stack Hub を復旧する場合にのみ、使用します。 このデプロイ モードでは、ソリューションに格納されているユーザー データは一切復旧されません。 この展開モードの範囲は、次のデータの復元に限定されます。

• 展開の入力
• 内部 ID サービス データ
• フェデレーション ID の構成 (ADFS デプロイ)
• 内部の証明機関によって使用されるルート証明書
• Azure Resource Manager 構成のユーザー データ (例: サブスクリプション、プラン、オファー、リソース グループ、タグ、ストレージ クォータ、ネットワーク クォータ、コンピューティング リソースなど)
• Key Vault のシークレットと資格情報コンテナー
• RBAC のポリシー割り当てとロール割り当て

展開の際、ユーザーのサービスとしてのインフラストラクチャ (IaaS) リソースや、サービスとしてのプラットフォーム (PaaS) リソースは、復旧されません。 これらの損失には、IaaS VM、ストレージ アカウント、BLOB、テーブル、ネットワーク構成などが含まれます。 クラウドを復旧する目的は、デプロイの完了後に、オペレーターとユーザーがポータルに再度サインインできることを確実にすることです。 再度サインインしても、ユーザーにリソースは一切表示されません。 ユーザーのサブスクリプションと、管理者によって定義されていた元のプラン、オファー、ポリシーが復元されています。システムに再度サインインするユーザーは、障害が起きる前の元のソリューションであったものと同じ制約で操作することになります。 作業者は、クラウドの復旧が完了したら、付加価値 RP、サード パーティ製 RP、および関連するデータを手動で復元できます。

バックアップの検証

ASDK を使用してバックアップをテストし、データが有効であり、使用可能であることを確認できます。 詳細については、「ASDK を使用して Azure Stack のバックアップを検証する」を参照してください。

次のステップ

インフラストラクチャ バックアップ サービスの使用について、ベスト プラクティスを説明します。