序文
何人かの人にホストやサービスのクラスタをどうやって監視するのか聞かれたので、その方法の短いドキュメントを書くことにしました。かなり簡単なものなので、理解するのが容易だと思います。
最初に「クラスタ」が何を意味するのか決める必要があります。例を見ることでこれを簡単に理解出来ます。あなたの組織には冗長化されたDNSサービスを提供する5つのホストあるとします。もしそれらの一つが停止しても、大きな被害はありません。というのも残りのサーバが名前解決のサービスを提供し続けるからです。DNSサービスの稼動監視に関わっているなら、5つのDNSサーバを監視したいでしょう。これが私が サービス クラスタと考えるものです。サービスクラスタは監視している5つの別々のDNSサービスで構成されています。それぞれ個々のサービスを監視したいと思うかもしれませんが、特定の一つのサービスの稼動状態よりもDNSサービスのクラスタ全体の状態のほうが最重要です。
あなたの組織にハイアベイラビリティ(クラスタ化)ソリューションを提供するホストのグループがあれば、私はそれらを ホスト クラスタと考えます。もしあるホストがダウンしても、別のホストがダウンしたサーバの全ての業務を引き継ぎます。注釈 Linuxでのホストとサービスの冗長化を提供する情報 High-Availability Linux Project
アタックの計画
サービスやホストのクラスタを監視出来るかもしれないいくつかの方法があります。私は最も簡単だと思う方法を解説します。サービスやホストのクラスタの監視は二つの事柄を含みます:
ホストやサービスの個々のクラスタ構成要素の監視は思っているより簡単です。実際、あなたはすでにそれをやっています。サービスクラスタの場合、クラスタ要素のそれぞれのサービスを監視していることを確認してください。5つのDNSサーバからなるクラスタがあるなら、5つの別々のサービス定義(おそらくcheck_dns プラグインを使って)があることを確かめてください。ホストクラスタの場合、クラスタのメンバーそれぞれの適切なホスト定義(それぞれのホストに少なくとも一つの監視対象となるサービスも定義しなければなりません)があることを確かめてください。重要: 個々のクラスタ要素(ホストやサービス定義)の通知を停止しようと思うかもしれません。個々の要素に対する通知は送られなくなりますが、ステータスCGIで個々のホストやサービスの状態は依然として表示されます。これはいつかクラスタの障害の原因を正確に指摘するのに役に立つでしょう。
クラスタ全体の監視は前にキャッシュされているクラスタ要素の結果を使って行われます。クラスタの状態を決定するのに全てのクラスタ要素を再チェックすることも出来ますが、すでにキャッシュされた結果がすでにあるなら帯域とリソースを無駄に使う必要はありません。結果はどこにキャッシュされるのか?クラスタ要素のキャッシュされた結果はステータスファイルにあります(個々の要素を監視していると仮定)。check_cluster プラグインは特にステータスファイルにあるキャッシュされたホストとサービスの状態をチェックするように設計されています。重要: クラスタの個々の要素の通知を有効にしていなくても、クラスタ全体の状態チェックの通知は有効になります。
check_cluster2 プラグインの使用
check_cluster2プラグインはホストやサービスクラスタ全体の状態をチェックするように設計されています。ステータスファイルにある個々のホストやサービスクラスタの要素のキャッシュされた状態情報をチェックすることで動作します。
より詳細はこちら...check_cluster2プラグインはhttp://sourceforge.net/projects/nagiosplug/ にあるNagiosプラグインのcontribディレクトリに含まれています。
サービスクラスタの監視
あなたはネットワーク上に3つのDNSサーバを冗長構成しているとしましょう。 まず、クラスタサービスを監視する前に、それぞれのDNSサーバを個別に監視することが必要となります。 既に3つの個別のサービス(全て"DNS Service"とします)がDNSホスト("host1","host2"と"host3"とします)上で 動いているものとします。
サービスをクラスタとして監視する為には、新たに"クラスタ"サービスを作成する必要があります。 しかし、それを行う前にクラスタサービスをチェックするコマンドを設定しなければなりません。 以下の通りcheck_service_clusterというコマンドを設定してみましょう:
define command{
command_name check_service_cluster
command_line /usr/local/nagios/libexec/check_cluster2 --service -l $ARG1$ -w $ARG2$ -c $ARG3$ -d $ARG4$
}
今あなたは"クラスタ"サービスを作成する必要があり、check_service_clusterコマンドを クラスタのチェックコマンドとして作成して使わなければなりません。 どのようにして行うかは以降で触れます。 以下の例は2つ以上のクラスタサービスがnon-OK状態になるとCRITICALを生成し、 1つのサービスがnon-OK状態になるとWARNING状態にします。 クラスタの各々のサービスメンバー全て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_cluster2プラグインを使うサービスを定義 しなければなりません。サービスはどんなクラスタホストととも関係ありません。 Nagiosが稼動しているホストとサービスを関連づけるのはいい考えかもしれません。 結局、Nagiosが稼動しているホストがダウンすれば、 (冗長化監視ホスト構成でもとってなければ) Nagios自体が稼動しなくなるので、あなたの行いたい監視からは遠ざかってしまいます・・・。 -->
とにかく、check_host_clusterコマンドを以下の通り定義してみましょう:
define command{
command_name check_host_cluster
command_line /usr/local/nagios/libexec/check_cluster2 --host -l $ARG1$ -w $ARG2$ -c $ARG3$ -d $ARG4$
}
ホストクラスタには3つのホスト(名前は"host1","host2"と"host3"とします)があるものとします。 Nagiosにwarningアラートを生成させるにはクラスタの1ホストがUPでなければよく、criticalアラート を生成するには2つ以上ホストがUPでなければよいです。ホストクラスタの監視はこのように動作します。
define service{ ... check_command check_host_cluster!"Super Host Cluster"!1!2!$HOSTSTATEID:host1$,$HOSTSTATEID:host2$,$HOSTSTATEID:host3$ ... }
わたしたちは必要に応じてホスト状態マクロのカンマ区切りのリストを クラスタチェックコマンド中の$ARG4$マクロに渡す事に注意して下さい。 これは重要な事です!Nagiosは必要に応じた現在の個々のクラスタメンバーの ホスト状態をID(テキストではなく数値です)としてマクロに埋め込むのです。
できあがり! Nagiosは定期的にホストクラスタをチェックし、状態が悪化した時にはあなたに通知します (サービスの通知は有効になっているものとします)。