lk_logの出力その1：コミュニケーションパスのダウンとアップ

lk_logの出力その1：コミュニケーションパスのダウンとアップ

   コミュニケーションパスはLifeKeeperがHAクラスタとして動作するために必要な通信を行うための接続である。よってコミュニケーションパ スが切れるようなことがあってはならないが、もしコミュニケーションパスがダウン・アップした場合は以下のように出力される。

ダウンした場合

アップした場合

   またコミュニケーションパスによってハートビート通信のやり取りができなくなった場合には「FAILED」と出力される。FAILED状態から復旧した場合には「RESTORE」と出力される。

   なお、コミュニケーションパスの切断の検知はNIC（ネットワークインターフェースカード）のリンク状態によるのではなく、ハートビート通信の応答 があるかどうかによって判断される。よってサーバやネットワークが過負荷の状態で、ソフトウェアのレイヤで正常に通信できない状態になると、コミュニケー ションパスの切断が検出される場合があるので留意する必要がある。

   コミュニケーションパスのすべてが切れてしまった場合、HAクラスタとしての機能を果たすことができなくなる。この状態をスプリットブレインと呼び、先のコミュニケーションパスのFAILEDメッセージに加えて以下のようなログを確認することができる。

   上記のメッセージを起点に、LifeKeeperはスプリットブレインが起きた場合のシナリオにそった動作を開始する（詳しい動作は後述する「スプリットブレイン発生時のLifeKeeperの動作について」の項を参照）。

   コミュニケーションパスに関するログの確認が必要になるケースとしては、スプリットブレインが発生したタイミングや時刻を確認する場合である。スプリットブレイン発生後の切り替え動作について確認する場合には、その時刻を起点としてログの確認を行えばよい。

スプリットブレイン発生時のLifeKeeperの動作について

   スプリットブレインが発生した場合、LifeKeeperは可能な限りサービスを継続するためスタンバイ側ですべてのリソースを起動しようとする。

   この時、共有ストレージを使用してファイルシステムリソースを作成している場合、アクティブ側が持っているディスクリザーブをスタンバイノードが奪 い取る。ディスクリザーブが奪われたことがLifeKeeperで確認されると、アクティブノード側がLifeKeeperによって強制的に再起動され、 結果スタンバイノード側でサービスが継続されることになる。この動作によって両系からのディスクマウントを避け、データの保護が行われている。

   では、共有ファイルシステムを使用していない場合はどちらのノードでサービスが提供されることになるのか。まず判断の基準として考えられる点とし て、どちらのノードでIPリソースが起動しているかどうかである。LifeKeeperでサービスを保護する場合、仮IPリソース（仮想IP）を作成して 依存関係を形成する。

   スプリットブレインが発生して、スタンバイ側でリソースを起動しようとしたとき、依存関係においてサービスよりも下位にIPリソースがあれば、すで にアクティブ側でIPリソースが起動しているためスタンバイ側では起動できないということになる。よって、サービスはアクティブ側で継続されることにな る。