クラスタ化されたサービスとホストの監視
目次
導入 Introduction
何人かの人にホストやサービスのクラスタをどうやって監視するのか聞かれたので、その方法の短いドキュメントを書くことにしました。かなり簡単なものなので、理解するのが容易だと思います。
最初に「クラスタ」が何を意味するのか決める必要があります。例を見ることでこれを簡単に理解出来ます。あなたの組織には冗長化されたDNSサービスを提供する5つのホストあるとします。もしそれらの一つが停止しても、大きな被害はありません。というのも残りのサーバが名前解決のサービスを提供し続けるからです。 DNSサービスの稼動監視に関わっているなら、5つのDNSサーバを監視したいでしょう。これが私がサービスクラスタと考えるものです。サービスクラスタは監視している5つの別々のDNSサービスで構成されています。それぞれ個々のサービスを監視したいと思うかもしれませんが、特定の一つのサービスの稼動状態よりもDNSサービスのクラスタ全体の状態のほうが最重要です。
あなたの組織にハイアベイラビリティ(クラスタ化)ソリューションを提供するホストのグループがあれば、私はそれらを ホスト クラスタと考えます。もしあるホストがダウンしても、別のホストがダウンしたサーバの全ての業務を引き継ぎます。注釈 Linuxでのホストとサービスの冗長化を提供する情報 は High-Availability Linux Project です。
アタックの計画 Plan of Attack
サービスやホストのクラスタを監視出来るかもしれないいくつかの方法があります。私は最も簡単だと思う方法を解説します。サービスやホストのクラスタの監視は二つの事柄を含みます:
- クラスタの個々の要素の監視
- 実体集合としてのクラスタの監視
ホストやサービスの個々のクラスタ構成要素の監視は思っているより簡単です。実際、あなたはすでにそれをやっています。サービスクラスタの場合、クラスタ要素のそれぞれのサービスを監視していることを確認してください。 5つのDNSサーバからなるクラスタがあるなら、5つの別々のサービス定義(おそらくcheck_dns プラグインを使って)があることを確かめてください。ホストクラスタの場合、クラスタのメンバーそれぞれの適切なホスト定義 (それぞれのホストに少なくとも一つの監視対象となるサービスも定義しなければなりません)があることを確かめてください。 重要: 個々のクラスタ要素(ホストやサービス定義)の通知を停止しようと思うかもしれません。個々の要素に対する通知は送られなくなりますが、ステータス CGIで個々のホストやサービスの状態は依然として表示されます。これはいつかクラスタの障害の原因を正確に指摘するのに役に立つでしょう。
クラスタ全体の監視は前にキャッシュされているクラスタ要素の結果を使って行われます。クラスタの状態を決定するのに全てのクラスタ要素を再チェックすることも出来ますが、すでにキャッシュされた結果がすでにあるなら帯域とリソースを無駄に使う必要はありません。結果はどこにキャッシュされるのか？クラスタ要素のキャッシュされた結果はステータスファイル にあります(個々の要素を監視していると仮定)。 check_cluster プラグインは特にステータスファイルにあるキャッシュされたホストとサービスの状態をチェックするように設計されています。 重要: クラスタの個々の要素の通知を有効にしていなくても、クラスタ全体の状態チェックの通知は有効になります。
check_clusterプラグインの使用 Monitoring Service Clusters
check_clusterプラグインはそれぞれの個々のホストかサービスクラスタ要素の状態情報をチェックすることによってホストやサービスクラスタの総合的な状態を報告するように設計されています。
より詳細はこちら...check_clusterプラグインはhttp://sourceforge.net/projects/nagiosplug/ にあるNagiosプラグインのcontribディレクトリに含まれています。
サービスクラスタの監視 Monitoring Service Clusters
あなたはネットワーク上に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_cluster --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(テキストではなく数値です)としてマクロに埋め込むのです。
ホストクラスタの監視 Monitoring Host Clusters
ホストクラスタの監視はサービスクラスタの監視と非常によく似ています。明確に、大きな違いといえばクラスタメンバーがホストであってサービスでは無いという事です。ホストクラスタの状態監視をする為に、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"とします)があるものとします。 Nagiosにwarningアラートを生成させるにはクラスタの１ホストが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は定期的にホストクラスタをチェックし、状態が悪化した時にはあなたに通知します (サービスの通知は有効になっているものとします)。 ホストが落ちるとき、それぞれのクラスタメンバーのホスト定義のために、たぶん通知を無効にしたくなることに注意してください。クラスタの総合的な状態は、あなたと同じで、どんな個々のホストの状態についても同じようにあまり気にかけないのを覚えてください。あなたのネットワークレイアウトとあなたが実行しようとしていること次第で、あなたはホスト定義のために可能にされた届かない状態のための通知を残したがるかもしれません。
