「冗長系とフェールオーバーのネットワーク監視」の版間の差分

2010年9月3日 (金) 11:20時点における最新版

導入 Introduction

このセクションでは、様々なタイプのネットワークレイアウトで冗長化監視を実現するためのいくつかのシナリオについて述べます。冗長化ホストを使うことにより、Nagiosを実行する主要なホストがダウンしたりする場合や、ネットワークの一部に到達できなくなる場合に、あなたのネットワークを監視機能を維持することができます。

もし、Nagiosの使用方法を学んでいるところであれば私が示した 前提条件になれるまでは、冗長化を試さないように提案します。 冗長化は、理解するのに比較的複雑な問題であり、適切に実行させるのも難しいのです

index

前提条件

サンプルスクリプト

シナリオ 1 - 監視の冗長化

シナリオ 2 - 監視のフェイルオーバー化

前提条件　(Prerequisites)

冗長化の実装について考える前に、以下をよく知っている必要があります...

• ホストとサービスのためのイベントハンドラの実装
• Nagiosへシェルスクリプト経由での外部コマンドの発行
• nrpe アドオンまたは、他の方法を利用してリモートホスト・プラグインの実行
• check nagios プラグインを利用してNagiosのプロセスチェック

サンプルスクリプト　(Sample Scripts)

私がこのドキュメントの中で使用するサンプル・スクリプトは、Nagiosディストリビューションのサブディレクトリ内のeventhandlers/ですべて見つけることができます。 ただ、あなたのシステム上で実行させる為には、修正が必要でしょうが･･･。

シナリオ 1 - 監視の冗長化　(Scenario 1 - Redundant Monitoring)

導入 Introduction

この方法は、あなたのネットワーク上で冗長化監視を実装する簡単(かつ素朴な)方法であり、限られたケースの障害にのみ有効です。異なるネットワークセグメントを超える等のより優れた冗長化、より堅牢な冗長化を提供するためには、より複雑なセットアップが必要です。

目的 Goals

ここでの冗長化の目的は単純です。 「マスター」と「スレーブ」の両ホストは、ネットワーク上の同じホストとサービスを監視します。普通の状況の下では、「マスター」ホストだけが通知先に障害に関する"通知"を送るでしょう。私たちは「スレーブ」ホストが、次に挙げるような問題が発生した場合に通知先に通知する仕事を引き継いでNagiosを実行することを望みます。例えば、

1. Nagiosを実行している"マスター"ホストがダウンしている･･･。または、･･･
2. "マスター"上のNagiosプロセスが何かの理由でストップしている･･･、など

ネットワークレイアウトダイアグラム Network Layout Diagram

下記のダイアグラムは非常に単純なネットワークを示しています。このシナリオでは、ホストAおよびホストEがNagiosを実行しており図中のすべてのホストをモニターしている、ことを想定しています。ホストAは「マスター」ホスト、ホストEは「スレーブ」ホストと考えます。

初期プログラム設定 Initial Program Settings

スレーブホスト(ホストE)は初期設定のenable_notificationsディレクティブが無効になっているためホストやサービスの通知は行われません。 同様にスレーブホストはcheck_external_commandsディレクティブを有効にしておきます。これらの設定は簡単でしょう・・・。

初期設定 Initial Configuration

次に、マスターとスレーブのオブジェクト設定概要の違いを見る必要があります・・・。

上のダイヤグラムの全ホストの監視をマスターホスト(ホストA)が行う設定と仮定します。スレーブホスト(ホストE)はマスターホストと同じ監視ホスト、サービスの設定を行う必要があり、それに加えて次の設定を行います・・・。

