Azure Site RecoveryとHAクラスタを併用した構成と設定手順

こんにちは。
サイオステクノロジー國政です。プリセールスを担当しております。

Azure Backup編は弊社が提唱するHAクラスター構成である、WSFCとDataKeeperをAzure上に構築、その後運用に入るまでに考える事柄の一つである障害への備えとしてAzure Backupの有用性を考えてみました。

本後編では、もう一つの障害対策として Azure Site Recoveryについて、そもそもどんな機能か、どう設定するるとよいのかを手順交え紹介してみます。
また最後に、Azure BackupとAzure Site Recoveryの違いをまとめ、活用可能性を考えてみたいと思います。

Azure Site Recoveryとは?

SiteRecovery概要には、BCP対策として決まったタイミングで違う場所へレプリケーションを行い、有事の際には違うサイトでサービスの継続が可能と書かれています。有効な活用例としてはオンプレミスの構成をAzureへレプリケーションするケースも一般的なようですが、今回はAzure東日本リージョンで構築したWSFC＋DataKeeperの冗長化構成を東アジアリージョンへAzure to AzureのAzure Site Recoveryを試してみたいと思います。

Azure東日本サイトから東アジアサイトへのAzure Site Recovery設定の大まかな流れ

1. Backup and Site Recovery(OMS)コンテナを作成
2. レプリケーションの設定
   ・レプリケーション元の仮想マシンの選択
   ・レプリケーション先の設定(リソースグループ、ストレージアカウント、可用性セット、仮想ネットワーク)
3. レプリケーション設定を有効にする事により東アジアリージョン内の緑枠内の-asr付きリソースが作成される
4. テストフェイルオーバの実施(本番環境への影響はありません)
   ・レプリケーション先で仮想マシン、ネットワーク、ストレージ等起動に必要な物が揃った状態となるフェイルオーバー後にどういった動作となるか確認ができるので、調整が必要な場合はここで調整します
5. 上記4の手順で行ったテストフェイルオーバをクリーンナップ
6. 実際のフェイルオーバーを実施
7. 再保護をかける

レプリケーションの設定

手順3の初期レプリケーションが終わった状態のSite Recoveryの設定画面です、Replicated itemsが3となっている事はレプケーション対象の仮想マシンが3台である事を意味します。

この状態でリソース一覧を確認します。

レプリケーション設定を有効にする

可用性セット、仮想ネットワーク、ストレージアカウントの後ろに asr(Azure Site Recovery)がついたリソースが、レプリケーション先リージョンで自動的に作成されている事が確認できます。今回の設定では東アジアリージョンです。
これはフェイルオーバーした先で利用するモジュールとなります。東日本リージョンと東アジアリージョンでどう変化しているか確認します。

仮想ネットワーク:東日本リージョン アドレス範囲　10.0.0.0/24 　DNSサーバー10.0.0.100
仮想ネットワーク:東アジアリージョン アドレス範囲　10.0.0.0/24 　DNSサーバー10.0.0.100
どちらのリージョンの仮想ネットワークも同じアドレス空間である事が一つのポイントです。

可用性セット

高可用性セット東日本 障害ドメイン2 更新ドメイン5 Virtual Machines 3　　　　　　　　　　　　
高可用性セット東日本 障害ドメイン2 更新ドメイン5 Virtual Machines 0

レプリケーションの設定が終わった段階では以下のように東アジアリージョン内で箱が用意されたイメージです。

テストフェイルオーバの実施

では、続いてテストフェイルオーバを実施してみましょう。この操作では本番環境(東日本リージョン)への影響なしで実際のフェイルオーバーのシミュレートができます。

操作は保護された仮想マシンを選択し、テストフェイルオーバをクリックします。(今回は3台の仮想サーバー全部に行います)
指定できる内容としては、”リカバリーポイント”と仮想ネットワークです。今回の場合は、リカバリーポイントは最新で行います。

テストフェイルオーバが完了すると、仮想マシンには-testとついて区別されます。この状態でフェイルオーバー後の仮想マシンの状態を確認する事ができます。

