こんにちは、SCSKの前田です。
3回目は、少しLifeKeeperに特化したリソースで使われている機能や障害について説明したいと思います。
1回目・2回目の用語説明に関しては以下のリンクからどうぞ！
おさらい
HAクラスター製品ではアクティブ/スタンバイの構成で、アクティブ側のノードで障害を検知した場合、アクティブ側でアプリケーションの停止を行い、スタンバイ機でアプリケーションの起動を行う必要があります。
LifeKeeperとして、この一連の動作を可能にする製品が ARK になります。
ARK については、このあと説明していきたいと思います。
ARKとは？
ARK とは、Application Recovery Kits の略で、LifeKeeper が特定のアプリケーション（オープンソースソフトウェアや商用アプリケーション）を容易にリソースとして組み込むことが可能になる製品です。
ARK は、アプリケーションを操作するため、下記の4つのスクリプトで構成されています。
・起動スクリプト(restore)・・・アプリケーションを起動させる処理
・停止スクリプト(remove)・・・アプリケーションを停止させる処理
・監視スクリプト(quickCheck)・・・アプリケーションの状態を監視する処理
・再起動スクリプト(recover)・・・アプリケーションを再起動させる処理
ARK による、アプリケーションのリソースへの組み込みはウィザード形式（GUI上で設定）で作業が可能となり、ARK には、アプリケーションを操作（起動・停止・監視・再起動）するための4つのスクリプトがあらかじめ準備されているため、スクリプトを設計・作成するための開発工数の削減や人的なミスを防止することが出来ます。
また、意図的にスクリプトを変更しない限り、サポートの対象となります。
ARKを使うことで、スクリプトを作る必要が無いから、人的ミスもなく工数が削減出来るね。
ARKはサポートされているから、何か問題があった時に安心ね。
GenericARKとは？
GenericARK とは、LifeKeeper が製品として提供されている ARK が存在しないアプリケーションを操作（起動・停止・監視・再起動）するため、汎用的に利用が可能な ARK になります。
製品として提供されている ARK と違い、アプリケーションを操作（起動・停止・監視・再起動）するためのスクリプトを予め準備する必要があり、変更可能な箇所以外に修正のない汎用スクリプトを利用しない限り、スクリプトに対するサポートは受けられません。
（変更可能な箇所以外に修正のない汎用スクリプトに関してはサポート対象になります。）
ただし、サポートを受けられない分、最低限の制約（正常時の戻り値「0」と、異常時の戻り値「1」）を厳守することで自由にスクリプトをカスタマイズすることが可能となります。
QSPとは？
QSP とは、Quick Service Protection の略で、Linux や Windows において、スクリプトを準備せず、OSのサービスをGUI操作で簡単に冗長化出来る ARK になります。
Linux では service コマンドで起動や停止できるサービスが対象となり、Windows では Windows サービスに登録されているサービスが対象になります。
QSP は簡単に冗長化出来る反面、quickCheck では簡易的なチェックしか行っておらず、複雑な起動や停止処理が必要なアプリケーションには対応出来ないため、GenericARK を利用する必要があります。
OS のサービスを簡易的に冗長化するには、QSP を使うのが便利だね。
複雑な起動や停止処理が必要なアプリケーションは、GenericARK があるから、使い分けが出来そうね。
restoreとは？
restore とは、LifeKeeper のリソースにおける、アプリケーションやサービスの起動するためのスクリプトになります。
restore は、LifeKeeper の GUI 管理画面からの操作であったり、LifeKeeper の perform_action コマンドでユーザが明示的にリソースの起動を行う場合や、障害の検知によって実施されるフェイルオーバー時に、移動先サーバの LifeKeeper が自動的にリソースを起動する場合にも実行されます。
removeとは？
remove とは、LifeKeeper のリソースにおける、アプリケーションやサービスの停止するためのスクリプトになります。
remove は、LifeKeeper の GUI 管理画面からの操作であったり、LifeKeeper の perform_action コマンドでユーザが明示的にリソースの停止を行う場合や、障害の検知によって実施されるフェイルオーバー時に、移動元サーバの LifeKeeper が自動的にリソースを停止する場合にも実行されます。
quickCheckとは？
quickCheck とは、LifeKeeper のリソースにおける、アプリケーションやサービスの監視を行うためのスクリプトになります。このスクリプトでは、監視対象のリソースが正常に動作していることを確認するための処理になっており、ARK によっては単純にアプリケーションやサービスが開始されているだけの確認ではなく、内部的な処理が正常に行われているかの確認も含まれます。
quickCheck は、ユーザが明示的に実施することはなく、リソースが起動しているサーバで LifeKeeper が決められた間隔で自動的に実行されています。実行したけ結果、戻り値が0であれば正常で、戻り値が1であれば異常と判断されます。
なお、この処理(スクリプト)はオプションとなっており、監視が必要のないリソース(アプリケーション等)に関しては利用しないことも可能になっています。
ただし、復旧処理(リカバリ処理)が必要な場合、quickCheck は必須なスクリプトになります。
recoverとは？
recover とは、LifeKeeper のリソースにおける、アプリケーションやサービスの復旧処理(リカバリ処理)を行うためのスクリプトになります。
recover は、quickCheck と同様にユーザが明示的に実施することはなく、リソースの監視処理(quickCheck)によって、リソースが異常と判断された場合に LifeKeeper がリソースの稼働サーバで1度だけ復旧処理が実行されます。このスクリプトでリソースの復旧に失敗した場合、フェイルオーバーが行われます。
なお、この処理(スクリプト)もオプションとなっており、復旧処理(リカバリ処理)が必要のないリソース(アプリケーション等)に関しては利用しないことも可能になっています。
その場合、監視処理(quickCheck)で異常と判断された場合、即座にフェイルオーバーが行われることなります。
ノード障害とは？
LifeKeeper としてのノード障害とは、ハードウェアの故障やソフトウェアの問題など、様々な原因によって障害が発生し、ノード間でハートビートとしての通信が一定間隔で確認が出来ない状態になったことを表します。
障害の種類としては、ハードウェア障害となるノードのCPU、メモリ、ディスクなど物理的な故障、ソフトウェア障害となるOSやアプリケーションの不具合、ネットワーク障害となる物理的なケーブルの断線やルータの故障などがあります。
この状態になった場合、LifeKeeper としてはフェイルオーバーの処理が開始されます。
リソース障害とは？
リソース障害とは、LifeKeeper として監視対象となっているリソースの監視処理(quickCheck)によってリソースが異常と判断された状態、または復旧処理(recover)によってリソースの復旧に失敗した状態のことを表します。
リソースが異常と判断される条件としては、冗長化(リソース)対象のサービスが停止されること、ARK によってはサービスが起動されていてもサービスの動作として正常な結果を応答出来ない状態も異常と判断されることもあります。
この状態になった場合も、LifeKeeper としてはフェイルオーバーの処理が開始されます。
まとめ
今回はLifeKeeperのリソースで使われている機能や障害の用語について説明して来ましたが、いかがでしたでしょうか？
少しでもLifeKeeperを身近に感じて頂けたら幸いです。
次回はLifeKeeperのリソースで使われている機能や障害について説明したいと思いますので、お楽しみに！
