Azure上に構成したSANLess Clusters構成の運用 – Azure Site Recovery編

前編、後編の検証概念図
Pocket

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

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

後編ではもう一つの障害対策としてAzure Backupではなく Azure Site Recoveryを使った場合はどうか、最後にAzure BackupとAzure Site Recoveryの違いなどもSANLess Cluster構成の場合を念頭に考えてみたいと思います。

前編、後編の検証概念図

前編、後編の検証概念図

Azure Site Recoveryとは?

SiteRecovery概要には、BCP対策として決まったタイミングで違う場所へレプリケーションを行い、有事の際には違うサイトでサービスの継続が可能と書かれています。有効な活用例としてはオンプレミスの構成をAzureへレプリケーションするケースも一般的なようですが、今回はAzure東日本リージョンで構築したSANLess Clusters構成を東アジアリージョンへ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の設定画面

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

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

リソース一覧を確認

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

東日本リージョンと東アジアリージョンでどう変化しているか確認

 

東日本リージョンと東アジアリージョンでどう変化しているか確認2

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

高可用性セット

高可用性セット

高可用性セット2

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

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

レプリケーションの設定が終わった段階

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

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

テストフェイルオーバが完了すると、仮想マシンには-testとついて区別されます

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

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

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

 

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

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

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

実際に東日本リージョンから東アジアリージョンへフェイルオーバーを実施

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

約6分ほどでフェイルオーバーは完了、東日本サイトの仮想マシンは停止、東アジアサイトの仮想マシンは起動となる

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

Re-Protectを実施すると、元の仮想マシン(東日本リージョン)は自動的に削除されます。

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

レプリケーションの方向も東アジアリージョンから東日本リージョンに変更されています。

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

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

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

WSFCの管理画面(フェールオーバークラスターマネージャー画面)内の一番下部分のファイル共有監視がNGとなっていました。

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

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

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

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

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

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

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

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

   Azure Backup   Azure Site Recovery(Azure to Azure) 
 手軽さ   Azureに標準で搭載されている機能なので手軽   Azureに標準で搭載されている機能なので手軽   
 費用  インスタンスが50GB以下\510円+利用したストレージ料金が最小費用    保護するインスタンス毎に \2,550円
それ以外にStorage、トランザクション、送信データ転送などが課金対象となる
 復旧時間  データ量にもよるが、1時間~2時間ほどは必要か  初期レプリケーションは40分ほど、フェイルオーバーにかかった時間は6分ほど(弊社テスト環境調べ)
 復旧作業  リストア後にネットワーク体系の変更を行う必要がある  事前のテストフェイルオーバにて確認可能、AutomationScriptと連携させるとある程度自由に復旧が可能
 設定留意点  日単位もしくは週単位でしかジョブ設定できない。  フェイルオーバー後に再保護をかけると、元の仮想マシンは削除されます
Site Recoveryは基本的には手動でのフェイルオーバーを想定しています
 制限事項   1TB以上のディスクを持つVMはAzureBackupのサポート対象外  執筆時点ではAzure To Azureはプレビュー機能である
 その他利点

 オンプレto Azureなどバックアップの対象は多様。中身としてはVSS
オンラインでバックアップが可能。別途バックアップソフトの必要なし。
ファイル/フォルダ単位での復元も可能(今回の検証対象外)

  Default設定では、4時間毎にアプリ整合性スナップショットが実行され、24時間保持するポリシーが作成される。スナップショットは1-12時間が設定可能

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

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

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

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

共有ストレージ不要!
"SANLess Clusters"についてもっと詳しく

sanless-clusters banner


"SANLess Clusters"ソリューションを見る

SNSでもご購読できます。