LifeKeeper は、システムやアプリケーションの可用性を高めるためのクラスターソフトウェアです。本ブログでは、LifeKeeper クラスターシステムでアプリケーションを保護する方法と、クラスター専用スクリプトがない場合の保護方法について解説します。

LifeKeeperによるアプリケーション保護の基本

LifeKeeper は、HAクラスターソフトウェアです。HAクラスターソフトウェアは、稼働するサービスの可用性を高めるため導入されますが、サービスが停止するような障害が発生した場合に、自動的にリカバリーを行い、サービスを再開することを目的としています。LifeKeeper では、障害の検出について以下の2種類に分類されます。

• ノード障害
• リソース障害

ノード障害

ノード障害は、サービスを提供するクラスターノード（サーバーやVM）間でハートビートを送信し死活監視を行います。この監視はノード間で相互に行われており、電源障害などでノードが停止していないかどうかを確認します。アプリケーションの稼働する稼働系ノードで障害が発生した場合は、待機系ノードへサービスを自動的に切り替えて（フェイルオーバー）サービスを再開します。

以下がハートビートによる死活監視に関するフローチャートです。

リソース障害

リソース障害は、クラスターで保護対象とするアプリケーションやIPアドレス、ディスクをリソースとしてクラスターノードに登録を行い、定期的に稼働系ノードに対してリソース監視プログラムを実行し、リソースの正常/異常を確認します。リソースで異常を検出した場合は、異常を検出した稼働系ノードでのローカルリカバリーを試みて、復旧しない場合は待機系ノードにフェイルオーバーを行います。

上記のように障害を検出した場合に自動的にリカバリーを行う対象をリソースとよび、リソースとして登録することを”アプリケーション保護”と呼びます。以降ではアプリケーション保護の方法について説明します。

以下がリソース監視/障害発生時のフローチャートです。

LifeKeeperでリソース登録可能なアプリケーション

LifeKeeper でリソースとして保護できるアプリケーションは多岐にわたります。ノード間で切り替えが必要な機能はすべてリソースとして登録を行います。リソースの具体的分類は以下のようになります。

• クライアント接続インターフェース
• ノード間で共有可能なデータ領域
• サービスとして提供するアプリケーション

クライアント接続インターフェース

クラスターで稼働するアプリケーションは複数ノード間を切り替えながら稼働するため、通常のIPアドレスへの接続ではノードが切り替わるたびにIPアドレスが変わってしまいます。ノードが変わっても接続先が変化しないインターフェースをリソースとして登録して運用します。一般的にはプライマリーIPアドレスに紐づくセカンダリーIPアドレスを仮想IPアドレスとしてノード間で切り替えて利用する方法が利用されます。仮想IPアドレスの他に、DNSに登録されたAレコードを書き換えることで、接続先のDNSアドレスを固定したり、ロードバランサーのヘルスチェックプローブで接続先ノードを制御したりする方法もあります。

LifeKeeper で実際に採用可能なリソースとして以下の Application Recovery Kit (ARK)が提供されています。※一部のARKについては将来提供が終了する可能性があります。

