冗長系とフェールオーバーのネットワーク監視

導入 Introduction

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

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

index

前提条件

サンプルスクリプト

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

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

前提条件　(Prerequisites)

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

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

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

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

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

導入 Introduction

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

目的 Goals

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

Nagiosを実行している"マスター"ホストがダウンしている･･･。または、･･･
"マスター"上の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プロセスを監視する頻度を増やすことで極力短くすることで可能であることは明白です。あと考えられるのは単純な偶然によるものですが、この" ブラックアウト"した合計時間をあまり気にしてはいけません。

冗長系とフェールオーバーのネットワーク監視

目次

導入 Introduction

index

前提条件　(Prerequisites)

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

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

導入 Introduction

目的 Goals

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

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

初期設定 Initial Configuration

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

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

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

タイムラグ Time Lags

特殊なケース Special Cases

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

案内メニュー

個人用ツール

名前空間

変種

表示

その他

検索

案内

ツール

冗長系とフェールオーバーのネットワーク監視

目次

導入 Introduction

index

前提条件 (Prerequisites)

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

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

導入 Introduction

目的 Goals

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

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

初期設定 Initial Configuration

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

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

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

タイムラグ Time Lags

特殊なケース Special Cases

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

案内メニュー

検索

前提条件　(Prerequisites)

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

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