
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リージョンが限定されていますので、Azureの記事にあるグローバルロードバランサーを確認して構成を検討してください。
参加リージョンとしてはJapanEastとSoutheast Asiaに各クラスターノードを配置して運用するため、ホームリージョンは距離の近いEast Asiaを選択しています。
East Asiaリージョンが単一障害点となりそうですが、East Asiaリージョンがダウンしてもグローバルロードバランサーは影響を受けません。
今回提供するサービスはWebサーバー(httpd)を使用します。リージョン間ロードバランサーおよびパブリックロードバランサーの設定で「フローティングIP」を有効にすることでListenのアドレスに設定するパブリックIPアドレスへの接続が可能となります。
- ■構築手順
- 1.仮想ネットワークを作成する
- 2.仮想マシンを作成する
- 3.仮想ネットワーク間のピアリングの設定を行う
- リモート仮想ネットワーク ピアリングの設定
- ローカル仮想ネットワーク ピアリングの設定
- 4.OSにログインし、LifeKeeperのインストール準備を行う
- 5.LifeKeeper for Linuxのインストール
- 6.クラスター環境のセットアップ
- 7.リージョン間でディスクの同期(レプリケーションリソースの作成)を行う
- 8.IPリソースの登録を行う
- 9.httpd(Apache)をクラスターリソースとして登録する
- 10.リージョン間ロードバランサーの設定を行う
- 11.LB Health Checkリソースを作成する
- 12.クラスター設定の確認
■構築手順
リージョン間ロードバランサーを使用したクラスター環境の構築は、以下の手順で行います。今回は、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のインストールに向けて準備を行います。以下の操作を両ノードで行ってください。
- /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 - ファイアウォールの設定を無効化する。またはLifeKeeperで使用するポートでの通信を可能となるよう設定する
- 以下のコマンドでSELinux を無効化する
# sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config
# setenforce 0
※システム再起動後から disabledになります。
- 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結果です。
- httpd(Apache)パッケージを両ノードにインストールする
# dnf install httpd
5.LifeKeeper for Linuxのインストール
LifeKeeper for Linuxのインストールを行います。LifeKeeper for Linuxはクラスターに所属するクラスターノードにインストールを行う必要があります。以下を参考にすべてのノードにLifeKeeperのインストールを行ってください。
- LifeKeeper for Linux では、サーバーごとに Core ライセンス、およびオプションライセンスが必要となります。ライセンスの取得については以下をご確認ください。
- ライセンスを取得しましたら、インストールを開始します。インストールイメージをダウンロードして、イメージ内からsetupスクリプトを実行します。setup スクリプト実行の詳細は以下を確認してください。
- インストールが完了しましたら、正常にインストールが完了しているかどうか出力メッセージを確認してください。以下のサイトで具体的な確認方法がございます。ご参考ください。
6.クラスター環境のセットアップ
インストールを行ったクラスターノードを接続してクラスターシステムを構築します。具体的には、クラスターノード間を接続するコミュニケーションパスの設定を行います。
コミュニケーションパスはクラスターの設定を保つ生命線となり、1経路切断されてもクラスターが保てるよう冗長構成が推奨されています。そのため物理環境や仮想環境などでは、ネットワークの冗長化やコミュニケーションパスを複数経路設定いただく事を推奨しています。
クラウド環境は内部で冗長構成となっていることや、今回のようなリージョン間通信を前提とする場合は、2経路設定するまでもなく冗長化されていると考えられますので、当記事では1経路のみ登録をおこないます。
LifeKeeper GUIから設定を行う場合、以下を参考にしてください。
◆コミュニケーションパスの作成
LKCLI コマンドを使用したコマンドラインによる設定も可能です。
コマンドラインによる設定を行う場合、以下をご参考ください。
◆コミュニケーションパスの作成・削除
LKCLIコマンドで作成する場合は、以下のようにコマンドを実行します。(両ノードで実施)
■クラスターノード 202502JE0LKL01 で実行 ■クラスターノード 202502SALKL01 で実行 |
以降のLifeKeeper リソース登録では、コマンドラインのLKCLIを使用します。
LKCLIの詳細は以下をご確認ください。
7.リージョン間でディスクの同期(レプリケーションリソースの作成)を行う
JapanEastリージョンとSoutheastAsiaリージョン間の仮想マシンにて、ディスクパーティション間のレプリケーションを行います。レプリケーションにはDataKeeper for Linuxを使用します。
DataKeeper リソース、Filesystemリソースの作成は以下のコマンドで実行します。
■DataKeeperリソース、File systemリソースの作成 ■DataKeeperリソースの拡張 ■File systemリソースの拡張 |
DataKeeper for Linux の詳細は以下をご確認ください。
◆SIOS DataKeeper for Linux
8.IPリソースの登録を行う
httpd(Apache)をリソースとして保護するにあたり、IPリソースを作成する必要があります。AzureではOSの仮想IPアドレスを認識しませんが、httpdリソースと連携するため、グローバルロードバランサーのフロントIエンドIPアドレスと一致するパブリックIPアドレス(20.***.***.***)を仮想IPアドレスとして登録します。
- ブロードキャストPING を無効化します。
# sed -i s/NOBCASTPING=0/NOBCASTPING=1/g /etc/default/LifeKeeper
- 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 の設定をクラスターに対応した値に変更してリソースとして登録を行います。
- クラスターとして登録するにあたり、設定ファイル”/etc/httpd/conf/httpd.conf” の以下の値にパブリックIPアドレスを設定します。
(47行目)
Listen
20.***.***.***:8080
- 共有ディスク内に共有のコンテンツファイル(html)を置くため、以下の設定を変更します。
(124行目)
DocumentRoot "
/data/web"
(136行目)
<Directory "
/data/web">
- 共有ファイル内に、試験用のindex.htmlファイルを配置します。
# cat /data/web/index.html
<html>
Azure GLB Test 10.0.2.5
</html>
その他、httpd.conf に必要な設定については任意で行ってください。
- 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リソースはアクティブノードでヘルスチェックに応答し、自ノードがアクティブノードであることをロードバランサーに伝えます。
- LB Health Checkリソースの作成/拡張は以下のコマンドで設定します。
# lkcli resource create lbhc --tag LBHC-18080 --port 18080 --switchback INTELLIGENT
# lkcli resource extend lbhc --tag LBHC-18080 --dest 202502SALKL01LB Health Checkリソースの詳細は以下をご確認ください。
◆LB Health Check Kit管理ガイド - LB Health Checkリソースの作成が完了しましたら、ロードバランサーでヘルスチェックが稼働しているかどうかAzure 管理画面から確認します。ホーム>負荷分散|ロードバランサー>”アクティブノードのロードバランサー” から、正常状態の”詳細の表示”をクリックしてください。✔UPが表示されて、正常性プローブに正常に応答していることが確認できます。
- LB Health Checkリソースを作成したらhttpd リソースと依存関係を作成します。以下のコマンドでhttpd.8080リソースの親リソースとしてLBHC-18080リソースの紐づけを行います。
|
依存関係の作成など、LKCLI の詳細は、以下をご確認ください。
12.クラスター設定の確認
Azure Cross Region環境でのLifeKeeper for Linux構成は以下のようになります。
コマンドラインでの出力は以下です。
|
※パブリックIPアドレスは伏せています
LifeKeeper Web Management Console (LKWMC)から表示した場合、以下のようになります。
※パブリックIPアドレスは黒塗りしています
GUIの接続にはSSHポートフォワードを利用しています。詳細は以下をご確認ください。
◆クラウド環境でのSSHポートフォワーディングを利用したGUIへの接続
最後に、クラスターで保護するWebサーバーに接続を確認します。リージョン間ロードバランサーのパブリックIPアドレスに対して、ブラウザから接続してみてください。
http://”パブリックIPアドレス”
※パブリックIPアドレスは黒塗りしています
リージョン間ロードバランサーを使用したクラスター環境の構築は以上で完成です。最後に手動でリソースをスタンバイノードにスイッチオーバー(切り替え)しても同じように接続が出来ることを確認して下さい。