LifeKeeperでAzureのリージョンを跨いだHAクラスター構成の構築

    LifeKeeper でAzureのリージョンを跨いだHAクラスター構成の構築のサムネイル画像

    2025/1/15にLifeKeeper for Linux v9.9.0の追加サポートとしてAzureのリージョンを跨いだHAクラスター構成(以下「Azure Cross Region構成」)のサポートが開始されました。

    そのため、先行してAzure Cross Region構成 のサポートについて2025/2/4にブログで公開しています。
    このブログでは、Azure Cross Region構成へのLifeKeeper for Linux導入手順について紹介いたします。

    <注意:当社の責任範囲>

    本ブログは2025/3/26の動作検証にて確認した内容です。また、LifeKeeper for Linux v9.9.0を使用した動作検証です。将来のAzureの仕様変更やLifeKeeper for Linux のバージョンアップに伴う仕様変更にて内容が一致しなくなる可能性があります。当ブログの記載内容によって被った損害・損失については一切の責任を負いかねます。

    ---

    Azure Cross Region構成は、Azureより提供されているグローバルロードバランサーを使用して実現します。グローバルロードバランサーは以下のようにEast Asia(ホームリージョン)で入り口となるロードバランサーを登録して、各クラスターノードを配置するリージョン(参加リージョン)を登録して構成します。

     

      Azure Cross Region構成図 

     

    ホームリージョンは利用可能なAzureリージョンが限定されていますので、Azureの記事にあるグローバルロードバランサーを確認して構成を検討してください。

    参加リージョンとしてはJapanEastとSoutheast Asiaに各クラスターノードを配置して運用するため、ホームリージョンは距離の近いEast Asiaを選択しています。

    East Asiaリージョンが単一障害点となりそうですが、East Asiaリージョンがダウンしてもグローバルロードバランサーは影響を受けません。

    今回提供するサービスはWebサーバー(httpd)を使用します。リージョン間ロードバランサーおよびパブリックロードバランサーの設定で「フローティングIP」を有効にすることでListenのアドレスに設定するパブリックIPアドレスへの接続が可能となります。

     

    ■構築手順

    リージョン間ロードバランサーを使用したクラスター環境の構築は、以下の手順で行います。今回は、LifeKeeper for Linux を使用して、RHEL9.4環境でhttpd(Apache)リソースを保護しました。各顧客の環境に合わせて、OSやアプリケーションを読み替えてご参考ください。

     

      1.仮想ネットワークを作成する

      仮想ネットワークは、クラスターノードを配置するJapan East, Southeast Asiaの2か所に作成します。それぞれ、アクティブノードとスタンバイノードを配置するネットワークです。

       

      アクティブノードネットワーク(Japan East)

      仮想ネットワーク名

      nw-JapanEast

      リージョン

      Japan East 

      アドレス空間

      10.0.2.0/24

      DNSサーバー

      Azure 提供の DNS サービス

      暗号化

      無効

      DDoS 保護プラン

      無効

      スタンバイノードネットワーク(Southeast Asia)

      仮想ネットワーク名

      nw-SoutheastAsia

      リージョン

      Southeast Asia

      アドレス空間

      10.0.3.0/24

      DNSサーバー

      Azure 提供の DNS サービス

      暗号化

      無効

      DDoS 保護プラン

      無効

       

      2.仮想マシンを作成する

      クラスターノードとなる仮想マシンを作成します。Japan East、Southeast Asiaの各リージョンに1台づつ配置します。
      作成する仮想マシンは、ドキュメントにあるAzureでのクラスターノードの作成を参考にしてください。
      今回の構成では以下のように仮想マシンを作成しました。

       

      アクティブノード(Japan East)

      コンピュータ名

      202502JE0LKL01

      リージョン

      Japan East 

      可用性オプション

      可用性ゾーン

      可用性ゾーン

      ゾーン1

      イメージ

      Red Hat Enterprise Linux 9.4 (LVM) – x64 Gen2

      サイズ

      Standard DS1 v2

      ディスク

      システムディスク

      データディスク (レプリケーション用ディスク)

      IPアドレス

      10.0.2.5/24(静的)

      パブリック受信ポート

      ssh(22)

      負荷分散オプション

      なし(後から追加するため)

      スタンバイノード(Southeast Asia)

      コンピュータ名

      202502SALKL01

      リージョン

      Southeast Asia

      可用性オプション

      可用性ゾーン

      可用性ゾーン

      ゾーン1

      イメージ

      Red Hat Enterprise Linux 9.4 (LVM) – x64 Gen2

      サイズ

      Standard DS1 v2

      ディスク

      システムディスク

      データディスク (レプリケーション用ディスク)

      IPアドレス

      10.0.3.4/24(静的)

      パブリック受信ポート

      ssh(22)

      負荷分散オプション

      なし(後から追加するため)

       

      3.仮想ネットワーク間のピアリングの設定を行う

      仮想ネットワーク間のピアリング設定は、作成した仮想ネットワークの設定メニューにある”ピアリング”から行います。
      ピアリング設定は片方の仮想ネットワークからピアリングを作成することで、リモートの仮想ネットワークにも設定を反映します。以下の設定は、nw-JapanEastから追加したピアリング設定です。

      ピアリングのリンク名(nw-SoutheastAsia側のリンク名)

      GlobalPeering_JE_SA

      仮想ネットワークのデプロイモデル

      Resource Manager

      リソースIDを知っている

      なし

      仮想ネットワーク

      nw-SoutheastAsia

      リモート仮想ネットワーク ピアリングの設定

      ‘nw-SoutheastAsia’ に ‘nw-JapanEast’ へのアクセスを許可する

      あり

      nw-JapanEast’ からのトラフィック転送の受信を ‘nw-SoutheastAsia’ に許可する

      あり

      ‘nw-SoutheastAsia’ 内のゲートウェイまたはルート サーバーに ‘nw-JapanEast’ へのトラフィックの転送を許可する

      なし

      nw-JapanEast’ のリモート ゲートウェイまたはルート サーバーを使用するために ‘nw-SoutheastAsia’ を有効にする

      なし

      ローカル仮想ネットワーク ピアリングの設定

      ピアリングのリンク名(nw-JapanEast側のリンク名)

      GlobalPeering_SA_JE

      ‘nw-JapanEast’ に ‘nw-SoutheastAsia’ へのアクセスを許可する

      あり

      nw-JapanEast’ からのトラフィック転送の受信を ‘nw-SoutheastAsia’ に許可する

      あり

      ‘nw-SoutheastAsia’ 内のゲートウェイまたはルート サーバーに ‘nw-JapanEast’ へのトラフィックの転送を許可する

      なし

      nw-JapanEast’ のリモート ゲートウェイまたはルート サーバーを使用するために ‘nw-SoutheastAsia’ を有効にする

      なし

       

      4.OSにログインし、LifeKeeperのインストール準備を行う

      Azureの仮想マシンにログインを行います。ピアリング設定が完了しているため、ノード間のネットワークでの通信が可能です。ping などで通信が可能かどうか確認してください。

      通信が可能であれば、LifeKeeperのインストールに向けて準備を行います。以下の操作を両ノードで行ってください。

      1. /etc/hostsに赤字の項目を追加しノード間での名前解決を可能にする

        # cat /etc/hosts
        127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
        ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
        10.0.2.5        202502JE0LKL01 202502je0lkl01.internal.cloudapp.net
        10.0.3.4        202502SALKL01 202502salkl01.internal.cloudapp.net

      2. ファイアウォールの設定を無効化する。またはLifeKeeperで使用するポートでの通信を可能となるよう設定する

      3. 以下のコマンドでSELinux を無効化する

        # sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config
        # setenforce 0

        ※システム再起動後から disabledになります。

      4. partedコマンドを使用してデータ用ディスクにパーティションを作成する

        # parted -s /dev/sdc mklabel gpt
        # parted /dev/sdc mkpart primary 0% 100%

        # parted /dev/sdc print
        Model: Msft Virtual Disk (scsi)
        Disk /dev/sdc: 4295MB
        Sector size (logical/physical): 512B/4096B
        Partition Table: gpt
        Disk Flags:

        Number  Start   End     Size    File system  Name     Flags
         1      1049kB  4294MB  4293MB  xfs          primary

        ※上記はファイルシステム作成後のprint結果です。

      5. httpd(Apache)パッケージを両ノードにインストールする

        # dnf install httpd

      5.LifeKeeper for Linuxのインストール

      LifeKeeper for Linuxのインストールを行います。LifeKeeper for Linuxはクラスターに所属するクラスターノードにインストールを行う必要があります。以下を参考にすべてのノードにLifeKeeperのインストールを行ってください。

      1. LifeKeeper for Linux では、サーバーごとに Core ライセンス、およびオプションライセンスが必要となります。ライセンスの取得については以下をご確認ください。

        LifeKeeper ライセンスについて

      2. ライセンスを取得しましたら、インストールを開始します。インストールイメージをダウンロードして、イメージ内からsetupスクリプトを実行します。setup スクリプト実行の詳細は以下を確認してください。

        セットアップスクリプトの操作

      3. インストールが完了しましたら、正常にインストールが完了しているかどうか出力メッセージを確認してください。以下のサイトで具体的な確認方法がございます。ご参考ください。

        LifeKeeper インストールの確認

      6.クラスター環境のセットアップ

      インストールを行ったクラスターノードを接続してクラスターシステムを構築します。具体的には、クラスターノード間を接続するコミュニケーションパスの設定を行います。

      コミュニケーションパスはクラスターの設定を保つ生命線となり、1経路切断されてもクラスターが保てるよう冗長構成が推奨されています。そのため物理環境や仮想環境などでは、ネットワークの冗長化やコミュニケーションパスを複数経路設定いただく事を推奨しています。

      クラウド環境は内部で冗長構成となっていることや、今回のようなリージョン間通信を前提とする場合は、2経路設定するまでもなく冗長化されていると考えられますので、当記事では1経路のみ登録をおこないます。

       

      LifeKeeper GUIから設定を行う場合、以下を参考にしてください。
      コミュニケーションパスの作成

      LKCLI コマンドを使用したコマンドラインによる設定も可能です。
      コマンドラインによる設定を行う場合、以下をご参考ください。
      コミュニケーションパスの作成・削除

      LKCLIコマンドで作成する場合は、以下のようにコマンドを実行します。(両ノードで実施)

      ■クラスターノード 202502JE0LKL01 で実行
      # lkcli commpath create --laddr 10.0.2.5 --raddr 10.0.3.4 --dest 202502SALKL01

      ■クラスターノード 202502SALKL01 で実行
      # lkcli commpath create --laddr 10.0.3.4 --raddr 10.0.2.5 --dest 202502JE0LKL01

      以降のLifeKeeper リソース登録では、コマンドラインのLKCLIを使用します。
      LKCLIの詳細は以下をご確認ください。

       

      LKCLIガイドはこちらボタン

       

      7.リージョン間でディスクの同期(レプリケーションリソースの作成)を行う

      JapanEastリージョンとSoutheastAsiaリージョン間の仮想マシンにて、ディスクパーティション間のレプリケーションを行います。レプリケーションにはDataKeeper for Linuxを使用します。

      DataKeeper リソース、Filesystemリソースの作成は以下のコマンドで実行します。

      ■DataKeeperリソース、File systemリソースの作成
      # lkcli resource create dk --tag rep-data --mode synchronous --bitmap /opt/LifeKeeper/bitmap_rep-data --hierarchy new --device /dev/sdc1 --fstype xfs --mount_point /data --fstag /data

      ■DataKeeperリソースの拡張
      # lkcli resource extend dk --tag rep-data --dest 202502SALKL01 --mode synchronous --laddr 10.0.2.5 --raddr 10.0.3.4

      ■File systemリソースの拡張
      # lkcli resource extend fs --tag /data --dest 202502SALKL01

      DataKeeper for Linux の詳細は以下をご確認ください。
      SIOS DataKeeper for Linux

       

      8.IPリソースの登録を行う

      httpd(Apache)をリソースとして保護するにあたり、IPリソースを作成する必要があります。AzureではOSの仮想IPアドレスを認識しませんが、httpdリソースと連携するため、グローバルロードバランサーのフロントIエンドIPアドレスと一致するパブリックIPアドレス(20.***.***.***)を仮想IPアドレスとして登録します。

      1. ブロードキャストPING を無効化します。

        # sed -i s/NOBCASTPING=0/NOBCASTPING=1/g /etc/default/LifeKeeper


      2. IPリソース(realip)でのリソース作成は以下のコマンドで実施します。

        # lkcli resource create ip --tag ip-20.***.***.*** --ipaddr 20.***.***.*** --switchback INTELLIGENT --device eth0
        # lkcli resource extend ip --tag ip-20.***.***.*** --dest 202502SALKL01 --switchback INTELLIGENT --template_priority 1 --target_priority 10 --device eth0

      9.httpd(Apache)をクラスターリソースとして登録する

      Webサーバーをクラスターの保護サービスとして登録します。Webサーバーとして、httpd(Apache)を使用します。httpd の設定をクラスターに対応した値に変更してリソースとして登録を行います。

      1. クラスターとして登録するにあたり、設定ファイル”/etc/httpd/conf/httpd.conf” の以下の値にパブリックIPアドレスを設定します。

        (47行目) Listen 20.***.***.***:8080

      2. 共有ディスク内に共有のコンテンツファイル(html)を置くため、以下の設定を変更します。

        (124行目) DocumentRoot "/data/web"

        (136行目) <Directory "/data/web">

      3. 共有ファイル内に、試験用のindex.htmlファイルを配置します。

        # cat /data/web/index.html
        <html>

                Azure GLB Test 10.0.2.5
        </html>

        その他、httpd.conf に必要な設定については任意で行ってください。

      4. Webサーバーの準備が行えましたら、以下のコマンドでhttpd(Apache) リソースとして登録します。

        # lkcli resource create apache --tag httpd.8080 --root /etc/httpd --path /usr/sbin/httpd --switchback INTELLIGENT
        # lkcli resource extend apache --tag httpd.8080 --dest 202502SALKL01 --switchback INTELLIGENT --template_priority 1 --target_priority 10

       

      10.リージョン間ロードバランサーの設定を行う

      リージョン間でのロードバランサーの設定を行います。各仮想マシンを配置した参加リージョン2か所にパブリックロードバランサー、ホームリージョン1か所にリージョン間ロードバランサーを配置します。Azure のユーザーポータルからロードバランサーを選択して、以下のサイトを参考に設定を行って下さい。

      Azure – Global Load Balancer(リージョン間ロードバランサー)の作成

      なお今回の設定ではリージョン間ロードバランサーおよびパブリックロードバランサーの両方でフローティングIPを ”有効” にしています。 

      11.LB Health Checkリソースを作成する

      グローバルロードバランサーの設定が完了しましたら、ヘルスチェックに応答するLB Health Checkリソースを作成します。LB Health Checkリソースはアクティブノードでヘルスチェックに応答し、自ノードがアクティブノードであることをロードバランサーに伝えます。

      1. LB Health Checkリソースの作成/拡張は以下のコマンドで設定します。

        # lkcli resource create lbhc --tag LBHC-18080 --port 18080 --switchback INTELLIGENT
        # lkcli resource extend lbhc --tag LBHC-18080 --dest 202502SALKL01

        LB Health Checkリソースの詳細は以下をご確認ください。
        LB Health Check Kit管理ガイド

      2. LB Health Checkリソースの作成が完了しましたら、ロードバランサーでヘルスチェックが稼働しているかどうかAzure 管理画面から確認します。ホーム>負荷分散|ロードバランサー>”アクティブノードのロードバランサー” から、正常状態の”詳細の表示”をクリックしてください。✔UPが表示されて、正常性プローブに正常に応答していることが確認できます。


      3. LB Health Checkリソースを作成したらhttpd リソースと依存関係を作成します。以下のコマンドでhttpd.8080リソースの親リソースとしてLBHC-18080リソースの紐づけを行います。

      # lkcli dependency create --parent LBHC-18080 --child httpd.8080

      依存関係の作成など、LKCLI の詳細は、以下をご確認ください。

      LKCLIガイドはこちらボタン

       

      12.クラスター設定の確認

      Azure Cross Region環境でのLifeKeeper for Linux構成は以下のようになります。
      コマンドラインでの出力は以下です。

      # lkcli status -q
      LOCAL           TAG                 ID                                    STATE     PRIO  PRIMARY
      202502JE0LKL01  LBHC-18080          LBHC-18080                            ISP          1  202502JE0LKL01
      202502JE0LKL01   apache-etc.httpd   apache-etc.httpd                      ISP          1  202502JE0LKL01
      202502JE0LKL01    ip-20.***.***.***  IP-20.***.***.***                      ISP          1  202502JE0LKL01
      202502JE0LKL01    /data             /data                                 ISP          1  202502JE0LKL01
      202502JE0LKL01     rep-data         97d3f6e9-40c2-42f9-97d4-cbb541f690f5  ISP          1  202502JE0LKL01

      MACHINE        NETWORK ADDRESSES/DEVICE   STATE     PRIO
      202502SALKL01  TCP     10.0.2.5/10.0.3.4  ALIVE        1

      ※パブリックIPアドレスは伏せています

       

      LifeKeeper Web Management Console (LKWMC)から表示した場合、以下のようになります。

      ※パブリックIPアドレスは黒塗りしています

      GUIの接続にはSSHポートフォワードを利用しています。詳細は以下をご確認ください。
      クラウド環境でのSSHポートフォワーディングを利用したGUIへの接続

      最後に、クラスターで保護するWebサーバーに接続を確認します。リージョン間ロードバランサーのパブリックIPアドレスに対して、ブラウザから接続してみてください。

       

      http://”パブリックIPアドレス”

      ※パブリックIPアドレスは黒塗りしています

      リージョン間ロードバランサーを使用したクラスター環境の構築は以上で完成です。最後に手動でリソースをスタンバイノードにスイッチオーバー(切り替え)しても同じように接続が出来ることを確認して下さい。