TOP設計・移行・活用> lk_logの出力その2:リソースの起動・停止・監視の実行およびその結果
LifeKeeperのすべて
LifeKeeperのすべて

第14回:LifeKeeperの管理 - ログの確認方法とSNMPの設定
著者:サイオステクノロジー クラスタソリューショングループ
監修者:サイオステクノロジー  小野寺 章   2006/2/24
前のページ  1  2  3   4  次のページ
lk_logの出力その2:リソースの起動・停止・監視の実行およびその結果

   LifeKeeperはリソースの起動・停止・監視をそれぞれ「restore」「remove」「quickCheck」というスクリプトを実行することによって行われている。切り替えの発生原因や切り替えがうまく実施されなかった場合の原因を知るには、リソースごとに実行されるスクリプトの処理内容と結果について確認していくことになる。

   切り替え時に実行している処理などのログの表示については各ARKによって異なるため、ここですべてを紹介することは難しい。しかし、リソースの起動や停止が行われた起点や、リソースの起動・停止・監視の処理が成功したかどうかの結果についてはほとんどのARKで共通しているので、ファイルシステムリソースの起動時のログを例に解説する。

   以下のログはファイルシステムリソースの起動に成功した場合のログである。

LifeKeeper: RESTORE FILE SYSTEM /shared START AT: 日時
LifeKeeper: "fsck"ing file system /shared
fsck.ext3 -y /dev/<デバイス>
e2fsck 1.35 (日時)
/dev/<デバイス>: recovering journal
/dev/<デバイス>:: clean, 242555/8896512 files, 8466131/17782676 blocks
LifeKeeper: mounting file system /shared
mount -text3 -orw /dev/<デバイス> /shared
LifeKeeper: File system /shared has been successfully mounted.
LifeKeeper: RESTORE FILE SYSTEM /shared END err=0 AT: 日時

   多くのARKではリソースが起動されるときには「RESTORE」というメッセージが出力される。そしてその後、そのサービスを起動するために実行した処理内容が記載される。そして起動の処理が問題なく終了した場合には「END err=0」というメッセージを確認することができる。この「err=0」とはスクリプトの返り値をあらわしている。

   LifeKeeperで使用しているリソースの停止・起動・監視のスクリプトは、すべて返り値によってエラーであるかそうでないかを判断している。返り値が「0」であった場合は、そのスクリプトが問題なく終了したことをあらわしており、戻り値が「1」であった場合は、エラーで終了したと判断される。

   リソースの起動・停止が「err=1」で終了した場合は、リソースがFAILの状態「OSF」で処理を終了する。リソースの監視時に実行されるquickCheckスクリプトが戻り値「1」で終了した場合には、フェイルオーバーのトリガーとなる。これはGenericARKで使用するスクリプトを自分で作成する場合でも、戻り値は同様に実装する必要がある。

   LifeKeeperで保護しているサービスが何らかの原因で切り替わった場合、あるいは起動に失敗してしまった場合は、まずは戻り値から実行結果について確認を行う。失敗しているログを見つけたら、その処理内容について確認しサーバや保護対象のソフトウェアの状態などを確認していくとよい。

   lk_logの出力については以上となる。

   lk_logの出力は、ややわかりにくいところがある。しかし、単純な切り替わりの原因や起動の失敗などについて確認したい場合は、これまで紹介した内容を基に確認していただければ、少しでも読みやすくなるのではないかと思われる。


LifeKeeper for LinuxでSNMPトラップを送信するよう設定する

   サーバを運用しているとき、そのサーバになんらかの変化や異常があった場合に管理者へ通知する仕組みが使われることが多い。LifeKeeperではSNMPトラップをリモートの管理サーバ(SNMPマネージャ)に送信するように設定することができる。LifeKeeperがSNMPによって通知するメッセージはおおよそ以下の場合である。

  • コミュニケーションパスが切れた場合/復旧した場合
  • 切り替えが発生した場合
  • LifeKeepperが停止した場合/復旧した場合

表1:LifeKeeperがSNMPによって通知するメッセージ

   またSNMPの設定を行う条件として、以下のパッケージがOSにインストールされている必要があるのでご確認いただきたい。

  • net-snmp-libs
  • net-snmp
  • net-snmp-utils

表2:OSにインストールされている必要があるパッケージ

   まず、LifeKeeperでトラップを送信するアドレスの指定を行う。アドレスの指定にはコマンドを使用するか、LifeKeeperの設定ファイルである/etc/default/LifeKeeperを直接編集する。

   SNMPトラップの送信先をコマンドで指定する場合は以下の通り

# lk_configsnmp <SNMPTRAPを送信するIPアドレス>

   上記のコマンドを実行すると/etc/default/LifeKeeperの設定項目に追記される。

LK_TRAP_MGR=<SNMPTRAPを送信するIPアドレス>

   以上でLifeKeeper上の設定は終了である。

   次にOSにインストールされたSNMPの設定を行う。最低限必要な設定はコミュニティの設定である。コミュニティの設定はsnmp.confファイルを編集する。

   ファイルのパスはOSやインストール方法によって異なる場合があるので、ご確認いただきたい。設定する内容は以下の1行である。

defCommunity コミュニティ名

   設定は以上である。SNMPトラップが送信されるかどうかを確認するには、保護しているリソースやコミュニケーションパスで擬似障害を発生させるのが最もわかりやすい。

   もし、SNMPトラップが送信されない場合にはlk_logコマンドを使用して確認することができる。確認方法は以下の通りである。

lk_log SNMP

   もし、設定や環境に問題があればログに出力される場合があるので内容を確認して設定を変更するとよい。

   なお、どのような場合にSNMPトラップが発行されるかを詳細に知りたい場合は、LifeKeeperのオンラインマニュアルを参照していただきたい。オンラインマニュアルはSteelEye社の以下のURLでバージョン別に確認することができ、キーワードで検索することが可能である。

LifeKeeperのドキュメント「SteelEye: Support > Documentation」
http://licensing.steeleye.com/support/docm.php

前のページ  1  2  3   4  次のページ


サイオステクノロジー株式会社 クラスタソリューショングループ
著者プロフィール
サイオステクノロジー株式会社 クラスタソリューショングループ
サイオステクノロジーにおいて、SteelEye LifeKeeperの技術サポートや構築支援を行うエンジニア集団。日本国内で、彼ら以上にLifeKeeperを知る者たちはいないと自負している。世の中のすべてのHAクラスタがLifeKeeperになることを夢見て日々奮闘を続けている。


サイオステクノロジー株式会社 小野寺 章
監修者プロフィール
サイオステクノロジー株式会社  小野寺 章
インフラストラクチャービジネスユニット
エンタープライズソリューション部 部長
国産汎用機メーカに入社し、汎用機のSEを10数年担当、1994年頃からオープン・ダウンサイジングブームの到来とともにUNIX系OSを担当し、Solaris、HP/UXでSun Cluster、Veritas Cluster、MC/ServiceGuardなどを使用した、多数のミッションクリティカルシステムのHAシステム構築に従事。2001年ノーザンライツコンピュータ(現サイオステクノロジー)へ入社後、SteelEye LifeKeeperの総責任者としての国内での販売・サポート業務に従事。


INDEX
第14回:LifeKeeperの管理 - ログの確認方法とSNMPの設定
  はじめに
  lk_logの出力その1:コミュニケーションパスのダウンとアップ
lk_logの出力その2:リソースの起動・停止・監視の実行およびその結果
  LifeKeeper for Linuxでイベントがあった場合にメールを送信するよう設定する