序論
何人かがホストまたはサービスのクラスタ監視に取り組む方法を尋ね、私は、どうこれをするかに関して少しのドキュメントにまとめる決めました。 それがかなり直接的なので、うまくいけば、いろいろなことが分かり易くなります…
まず最初離れて、私たちは、「クラスタ」で言っていることを定義する必要があります。 これを簡単に行うのに、例を上げます。 あなたの組織には5つのホストがあるとしましょう(あなたの組織に冗長なDNSサービスを提供)。 それらの1つが故障しても、それは大きな障害ではありません。なぜなら残っているサーバが、名前解決サービスを提供し続けるからです。 あなたが組織にDNSサービスの稼動監視に関わり、5つのDNSサーバを監視したい場合。 これがサービス・クラスタと私が考えていることです。 サービス・クラスタは監視している5つの別々のDNSサービスから成ります。 それぞれの個々のサービスを監視したいと考えていますが、主な関心事は特別などんな一つのサービス稼動よりもむしろDNSサービス・クラスタの総合的な状態にです。
あなたの組織に高信頼性(クラスタリング)ホスト・グループがあるなら、それらをホスト・クラスタとみなします。 1つの特定のホストが故障すると、別のものは、故障したサーバ全ての機能を引き継ぐ状態となります。注釈として ホストとサービスを提供するLinux冗長系の情報として 高信頼性Linux プロジェクトのサイトをチェックします。
攻撃計画
潜在的にサービスやホスト・クラスタを監視する幾つかの方法があります。 私は最も簡単と信じている方法を説明します。 サービスかホスト・クラスタの監視には2つの事あります:
- 個々のクラスタ要素の監視
- 集合体としてクラスタの監視
個々のホストやサービス・クラスタ要素を監視するのは思うより簡単です。 事実上、たぶん既にそれをしています。 サービス・クラスタに関しては、ただクラスタのそれぞれのサービス要素監視していることを確認します。 5つのDNSサーバのクラスタを持っているなら、5つの別々のサービス定義を必ず持っています(たぶんcheck_dnsプラグインを使っています。)。 ホスト・クラスタについて、クラスタの各メンバーの適切なホスト定義を設定したかを確認します。(また、監視する最低1つのサービスをそれぞれのホストに定義しなければいけません。) 重要: 個々のクラスタ要素(ホストやサービス定義）の通知を無効にしたいと思っていると思います。 個々の要素に関して通知を全く送りませんが、それでも、個々のホストかサービス状態の表示は状態CGIで見られます。 これは将来クラスタ中の障害箇所を正確に特定するのに役に立ちます。
全体のクラスター監視はクラスター要素の前のキャッシュ結果を使うことで行われます。 クラスタの状態を決めるためクラスタの全ての要素を再チェックできても、結果が既にキャッシュにあるのになぜ通信と資源を無駄に使うのですか？ 結果はどこでキャッシュされますか? キャッシュされたクラスタ要素の結果は状態ファイルの中に有ります。(各要素を監視していると仮定して)。 check_cluster・プラグインは、特に状態ファイル中でキャッシュされたホストとサービスステータスをチェックする様に設計されています。 重要: クラスタの個々の要素の通知を許可しませんでしたが、全体のクラスタ状態チェックでは許可したくなるでしょう。
check_cluster プラグイン使用
check_cluster・プラグインは、それぞれの個々のホストかサービス・クラスタ要素の状態情報をチェックすることによってホストかサービス・クラスタの総合的な状態を報告するように設計されています。
さらに… check_cluster プラグインは、http://sourceforge.net/projects/nagiosplug/ のNagios プラグイン・リリースのcontribディレクトリにあります。
サービス・クラスタ監視
あなたのネットワークで冗長なサービスを提供する3つのDNSサーバがあるとしましょう。 まず最初に、オフです、クラスタとしてそれらを監視できる前に、個別にそれぞれのこれらのDNSサーバを監視する必要があります。 あなたにはDNSホスト("host1"、"host2"、および"host3"と呼ばれます)に関連して3つの別々のサービス(全て「DNSサービス」と呼ばれる)が既にあると仮定します。
クラスタとしてサービスを監視するために、新しい「クラスタ」サービスを作成する必要があります。 しかしながら、それをする前に、サービス・クラスタ・チェック命令の設定を確認します。 次の様な check_service_cluster 定義と呼ばれるコマンドがあると仮定しましょう:
define command{
command_name check_service_cluster
command_line /usr/local/nagios/libexec/check_cluster --service -l $ARG1$ -w $ARG2$ -c $ARG3$ -d $ARG4$
}今、「クラスタ」サービスを作成し、check_service_cluster コマンドで、今、作成したクラスターのチェックコマンドを使う必要があります。 以下の例はどうこれを行うかの例です。 以下の例では、クラスターの2つかそれ以上のサービスがOKでない状態となるとCRITICAL警告を出します。そして１つだけのサービスがOK以外の状態となると WARINGの警報を出します。 クラスタの全てのサービス・メンバーがOKであると、クラスタ・チェックはOKステータスを返します。
define service{ ...
check_command check_service_cluster!"DNS Cluster"!1!2!$SERVICESTATEID:host1:DNS Service$,$SERVICESTATEID:host2:DNS Service$,$SERVICESTATEID:host3:DNS Service$
...
}クラスタ・チェック・コマンドにおける$ARG4$マクロにオンデマンドサービスステータスのマクロのコンマで区切られたリストを渡しているのに気付くのは重要です。 それは重要です! Nagiosはクラスタの個々のメンバーの現在のサービス状態ID(テキスト文字列よりむしろ数値)をそれらのオンデマンド・マクロに入れます。
ホスト・クラスタ監視
ホスト・クラスタを監視するのは、サービス・クラスタを監視するのと良く似ています。 明らかに、主な違いは、クラスタ・メンバーがサービスではなく、ホストであるということです。 ホスト・クラスタの状態を監視するために、check_cluster・プラグインを使うサービスを定義しなければなりません。 サービスはクラスタのホストのどれかに関連しているべきではありません、そのホストが落ちるとこれがクラスタの通知で問題を起こします。 Nagiosが実行してるホストとサービスを関連させることが良いアイデアかもしれません。 結局、Nagiosが実行しているホストが、停止したなら、Nagiosがそれ以上稼働しないので、監視に何も出来ません(冗長系の監視ホストを設定されている場合は別です)…
とにかく、以下の様にcheck_host_cluster コマンド定義があると仮定しましょう:
define command{
command_name check_host_cluster
command_line /usr/local/nagios/libexec/check_cluster --host -l $ARG1$ -w $ARG2$ -c $ARG3$ -d $ARG4$
}クラスター・ホストには3つのホストがあるとします。("host1"、"host2"、および"host3"と命名された) クラスタの1つのホストがUPでなければWARNIG、2つ以上のホストがUPでなければCRITICALの警告をNagiosに出して欲しいなら、ホスト・クラスタを監視するサービス定義はこの様になります。
define service{
...
check_command check_host_cluster!"Super Host Cluster"!1!2!$HOSTSTATEID:host1$,$HOSTSTATEID:host2$,$HOSTSTATEID:host3$
...
}クラスタ・チェック・コマンドにおける$ARG4$マクロにオンデマンド・ホスト状態のマクロをコンマで区切られたリストで渡しているのに気付くのは重要です。 それは重要です! Nagiosはクラスタの個々のメンバーの現在のホスト状態ID(テキスト文字列よりむしろ数値)をそれらのオンデマンド・マクロに入れます。
それです! 状態が悪化しているとき(サービスのための通知を許可にしたと仮定します)、Nagiosは定期的にホスト・クラスタの状態をチェックして、あなたに通知を出します。 個々のクラースター・メンバーのホスト定義でホストが停止したときは大抵、通知を禁止したい事に注意します。クラスター全体の状態に対応するからホスト個別の状態にそんなに関わりたくない事に留意します。 ネットワーク・レイアウトと実行しようとしている事によって、ホスト定義で可能にされたUNREACHABEL状態のままにしておきたいかもしれません。
参照: アクティブ・チェック, マクロ