テストフェイルオーバをクリーンナップ

確認(シュミレーション)が済んだ段階でテストフェイルオーバーのクリーンナップを行います。

STATUS列がProtectedになっていればOKです。

実際のフェイルオーバーを実施

続いて実際に東日本リージョンから東アジアリージョンへフェイルオーバーを実施します。 テストフェイルオーバとの違いは「リカバリーポイントの選択」と、「フェイルオーバー前に仮想マシンをシャットダウンします」のチェックボックスにチェックを入れておく事です。

約6分ほどでフェイルオーバーは完了、東日本サイトの仮想マシンは停止、東アジアサイトの仮想マシンは起動となる
(画面は仮想マシンをダッシュボードにピン留めしているので表示されています)

再保護をかける

東アジアでリソースが起動した後は、そのリソースを保護する必要があります。
3台の仮想マシンに対して再保護(Re-Protect)を実施し、保護状態にします。

Re-Protectを実施すると、元の仮想マシン(東日本リージョン)は自動的に削除（※）されます。
そして、レプリケーションの方向も東アジアリージョンから東日本リージョンに変更されています。

（※）現在は元の仮想マシンが削除されない仕様に変更になっています。詳細は下記Microsoft社のページでご確認ください。
Azure to Azure の DR 対策でフェールオーバー後に再保護を実施する際、 Azure 仮想マシンが削除されない機能改善について

フェイルオーバー後の状態について確認します。

・3台のサーバーについては、Windows Server のシャットダウンイベントの追跡ツールの入力がありました。

WSFCの管理画面(フェールオーバークラスターマネージャー画面)内の一番下部分のファイル共有監視がNGとなっていました。
ただし、操作を行う右画面から「オンラインにする」の操作で即時復旧しました。

DataKeeperについても自動的に起動しており、WSFCに正しく追従している事が確認できた。

SQLサーバーも正しく起動しており、フェイルオーバー前の状態(レコード1000件登録)も同じ状態で起動している事が確認できました。

各仮想マシンの固定IP等も正しく復元されており、WSFC＋DataKeeperのシステムとしては、サービスも自動で開始されています。
少し見ただけでは東日本リージョンから東アジアリージョンに移っただけのように見えます。もう一点この検証環境で見えた点は、Public IPの設定を東日本サイトでは有効、動的に設定していたが、東アジアサイトへフェイルオーバーした際にはPublic IPの設定は無効となっていました。

これはテストフェイルオーバでも事前に確認した動作なので、特に問題はないが、違った動きをしたとして記載しておく。この点などはLBを前段に入れるとか、固定IPを持っておくとか要件に合わせて設計すれば大きな問題ではないでしょう。

さて、最後に前編と後編で2つのアプローチでWSFC＋DataKeeperのAzure上での障害対策を考えてみました。

（※）現在は元の仮想マシンが削除されない仕様に変更になっています。詳細は下記Microsoft社のページでご確認ください。
Azure to Azure の DR 対策でフェールオーバー後に再保護を実施する際、 Azure 仮想マシンが削除されない機能改善について

今回は未検証となった事項についての所見です。

マニュアルや実際の動作から考察した所、
Azure Backup ≒ VSS
Azure Site Recovery ≒ Hyper-V レプリカに近い動作をしているように見受けられます。

本構成がファイルサーバ用途であれば、Azure Backupは仮想マシンだけでなくファイル単位での復元も可能なようです(弊社未検証)。Azure Site RecoveryはMSSQLをHAクラスタ構成で利用する場合、その構成のまま丸ごと他リージョンにレプリケーションされています。切り替え(フェイルオーバー)自体は手動で行う事になりますが、全体的な振る舞いとしては、クラスタシステムを ”そのまま” “まるごと” 違うリージョンで起動できる恩恵は、バックアップやリストアから復元する作業と比較して復旧までの時間も大幅な短縮が見込めると思います。

ぜひAzure上でHAクラスタ構成をお考えで、障害に対する備えもお考えの方は、Azure純正で利用可能なAzure BackupやAzure Site Recoveryのご利用も検討されてはいかがでしょうか。