Azure Site Recovery 概要と、可能なこと・不可能なこと

ASR – その意義と概要

Public Cloud として Azure を選択するメリット (Advantage) の 1 つに、Microsoft が長年培ってきたオンプレミス・テクノロジーとの融合 (ハイブリッド技術) がある。クラウドへの本格参入ができない古い体質の業界や企業では、オンプレミスにある資産を Public Cloud に移すのは不可能かもしれないが、こうした安価でスケーラブルなクラウドが、いざというときのリカバリー サイトとして利用できるなら現実味があるだろう。
Azure Site Recovery (ASR) は、そうした「現実解」のニーズに対応した Public Cloud のサービスと言って良い。

Azure Site Recovery (ASR) を介することで、オンプレミスのマシン イメージを Azure 上に Replication し、いざオンプレミス環境に障害が発生した際には、このバックアップされたイメージ (.vhd) を元に、すぐに Azure 上にマシンを稼働して (Failover して)、VPN や閉域網などを経由して企業内から継続的にサービスを利用可能にする。
Primary の復旧が完了したら、Reverse Replicate といって、稼働中の (Azure 上の) リカバリー サイトを元の Primary サイトへ戻すための仕組み (要するに “Failback”) も提供する。


(From Microsoft Hybrid Cloud Blog)

この Azure Site Recovery (ASR) について、よくある疑問点 (利用時の初歩的な質問) を以下の 3 つの観点でまとめたので、これから導入を検討される方は参考にしていただきたい。
後述の通り、ネットワークまわりをどう設計するかは、充分な考察が必要だ。

ASR – よくある疑問 (まとめ)

対象のソース

Primary として選べるソースタイプとしては、以下が利用可能。
なお、現在、Windows Server 2016 の Physical Server はサポートされていないので注意してほしい。(いずれ対応されると思うが)

  • Physical Machine (On-Premise)
  • Hyper-V 上の Guest VM (On-Premise)
  • VMWare 上の VM (On-Premise)
  • Azure 上の VM

いまでは Azure 上の VM などもリカバリー可能だが、ASR は、当初はオンプレミス上の環境をクラウドにリカバリーして事業継続するためのサービスとして登場しており、ASR を中継することで、On-Premise to Azure だけでなく、Azure を中継した On-Premise to On-Premise のリカバリーに使うことも可能だ。

ネットワーク

ASR ではいろいろなアーキテクチャが考えられるが、ここでは話が混乱しないよう On-premises to Azure で考えてみよう。

上述の通り、Failover 後は、企業内からリカバリー先のマシン (今回の場合、Azure 上のマシン) を利用するため、Azure 上の Recovery Site と On-Premise との間はあらかじめ同じネットワークに入れることになる。(あらかじめ Azure の Site-to-Site VPN や ExpressRoute で Recovery 先と接続しておく。)
このように、ASR 利用時は、DR (Disaster Recovery) 時も踏まえた充分なトポロジー設計が必要になる。

例えば、Azure では、同一ネットワーク上に同一のアドレス空間を持たせることはできないので、Recovery された VM は一般に IP アドレスが変更される。このため、リカバリー対象のマシンで DNS サーバーとの接続が必要になり、Azure の Virtual Network (VNet) 上の DNS Server としてオンプレ側の DNS Server を指定したり、あるいは Failover の際に DNS Server も Replication するなど方針を決める必要があるだろう。(Failover 先の Azure VM で IP Address を同じにすることも不可能ではないが、ASR がこうした仕組みを備えているわけでないため、自身でこうした Subnet Failover (転換処理) を実装することになる。)

ASR は、上述の通りイメージ ベースでの Recovery になるので、すべてを ASR に頼るのではなく、データベース (RDB), AD (Active Directory) などでは、下記のようなコンポーネントが持つ Recovery テクノロジーを組み合わせることも検討する。(Multi-Tier アプリケーションのように複数台のマシンで状態の一貫性が必要になる場合には、Multi VM Consistency という機能を有効化することで一貫性を維持できる。)

また、オンプレミスから Azure への Replication (delta による差分反映など) では一般にインターネット (Azure に向けての inbound の https ポート) が使われるが、以下も考慮しておこう。

  • トラフィック送信にインターネットを使わず、Azure ExpressRoute Public Peering を使うよう構成することも可能
  • ただし、現在、トラフィック送信に Site-to-Site VPN を使うことは不可能

一方、Failback では、一般にインターネット回線は利用できないので注意してほしい。Failback の場合は、Azure 側から On-Premise への https による inbound アクセスがおこなわれるため、Azure Network (Azure VNet) からの VPN か ExpressRoute を介して On-Premise につなぐことになるためだ。(Failback も計画に含めるなら、戻す際のネットワーク構成も考慮する必要がある。)

ネットワーク帯域については、ASR Capacity Planner が使用できる。(この ASR Capacity Planner は、Azure 上の ASR 設定の途中でリンクが表示され、ダウンロードを促すようになっている。)

運用手順

ASR では Failover は自動でおこなわれないので、運用・監視は自身でおこない (または、他製品を組み合わせて)、UI (Azure Portal), スクリプト, SDK などから能動的に Failover を呼び出す。(Failover を呼び出すと、Recovery 先でリカバリー イメージを元に VM が起動する。)
なお、OMS と組み合わせた場合は、既に構成のための機能が OMS に Built-in されている。

下記の 3 種類の Failover が提供されていて、いわゆる障害発生時に呼び出す「Unplanned Failover」は、他の 2 つと異なり Failover 時に最新の Delta Replication は作成しない。(その時点でとられている最新のイメージを元に Failover する。)

  • Test Failover
  • Planned Failover
  • Unplanned Failover

Failover 後の処理は、Azure Automation Runbook を使うことができる。VNet 等の Azure Resource の構成や、VM 内でのセットアップスクリプトの実行などは、Azure Automation Runbook を組み合わせて構成する。

Microsoft Azure : Add Azure Automation runbooks to recovery plans
https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-runbook-automation

 

ここでは ASR 導入の際の初歩的な疑問を中心にまとめたが、細かなトポロジーや FAQ は以下が参考になるので是非参照してほしい。

Azure Site Recovery support matrix (On-premises to Azure)
https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-support-matrix-to-azure

Azure Site Recovery FAQ
https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-faq

 

Advertisements