
LifeKeeper v10の新機能「LBHC ARK」によるAWS・Azure・GCPでのHAクラスタ構成を解説。
特にAWSのNLBを活用した構成は、Direct Connect接続時にも有効です。2026年1月時点の検証結果に基づき、各方式との違いやJP1等の外部ソフトとの連携における注意点まで詳しく紹介します。
はじめに
AWSが提供するクラウド環境を利用する場合、DBや基盤システムなどのアプリケーションサーバーをクラウドに配置して、ユーザーのオンプレミス環境の既存システムから接続して利用するというケースが多くあります。オンプレミス環境からの接続で利用する場合、AWS環境ではダイレクトコネクトのような専用線を契約して、接続して利用することが多い印象です。
LifeKeeperでは、これまでダイレクトコネクトによる接続に対して、Transit Gatewayを使用したルートテーブルのターゲットの書き換えによるクラスター制御か、Route53のAレコードの書き換えによるクラスター制御を推奨してきました。
今回の記事では、Recovery Kit for EC2(ルートテーブル、EIP方式)、Recovery Kit for Amazon Route 53という接続方式に、4つ目の接続方式としてサポートされているLoad Balancer Hearth Check(LBHC)ARKについて紹介します。
Load Balancer Hearth Check(LBHC)について
Load Balancer(LB)は、本来的には負荷分散型クラスターシステムのことです。接続数の多いフロントエンドシステム(Webなど)に負荷分散型クラスターシステムとして配置することで、1台のシステムに接続が集中してサービスの処理性能が下がる(応答が遅くなる)ことを防ぐ役割を果します。以下のように、ロードバランサの配下に複数台のサーバーを配置する構成をとります。
|
ここで紹介する LifeKeeper は、ロードバランサとは別クラスターシステムであるHigh Availability(HA)クラスターシステムを実現するソフトウェアです。本製品の LifeKeeper のLBHC ARKは、負荷分散型クラスターシステムであるロードバランサのLBHCを利用することで、HAクラスターシステムを実現しています。
LBHCは、上記のようにロードバランサ配下に登録したサーバー(クラスターノード)のヘルスチェックを定期的に行い、ロードバランサへの接続を分配する機能となります。
LifeKeeper によるHAクラスターは、常に1台のノードのみでサービスを起動するため、LBHCでサービスの起動したノード(アクティブノード)を判定します。また、接続先の正常性を判定して、異常がある場合はスタンバイノードに切り替えを行います。
このように、LifeKeeper のLBHC ARK は、負荷分散型クラスターで使用されるロードバランサーを使用して、HAクラスターを構成します。
また、この LBHC ARK を利用するメリットとして大きいのは、ロードバランサを利用する権限以外に、ロール権限が不要な点が挙げられます。
現在、LBHC ARKを使用したHAクラスターは、以下のクラウド環境で提供するロードバランサを使用することが可能です。
- Amazon Web Service
- Microsoft Azure
- Google Cloud
詳細は、以下の資料をご確認ください。
- Recovery Kit for Load Balancer Health Check管理ガイド
https://docs.us.sios.com/spslinux/10.0/ja/topic/lifekeeper-for-linux-generic-application-recovery-kit-for-load-balancer - AWSでロードバランサーを使用した構成
https://docs.us.sios.com/sps/10.0/ja/topic/aws-lbhc-quick-start-guide https://docs.us.sios.com/spslinux/10.0/ja/topic/creating-aws-network-load-balancer-scenario
- Recovery Kit for Load Balancer Health Check 管理ガイド
https://docs.us.sios.com/sps/10.0/ja/topic/lifekeeper-for-linux-lbhc - AWSでロードバランサーを使用した構成
https://docs.us.sios.com/sps/10.0/ja/topic/aws-lbhc-quick-start-guide
AWS Load balancer を使用した構成について
AWS 環境でロードバランサのフロントIPアドレスをクラスター仮想IPアドレスとして利用する場合、ロードバランサはNetwork Load Balancer(NLB) で構成し、ターゲットグループにクラスターノードを登録します。LBHC ARKでヘルスチェックに応答して、アクティブノードをロードバランサに伝えます。
AWSでの LBHC ARKの運用は以下をご参考ください。
AWSでロードバランサーを使用した構成
https://docs.us.sios.com/sps/10.0/ja/topic/aws-lbhc-quick-start-guide
ダイレクトコネクトやVPCピアリング接続構成でも利用可能
NLB は、フロントIPアドレスへの接続に対してダイレクトコネクトやVPCピアリング接続などもサポートしています。そのため、LBHC ARK で保護対象とするロードバランサを利用した構成が可能です。取り急ぎ、手元の環境で以下のようなVPCピアリング接続について確認して、クライアントからクラスターシステムに接続が可能なことを確認しました。
![]() |
ダイレクトコネクトについては検証環境リソースの都合でなかなか動作検証が行えないのですが、以下の資料にもあるように接続をサポートしていますので、問題なく利用可能という認識です。
Network Load Balancer
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/network/network-load-balancers.html
ダイレクトコネクト経由の接続の場合、これまで Route53 を使用した方法や、Transit Gatewayを使用したルートテーブルシナリオを公開していました。IAM ロール権限が課題となりRoute53 の導入が難しい場合や、Transit Gatewayを使用したルートテーブルシナリオが利用できないケースなどで、LBHC ARKによるフロントIPアドレスが有効と考えられます。
LBHC ARK を使用したAWS構成についてもご検討ください。
補足となりますが、2026年1月現在、JP1は当ブログで紹介したAWSのNLBを使用した構成にアプリケーション側の要件で対応しておりません。
今後の対応を含め、LifeKeeper に関連するご要望、お問い合わせについては、以下よりご連絡をお願いいたします。
▼お問い合わせ
https://bccs.sios.jp/contact/index.html
| ⚠️注意:当社の責任範囲 本ブログは2026/1/23の動作検証にて確認した内容です。また、LifeKeeper for Linux v10.0を使用した動作検証です。将来のAWSの仕様変更やLifeKeeper for Linux のバージョンアップに伴う仕様変更にて内容が一致しなくなる可能性があります。 当ブログの記載内容によって被った損害・損失については一切の責任を負いかねます。 |









