Azure Stack Hub のバックアップ/ディザスタリカバリを理解する

この記事の内容

Azure Stack Hub はパブリッククラウドに近い基盤であり、従来の仮想基盤と同じアプローチでの DR は取れない
復旧には「OEM」「オペレーター」「ユーザー」の3者が段階的に関与し、フルリカバリには数週間〜数ヶ月かかる場合がある
DR の選択肢は「単一サイト」「Azure パブリッククラウドへのフェイルオーバー」「複数 Azure Stack Hub による冗長構成」の3つ
VM バックアップはゲストエージェントベースが主流であり、Azure Stack Hub 自体のバックアップとは別物
現時点では冗長構成はすべて自分たちで設計・実装する必要がある

Azure Stack Hub における DR の基本的な考え方

Azure Stack Hub を運用するうえで、まず理解しておくべき重要なドキュメントとして、Microsoft が公開している「Azure Stack Hub for Business Continuity and Disaster Recovery」があります（2019年11月公開）。

このドキュメントで繰り返し強調されているのは、Azure Stack Hub は従来の仮想基盤とは異なるという点です。Azure Stack Hub はパブリッククラウドに近い「クラウド基盤」として捉える必要があります。

インフラストラクチャーとユーザーリソースの責任分界

Azure Stack Hub の DR を考えるにあたって、責任の所在を明確に分ける必要があります。

Azure Stack Hub インフラストラクチャー：オペレーター（導入・運用担当者）が責任を持つ領域
ユーザーリソース（VM、データベース、ストレージアカウントなど）：ユーザーが責任を持つ領域

同一の担当者が両方を管理しているケースもありますが、その場合でも役割を分けて考えることが重要です。

Azure Stack Hub の構造

Azure Stack Hub は以下のような階層構造で成り立っています。

スケールユニット（4〜16ノードのクラスター相当）
リージョン
Azure Stack Hub クラウド（データセンター内に設置）

この構造の特性上、ホストレベルでバックアップを取得してリストアするという従来の仮想基盤的なアプローチは取れません。また、スケールユニットを離れたサイトに分散配置するような構成も標準ではサポートされていません。

フルリカバリに要する時間と3段階の復旧フェーズ

Azure Stack Hub の復旧には、複数の関係者が段階的に関与します。

Phase 0：ハードウェア復旧（OEM 担当）

ハードウェアレベルで障害が発生した場合、新しいハードウェアの調達・設置・クラウド自体のリストアは OEM（ハードウェアメーカー） が担当します。ユーザーや SI が独自に実施することはできません。

この Phase 0 だけで、数週間単位の時間がかかる可能性があります。

Phase 1：PaaS サービスの復旧（オペレーター担当）

ハードウェアと Azure Stack Hub クラウド基盤が復旧した後、オペレーターが追加で展開していた PaaS サービスをリストアします。

Phase 2：ユーザーリソースの復旧（ユーザー担当）

最終的に、ユーザーが VM やデータベースなどのリソースを復旧させます。

このように 3段階の工程を経るため、フルリカバリには非常に長い時間がかかることを前提に SLA を設計する必要があります。

冗長性の仕組み

Azure Stack Hub 自体にはノードレベル・システムレベル・スケールユニットレベルでの冗長性が備わっています。ユーザー側でも VM や PaaS サービスを冗長構成で作成することは可能です。

ただし、「データセンター全体が大規模な災害に遭う」といったシナリオになると、ディザスタリカバリの検討が必要になります。

DR 戦略の3つの選択肢

選択肢1：単一 Azure Stack Hub での運用

同一の Azure Stack Hub 内で復旧を完結させる構成です。ハードウェアレベルの大規模障害が発生した場合は、OEM によるリカバリが必要となり、復旧に非常に時間がかかります。

選択肢2：Azure パブリッククラウドへのフェイルオーバー

