イントロダクション
何人かの人にホストやサービスのクラスタをどうやって監視するのか聞かれたので、その方法の短いドキュメントを書くことにしました。かなり簡単なものなので、理解するのが容易だと思います。
最初に「クラスタ」が何を意味するのか決める必要があります。例を見ることでこれを簡単に理解出来ます。あなたの組織には冗長化されたDNSサービスを提供する5つのホストあるとします。もしそれらの一つが停止しても、大きな被害はありません。というのも残りのサーバが名前解決のサービスを提供し続けるからです。DNSサービスの稼動監視に関わっているなら、5つのDNSサーバを監視したいでしょう。これが私が サービス クラスタと考えるものです。サービスクラスタは監視している5つの別々のDNSサービスで構成されています。それぞれ個々のサービスを監視したいと思うかもしれませんが、特定の一つのサービスの稼動状態よりもDNSサービスのクラスタ全体の状態のほうが最重要です。
あなたの組織にハイアベイラビリティ(クラスタ化)ソリューションを提供するホストのグループがあれば、私はそれらを ホスト クラスタと考えます。もしあるホストがダウンしても、別のホストがダウンしたサーバの全ての業務を引き継ぎます。注釈 Linuxでのホストとサービスの冗長化を提供する情報 High-Availability Linux Project
アタックの計画
サービスやホストのクラスタを監視出来るかもしれないいくつかの方法があります。私は最も簡単だと思う方法を解説します。サービスやホストのクラスタの監視は二つの事柄を含みます:
ホストやサービスの個々のクラスタ構成要素の監視は思っているより簡単です。実際、あなたはすでにそれをやっています。サービスクラスタの場合、クラスタ要素のそれぞれのサービスを監視していることを確認してください。5つのDNSサーバからなるクラスタがあるなら、5つの別々のサービス定義(おそらくcheck_dns プラグインを使って)があることを確かめてください。ホストクラスタの場合、クラスタのメンバーそれぞれの適切なホスト定義(それぞれのホストに少なくとも一つの監視対象となるサービスも定義しなければなりません)があることを確かめてください。重要: 個々のクラスタ要素(ホストやサービス定義)の通知を停止しようと思うかもしれません。個々の要素に対する通知は送られなくなりますが、ステータスCGIで個々のホストやサービスの状態は依然として表示されます。これはいつかクラスタの障害の原因を正確に指摘するのに役に立つでしょう。
クラスタ全体の監視は前にキャッシュされているクラスタ要素の結果を使って行われます。クラスタの状態を決定するのに全てのクラスタ要素を再チェックすることも出来ますが、すでにキャッシュされた結果がすでにあるなら帯域とリソースを無駄に使う必要はありません。結果はどこにキャッシュされるのか?クラスタ要素のキャッシュされた結果はステータスファイルにあります(個々の要素を監視していると仮定)。check_cluster プラグインは特にステータスファイルにあるキャッシュされたホストとサービスの状態をチェックするように設計されています。重要: クラスタの個々の要素の通知を有効にしていなくても、クラスタ全体の状態チェックの通知は有効になります。
check_cluster プラグインの使用
check_clusterプラグインはホストやサービスクラスタ全体の状態をチェックするように設計されています。ステータスファイルにある個々のホストやサービスクラスタの要素のキャッシュされた状態情報をチェックすることで動作します。
More to come... check_clusterプラグインはテンポラリ的にここにあります http://www.nagios.org/download/alpha。
サービスクラスタの監視
最初にクラスタを監視する新しいサービスを定義しなければなりません。このサービスはクラスタ全体の状態をチェックします。おそらく注意する必要がある障害がいつあるのか知るために、このサービスの通知を有効にしたいでしょう。クラスタメンバーのある一つのサービスの状態についてはさほど気にしないので、それらのサービス定義の中で通知を停止することも出来ます。
check_service_cluster コマンドを次のように定義したとしましょう
define command{
command_name check_service_cluster
command_line /usr/local/nagios/libexec/check_cluster --service /usr/local/nagios/var/status.log $ARG1$ $ARG2$ < $ARG3$
}
サービスクラスタのメンバーである5つのサービスがあるとします。クラスタの要素で2かそれ以上でワーニング、3かそれ以上のサービスでnon-OK状態ならnon-OK状態かCRITICALをNagiosに出させたいとすると、クラスタを監視するサービス定義の<check_command> 引数はこんな感じになります:
check_service_cluster!2!3!/usr/local/nagios/etc/servicecluster.cfg
$ARG3$ マクロはチェックが実行される時に/usr/local/nagios/etc/servicecluster.cfgで置換されます。これは check_cluster プラグインがクラスタメンバーの名前を読み込むファイルなので、そのファイルを作成しメンバーのサービスを追加する(一行に一つ)必要があります。サービス記入の書式はサービスが関係するホストの短縮名、次にセミコロン、最後にサービスの説明となります。ファイルの中身の例は次のようになります:
host1;DNS Service
host2;DNS Service
host3;DNS Service
host4;DNS Service
host5;DNS Service
host6;DNS Service
ホストクラスタの監視
ホストクラスタの監視はサービスクラスタの監視と非常に似ています。明らかに一番の違いはクラスタメンバーがホストであってサービスでないことです。ホストクラスタの状態を監視するために、check_cluster プラグインを使うサービスを定義しなければなりません。サービスはクラスタのどのホストとも関連があってはいけません。そうすると、そのホストがダウンした場合、クラスタの通知に問題が発生します。サービスをNagiosが稼動しているホストと関連付けるのはいい考えかもしれません。Nagiosが稼動しているホストがダウンすると、Nagiosは稼動していなくて監視に関する限り何も出来ることはありません(監視の冗長化 をやっていない場合ですが)。
check_host_cluster を次のように定義したとします
define command{
command_name check_host_cluster
command_line /usr/local/nagios/libexec/check_cluster --host $ARG1$ $ARG2$ /usr/local/nagios/var/status.log < $ARG3$
}
ホストクラスタには6つのホストがあることにします。もし2かそれ以上のホストがUPしていなければWARNING、4かそれ以上のホストがUPしていなければCRITICALをNagiosに警告させる場合、クラスタ監視のためのサービス定義の<check_command> 引数はこんな感じになります:
check_host_cluster!2!4!/usr/local/nagios/etc/hostcluster.cfg
$ARG3$ マクロはチェックされる時に /usr/local/nagios/etc/hostcluster.cfgに置換されます。これはcheck_cluster プラグインがクラスタメンバーの名前を読み出すファイルなので、ファイルを作成し、メンバーの全ホストの短縮名(ホスト定義で決めているように)を加える必要があります(一行にひとつ)。ファイルの内容は次のようになります:
host1
host2
host3
host4
host5
host6
出来たぜ! Nagiosは定期的にホストクラスタの状態をチェックし、状態がいつ悪くなったか通知を送信します(サービス通知を有効にしている場合)。クラスタメンバー個々のホスト定義の注意として、ホストがダウンした時の通知を停止させがちです。クラスタ全体の状態のように、個々のホストの状態は気にしなくてもよいことを覚えておきなさい。ネットワークの構成ややろうとしていることにより、ホスト定義で不到達状態の通知を有効にしておきたいと思うかもしれません。