災害対策に！LifeKeeperを使ったAzureクロスリージョンHAクラスタについて

こんにちは。SCSKの津田です。
今回は、LifeKeeperによるAzureのリージョンを跨いだHAクラスター構成についてご紹介いたします。

はじめに

昨今の自然災害の増加に伴い、AWSやAzureといったパブリッククラウド環境では、リージョンを跨いだHAクラスター構成（クロスリージョン構成）のニーズが高まっています。

LifeKeeperでは、2023年頃よりAWSでのクロスリージョン構成のサポートが開始されました。
さらに、2025年1月からはAzureでもクロスリージョン構成に対応しています（LifeKeeper for Linux：v9.9.0以降、LifeKeeper for Windows：v8.10.2以降）。

今回はAzureのクロスリージョン環境上にLifeKeeperを構築し、簡単な動作確認を行ってみました。
本記事では、クロスリージョン構成における処理の流れや、LifeKeeper構築のためのAzure設定のポイントについてご紹介します。

▼AWSのクロスリージョン構成について気になる方はこちらもご参照ください▼

LifeKeeper × Azureクロスリージョン構成 について

LifeKeeper構築の観点で単一リージョン構成とクロスリージョン構成を比較すると、
Azureのロードバランサーによるヘルスチェックプローブを利用する点では同様になりますが、単一リージョン構成では内部ロードバランサーを利用するのに対し、Azure クロスリージョン構成は、グローバルロードバランサーを使用します。

▼単一リージョン構成については以下をご参照ください。▼

以下は、今回検証で構築した環境の構成図です。
(※Windows環境)

それではLifeKeeperを利用したAzure クロスリージョン構成での処理について、簡単に説明します。

まず、グローバルロードバランサーからパブリックロードバランサーを介してヘルスチェックが行われます。
単一リージョン構成での内部ロードバランサ―(ILB)同様、ヘルスチェックは「LB Health Check Kit」リソース(以下図『lbhc』)の機能でヘルスチェック用ポート（今回は26001）に対して行われます。

続いて、ヘルスチェックに応答した稼働系ノードに対して、グローバルロードバランサーから仮想IPにむけた通信が行われます。
LifeKeeperの仮想IPリソース作成時に、グローバルロードバランサーのPublic IPを登録することにより、HAクラスタの稼働系ノードでは、グローバルロードバランサーのPublic IPが仮想IPとして割り当てられています。
これによりクライアントから稼働系ノードへは、グローバルロードバランサーのPublic IP（＝仮想IP）を利用して通信を行います。

※アクティブ・スタンバイが切り替わると、仮想IPリソースとLB Health Check Kitの両リソースが待機系ノードに切り替わるため、
ヘルスチェックは待機系ノードから応答があり、待機系ノードの仮想IPに向けて通信します。

環境構築・検証

環境構築流れ

構築については、以下の順序で作業を行いました。

次に、③ピアリング設定、④ロードバランサー作成について設定例をご紹介していきます。

③④以外の作業につきましては、以下をご参照ください。
(※2025年10月時点リンク。基本的にAzure単一リージョンでのLifeKeeper構築と差異はありません。)
※リソースにつきましては、この構成特有のリソース作成方法はないため、各ARKのリソース作成手順をご参照ください。

Windows : https://docs.us.sios.com/sps/8.11.0/ja/topic/create-cluster-node-primay-and-standby
Linux : https://docs.us.sios.com/spslinux/9.9.1/ja/topic/microsoft-azure-quick-start-guide

クロスリージョン構成の設定ポイント

ここでは作業の中からクロスリージョン構成でポイントとなるピアリング設定、ロードバランサー作成について設定内容をご紹介します。
(Azureの設定項目は、継続的にアップデートされるため) 

ピアリング(Azure Vnet Peering)設定

仮想ネットワーク間のピアリング設定は、リージョンが異なるHAクラスターノード間の通信(LifeKeeperのコミュニケーションパス、レプリケーション)に必要となります。
設定はAzureコンソール上から、片方の仮想ネットワークからピアリングを作成することで、リモートの仮想ネットワークにも設定を反映します。以下の設定は、仮想ネットワーク「NW_JapanEast」から追加したピアリング設定です。

パブリックロードバランサ―作成

Azureコンソールから、LifeKeeperで保護するノードが配置される各リージョン(Japan East、Southeast Asia)でパブリックロードバランサーを構築します。

＜Japan Eastのパブリックロードバランサ―＞

※Japan Eastのパブリックロードバランサ―設定後、仮想マシン(LK01JE)のネットワークセキュリティグループで受信・送信セキュリティ規則を追加する。

＜Southeast Asiaのパブリックロードバランサ―＞

※Japan Eastのパブリックロードバランサ―設定後、仮想マシン(LK02SA)のネットワークセキュリティグループで受信・送信セキュリティ規則を追加する。

グローバルロードバランサ―

Azureコンソールから、LifeKeeperで保護するノードが配置されるリージョン間のグローバルロードバランサーを構築します。

動作確認

単一リージョン構成での記事同様に、IISを利用して簡単な動作確認を行いました。

<事前準備>

• クラスタ内各ノードのIISのドキュメントルートに、サーバ名を記載したテストページ(htmlファイル)を格納します。
  ＜LK01JE %SystemDrive%\inetpub\wwwroot\test_page.htm＞
              

  ＜LK02SA %SystemDrive%\inetpub\wwwroot\test_page.htm＞

<動作確認>

• LK01JE がアクティブのとき
  クライアント端末から仮想IP宛にIISのテストページにアクセスすると、想定通りLK01JEのテストページが表示されました。      

   

• LK02SA がアクティブのとき
  クライアント端末から仮想IP宛にIISのテストページにアクセスすると、想定通りLK02SAのテストページが表示されました。
        

  

注意点

• クロスリージョン構成では、DataKeeperによるデータレプリケーションも可能です。
  ご利用をご検討の際は、データベースに関連するサービスや制限事項についてサイオステクノロジー社へご確認いただくことを推奨いたします。
• 2025年10月時点では、「JP1/AJS3 – Manager」および「JP1/AJS3 – Agent」のサービス保護はサポート対象外となっておりますのでご注意ください。
• 今回は2ノード構成を例としておりますが、グローバルロードバランサーの機能を利用することで、3ノード以上への拡張も可能であり、LifeKeeperの観点でもサポート範囲となります。グローバルロードバランサーの制限事項にご留意ください。
  
  グローバル ロード バランサー - Azure Load Balancer

  Azure Load Balancer のグローバル ロード バランサー レベルの概要。

  learn.microsoft.com
• クロスリージョン構成では、費用、設計、パフォーマンス、運用等、多くの観点で十分な検討が必要となります。本構成は一例となりますので、参考情報としてご活用ください。また、具体的な構成案がありLifeKeeperをご検討される際は、事前にサイオステクノロジー社へのご確認を推奨いたします。

さいごに

今回は、LifeKeeperの観点からAzureにおけるクロスリージョン構成についてご紹介しました。

AWSと比較して、サイオステクノロジー社が発信しているドキュメントはまだ少なく、サポートされていないサービスも存在するなど、十分に展開されているとは言えない部分が見受けられます。しかし、今後は災害対策環境へのニーズの高まりに伴い、サポート範囲の拡充も期待できますので、引き続きその動向に注目していきたいと思います！