Azure Stack Hub での運用を通常時とし、有事の際は Azure パブリッククラウドで立ち上げる構成です。他の仮想基盤でも一般的な考え方であり、Azure Stack Hub でも同様のアプローチが取れます。

選択肢3：複数 Azure Stack Hub による冗長構成

最もコストはかかりますが、最も短い復旧時間を実現できます。2台の Azure Stack Hub をネットワーク的に接続し、アクティブ-アクティブ構成やアクティブ-スタンバイ構成を組むことが可能です。

例えば、サイト A とサイト B それぞれに Azure Stack Hub を配置し、SQL データベースをスケールユニットレベルで非同期レプリケーションする構成を取れば、サイト A が完全に停止した場合でもサイト B で継続稼働できます。

バックアップのベストプラクティス

VM バックアップ

Azure Stack Hub 上の VM バックアップには、ゲストエージェントを使用したバックアップが一般的です。

手順の概要は以下のとおりです。

VM にゲストエージェントをインストール
バックアップシステムで定期バックアップを取得
リストア時は VM を再作成 → OS インストール → ゲストエージェントインストール → バックアップからリストア

ゲストエージェントベースのバックアップであれば、Azure Stack Hub 上の VM にも同じ手法が適用できます。

なお、ディスクスナップショットを利用したバックアップは推奨されません（ドキュメント上でも注意が記載されています）。

Azure Stack Hub インフラストラクチャーバックアップ

Azure Stack Hub 自体のバックアップ機能も存在します。これは管理者ポータルから有効化するものです。

このバックアップに含まれる内容は以下のとおりです。

ロールベースのアクセス制御（RBAC）設定
プランとオファー
事前定義されたクォータとストレージクォータ
Key Vault のシークレット

含まれないもの：

テナント VM
ストレージリソース（VM のデータなど）

このバックアップはあくまで Azure Stack Hub 基盤自体の復旧を目的としたものであり、VM データは別途バックアップが必要です。

バックアップの保存先

Azure Stack Hub のバックアップ（インフラストラクチャーバックアップ、VM バックアップともに）は、Azure Stack Hub の外側に保存することが推奨されます。具体的にはオンプレミスのファイルサーバーや Azure パブリッククラウドへの保存が考えられます。

Azure Site Recovery との組み合わせ

Azure Site Recovery を使用して、Azure Stack Hub 上の VM を Azure パブリッククラウド上にレプリケーションして冗長構成を組むことも可能です。ドキュメントも整備されており、DR 戦略の一つとして選択肢に加えられます。

パブリック Azure との違いに注意

パブリック Azure では、リージョン内のデータセンター冗長性や VM の自動再配置、ストレージの複数拠点保存などが Microsoft 側で透過的に管理されています。

しかし Azure Stack Hub にはこれらの仕組みはなく、冗長化はすべて自分たちで設計・実装する必要があります。パブリック Azure と同じ水準の可用性を期待している場合は認識の齟齬が生じやすいため、注意が必要です。

まとめ

Azure Stack Hub のバックアップ/DR は、パブリック Azure と比べて自分たちで設計・実装しなければならない範囲が非常に広く、また障害時の復旧フローも OEM・オペレーター・ユーザーの3者による多段階プロセスとなります。

重要なポイントを整理すると以下のとおりです。

従来の仮想基盤的な DR アプローチは取れない。クラウド基盤として捉えること
フルリカバリには数週間〜数ヶ月を要する可能性があるため、SLA の設定には現実的な見積もりが必要
DR 戦略は「単一サイト」「Azure パブリッククラウド併用」「複数 Azure Stack Hub」の3択から要件に応じて選択する
VM バックアップはゲストエージェントベースが推奨。インフラバックアップとは別物と理解する
バックアップデータは Azure Stack Hub の外部に保存すること

将来的には複数の Azure Stack Hub 間でパブリック Azure のようなレプリケーション機構が提供されることへの期待もありますが、現時点では上記の現実を踏まえたうえで、きちんとした構成を自ら設計することが求められます。