序文
このセクションでは、ネットワークレイアウトの様々なタイプの冗長化監視ホストを実行するためのいくつかのシナリオについて述べます。 冗長化ホストを使って、Nagiosを実行する主要なホストがダウンしたりする場合や、あなたのネットワークの一部に到達できなくなる場合に、あなたのネットワークを監視を維持することができます。
Note: もしあなたが、Nagiosの使用方法を学んでいるところであれば私が示した 前提条件になれるまでは、冗長化を試さないように助言しておきます。冗長化は、理解するのに比較的複雑な問題であり、適切に実行させるのにも難しいのです。
目次
前提条件
サンプルスクリプト
シナリオ 1 - 監視の冗長化
シナリオ 2 - 監視のフェイルオーバー化
前提条件 |
冗長化の実行について考える前に、あなたは次のことに精通している必要があります。
サンプルスクリプト |
私がこのドキュメントの中で使用するサンプル・スクリプトは、Nagiosディストリビューションのサブディレクトリ内のeventhandlers/ですべて見つけることができます。ただ、あなたのシステム上で実行させる為には、修正が必要でしょうが・・・。
シナリオ 1 - 監視の冗長化 |
序文
この方法は、あなたのネットワーク上で冗長監視ホストをインプリメントする簡単(かつ素朴な)方法です。また、それは限られた数の失敗から守ってくれるでしょう。異なるネットワークセグメントなどを超えて、より賢い冗長化、よりよい冗長化を提供するためには、よる複雑なセットアップが必要です。
目的
この種の冗長化の目的は単純です。「マスター」と「スレーブ」の両ホストは、ネットワーク上の同じホストとサービスを監視します。 普通の状況の下では、「マスター」ホストだけが問題に関する通知先に"通知"を送るでしょう。私たちは「スレーブ」ホストが、次のような問題に対して通知先に通知する仕事を引き継いでNagiosを実行することを望みます。例えば、
ネットワーク構成図
下記の図形は非常に単純なネットワークを示しています。このシナリオについては、私は、ホストAおよびEがNagiosを実行しており示されたホストをすべてモニターしている、と推定しています。ホストAは「マスター」ホスト、ホストEは「スレーブ」ホストと考えます。
![]() |
初期プログラム設定
スレーブホスト(ホストE)は初期設定のenable_notificationsディレクティブが無効になっています。そのためホストやサービスの通知は行われません。同様にスレーブホストは check_external_commandsディレクティブを有効にしておきます。これらの設定は簡単でしょう・・・。
初期設定
次に、マスターとスレーブのオブジェクト設定ファイルの違いを見る必要があります・・・。
上の図の全ホストの監視をマスターホスト(ホストA)が行う設定と仮定します。スレーブホスト(ホストE)はマスターホストと同じ監視ホスト、サービスの設定を行う必要があり、それに加えて次の設定を行います・・・。
重要な点としては、ホストA(マスターホスト)はホストE(スレーブホスト)の状態は知らなくても良いということです。このシナリオでは単純にその必要がありません。もちろん、ホストAからホストEの監視を行いたければやってもかまいませんが、冗長構成にはなんの影響も与えません・・・。
イベントハンドラコマンド定義
スレーブホスト上に次のようなイベントハンドラをコマンド定義に記述するためちょっと時間を割く必要があります。次に例を挙げます・・・。
define command{
command_name handle-master-host-event
command_line /usr/local/nagios/libexec/eventhandlers/handle-master-host-event $HOSTSTATE$ $HOSTSTATETYPE$
}
define command{
command_name handle-master-proc-event
command_line /usr/local/nagios/libexec/eventhandlers/handle-master-proc-event $SERVICESTATE$ $SERVICESTATETYPE$
}
イベントハンドラスクリプトを/usr/local/nagios/libexec/eventhandlersディレクトリに置くという前提になっています。おき場所はべつに好きなところで結構ですが、例をちょっと修正する必要があります。
イベントハンドラスクリプト
では、次のようなイベントハンドラスクリプトについて見ていきましょう・・・。
ホストイベントハンドラ(handle-master-host-event):
#!/bin/sh # Only take action on hard host states... case "$2" in HARD) case "$1" in DOWN) # The master host has gone down! # We should now become the master host and take # over the responsibilities of monitoring the # network, so enable notifications... /usr/local/nagios/libexec/eventhandlers/enable_notifications ;; UP) # The master host has recovered! # We should go back to being the slave host and # let the master host do the monitoring, so # disable notifications... /usr/local/nagios/libexec/eventhandlers/disable_notifications ;; esac ;; esac exit 0
Service Event Handler (handle-master-proc-event):
#!/bin/sh # Only take action on hard service states... case "$2" in HARD) case "$1" in CRITICAL) # The master Nagios process is not running! # We should now become the master host and # take over the responsibility of monitoring # the network, so enable notifications... /usr/local/nagios/libexec/eventhandlers/enable_notifications ;; WARNING) UNKNOWN) # The master Nagios process may or may not # be running.. We won't do anything here, but # to be on the safe side you may decide you # want the slave host to become the master in # these situations... ;; OK) # The master Nagios process running again! # We should go back to being the slave host, # so disable notifications... /usr/local/nagios/libexec/eventhandlers/disable_notifications ;; esac ;; esac exit 0
これがもたらす事
スレーブホスト(ホストE)は初期状態では通知は無効で、マスターホスト(ホストA)のNagiosプロセスが有効である間はどんなホスト、サービス通知も発しません。
スレーブホスト(ホストE)のNagiosプロセスはマスターホストが次のようになったときに有効になります・・・
スレーブホスト(ホストE)のNagiosプロセスの通知が有効になるため、サービスやホストの障害・復旧時に通知が送られるようになります。この時点で、ホストEがホストやサービスの通知設定を引き継いだということになります。
ホストEのNagiosプロセスが再度スレーブホストに戻る時は次の時です・・・。
ホストEのNagiosプロセスの通知が無効になるためサービスやホストの障害・復旧通知は送られなくなります。この段階で、ホストEはホストAに通知を送る権限を受け渡したと言うことになります。すべてが最初の状態に戻ったということになります。
タイムラグ
Nagiosの冗長化は決して完璧ではありません。その問題の1つに、マスターホストが停止してスレーブホストに移行するまでのタイムラグが挙げられます。このタイムラグは次に影響されます・・・。
これらのタイムラグを最小限に抑えるには・・・
ホストAのNagiosが復旧した時に、ホストEがスレーブホストに戻る前に同様のラグが生じます。このラグは次に影響されます・・。
Nagiosが監視権限を移行する際の実際のタイムラグは定義したサービスの数にとても依存しています(サービスチェックの間隔や単純に偶然性など)。とにかく、まったく冗長が無いよりはましでしょう。
特別なケース
ここで一つ知っておくべき事を挙げます・・・。もしホストAがダウンした場合、ホストEは障害通知を有効にし、通知を送る責任を引き継ぎます。ホストAが復旧した時、ホストEは通知が無効になります。もし、- ホストAが復旧した時 - ホストAのNagiosプロセスが適切に起動しなかったら、どちらのホストも通知が有効にならない時間ができるでしょう! 幸い、Nagiosのサービスチェックロジックはこの現象について解決できます。次に、ホストEのNagiosプロセスがホストAのNagiosプロセスをチェックする際にホストAのNagiosプロセスが稼働していないことを検知するでしょう。ホストEは再度通知を有効にし、通知先に通知を送るよう設定します。
どちらのホストもネットワークを監視していない正確な時間を測定するのは難しいです。監視していない時間を極力短くすることは(ホストE上で)ホストAのNagiosプロセスを監視する頻度を増やすことで極力短くすることで可能であることは明白です。あと考えられるのは単純な偶然によるものですが、この"ブラックアウト"した合計時間をあまり気にしてはいけません。
シナリオ2 - 監視のフェイルオーバー化 |
序文
監視のフェイルオーバー化も(上のシナリオ 1で述べた)監視の冗長化とよく似ていますが、わずかに異なります。
目的
監視のフェイルオーバー化の基本的な目的は、マスターホストのNagiosプロセスが稼働している際は、スレーブホストのNagiosプロセスはアイドル状態にしておく事にあります。マスターホストのプロセスが(ホストダウンなどで)停止した場合に、スレーブホストが監視を開始するようにするということです。
シナリオ 1 で述べた、マスター監視ホストがダウンした場合、通知設定を引き継ぐやり方にはいくつかの落とし穴があります。その最大の問題点は、マスターと同じ時間に同じホストやサービスをスレーブホストが監視していると言うことです!これはもし多数のサービスを定義していたら過度のトラフィックや負荷を引き起こす原因になる可能性があります。これからその問題をどのように回避するか説明します・・・。
初期プログラム設定
スレーブホストのexecute_service_checksとenable_notificationsディレクティブでアクティブチェックと通知を無効にします。これによりマスターホストが稼働しNagiosプロセスが実行されている間はスレーブホストから監視や通知を行わなくなります。スレーブホストでは check_external_commandsディレクティブを有効にしているか確認するのを忘れないようにしてください。
マスタープロセスチェック
スレーブホスト上でマスターホストのNagiosプロセスをチェックするスクリプトをcronジョブとしてもっとも頻繁に(1分毎)に設定します(マスターのNagiosプロセスの監視にはマスターホストでnrpe デーモンとcheck_nagiosを使いスレーブホストでcheck_nrpeプラグインを走らせます)。そのスクリプトは check_nrpe pluginから帰ってくるリターンコードをチェックします。もしリターンコードがnon-OKステートなら、そのスクリプトが外部コマンドファイルに通知とアクティブサービスチェックを有効にするように書き込みます。もしプラグインがOKステートを返したなら、そのスクリプトは外部コマンドファイルに通知とアクティブチェックを無効にするよう書き込みます。
このように行うことで、一度のサービス・ホスト監視に1つのプロセスだけがチェックすることになり、すべてを2回行うより遙かに効率的です。
同じく注意して欲しいのは、シナリオ 1で述べたホストとサービスのハンドラを定義してはいけない事です。なぜならこれらは異なるやり方だからです。
さらなる議論
ここでは、非常に基本的な監視のフェイルオーバー化を実装しました。しかしながら、事態をスムーズに行うために考慮すべき点が1つあります。
これまでの設定方法での最大の問題点は監視を引き継ぐ際に現在のホスト・サービスの状態は引き継がない点にあります。 この問題を解決する1つの方法としてはマスターホストでocspコマンドを有効にし、 nsca アドオンを使いスレーブホストへサービスチェックの結果を送る方法があります。 これによりスレーブホストは常に最新の監視ステータスを持つことが可能になります。 スレーブホスト上ではアクティブサービスチェックが無効になっているので、どんなサービスチェックも実行されません。 しかし、必要ならホストチェックしましょう。 これはマスターとスレーブのホストチェックが必要だという事を意味し、 監視の大部分はサービスチェックなのでたいした影響はありません。
設定に関してはおおよそこのくらいです。