レベル: 中級 Vallard Benincosa, Certified Technical Sales Specialist, IBM
2009年 03月 25日 2 回の記事からなるこの連載では、オープンソースのツール、Ganglia と Nagios を使ってデータ・センターを監視する実践的な方法を取り上げます。第 2 回のこの記事で説明するのは、Nagios をインストールして構成する方法です。Nagios は、コンピューター・システムおよびネットワークを監視するためのアプリケーションとしてよく使われているオープンソースのソフトウェアで、ホストとサービスを監視し、問題が発生するとユーザーにアラートを出します。この記事ではまた、Nagios に第 1 回で説明した Ganglia を統合し、標準クラスター、グリッド、そしてクラウドに対応するための 2 つの機能を Nagios に追加して、ネットワーク・スイッチとリソース・マネージャーの監視を支援する方法についても説明します。
第 1 回の復習
データ・センターが拡大して管理スタッフが足りなくなってくると、コンピューティング・リソースを効率的に監視するツールが必要になってきます。この連載の第 1 回では、Ganglia と Nagios を併せて使用する上での利点を説明した後、Ganglia をインストールして、独自の監視スクリプトで拡張する方法を紹介しました。
ここで、第 1 回で説明した監視のさまざまな定義 (誰がこの言葉を使い、誰が聞くかによって異なる定義) を思い出してください。
- クラスターでアプリケーションを実行しているユーザーの考え: 「自分のジョブはいつ実行されるのか、いつ完了するのか、前回と比べてジョブのパフォーマンスはどんな具合か」
- ネットワーク・オペレーション・センターのオペレーターの考え: 「対応する必要のある障害が発生していることを意味する赤いライトが点灯するのはいつか、そしてサービスが要請されるのはいつか」
- システム・エンジニアリング・グループのメンバーの考え: 「マシンのパフォーマンスはどんな具合か、すべてのサービスが正常に機能しているか、コンピューティング・リソースの使用状況にはどのような傾向が見られるか、そしてリソースの使用を効率化するにはどうすればよいか」
監視したい対象そのものを監視するためのコードは、数あるオープンソースのなかに見つかるはずですが、オープンソースの監視ツールを使用する上で最も難しい部分は、監視ツールをインストールしてから、それぞれの環境に合わせて適切に機能させるにはどのような構成にすればよいかを突き止めるところにあります。なぜなら、オープンソースの (および商用の) 監視ツールには以下の 2 つの大きな問題があるからです。
- ユーザーが監視したいあらゆる対象を、ユーザーの思うように監視するツールは 1 つもありません。
- データ・センターでツールを思うように機能させるためには大量のカスタマイズが必要となる場合があります。
Ganglia は、データ・センターの監視用ツールで、ハイパフォーマンス・コンピューティング環境で盛んに使用されています (ただし、クラウドやレンダー・ファーム、そしてホスト・センターなどといった他の環境にとっても魅力的なツールです)。アラート・メカニズムとしての役割に重点を置いている Nagios とは異なり、Ganglia はメトリックの収集、そして収集したメトリックの追跡に重点を置いています。以前の Ganglia では、ホストから情報を収集するためにホストごとにエージェントを実行しなければなりませんでしたが、現在は Ganglia のスプーフィング・メカニズムによって、ありとあらゆる対象からメトリックを取得できるようになっています。Ganglia には通知システムは組み込まれていませんが、代わりにターゲット・ホストでスケーラブルな組み込みエージェントをサポートするように設計されています。
第 1 回を読んだ皆さんは、Ganglia をインストールできるだけでなく、さまざまなユーザー・グループからの監視に関する質問に答えられるようになっているはずです。また、基本的な Ganglia セットアップを構成してから Python モジュールを使って IPMI (Intelligent Platform Management Interface) で機能を拡張し、Ganglia ホスト・スプーフィングを利用して IPMI を監視することもできるはずです。
第 1 回を復習し終えたところで、ここからは Nagios に目を向けます。
Nagios の紹介
今回は、Nagios をインストールする方法、そして Ganglia を Nagios と連動させる方法を説明します。Nagios には、標準クラスター、グリッド、クラウド (あるいは、その他のスケールアウト・コンピューティングを意味するお好みの流行語を使ってもかまいません) での監視作業に役立つように 2 つの機能を追加します。2 つの機能とは、以下を対象とした機能です。
- ネットワーク・スイッチの監視
- リソース・マネージャーの監視
この例では、TORQUE を監視します。一連の手順が完了した暁には、データ・センター全体の監視システムを制御するためのフレームワークが完成します。
Nagios は Ganglia と同じく、HPC や他の環境で盛んに使用されていますが、メトリックの収集と追跡に重点を置いている Ganglia とは異なり、Nagios ではアラート・メカニズムに重点が置かれています。以前の Nagios ではターゲット・ホストから情報をポーリングしていただけですが、最近になって開発されたプラグインにより、ターゲット・ホストでエージェントを実行できるようになっています。また、Nagios には通知システムが組み込まれています。
早速 Nagios をインストールして、HPC Linux® クラスターのベースライン監視システムをセットアップしてみましょう。このシステムは、三者三様に定義された監視に対応します。
- アプリケーションのユーザーは、キューがどの程度いっぱいになっているかを表示し、ジョブを実行するために使用可能なノードを確認できるようになります。
- NOC では、Nagios Web インターフェース上でシステム障害のアラートや赤く光るエラー表示を見られるようになります。また、ノードがダウンしている場合や、温度が高くなりすぎた場合には、E メールで通知されることになります。
- システム・エンジニアは、取得したデータをグラフ化し、クラスターの使用状況に関するレポートを作成して、今後のハードウェア購入について決定できるようになります。
Nagios のインストール方法
マシン上で Nagios を動作させるための手順についてはインターネットに十分な資料がありますが、私はさまざまな環境に Nagios をインストールしやすいように、インストール・スクリプトを作成しました。
まず始めに、以下の 2 つのパッケージをダウンロードする必要があります。
- Nagios (バージョン 3.0.6 でテスト済み)
- Nagios プラグイン (バージョン 1.4.13 でテスト済み)
アドオンには以下のものがあります。
- Nagios Event Log: Windows イベント・ログの監視を可能にするためのアドオンです。
- NRPE: Ganglia 機能の多くを提供します。
tarball を取得してディレクトリーに配置します。例えば、私の /tmp ディレクトリーには以下の 3 つのファイルが配置されています。
- nagios-3.0.6.tar.gz
- nagios-plugins-1.4.13.tar.gz
- naginstall.sh
リスト 1 に、naginstall.sh インストール・スクリプトを記載します。
リスト 1. naginstall.sh スクリプト
#!/bin/ksh
NAGIOSSRC=nagios-3.0.6
NAGIOSPLUGINSRC=nagios-plugins-1.4.13
NAGIOSCONTACTSCFG=/usr/local/nagios/etc/objects/contacts.cfg
NAGIOSPASSWD=/usr/local/nagios/etc/htpasswd.users
PASSWD=cluster
OS=foo
function buildNagiosPlug {
if [ -e $NAGIOSPLUGINSRC.tar.gz ]
then
echo "found $NAGIOSPLUGINSRC.tar.gz building and installing Nagios"
else
echo "could not find $NAGIOSPLUGINSRC.tar.gz in current directory."
echo "Please run $0 in the same directory as the source files."
exit 1
fi
echo "Extracting Nagios Plugins..."
tar zxf $NAGIOSPLUGINSRC.tar.gz
cd $NAGIOSPLUGINSRC
echo "Configuring Nagios Plugins..."
if ./configure --with-nagios-user=nagios --with-nagios-group=nagios
-prefix=/usr/local/nagios > config.LOG.$$ 2>&1
then
echo "Making Nagios Plugins..."
if make -j8 > make.LOG.$$ 2>&1
then
make install > make.LOG.$$ 2>&1
else
echo "Make failed of Nagios plugins. See $NAGIOSPLUGINSRC/make.LOG.$$"
exit 1
fi
else
echo "configure of Nagios plugins failed. See config.LOG.$$"
exit 1
fi
echo "Successfully built and installed Nagios Plugins!"
cd ..
}
function buildNagios {
if [ -e $NAGIOSSRC.tar.gz ]
then
echo "found $NAGIOSSRC.tar.gz building and installing Nagios"
else
echo "could not find $NAGIOSSRC.tar.gz in current directory."
echo "Please run $0 in the same directory as the source files."
exit 1
fi
echo "Extracting Nagios..."
tar zxf $NAGIOSSRC.tar.gz
cd $NAGIOSSRC
echo "Configuring Nagios..."
if ./configure --with-command-group=nagcmd > config.LOG.$$ 2>&1
then
echo "Making Nagios..."
if make all -j8 > make.LOG.$$ 2>&1
then
make install > make.LOG.$$ 2>&1
make install-init > make.LOG.$$ 2>&1
make install-config > make.LOG.$$ 2>&1
make install-commandmode > make.LOG.$$ 2>&1
make install-webconf > make.LOG.$$ 2>&1
else
echo "make all failed. See log:"
echo "$NAGIOSSRC/make.LOG.$$"
exit 1
fi
else
echo "configure of Nagios failed. Please read $NAGIOSSRC/config.LOG.$$ for details."
exit 1
fi
echo "Done Making Nagios!"
cd ..
}
function configNagios {
echo "We'll now configure Nagios."
LOOP=1
while [[ $LOOP -eq 1 ]]
do
echo "You'll need to put in a user name. This should be the person"
echo "who will be receiving alerts. This person should have an account"
echo "on this server. "
print "Type in the userid of the person who will receive alerts (e.g. bob)> \c"
read NAME
print "What is ${NAME}'s email?> \c"
read EMAIL
echo
echo
echo "Nagios alerts will be sent to $NAME at $EMAIL"
print "Is this correct? [y/N] \c"
read YN
if [[ "$YN" = "y" ]]
then
LOOP=0
fi
done
if [ -r $NAGIOSCONTACTSCFG ]
then
perl -pi -e "s/nagiosadmin/$NAME/g" $NAGIOSCONTACTSCFG
EMAIL=$(echo $EMAIL | sed s/\@/\\\\@/g)
perl -pi -e "s/nagios\@localhost/$EMAIL/g" $NAGIOSCONTACTSCFG
else
echo "$NAGIOSCONTACTSCFG does not exist"
exit 1
fi
echo "setting ${NAME}'s password to be 'cluster' in Nagios"
echo " you can change this later by running: "
echo " htpasswd -c $NAGIOSPASSWD $Name)'"
htpasswd -bc $NAGIOSPASSWD $NAME cluster
if [ "$OS" = "rh" ]
then
service httpd restart
fi
}
function preNagios {
if [ "$OS" = "rh" ]
then
echo "making sure prereqs are installed"
yum -y install httpd gcc glibc glibc-common gd gd-devel perl-TimeDate
/usr/sbin/useradd -m nagios
echo $PASSWD | passwd --stdin nagios
/usr/sbin/groupadd nagcmd
/usr/sbin/usermod -a -G nagcmd nagios
/usr/sbin/usermod -a -G nagcmd apache
fi
}
function postNagios {
if [ "$OS" = "rh" ]
then
chkconfig --add nagios
chkconfig nagios on
# touch this file so that if it doesn't exist we won't get errors
touch /var/www/html/index.html
service nagios start
fi
echo "You may now be able to access Nagios at the URL below:"
echo "http://localhost/nagios"
}
if [ -e /etc/redhat-release ]
then
echo "installing monitoring on Red Hat system"
OS=rh
fi
# make sure you're root:
ID=$(id -u)
if [ "$ID" != "0" ]
then
echo "Must run this as root!"
exit
fi
preNagios
buildNagios
buildNagiosPlug
configNagios
postNagios
|
./naginstall.sh スクリプトを実行してください。
このコードは Red Hat システム上で動作するので、連載第 1 回で説明したすべての依存関係がインストールされていれば正常に動作するはずです。naginstall.sh の実行中には、Nagios がアラートを送信する対象ユーザーを入力するよう求めるプロンプトが出されます。送信先ユーザーには、後から他のユーザーを追加することもできます。大抵の組織には、あるグループの人々にまとめて送信するためのメール・エイリアスがあるはずです。
インストールの際に問題が発生した場合には、Nagios Web ページ (「参考文献」にリンクを記載) を調べて、メーリング・リストに加わってください。私の経験から言うと、Nagios や Ganglia のように普及しているパッケージのほとんどは、比較的簡単にインストールすることができます。
Nagios の構成方法
インストール・スクリプトが問題なく機能し、すべてが完璧にインストールされたとします。スクリプトが正常に終了すると、Web ブラウザーを開いてローカル・ホストが監視されていることを確認できるはずです (図 1 を参照)
図 1. 監視中のローカル・ホストを表示する画面
Service Detail をクリックすると、ローカル・マシン上の複数のサービス (Ping、HTTP、負荷、ユーザーなど) を監視中であることがわかります。これは、デフォルトによる構成です。
ここで、Root Partition というサービスについて検討してみましょう。このサービスは、ルート・パーティションがフルになるとアラートを出すサービスです。このルート・パーティション・チェックがどのような動作をしているかを完全に理解するには、インストール時に生成された構成ファイルを調べます。
マスター構成ファイル
インストールに naginstall.sh スクリプトを使用した場合、マスター構成ファイルは /usr/local/nagios/etc/nagios.cfg に置かれます。このスクリプトには、追加の定義が設定された複数の cfg_files が示されています。以下は、そのうちの 1 行です。
cfg_file=/usr/local/nagios/etc/objects/localhost.cfg
上記のファイルを調べると、Web ビューに表示されているローカル・ホストのサービスすべてが含まれていることがわかります。つまり、デフォルト・サービスの構成はこのファイルのなかで行われているということです。Root Partition の定義は、行 77 にあります。
ルート・パーティション・チェックの階層は、図 2 のように構成されています。
図 2. ルート・パーティション・チェックの構成
まずは、Nagios オブジェクトの継承スキーマに注目してください。ルート・パーティションの定義はローカル・サービス定義を使用し、ローカル・サービス定義は汎用サービス定義を使用します。これにより、サービスを呼び出す方法と頻度、そしてその他の調整可能なパラメーターなどが定義されます。
この定義で次に重要な部分は、サービスが使用するチェック・コマンドです。ルート・パーティション・サービスは最初に check_local_disk というコマンド定義を使用し、パラメーターとして !20%!10%!/ を渡します。その意味は、サービスは check_local_disk コマンド定義が 20% をレポートすると警告を出し、10% をレポートすると致命的なエラーとなります。/ は、「/」パーティションをチェックしているという意味です。check_local_disk はパラメーターが渡されると、単に /usr/local/nagios/libexec ディレクトリーにある check_disk コマンドを呼び出します。
以上が、構成のセットアップ方法についての基本的な概念です。この概念を用いれば、必要な任意のパラメーターを監視して調整する独自のサービスを作成することができます。さらに詳しい動作内容を理解するには、ドキュメントを読んで、パラメーターのいくつかを実際に自分で試してみてください。
アラートを受けるためのサインアップ
構成がすべて完了したら、次はアラートにサインアップします。アラートの送信先ユーザーは最初の段階ですでに指定してありますが、/usr/local/nagios/etc/objects/contacts.cfg ファイルを変更することで、ユーザーを変更または追加することができます。必要な作業は、連絡先の名前と E メール・アドレスを自分の名前とアドレスに変更するだけです。基本的な Linux サーバーのほとんどは、すでにメールを処理するようにセットアップされているはずです。
次は、他のノードを構成します。
grid/cloud/cluster での他のノードの構成
私のダラス (Dallas) データ・センターには、一連のノードがあります。そこで、すべての構成ファイルを配置するディレクトリーを作成するために、以下の内容を実行します。
mkdir -p /usr/local/nagios/etc/dallas
Nagios には、このディレクトリーに構成ファイルが配置されることを伝えなければなりません。それには、nagios.cfg ファイルを変更して以下の行を追加します。
cfg_dir=/usr/local/nagios/etc/dallas
このディレクトリーには、かなり混乱しがちないくつかのファイルを作成します。図 3 に、エンティティーと、それぞれのエンティティーが属するファイルを示し、オブジェクト間の関係を明らかにします。
図 3. エンティティーとそれぞれが属するファイルの図
この図を念頭に置きながら、この後のセットアップとインストール手順を進めてください。
/usr/local/nagios/etc/dallas/nodes.cfg ファイルには、すべてのノードとノード・グループを定義します。監視対象のマシンには、以下の 3 つのタイプがあります。
- ネットワーク・サーバー (私の場合、該当するのは Linux サーバーで、これらのサーバーで Ganglia を実行しています。)
- ネットワーク・スイッチ (私が使用しているスイッチは、高速ギガビット・イーサネット対応です。)
- 管理デバイス (ブレード管理モジュール、古い IBM RSA カード、BMC、あるいはスマート PDU など)
上記に対応する 3 つのグループを作成します。
define hostgroup {
hostgroup_name dallas-cloud-servers
alias Dallas Cloud Servers
}
define hostgroup
hostgroup_name dallas-cloud-network
alias Dallas Cloud Network Infrastructure
}
define hostgroup
hostgroup_name dallas-cloud-management
alias Dallas Cloud Management Devides
}
|
次に作成するのは、これらのノード・グループのノードが共有する一般特性を持つ 3 つのテンプレート・ファイルです。
define host {
name dallas-management
use linux-server
hostgroups dallas-cloud-management
# TEMPLATE!
register 0
}
define host {
name dallas-server
use linux-server
hostgroups dallas-cloud-servers
# TEMPLATE!
register 0
}
define host {
name dallas-network
use generic-switch
hostgroups dallas-cloud-network
# TEMPLATE!
register 0
}
|
これで、個々のノード定義は dallas-management、dallas-server、または dallas-network のいずれかになります。それぞれの例を以下に示します。
define host {
use dallas-server
host_name x336001
address 172.10.11.1
}
define host {
use dallas-network
host_name smc001
address 172.10.0.254
}
define host {
use dallas-management
host_name x346002-rsa
address 172.10.11.12
}
|
これらのノードのリストを調べ、ダラス・ラボにあるノードを該当するファイルに完全に設定するスクリプトを生成しました。Nagios を再起動すると、すべてのノードがチェックされ、到達可能かどうかが確認されます。しかしその前に、他にも追加しなければならないサービスがあります。
まず Nagios を再起動して、設定が適用されていることを確認する必要があります。設定が適用されていれば、HostGroup Overview ビューにグループが表示されるはずです。エラーが出た場合には、以下を実行してください。
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
上記を実行するとファイルが検証され、エラーを探してくれます。
これで、基本サービスを追加する準備が整いました。ローカル・ホストのテンプレートに従うと、簡単に実行できるサービスは、dallas-cloud-servers グループでの SSH チェックです。このサービス用に新しいファイル、/usr/local/nagios/etc/dallas/host-services.cfg を作成するところから取り掛かることにしましょう。それには、監視対象のローカル・ホストから構成をコピーするのが手っ取り早い方法です。以下に、構成をコピーしてから依存関係を追加した host-services.cfg ファイルを記載します。
define service{
use generic-service
hostgroup_name dallas-cloud-servers
service_description SSH
check_command check_ssh
}
define service{
use generic-service
hostgroup_name dallas-cloud-servers
service_description PING
check_command check_ping!100.0,20%!500.0,60%
}
define servicedependency{
hostgroup_name dallas-cloud-servers
service_description PING
dependent_hostgroup_name dallas-cloud-servers
dependent_service_description SSH
}
|
PING が上手くいかなかった場合には、SSH のテストは不要だと判断しました。これをベースにして、あらゆる類の構成を追加することができますが、その前に確認しなければならないことがあります。以下のコマンドを実行して変更を反映させるか、Nagios を再起動するかしてメニューをテストし、ping と ssh によるノードのチェックが正常に行われることを確認してください。
service nagios reload
すべて順調ですか？次の手順ではいよいよ興味深い段階に進んで、Ganglia を統合します。
Ganglia メトリックをレポートする機能の Nagios への統合
Nagios のプラグインの入手先としては Nagios Exchange も絶好の場所ですが、今回 Nagios に追加する Ganglia プラグインとしては、連載第 1 回でダウンロードした tarball があれば十分です。tarball を /tmp ディレクトリーに解凍してある場合、以下のように contrib ディレクトリーに置かれている check_ganglia.py スクリプトをコピーするだけで Ganglia プラグインを追加することができます。
cp /tmp/ganglia-3.1.1/contrib/check_ganglia.py \
/usr/local/nagios/libexec/
|
check_ganglia は優れた Python スクリプトで、gmetad を実行しているサーバーと同じサーバー上で動作します (私の場合、これに該当するのは管理サーバーで、ここでは Nagios も実行されています)。このスクリプトには、ローカル・ホストのポート 8649 に対して問い合わせを行わせます。こうすれば、リモート・コマンドを実行することによってネットワーク・トラフィックを浪費せずに、Ganglia を拡張することによるメリットを活かせることになります。
telnet localhost 8649 を実行すると、ノード上に、すべてのノードで収集されたデータからの大量の出力が表示されます (第 1 回の手順に従って Ganglia が稼働中になっているという前提です)。ここで、Ganglia が用意しているいくつかのメトリックを監視してみましょう。
/var/lib/ganglia/rrds ディレクトリーの奥まで進んでいくと、各ホストで測定中のメトリックがいくつか見つかります。わかりやすいグラフが生成されていて、メトリックの時間変化を分析することができます。これらのメトリックのうち、これから load_one、disk_free を測定することにします。さらに、第 1 回で有効にした IPMI 温度測定も加えます。
/usr/local/nagios/etc/dallas/ganglia-services.cfg ファイルを作成して、以下のようにサービスを追加します。
define servicegroup {
servicegroup_name ganglia-metrics
alias Ganglia Metrics
}
define command {
command_name check_ganglia
command_line $USER1$/check_ganglia.py -h $HOSTNAME$ -m $ARG1$ -w $ARG2$ -c $ARG3$
}
define service {
use generic-service
name ganglia-service
hostgroup_name dallas-cloud-servers
service_groups ganglia-metrics
notifications_enabled 0
}
define service {
use ganglia-service
service_description load_one
check_command check_ganglia!load_one!4!5
}
define service {
use ganglia-service
service_description ambient_temp
check_command check_ganglia!AmbientTemp!20!30
}
define service {
use ganglia-service
service_description disk_free
check_command check_ganglia!disk_free!10!5
}
|
Nagios を再起動すると、Ganglia メトリックに関するアラートが有効になります。
1 つ注意する点として、check_ganglia.py コマンドはしきい値が高くなり過ぎた場合にしかアラートを出しません。disk_free の場合と同様に、しきい値が低くなり過ぎた時にもアラートを出すには、コードに手を加える必要があります。そこで、ファイルの終わりを以下のように変更しました。
if critical > warning:
if value >= critical:
print "CHECKGANGLIA CRITICAL: %s is %.2f" % (metric, value)
sys.exit(2)
elif value >= warning:
print "CHECKGANGLIA WARNING: %s is %.2f" % (metric, value)
sys.exit(1)
else:
print "CHECKGANGLIA OK: %s is %.2f" % (metric, value)
sys.exit(0)
else:
if critical >= value:
print "CHECKGANGLIA CRITICAL: %s is %.2f" % (metric, value)
sys.exit(2)
elif warning >= value:
print "CHECKGANGLIA WARNING: %s is %.2f" % (metric, value)
sys.exit(1)
else:
print "CHECKGANGLIA OK: %s is %.2f" % (metric, value)
sys.exit(0)
|
Nagios を再ロードしてください。
service nagios restart
すべて順調に行けば、Nagios によって監視中の Ganglia データが表示されるはずです。
図 4. Nagios による Ganglia データの監視
Ganglia と Nagios が連動するようになった今、ほとんどすべてのメトリックを監視できるようになりました。あなたがクラウドの支配者になったわけです。
Nagios の拡張: ネットワーク・スイッチの監視
クラウドと仮想化がごく一般的に利用されるようになっているなか、これまで「ネットワーク担当者」と「システム担当者」の間に引かれていた一線があいまいになってきています。システム管理者がネットワーク・スイッチの構成を無視し続け、ネットワーク・トポロジーについて理解しようとしなければ、時代に取り残されてしまう危険があります。
そこで、皆さんが不完全さに直面することがないように、これからネットワーク・スイッチを監視するように Nagios を拡張する方法を紹介します。スイッチのベンダーによるソリューションにだけ依存するのではなく、Nagios を使ってネットワーク・スイッチを監視する上での利点は、その単純さにあります。Nagios ではあらゆるベンダーのスイッチを監視することができます。ping が機能することは確認したので、今度はスイッチでの SNMP を調べます。
一部のスイッチは、デフォルトで SNMP が有効になっています。SNMP は、ベンダーの指示に従ってセットアップすることができます。Cisco のスイッチに SNMP をセットアップするには、以下に記載する例に従ってください。これは私のスイッチの場合のセットアップで、このスイッチのホスト名は c2960g です。
telnet c2960g
c2960g>enable
c2960g#configure terminal
c2960g(config)#snmp-server host 192.168.15.1 traps SNMPv1
c2960g(config)#snmp-server community public
c2960g(config)#exit
c2960g#copy running-config startup-config
|
何を監視できるのかを確認するには、以下のように snmpwalk を実行してファイルに接続します。
snmpwalk -v 1 -c public c2960g
何も問題がなければ、大量の情報が出力されます。この出力を保存すれば、監視対象となっているさまざまな場所を調べることができます。
ここで、もう 1 つ別のスイッチを例として使用します。snmpwalk コマンドを実行すると、ポートとそれぞれのラベルが表示されます。私が取得したいのは、以下の情報です。
- MTU (
IF-MIB::ifMtu.<portnumber>)
- ポートの動作速度 (
IF-MIB::ifSpeed.<port number>)
- ポートが作動しているかどうか (
IF-MIB::ifOperStatus.<port number>)
上記を監視するため、/usr/local/nagios/etc/dallas/switch-services.cfg という新しいファイルを作成します。ネットワーク・ホストとスイッチとの間の対応表があるので、何がどこにあるのかはわかります。このような対応表をまだ用意していないとしたら、ぜひ用意してください。本物のクラウドにしたければ、すべてのリソースが既知の状態でなければなりません。
ここでは一例として、ノード x336001 を使用します。このノードはポート 5 にあることがわかっています。この場合の switch-services.cfg ファイルの中身は以下のようになります。
define servicegroup {
servicegroup_name switch-snmp
alias Switch SNMP Services
}
define service {
use generic-service
name switch-service
host_name smc001
service_groups switch-snmp
}
define service {
use switch-service
service_description Port5-MTU-x336001
check_command check_snmp!-o IF-MIB::ifMtu.5
}
define service {
use switch-service
service_description Port5-Speed-x336001
check_command check_snmp!-o IF-MIB::ifSpeed.5
}
define service {
use switch-service
service_description Port5-Status-x336001
check_command check_snmp!-o IF-MIB::ifOperStatus.5
}
|
完了したら、Nagios を再起動してください。すると、スイッチのエントリーが表示されます。
図 5. スイッチの監視
以上は、スイッチを監視する方法の一例でしかありません。この例ではアラートも設定していなければ、クリティカル・アクションの内容も指定していないことに注意してください。また、お気付きかもしれませんが、libexec ディレクトリーには同様のことを実行可能なファイルが他にもあります。check_ifoperstatus を利用したり他の方法で行ったりしても、この目的を達成できることが考えられます。このように、Nagios では 1 つのタスクをさまざまな方法で実現することができます。
Nagios の拡張: TORQUE を監視するためのジョブ・レポートの作成
TORQUE に対しては、さまざまなスクリプトを作成して、このキューイング・システムの動作状況を判断することができます。このセクションで説明する拡張では、TORQUE が稼働中であることを前提とします。TORQUE は、Moab や Maui などのスケジューラーと連動するリソース・マネージャーです。ここでは、Colin Morey が作成したオープンソースの Nagios プラグインを見ていきます。
このプラグインをダウンロードして /usr/local/nagios/libexec ディレクトリーに配置し、実行可能であることを確認してください。このコードには多少手を加え、use lib "/usr/nagios/libexec"; を use lib "/usr/local/nagios/libexec"; に変更することによって、Nagios がインストールされているディレクトリーを変更しなければなりませんでした。また、my $qstat = '/usr/bin/qstat' ; を qstat コマンドがある場所に変更する必要もありました。私の場合は、my $qstat = '/opt/torque/x86_64/bin/qstat' ; となります。
コードが機能することを検証してください (私は dque というキューを使用しています)。
[root@redhouse libexec]# ./check_pbs.pl -Q dque -tw 20 -tm 50
check_pbs.pl Critical: dque on localhost checked, Total number of jobs
higher than 50. Total jobs:518, Jobs Queued:518, Jobs Waiting:0, Jobs
Halted:0 |exectime=9340us
|
-h オプションを使用して、表示する監視対象を追加することもできます。早速、このコードを構成ファイル /usr/local/nagios/etc/dallas/torque.cfg に組み込んでください。
define service {
use generic-service
host_name localhost
service_description TORQUE Queues
check_command check_pbs!20!50
}
define command {
command_name check_pbs
command_line $USER1$/check_pbs.pl -Q dque
-tw $ARG1$ -tm $ARG2$
}
|
Nagios を再起動すると、このサービスがローカル・ホストの下に表示されます。
図 6. Nagios の再起動後に表示されたTORQUE サービス
上記ではクリティカル・アラートが出ていますが、これは、518 個のジョブがキューに入れられているためです。
当然のことながら、TORQUE を追跡する方法や作成できるスクリプト、そしてすでに作成されているスクリプトは他にもあります。pbs ノードを使用してノードのステータスを知らせるスクリプトを作成することさえ可能です。人々は自分のノードがどこで実行されているのか、そしてジョブがどれだけの期間、実行されているかということに、より大きな関心を持つものです。この簡単な例では、実行可能な内容を大まかに伝え、わずかな時間で監視ソリューションをいかに改善できるかを明らかにしただけに過ぎません。
まとめ
システム管理者の方は、この 2 回連載の記事を読んで、Ganglia と Nagios を実行して実際にデータ・センターを監視する (今までにはなかった) 自信がついたはずです。この 2 つのパッケージの適用範囲は計り知れません。今回はそのうち、クラスター、グリッド、あるいはクラウド・インフラストラクチャーに関連する内容に触れてきました。
この監視ソリューションのセットアップでは、そのほとんどの時間が監視対象のサービスを構成する作業に費やされました。すでに存在する多数の代替ソリューションは、いずれも機能を繋ぎ合せるものであって、機能そのものではありません。つまり、ソリューションはプラグインを追加するためのフレームワークを提供するのであって、すでに完成されたプラグインを備えているソリューションはめったにないということです。プラグインに関する作業の大部分は管理者またはユーザーが行わなければならないので、実際にこの監視ソリューションによって優れたデータ・センター監視作業の大半が完成するのであれば、プラグインに関する作業はたいがい平凡なものとなります。
Ganglia と Nagios を組み合わせると、単なるフレームワーク以上のものになります。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | | | Vallard Benincosa は 2001年から HPC クラスターの構築を続けています。IBM がデプロイしている最大規模の計算ファームの多くに取り組んでいる彼は、これまで Ohio Super Computing Center や NASA にあるクラスターを含め、IBM 最大級の Linux クラスターの設計、インストール、管理に携わってきました。 |
記事の評価
| 