• TホストA(ホストEの設定ファイルホストAのホスト定義に、イベントハンドラを設定する必要があります。このイベントハンドラの名前は handle-master-host-eventとします。
• ホストEの設定ファイルにホストAのNagiosプロセスを監視するためのサービス定義を記述します。 これは check_nagiosプラグインをホストA上で動かすということと仮定します。 これはこのFAQ通りにやればよいでしょう。(アップデートしてください!).
• ホストAのNagiosプロセスチェックのサービス定義にイベントハンドラを設定します。このイベントハンドラの名前はhandle-master-proc-eventとしておきます。

重要な点としては、ホストA(マスターホスト)はホストE(スレーブホスト)の状態は知らなくても良いということです。このシナリオでは単純にその必要はありません。 もちろん、ホストAからホストEの監視を行いたければやってもかまいませんが、冗長構成にはなんの影響も与えません…。

イベントハンドラコマンド定義 Event Handler Command Definitions

スレーブホスト上に次のようなイベントハンドラをコマンド定義に記述するためちょっと時間を割く必要があります。次に例を挙げます・・・。

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ディレクトリに置くという前提になっています。置き場所はどこでも好きなところで結構ですが、この例をちょっと修正する必要があります。

イベントハンドラスクリプト Event Handler Scripts

それでは、イベントハンドラスクリプトがどんなものか見ていきましょう・・・。

ホストイベントハンドラ (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

サービスイベントハンドラ (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

これらがもたらすもの What This Does For Us

初期状態ではスレーブホスト(ホストE)の通知が無効であるため、マスターホスト(ホストA)のNagiosプロセスが有効である間はどんなホスト、サービス通知も発しません。

スレーブホスト(ホストE)のNagiosプロセスはマスターホストが次のようになったときに有効になります・・・

• マスターホスト(ホストA)がダウンしhandle-master-host-event が実行された時。
• マスターホスト(ホストA)のNagiosプロセスが停止し、handle-master-proc-eventサービスイベントハンドラが実行された時。

スレーブホスト(ホストE)のNagiosプロセスの通知が有効になるため、サービスやホストの障害・復旧時に通知が送られるようになります。この時点で、ホストEがホストやサービスの通知設定を引き継いだということになります!

ホストEのNagiosプロセスが再度スレーブホストに戻る時は次の時です・・・。

• ホストAが復旧し、handle-master-host-eventホストイベントハンドラが実行された時。
• ホストAのNagiosプロセスが復旧し、handle-master-host-event が実行された時。

ホストEのNagiosプロセスの通知が無効になるためサービスやホストの障害・復旧通知は送られなくなります。この段階で、ホストEはホストAに通知を送る権限を受け渡したと言うことになります。すべてが最初の状態に戻ったということになります。

タイムラグ Time Lags

Nagiosの冗長化は決して完璧ではありません。その問題の１つに、マスターホストが停止してスレーブホストに移行するまでのタイムラグが挙げられます。このタイムラグは次の事柄の際に発生します・・・。

• マスターホストが停止し、スレーブホストが初めて問題を検出するまでの時間
• マスターホストで本当に障害発生したか検証するに必要な時間(スレーブホストがサービスやホストチェックを再試行している時間)
• イベントハンドラの実行と次のNagiosからの外部コマンドのチェックまでの間の時間

これらのタイムラグを最小限に抑えるには・・・

• ホストEのNagiosプロセス(再)チェックを1回にするか、もっと頻繁に行う設定にする。この設定はサービス定義のcheck_intervalとretry_intervalオプションで行います。
• ホストAのホスト障害検知を早くするために(ホストE)上でホストAのホストチェック回数を設定する。これはホスト定義のmax_check_attempts引数で設定します。
• ホストE上の外部コマンドチェックの頻度をあげる。 これはメイン設定ファイルのcommand_check_intervalオプションで設定します。

ホストAのNagiosが復旧した時、つまり、ホストEがスレーブホストに戻る前に同様のラグが生じます。このラグは次に影響されます・・。

• ホストAの復旧とホストEのNagiosプロセスがホストAの復旧を検知するのにかかる時間。
• ホストBのイベントハンドラが実行され、ホストEのNagiosプロセスが次に外部コマンドをチェックする間の時間。

Nagiosが監視権限を移行する際の実際のタイムラグは定義したサービスの数に依存しています(サービスチェック間隔や偶然性など)。とにかく、まったく冗長が無いよりはましでしょう。

特殊なケース Special Cases

ここで一つ知っておくべき事を挙げます・・・。もしホストAがダウンした場合、ホストEは障害通知を有効にし、通知を送る責任を引き継ぎます。ホストAが復旧した時、ホストEは通知が無効になります。もし、- ホストAが復旧した時で - ホストAのNagiosプロセスが適切に起動しなかったら、どちらのホストも通知が有効にならない時間ができるでしょう！幸い、Nagiosのサービスチェックロジックはこの現象について解決できます。次に、ホストEのNagiosプロセスがホストAのNagiosプロセスをチェックする際にホストAのNagiosプロセスが稼働していないことを検知するでしょう。ホストEは再度通知を有効にし、通知先に通知を送るよう設定します。

どちらのホストもネットワークを監視していない正確な時間を測定するのは難しいです。監視していない時間を極力短くすることは(ホストE上で)ホストAの Nagiosプロセスを監視する頻度を増やすことで極力短くすることで可能であることは明白です。あと考えられるのは単純な偶然によるものですが、この" ブラックアウト"した合計時間をあまり気にしてはいけません。

シナリオ2 - 監視のフェイルオーバー化 (Scenario 2 - Failover Monitoring)

導入 Introduction

監視のフェイルオーバー化も(上のシナリオ1)で述べた)監視の冗長化とよく似ていますが、わずかに異なります。

目的 Goals

監視のフェイルオーバー化の基本的な目的は、マスターホストのNagiosプロセスが稼働している際は、スレーブホストのNagiosプロセスはアイドル状態にしておく事にあります。マスターホストのプロセスが(ホストダウンなどで)停止した場合に、スレーブホストが監視を開始するようにするということです。

シナリオ1で述べた、マスター監視ホストがダウンした場合、通知設定を引き継ぐやり方にはいくつかの落とし穴があります。その最大の問題点は、マスターと同じ時間に同じホストやサービスをスレーブホストが監視していると言うことです！これはもし多数のサービスを定義していたら過度のトラフィックや負荷を引き起こす原因になる可能性があります。これからその問題をどのように回避するか説明します・・・。

初期プログラム設定 Initial Program Settings

スレーブホストのexecute_service_checksとenable_notificationsディレクティブでアクティブチェックと通知を無効にします。これによりマスターホストが稼働しNagiosプロセスが実行されている間はスレーブホストから監視や通知を行わなくなります。スレーブホストでは check_external_commandsディレクティブを有効にしているか確認するのを忘れないようにしてください。

マスタープロセスチェック Master Process Check

スレーブホスト上でマスターホストのNagiosプロセスをチェックするスクリプトをcronジョブとしてもっとも頻繁に(1分毎)に設定します(マスターのNagiosプロセスの監視にはマスターホストでnrpeデーモンとcheck_nagiosを使いスレーブホストでcheck_nrpeプラグインを走らせます)。そのスクリプトはcheck_nrpeプラグインから帰ってくるリターンコードをチェックします。もしリターンコードがnon-OKステートなら、そのスクリプトが外部コマンドファイルに通知とアクティブサービスチェックを有効にするように書き込みます。もしプラグインがOKステートを返したなら、そのスクリプトは外部コマンドファイルに通知とアクティブチェックを無効にするよう書き込みます。

このように行うことで、一度のサービス・ホスト監視に1つのプロセスだけがチェックすることになり、すべてを2回行うより遙かに効率的です。

同じく注意して欲しいのは、シナリオ1で述べたホストとサービスのハンドラを定義してはいけない事です。なぜならこれらは異なるやり方だからです。

さらなる議論 Additional Issues

ここでは、非常に基本的な監視のフェイルオーバー化を実装しました。しかしながら、事態をスムーズに行うために考慮すべき点が1つあります。

これまでの設定方法での最大の問題点は監視を引き継ぐ際に現在のホスト･サービスの状態は引き継がない点にあります。この問題を解決する1つの方法としてはマスターホストでocspコマンドを有効にし、nscaアドオンを使いスレーブホストへサービスチェックの結果を送る方法があります。これによりスレーブホストは常に最新の監視ステータスを持つことが可能になります。スレーブホスト上ではアクティブサービスチェックが無効になっているので、どんなサービスチェックも実行されません。しかし、必要ならホストチェックしましょう。これはマスターとスレーブのホストチェックが必要だという事を意味し、監視の大部分はサービスチェックなのでたいした影響はありません。

設定に関してはこれぐらいで十分でしょう。