本記事では、Azure Site Recoveryで弊社HAクラスタソフト「LifeKeeper」を利用したクラスター構成の複製手順についてご紹介します。
Azure Site Recoveryとは
最近はBCPの施策として、HAクラスターを導入するほかに、遠隔地へデータのレプリケーションをおこない大規模災害へ備えるケースが増えています。Azure Site Recovery（ASR） は別のリージョンに仮想マシンイメージをレプリケーションすることで、リージョン災害などで停止してしまった仮想マシンの復旧を安全なリージョンでスムーズに復旧が行えるサービスです。
今回はASRを使用して、LifeKeeper for Windows/LifeKeeper for Linux で構築したHAクラスターノードをリージョン間でレプリケーションを行いました。実際に行った構成について紹介させていただきます。なお、動作を確認したのは2024/7/19となります。
＜注意：当社の責任範囲＞
ASRのサービスそのものをLifeKeeperで冗長化しているわけではないため、ASRはLifeKeeperのサポート対象として考慮されません。このため、お客様の責任でLifeKeeperの環境でASRをご使用願います。当社の製品サポートでは、ASRをお使いになられていてもお問い合わせは受付致しますが、ASRそのものに関するお問い合わせは受付致しかねます。
レプリケーション対象となるクラスターの構成
ASRはAzure 仮想マシンの他にVMware仮想マシンやHyper-V 仮想マシンをレプリケーション対象とすることが可能なようですが、今回はAzure仮想マシンに以下の２構成のクラスターノードを作成してレプリケーション対象としました。
クラスター構成１
イメージ | Red Hat Enterprise Linux 9.3 (LVM) – Gen 2 |
クラスターソフトウェア | LifeKeeper for Linux v9.8.1 |
共有ディスク | レプリケーション（DataKeeper for Linux 9.8.1） |
クラスターノード数 | ３台（２ノードクラスター＋Witness Server) |
保護対象リソース | Load Balancer Health checkリソース, IPリソース、ファイルシステムリソース、DataKeeperリソース、PostgreSQLリソース |
Load Balancer(仮想IPアドレス） | 10.0.1.200 |
PostgreSQL Server | 13.14-1.el9_3 |
クラスター構成２
イメージ | Windows Server 2022 Datacenter – x64 Gen2 |
クラスターソフトウェア | LifeKeeper for Windows v8.10.1 |
共有ディスク | レプリケーション（DataKeeper for Windows 8.10.1） |
クラスターノード数 | ３台（２ノードクラスター＋Witness Server) |
保護対象リソース | Load Balancer Health checkリソース, IPリソース、ボリュームリソース（DataKeeper）、PostgreSQL リソース |
Load Balancer(仮想IPアドレス） | 10.0.1.220 |
PostgreSQL Server | 16.3-2 |
＊Azure shared Disk (ZRS、LRS)を使用したASRは、現在のところ Windows Server Failover Cluster構成でのみサポートとなります。このため、LifeKeeper構成でASRを使う場合は、DataKeeper構成が前提となります。
Azure Site Recovery設定の流れ
レプリケーション対象となる仮想マシンの準備ができましたら、以下の手順で仮想マシンのレプリケーション、フェールオーバーのテストを行います。
- ターゲットリージョンの設定とアクセス権限を設定する
- ターゲットリージョンにコンテナーを作成する
- レプリケーションを有効化する
- テストフェールオーバーを実施する
- フェールオーバー後の設定
- テストフェールオーバーのクリーンアップ
- フェールオーバーを実施する
１．ターゲットリージョンとアクセス権限
ASRは、仮想マシンが稼働するリージョンの他に、レプリケーションデータを保管するリージョンを用意する必要があります。そのため、ターゲットリージョンの決定とアクセス権限を事前に割り当ててから作業を行ってください。
今回はJapan East から近くゾーンを3つ使えるEast Asiaをターゲットリージョンとして設定します。また、リソースグループ、仮想ネットワーク、サブネットはASR の設定時に作成が可能ですが、事前に作成して選択することも可能です。
ターゲットリージョン | East Asia |
リソースグループ | lkrg-easia |
仮想ネットワーク | lkvnet-easia(10.0.0.0/16) |
サブネット | sub01-easia(10.0.1.0/24) |
２．Recovery Servicesコンテナーの作成
① まずデータを格納する Azure のストレージ エンティティである「Recovery Services コンテナー」を作成します。ホーム画面から”recovery”で検索をすると以下のように表示されますので、”Recovery Srvices コンテナー”を選択します。
② Recovery Servicesコンテナーの管理画面が表示されます。コンテナーが無い場合は無い場合は以下のように表示されます。”＋作成” か “Recovery Servicesコンテナーの作成”をクリックしてコンテナーの作成を行います。
③ コンテナーの作成を行います。レプリケーション先のリージョンを選択する必要があります。
④ コンテナーの設定を確認して作成を行います。
⑤ 以下のようにコンテナーが作成されました。
３．レプリケーションの設定
コンテナーリソースからSite Recovery の有効化を行います。具体的には、レプリケーション対象となる仮想マシンを選択して、作成したコンテナーへレプリケーションを行います。
① ”Site Recovery を有効にする”をクリックします。
② Azure仮想マシンから”1.レプリケーションを有効にする”をクリックします。
③ ソースとなるリージョン、リソースグループを選択します。
④ レプリケーション対象となる仮想マシンを選択します。
⑤ ターゲットリージョン、リソースグループや仮想ネットワークを選択します。事前に作成済みの場合は既存のリソースグループや仮想ネットワークを選択してください。＊ここで新規作成も可能です。
⑥ 管理画面ではレプリケーションポリシーなどの設定が可能です。
⑦ 設定の確認をします。問題なければレプリケーションの有効化をクリックします。選択した仮想マシンのレプリケーションが開始されます。実際のレプリケーションが完了するまで同期容量などによりますが、１時間程度かかります。
⑧ レプリケーションが完了しましたら、作成したコンテナーの左メニューから”レプリケーションされたアイテム”をご確認ください。レプリケーション対象とした仮想マシン毎に用意され、状態が”Protected”と表示されます。
４．テストフェールオーバの実施
テストフェールオーバーが完了していないため、”フェールオーバーの正常性”が警告となっています。そのため、テストフェールオーバーを実施します。
① ”レプリケーションされたアイテム”からひとつ仮想マシン(lksql01)を選択して、”テストフェールオーバー”を選択する。
② フェールオーバーを行う復旧ポイント、仮想ネットワークを選択して、テストフェールオーバーを開始する。なおここで選択するAzure仮想ネットワークは、レプリケーションの設定に選択したAzure仮想ネットワークとは別のネットワークを追加して選択します。
③ 完了すると、フェールオーバーを行った仮想マシンが作成されます。
④ Recovery ServicesコンテナーのVMのステータスから警告が消えることを確認できます。
⑤ 他の仮想マシンも同様にテストフェールオーバーを実施します。
テストフェールオーバーは完了です。
５．フェールオーバー後の設定確認
ASRによるレプリケーションデータをフェールオーバーした環境を確認したところ、フェールオーバー対象となるのは、仮想マシン、仮想ネットワーク、1本目のネットワークとなりました。そのため、パブリックIPアドレス、2本目以降のネットワーク、ロードバランサーなどは引き継がれません。また、LifeKeeper for LinuxとLifeKeeper for Windowsでは以下のような再設定が必要でした。フェールオーバー後には以下の対策を行い、リカバリーを完了させる必要があります。
| LifeKeeper for Linux v9.8.1 | LifeKeeper for Windows v8.10.1 |
ロードバランサー | ASRではロードバランサーのレプリケーションされないため、リカバリー先のリージョンで再作成が必要 | ASRではロードバランサーのレプリケーションされないため、リカバリー先のリージョンで再作成が必要 |
2枚目以降のネットワーク | ASRでは2枚目以降のネットワークは引き継がないため、再設定（デタッチ、アタッチ）が必要 | ASRでは2枚目以降のネットワークは引き継がないため、再設定（デタッチ、アタッチ）が必要 |
IPリソース | 対応無し | IPリソースのハードウェア情報が変更されるため、再作成が必要 |
ネットワークインターフェースのメトリック | 対応無し | GUIを改善するメトリックの設定が引き継がれないため、再設定が必要 |
仮想マシンへの接続方法 | パブリックIPアドレスが割り当てられないため、パブリックIPアドレスの割り当てや、踏み台サーバーの準備が必要 | パブリックIPアドレスが割り当てられないため、パブリックIPアドレスの割り当てや、踏み台サーバーの準備が必要 |
DataKeeper リソースのBitmapファイル再作成 |
| 以下のコマンドを実行して、対象となるDataKeeperリソースボリュームを全同期する
|
DataKeeper リソースのディスクをバックアップデータなどからのリストアが行われた場合、DataKeeperがレプリケーションの管理で利用するインテントログ（ビットマップファイル）が信頼できない状態となります。
そのためビットマップファイルを作り直し、正常な状態に戻す必要があります。ビットマップファイルの作り直しには以下のコマンドを使用してレプリケーションの全同期を行います。
- LifeKeeper for Linux
# /opt/LifeKeeper/bin/ mirror_action <リソース名> pause # /opt/LifeKeeper/bin/mirror_action <リソース名> fullresync |
- LifeKeeper for Windows
> cd “c:\Program Files (x86)\SIOS\DataKeeper > EMCmd.exe <ホスト名> BREAKMIRRPR <Drive letter> > EMCmd.exe <ホスト名> RESYNCMIRRPR <Drive letter> |
６．テストフェールオーバをクリーンアップ
テストフェールオーバー環境での動作確認が終わりましたら、テスト環境の削除を行います。以下の画面から”テストフェールオーバーのクリーンアップ”をクリックして、フェールオーバーを行った環境を削除してください。
７．フェールオーバーの実施
１．実際のフェールオーバーを行います。レプリケーションされたアイテムの中から、フェールオーバーを行う仮想マシンを選択します。
２．上部のタブから”フェールオーバー”をクリックします。
３．フェールオーバーが可能な場合、以下の画面が出力されます。フェールオーバーを押してフェールオーバーを開始します。
※他のクラスターノードも同じ手順で順次フェールオーバーを開始してください。
４．フェールオーバーが完了すると、レプリケーションされたアイテムの状態が”Failover Conmpleted”と表示されます。
※フェールオーバー後の対策を行い、リソースの起動、およびサービスへの接続が可能なことを確認してください。
サービスへの接続は、各クラスター構成で保護したPostgreSQL Serverに、Witness Server に導入した psqlを使用してロードバランサーのフロントIPアドレス経由で接続できることを確認しました。
- クラスター構成1で保護したPostgreSQL Server(Linux)
2．クラスター構成２で保護したPostgreSQL Server (Windows)
まとめ
以上が、Azure site recovery でHAクラスターであるLifeKeeper システムを保護する手順となります。リージョン間でのレプリケーションを行うためコストはかかりますが、ディザスタ・リカバリ（Disaster Recovery）環境を容易に導入できるメリットは多いと感じました。
ネットワーク情報を多く利用するクラスターシステムでは、ASRのフェイルオーバーで自動的に全てのリカバリーが完了する訳ではなく、フェイルオーバー後に必要な挙動があることを確認できました。実際にASRの導入を行う際はご参考ください。
また現状ではAzure shared Diskを使用した共有ディスクシステムをレプリケーションの対象とは出来ないようですが、今後マイクロソフト社に機能リクエストを挙げる予定です。