■ LifeKeeper for Linux
IPリソース（仮想IPアドレス）
EC2 リソース (AWS 専用)
Route53リソース (AWS 専用)
LB Health Checkリソース(AWS, Azure,OCI で利用可能）
Oracle Cloud Infrastructureリソース(OCI専用)

■ LifeKeeper for Windows
IPリソース（仮想IPアドレス）
DNSリソース
LAN Manager リソース
EC2 リソース (AWS 専用)
Route53リソース (AWS 専用)
LB Health Checkリソース(AWS, Azure,OCI で利用可能）
Oracle Cloud Infrastructureリソース(OCI専用)

ノード間で共有可能なデータ領域

クラスターで稼働するアプリケーションは複数のノードを切り替えながら稼働するが、切り替え後にも同じデータを利用可能なことが望まれています。そのため、共有ディスクやネットワークディスクをリソースとして登録したり、ノード間でリアルタイムレプリケーションを行うリソースを登録してノードの切り替え発生後も同じデータを利用できるようにします。これらのデータ共有についてもリソースとして登録を行いアプリケーションと一緒に切り替えられるよう設計します。

LifeKeeper で実際に採用可能なデータ共有型リソースは 以下のようなApplication Recovery Kit (ARK)が提供されています。※一部のARKについては将来提供が終了する可能性があります。

■ LifeKeeper for Linux
device, diskリソース(共有ストレージなど）
DataKeeperレプリケーションリソース
NASリソース(NFS クライアント）
VMDKリソース
HA-Addon(DRBD)リソース

■ LifeKeeper for Windows
ボリュームリソース
DataKeeperリソース

以下はデータ共有機能を補助する（マウント機能やLVM、RAWデバイス、マルチパス対応）リソースです。

■ LifeKeeper for Linux
File systemリソース
LVMリソース
Raw デバイスリソース
マルチパスリソース

• Device Mapper Multipath (DMMP) 
• SDD MultipathPowerPath
• HiCommand Dynamic Link Manager（HDLM）
• NEC iStorage StoragePathSavior multipath (SPS)

※LifeKeeper for Windowsには該当するARKがありません。

サービスとして提供するアプリケーション

クラスターシステムでは、サービスを提供するサーバーをリソースとして登録することで可用性を高めます。それぞれ以下のアプリケーションを保護するApplication Recovery Kit (ARK)が提供されています。※一部のARKについては将来提供が終了する可能性があります。

■ LifeKeeper for Linux
Apache
DB2
MySQL
WebSphere MQ
NFS
Oracle
PostgreSQL
Postfix
Quick Service Protection (QSP)
Samba
SAP
SAP HANA
SAP MaxDB
Sybase

JP1 AJS3 – Manager
JP1 AJS3 – Agent
HULFT

■ LifeKeeper for Windows
Microsoft SQL Server
PostgreSQL
Oracle
Microsoft Internet Information Services
File share list(ファイル共有）

JP1 AJS3 – Manager
JP1 AJS3 – Agent
HULFT

上記の1，2，3に該当するリソースについては、容易にクラスターへの登録を行い監視対象とすることができるよう、 Application Recovery Kit (ARK)というパッケージが提供されています。Application Recovery Kit (ARK)は監視内容も各アプリケーションのプロセスを監視するのみではなく、アプリケーションへの接続確認などを含めた検査を行うため、プロセス監視より広範囲な監視が可能であり、サイオステクノロジーにて動作検証が十分に行われたプログラムとなっています。ARKの処理概要の詳細は以下で確認が可能です。

Application Recovery Kit (ARK)のないアプリケーションの保護

LifeKeeper のARKは、対応するアプリケーションでのみ利用が可能ですが、その他の多くのアプリケーションには専用のARKは提供されていません。この場合でもLifeKeeper ではリソース登録が行えるよう、以下のARKを提供しています。

• Quick Service Protection (QSP) Recovery Kit
• Generic Application Recovery Kit

Quick Service Protection (QSP) Recovery Kit

Quick Service Protection (QSP)は、各OSの起動、停止、ステータス監視の機能を利用して、アプリケーションをリソースとして保護するプログラムです。

Linux の場合は、以下のコマンドによるアプリケーションの起動、停止、ステータス監視、再起動が可能であれば、ARKのないアプリケーションでもリソース保護が可能となります。

# service 
# systemctl  

Windows の場合は、Windowsサービスであることが条件です。

QSPには以下のようなメリット・デメリットがあります。

その他に、QSPは既存のRecovery Kit があるものやシステムアプリケーションを保護対象としてできなくなっています。

アプリケーションの監視内容が”ステータス監視”のみですが、プロセス障害時には障害検出が可能なため要件としては十分なケースが多いと考えられます。QSPでの導入が可能な場合は、QSPでのリソース作成をお勧めいたします。

QSPの詳細は以下をご確認ください。※2025年8月現在の最新バージョンです。

■LifeKeeper for Linux
Quick Service Protection (QSP) Recovery Kit

■LifeKeeper for Windows
Quick Service Protection ARK ドキュメンテーション

Generic Application Recovery Kit

Generic Application Recovery Kit は、上記のQSPを利用した導入ができないアプリケーションや、OS機能のステータス監視より特別な監視処理を行いたい場合にご利用いただくことをお勧めします。

Generic Application Recovery Kit は、該当アプリケーションを保護するために必要な以下のスクリプトを作成し、LifeKeeper GUI からスクリプトを指定してリソース作成を進めます。

• restore(起動スクリプト)※必須
• remove(停止スクリプト)※必須
• quickCheck, quickchk(監視スクリプト)
• deepchk(監視スクリプト・LifeKeeper for Windowsのみ）
• recover(回復スクリプト)

監視処理は上記の監視スクリプトでカスタマイズが可能です。

Generic Application のメリット・デメリットは以下となります。

スクリプト開発が必要ですが、最低限 restore, remove スクリプトを作成することでリソースとしての登録が可能です。各スクリプトは以下のように稼働します。スクリプトは戻り値0 で完了すると正常終了となり、1で完了すると異常終了と判定します。

※1.  LifeKeeper for Windows のみの機能、quickchkが３分間隔で実行するのに対して、deepchkは５分間隔で実行します。
※2. LifeKeeper for Linux のみの機能、フェイルオーバーの中断を抑制します。

スクリプトの開発手順

実際に、スクリプトを開発する際には、以下に開発ガイドを公開しています。是非ご参考ください。

[Linux] GenericARK開発ガイドとサンプルスクリプト
[ドキュメント][Windows] 汎用アプリケーションリソース開発の手引

まとめ

LifeKeeperは、Application Recovery Kit(ARK) を提供するリソースだけでなく、ARKのないアプリケーションでもクラスターにリソースとして登録して、監視やリカバリーを行い、システムの可用性につなげることが可能となっています。

御社で検討中のアプリケーションにおいても、ARKの有無を含め、LifeKeeper でリソース保護することが可能かどうかご確認ください。以下に、過去に対応したアプリケーション情報が公開されていますので、こちらからも実績があるかどうかご確認ください。

その他ご不明な点については、以下よりお気軽にお問い合わせください。