Ganglia と Nagios: 第 1 回 Ganglia でエンタープライズ・クラスターを監視する

オープンソースの Ganglia をインストール、構成、拡張して、効率よくデータ・センターを監視する

2 回の記事からなるこの連載では、オープンソースのツール、Ganglia と Nagios を使ってデータ・センターを監視する実践的な方法を取り上げます。第 1 回のこの記事で説明するのは、階層型設計に基づくハイパフォーマンス・クラスターを対象としたスケーラブルな分散監視システム、Ganglia をインストールして構成する方法です。また、Ganglia プラグインを作成したり、外部ソースのスプーフィングを有効にしたりすることで、監視機能をさらに追加する方法も学んでください。

Vallard Benincosa, Certified Technical Sales Specialist, IBM

Vallard Benincosa は 2001年から HPC クラスターの構築を続けています。IBM がデプロイしている最大規模の計算ファームの多くに取り組んでいる彼は、これまで Ohio Super Computing Center や NASA にあるクラスターを含め、IBM 最大級の Linux クラスターの設計、インストール、管理に携わってきました。



2009年 3月 04日

データ・センターが拡大して管理スタッフが足りなくなってくると、コンピューティング・リソースを効率的に監視するツールの必要性が今まで以上に重要になってきます。この「監視」という言葉は、データ・センターで使用する場合には紛らわしい言葉になりがちです。例えば以下のように、誰がこの言葉を使っているか、そして誰に対して使っているかによって意味が異なってくるからです。

  • クラスターでアプリケーションを実行しているユーザーが監視について考えること: 「自分のジョブはいつ実行されるのか、いつ完了するのか、前回と比べてジョブのパフォーマンスはどんな具合か」
  • ネットワーク・オペレーション・センター (NOC) のオペレーターが監視について考えること: 「対応する必要のある障害が発生していることを意味する赤いライトが点灯するのはいつか、そしてサービスが要請されるのはいつか」
  • システム・エンジニアリング・グループのメンバーが監視について考えること: 「マシンのパフォーマンスはどんな具合か、すべてのサービスが正常に機能しているか、コンピューティング・リソースの使用状況にはどのような傾向が見られるか、そしてリソースの使用を効率化するにはどうすればいいか」

このように定義が錯乱するなかで、あなたは監視したい対象そのものだけを監視するために数テラバイトのコードを調べなければなりません。しかも、それで終わりではありません。製品とサービスは山ほどあります。しかし幸いなことに、監視ツールの多くはオープンソースです。実際、オープンソースのツールのなかには、同じ機能を実現しようとしている市販のアプリケーションより優れているものもあります。

オープンソースの監視ツールを使用する上で最も難しい部分は、自分の環境に応じて機能するようにインストールと構成を行うことです。オープンソースの監視ツールの使用には、以下の 2 つの大きな問題があります。

  • ユーザーが監視したいあらゆる対象を、ユーザーの思うように監視するツールは 1 つもありません。なぜなら、ユーザーが定義する「監視」はそれぞれに異なるからです (前に説明したとおりです)。
  • 上記の問題が理由となって、データ・センターでツールを思うように機能させるためには大量のカスタマイズが必要となる場合があります。なぜなら、環境はどんなに標準的なものであっても、それぞれに固有だからです。

ちなみに、この 2 つの問題は市販の監視ツールにも当てはまります。

そこで、この連載ではデータ・センターを監視する 2 つのツール、Ganglia と Nagios を取り上げたいと思います。どちらもハイパフォーマンス・コンピューティング (HPC) 環境でとてもよく使われているツールですが、それ以外の環境 (クラウド、レンダー・ファーム、ホスト・センターなど) でも魅力的なツールになる性質を備えています。さらに、これらのツールが重点としている監視の定義はそれぞれに異なります。Ganglia はメトリックの収集、そして収集したメトリックの追跡に重点を置いている一方、Nagios はアラート・メカニズムとしての役割に重点を置いています。

それぞれに独立したプロジェクトとして進化したことから、この 2 つでは、以下のように重複して開発された部分があります。

  • Ganglia はかつて、ホストから情報を収集するために、ホストごとにエージェントを実行しなければなりませんでしたが、現在は Ganglia のスプーフィング・メカニズムによって、ありとあらゆる対象からメトリックを取得できるようになっています。
  • Nagios も同じく、ターゲット・ホストだけから情報をポーリングしていましたが、現在はプラグインを使用してエージェントをターゲット・ホストで実行します。

2 つのツールはいくつかの機能領域が似通ってきたものの、両方を実行することによってメリットを得られるだけの違いはまだ十分にあります。2 つを併せて実行することで、以下のように、それぞれの製品に欠けている部分を補うことができます。

  • Ganglia には通知システムが組み込まれていませんが、通知に関しては Nagios が得意とするところです。
  • Nagios にはターゲット・ホスト上にスケーラブルな組み込みエージェントはないようですが (この点については、反論する人もいると思います)、この部分は、Ganglia に元々意図された設計に含まれています。

この 2 つのツールのような機能を持つオープンソース・プロジェクトは他にもあり、それぞれ得意とする分野は異なります。よく使われるオープンソースの監視ソリューションとしては、Cacti、Zenoss、Zabbix、PCP (Performance Copilot)、Clumon などが挙げられます (もちろん、ここで挙げていない読者のお気に入りのソリューションもあるはずです)。その多くは (Ganglia と一部の Nagios プラグインも含め)、RRDTool または Tobi Oetiker の MRTG (Multi Router Traffic Grapher) を使用して、見やすいグラフを生成し、データを保管します。

このように、データ・センターを監視するためのオープンソース・ソリューションは数多くあります。しかし驚くことに、独自のソリューションを開発して他の人々がすでに行った作業を無視しているスケールアウト・コンピューティングによるデータ・センターをよく目にします。

この 2 回連載の記事では、Ganglia と Nagios の 2 つについて説明します。その理由は、この 2 つは最もよく使用されているツールであるという事例証拠があるからです。また、大規模な HPC の研究機関や大学での場合は特にそうですが、この 2 つの統合は極めて一般的な慣例となっています。それにも関わらず、その方法について説明している資料はほとんどありません。

皆さんがこの連載を読み終える頃には、Ganglia をインストールして Nagios と連動させられるようになっているだけでなく、さまざまなユーザー・グループからの監視についての質問にも答えられるようになっているはずです。この連載は出発点でしかありませんが、ここから基本的な知識を身に付けて、クラスターの全体的な構想を発展させてください。

この記事では、以下の内容を説明します。

  • Ganglia をインストールして基本的なセットアップを構成する方法
  • Python モジュールを使用して、IPMI (Intelligent Platform Management Interface) によって機能を拡張する方法
  • Ganglia ホスト・スプーフィングを使用して IPMI を監視する方法

最終的な目標は、先ほど説明した監視に対する 3 通りの見方にある程度対処できる、HPC Linux® クラスターのベースライン監視システムをセットアップすることです。

  • アプリケーションのユーザーは、キューがどの程度いっぱいになっているかを表示し、ジョブを実行するために使用可能なノードを確認できるようになります。
  • NOC では、Nagios Web インターフェースでシステム障害のアラートや赤く光るエラー表示を見られるようになります。また、ノードがダウンしている場合や、温度が高くなりすぎた場合には、E メールで通知されることになります。
  • システム・エンジニアはデータをグラフ化し、クラスターの使用状況に関するレポートを作成して、今後のハードウェア購入について決定できるようになります。

Ganglia の紹介

数千のノードにまで対応できるように設計された Ganglia は、UC Berkeley で立ち上げられたオープンソースの監視プロジェクトによって開発されたツールです。Ganglia ではマシンごとに gmond というデーモンが実行され、この gmond がオペレーティング・オペレーティングから収集したメトリック (プロセッサー速度、メモリー使用状況など) を指定されたホストに送信します。すべてのメトリックを受け取ったホストは、この情報を表示し、1 つの階層にまとめた形で伝播することができます。この階層スキーマこそが、Ganglia が優れたスケーラビリティーを実現できている理由です。gmond のオーバーヘッドはほんのわずかなので、ユーザーのパフォーマンスに影響を与えることなく、クラスター内のすべてのマシンで実行するには理想的なコードとなります。

このデータ収集の仕組み全体が、ノードのパフォーマンスに影響することもあります。それは、多数の小さなメッセージを同時に受信し続けることによって発生する、ネットワーク内の (いわゆる)「ジッター」です。この影響は、ノードのクロックをロックステップ方式で動作させることによって回避できることがわかっています。


Ganglia のインストール方法

Ganglia のインストール方法を説明している記事やリソースはインターネットに溢れています。ここで紹介するのは、私が xCAT ウィキに書いた方法です。この記事では、オペレーティング・システムが Red Hat 5 Update 2 のいずれかのバリエーションであることを前提とします (ただし、他のエンタープライズ Linux オペレーティング・システムの場合でも、手順はそれほど変わらないはずです)。

前提条件

yum リポジトリーがセットアップ済みであれば、前提条件をインストールする手順の大部分は、簡単な作業になるはずです。以下に一例を示します。

yum -y install apr-devel apr-util check-devel cairo-devel pango-devel libxml2-devel
  rpmbuild glib2-devel dbus-devel freetype-devel fontconfig-devel gcc-c++ expat-devel
  python-devel libXrender-devel

(注: yum は、本当はこれらの依存関係のほとんどを処理することになっていますが、私が行ったテストの 1 つでは、コンパイルに失敗しました。この失敗は、すべてのパッケージを追加することによって修正しました)。

上記の依存関係を処理した後は、Red Hat リポジトリーに含まれていないもう 1 つの前提条件が必要になります。この前提条件は、マシンがインターネットに接続していれば、以下のように取得してビルドすることができます。

wget \ http://ga13.files.bigpond.com:4040/fedora/linux/releases/9/Everything/source/
       SRPMS/libconfuse-2.6-1.fc9.src.rpm

rpmbuild --rebuild libconfuse-2.6-1.fc9.src.rpm
cd /usr/src/redhat/RPMS/x86_64/
rpm -ivh libconfuse-devel-2.6-1.x86_64.rpm libconfuse-2.6-1.x86_64.rpm

ミラーは度々変わるので、上記のコードが機能しない場合には、検索エンジンを使って libconfuse-2.6.-1.fc9 のソース RPM を検索してください。

RRDTool

RRDTool とは、Round Robin Database Tool の略です。Tobias Oetiker によって作成されたこのツールが提供するエンジンは、多数のハイパフォーマンス監視ツールに対応します。Ganglia はそのうちの 1 つですが、Cacti と Zenoss には RRDTool は対応していません。

Ganglia をインストールするには、まず、RRDTool が監視サーバーで実行されている状態にする必要があります。RRDTool は、他のプログラムが利用する極めて優れた以下の 2 つの機能を提供します。

  • このツールは、データをラウンドロビン・データベースに格納します。取り込んだデータが古くなると、データが間引きされて古いデータ全体としての解像度が低くなります。こうすることによってほとんどの場合、占有スペースを小さく抑えながらもデータの有効性は維持されます。
  • このツールでは、取り込んだデータからグラフを生成するためのコマンドラインの引数を使用することによって、グラフを作成することができます。

RRDTool をインストールするには、以下のコードを実行します (バージョン1.3.4 および1.3.6 でテストしました)。

cd /tmp/
wget http://oss.oetiker.ch/rrdtool/pub/rrdtool.tar.gz
tar zxvf rrdtool*
cd rrdtool-*
./configure --prefix=/usr
make -j8
make install
which rrdtool
ldconfig  # make sure you have the new rrdtool libraries linked.

RRDTool を環境内でスタンドアロン・ユーティリティーとして使う方法はさまざまにありますが、ここではそれについては触れないことにします。

Ganglia 本体のインストール

すべての前提条件が揃ったところで、Ganglia のインストールに取り掛かります。まずは、このツールを取得しなければなりません。この記事では Ganglia 3.1.1 を使用するので、ganglia-3.1.1.tar.gz ファイルをダウンロードして監視サーバーの /tmp ディレクトリーに置いてください。その上で、以下のコードを実行します。

cd /tmp/
tar zxvf ganglia*gz
cd ganglia-3.1.1/
./configure --with-gmetad
make -j8
make install

エラーなしで終了するはずですが、エラーが表示された場合には、欠けているライブラリーがないかどうかを確認してください。


Ganglia の構成方法

基本的なインストールは完了しましたが、Ganglia を実行させるには、いくつか対処しなければならない構成項目があります。そのため、これから以下のステップを実行します。

  1. コマンドラインでのファイル操作
  2. /etc/ganglia/gmond.conf の変更
  3. マルチホーム・マシンへの対処
  4. 管理サーバーでの起動

ステップ 1: コマンドラインでのファイル操作

以下のように操作します。

cd /tmp/ganglia-3.1.1/   # you should already be in this directory
mkdir -p /var/www/html/ganglia/  # make sure you have apache installed
cp -a web/* /var/www/html/ganglia/   # this is the web interface
cp gmetad/gmetad.init /etc/rc.d/init.d/gmetad  # startup script
cp gmond/gmond.init /etc/rc.d/init.d/gmond
mkdir /etc/ganglia  # where config files go
gmond -t | tee /etc/ganglia/gmond.conf  # generate initial gmond config
cp gmetad/gmetad.conf /etc/ganglia/  # initial gmetad configuration
mkdir -p /var/lib/ganglia/rrds  # place where RRDTool graphs will be stored
chown nobody:nobody /var/lib/ganglia/rrds  # make sure RRDTool can write here.
chkconfig --add gmetad  # make sure gmetad starts up at boot time
chkconfig --add gmond # make sure gmond starts up at boot time

ステップ 2: /etc/ganglia/gmond.conf の変更

/etc/ganglia/gmond.conf を変更して、クラスターに名前を付けます。クラスターの名前が「matlock」だとすると、name = "unspecified"name = "matlock" に変更します。

ステップ 3: マルチホーム・マシンへの対処

私のクラスターでは、eth0 にはシステムのパブリック IP アドレスが割り当てられていますが、監視サーバーは eth1 を介してプライベート・クラスター・ネットワークのノードと対話します。そのため、Ganglia が使用するマルチキャスト機能を確実に eth1 に関連付けなければなりません。それには、/etc/sysconfig/network-scripts/route-eth1 というファイルを作成し、このファイルに 239.2.11.71 dev eth1 という内容を追加します。

service network restart を実行することでネットワークを再起動してルートを調べれば、この IP が eth1 を経由していることを確認できます。注: 239.2.11.71 を追加しなければならない理由は、これが Ganglia のデフォルト・マルチキャスト・チャネルだからです。別のチャネルを使用する場合、またはチャネルを追加する場合には、このアドレスを変更してください。

ステップ 4: 管理サーバーでの起動

以上のステップを完了したら、すべてを監視サーバーで起動することができます。

service gmond start
service gmetad start
service httpd restart

Web ブラウザーを立ち上げて http://localhost/ganglia を指定して、管理サーバーにアクセスしてください。管理サーバーが現在、監視されていることがわかるはずです。また、複数のメトリックが監視されてグラフ化されていることもわかります。とりわけ役立つのは、このマシンの負荷を監視できることです。私のマシンの負荷は、以下のように表示されます。

図 1. 負荷の監視
負荷の監視

この図で負荷にほとんど変化が見られない理由は、マシンがアイドル状態になっているためです。

Ganglia をノードに配備する

これまでの手順で、Ganglia は管理サーバー上で実行中の状態になりました。ここからは、コンピューティング・ノード全体の状態について注意を傾けなければなりません。Ganglia をコンピューティング・ノードに配備するには、ファイルをいくつかコピーするだけの作業で済みます。この処理は、他の更新ツールに追加可能な Kickstart などを使っている場合には、ポスト・インストール・スクリプトに追加することができます。

やっつけ仕事の方法を取るとしたら、まず、すべてのホスト名が含まれるファイルを作成します。deathstar001 から deathstar100 までのノードがあるとすると、このファイルには /tmp/mynodes という名前を付けて、以下のような内容にします。

deathstar001
deathstar002
...skip a few...
deathstar099
deathstar100

後は、以下のコードを実行するだけです。

# for i in `cat /tmp/mynodes`; do 
scp /usr/sbin/gmond $i:/usr/sbin/gmond
ssh $i mkdir -p /etc/ganglia/
scp /etc/ganglia/gmond.conf $i:/etc/ganglia/
scp /etc/init.d/gmond $i:/etc/init.d/
scp /usr/lib64/libganglia-3.1.1.so.0 $i:/usr/lib64/
scp /lib64/libexpat.so.0 $i:/lib64/
scp /usr/lib64/libconfuse.so.0 $i:/usr/lib64/
scp /usr/lib64/libapr-1.so.0 $i:/usr/lib64/
scp -r /usr/lib64/ganglia $i:/usr/lib64/
ssh $i service gmond start
done

gmetad を再起動して Web ブラウザーの表示を更新すると、すべてのノードがリストに示されているはずです。

ここで考えられる問題には、以下のものがあります。

  • 前のステップ 3 での場合と同じように、明示的に静的ルートをノードに設定しなければならないことがあります。
  • ファイアウォールがポートをブロックする可能性があります。gmond はポート 8649 で動作します。gmond がマシンで実行中の場合には、コマンド telnet localhost 8649 を実行できるはずなので、このコマンドを実行して画面に出力される一連の XML を確認してください。

Ganglia による監視

自分の作業負荷を把握したり、ジョブの振る舞いを理解したりするのに苦労しているシステム・エンジニアは少なくありません。彼らはカスタム・コードを使っていることもあれば、自分たちの市販の製品が実行する内容を確かめるための調査をまだ済ませていないこともあります。そんなシステム・エンジニアにとって、Ganglia はアプリケーションのプロファイリングに役立ちます。

Ganglia を使用して、Linpack ベンチマーク実行時の特性を調べてみます。図 2 に示す期間のなかで、私は 3 種類の Linpack ジョブを起動しました。

図 2. Linpack ベンチマークのネットワーク・トラフィック
Linpack ベンチマークのネットワーク・トラフィック

上記のグラフからわかるように、ジョブが開始されるときには、ジョブの起動時にネットワークで何らかのアクティビティーが行われますが、このグラフで興味深い点は、ジョブの終了が近づくにつれ、ネットワーク・トラフィックが大幅に増加していることです。Linpack について何も知らなくても、ジョブの終了時にネットワーク・トラフィックが増加していることはわかります。

図 3 と図 4 に、CPU 使用率とメモリー使用量をそれぞれ示します。これらの図からわかるのは、プロセッサーをその処理能力の限界まで酷使していること、そして使用しているメモリー量がかなり多いことです。

図 3. CPU 使用率
CPU 使用率
図 4. メモリー使用量
メモリー使用量

上記のグラフから、実行しているアプリケーションの実態が明確になってきます。つまり、大量の CPU とメモリーを使用していること、そして、実行中のジョブの終わりに近づくにつれ、より多くのネットワーク・トラフィックを作り出していることです。このジョブには、これ以外にも明らかになっていない多くの特性がありますが、ジョブを理解する上で、これらのグラフが順調な出発点となります。

このような内容がわかっていれば、将来ハードウェアを追加で購入しなければなくなったときに、より賢い決定を下せるようになります。もちろん、Linpack を実行するためだけにハードウェアを購入する人は誰もいないとは思いますが・・・。


機能の拡張

基本的な Ganglia システムはかなりの有益な情報を提供してくれましたが、Ganglia のプラグインはさらに機能を拡張するために、以下の 2 つの方法を提供しています。

  • 帯域内プラグインを追加する
  • 他のソースから帯域外スプーフィングを追加する

Ganglia ではしばらくの間、前者のほうが一般的な方法でした。後者の方法は最近開発されたもので、機能の点では Nagios と重複します。これから実例を用いて、それぞれの方法について簡単に説明します。


帯域内プラグイン

帯域内プラグインは、以下の 2 つの方法で実現することができます。

  • クーロン・ジョブ・メソッドを使用して Ganglia の gmetric コマンドを呼び出し、データを入力する
  • 新しい Python モジュールのプラグインを使用してスクリプト化する

今まで一般的に用いられていたのは、1 番目の方法です。次の帯域外プラグインのセクションで詳しく説明しますが、この 1 番目の方法には、作業が複雑になるという問題があります。そこで、Ganglia 3.1.x では Python および C モジュール・プラグインを追加して、より自然に Ganglia を拡張できるようにしました。とりあえずここでは、2 番目の方法を説明することにします。

まず始めに、Python プラグインを Ganglia で使用できるようにします。以下のステップに従ってください。

  1. /etc/ganglia/gmond.conf ファイルを編集します。

このファイルを開くと、上から 4 分の 1 くらい下のところに modules というセクションがあります。このセクションは、以下のような内容になっています。

modules {
    module {
           name = "core_metrics"
     }
     ...
}

この modules セクションに、別のモジュールを追加します。追加するのは以下のコードです。

  module {
    name = "python_module"
    path = "modpython.so"
    params = "/usr/lib64/ganglia/python_modules/"
  }

私の gmond.conf ファイルでは、上記のコードを 90 行目に追加しました。これで、Ganglia が Python モジュールを使用できるようになります。さらに、その数行下にある include ('/etc/ganglia/conf.d/*.conf') 文の後に、include ('/etc/ganglia/conf.d/*.pyconf') という行を追加します。これらの文に、これから追加する内容の定義が含まれることになります。

  1. ディレクトリーを作成します。

そのために、以下のコマンドを実行します。

mkdir /etc/ganglia/conf.d
mkdir /usr/lib64/ganglia/python_modules
  1. すべてのノードでステップ 1 とステップ 2 を繰り返します。

その方法は以下のとおりです。

  • 監視対象のノードごとに新しい gmond.conf をコピーします。
  • ステップ 2 と同じ 2 つのディレクトリーを監視対象のノードごとに作成し、すべてのノードが Python 拡張機能を使用できるようにします。

Python モジュールを実行するようにノードがセットアップされたところで、新しいモジュールを作成します。この例では、Linux IPMI ドライバーを使用するプラグインを追加します。IPMI に馴染みのない方で、最近の Intel マシンや AMD マシンを操作したいという方は、是非この機会に IPMI について学んでください (「参考文献」を参照)。

この例でローカル・マシン上の IPMI デバイスと通信するために使用するのはオープンソースの IPMItool ですが、他にも OpenIPMI や freeipmi などの選択肢があります。これは単なる例に過ぎないので、別のツールを使いたいのでれば、遠慮なくそうしてください。

Ganglia に取り掛かる前に、IPMItool がお使いのマシンで機能することを確認するため、コマンド ipmitool -c sdr type temperature | sed 's/ /_/g' を実行します。このコマンドが機能しなければ、IPMI デバイス・ドライバーをロードしてから、もう一度実行してください。

modprobe ipmi_msghandler
modprobe ipmi_si
modprobe ipmi_devintf

ipmitool コマンドの実行結果として、以下の出力が表示されます。

Ambient_Temp,20,degrees_C,ok
CPU_1_Temp,20,degrees_C,ok
CPU_2_Temp,21,degrees_C,ok

上記からわかるように、この Ganglia プラグインが監視するのは周囲温度だけです。私は Ganglia ウィキで見つけたプラグインを基に、IPMI を使用する ambientTemp.py という極めて簡単なプラグインを作成しました。このプラグインは以下のスクリプトを実行します。

リスト 1. 簡単な Python プラグイン、ambientTemp.py
import os
def temp_handler(name):
  # our commands we're going to execute
  sdrfile = "/tmp/sdr.dump"
  ipmitool = "/usr/bin/ipmitool"
  # Before you run this Load the IPMI drivers:
  # modprobe ipmi_msghandler
  # modprobe ipmi_si
  # modprobe ipmi_devintf
  # you'll also need to change permissions of /dev/ipmi0 for nobody
  # chown nobody:nobody /dev/ipmi0
  # put the above in /etc/rc.d/rc.local

  foo = os.path.exists(sdrfile)
  if os.path.exists(sdrfile) != True:
    os.system(ipmitool + ' sdr dump ' + sdrfile)

  if os.path.exists(sdrfile):
    ipmicmd = ipmitool + " -S " + sdrfile + " -c sdr"
  else:
    print "file does not exist... oops!"
    ipmicmd = ipmitool + " -c sdr"
  cmd = ipmicmd + " type temperature | sed 's/ /_/g' "
  cmd = cmd + " | awk -F, '/Ambient/ {print $2}' "
  #print cmd
  entries = os.popen(cmd)
  for l in entries:
    line = l.split()
  # print line
  return int(line[0])

def metric_init(params):
    global descriptors

    temp = {'name': 'Ambient Temp',
        'call_back': temp_handler,
        'time_max': 90,
        'value_type': 'uint',
        'units': 'C',
        'slope': 'both',
        'format': '%u',
        'description': 'Ambient Temperature of host through IPMI',
        'groups': 'IPMI In Band'}

    descriptors = [temp]

    return descriptors

def metric_cleanup():
    '''Clean up the metric module.'''
    pass

#This code is for debugging and unit testing
if __name__ == '__main__':
    metric_init(None)
    for d in descriptors:
        v = d['call_back'](d['name'])
        print 'value for %s is %u' % (d['name'],  v)

リスト 1 を /usr/lib64/ganglia/python_modules/ambientTemp.py の中にコピーします。この作業は、クラスター内のすべてのノードで行う必要があります。

このスクリプトをクラスター内に含まれるすべてのノードに追加したら、Ganglia にこのスクリプトの実行方法を指示します。/etc/ganglia/conf.d/ambientTemp.pyconf という名前のファイルを新しく作成してください。このファイルの中身を以下のようにします。

リスト 2. ambient.Temp.pyconf
modules {
  module {
    name = "Ambient Temp"
    language = "python"
  }
}

collection_group {
  collect_every = 10
  time_threshold = 50
  metric {
    name = "Ambient Temp"
    title = "Ambient Temperature"
    value_threshold = 70
  }
}

すべてのノードでリスト 2 のファイルを保存します。

gmond を再起動する前にもう 1 つ必要な作業は、IPMI デバイスのアクセス権を変更して、誰もこのデバイスに対する操作を実行できないようにすることです。他のユーザーが操作を実行できるとなると、IPMI インターフェースは悪意のある人々からの攻撃に対して極めて脆弱になってしまいます。

これは単なる一例ですが、chown nobody:nobody /dev/ipmi0 のように変更してください。

すべてのノードで gmond を再起動してください。gmond が実行中になると、Web ブラウザーの表示を更新することで、以下のようなグラフが表示されるはずです。

図 5. IPMI 帯域内メトリック
IPMI 帯域内メトリック

帯域内メトリックの優れているところは、ホスト上でプログラムを実行して、他のメトリックが使用する収集メカニズムと同じ収集メカニズムによって情報を伝播できることです。一方、IPMI の場合は特にそうですが、この方法を機能させるためにはホスト上でのかなりの構成作業が必要になるという欠点があります。

上記の手順では、スクリプトが Python で作成されていること、構成ファイルが揃っていること、そして gmond.conf が正しく設定されていることを確認しなければなりませんでした。これはすべて、たった 1 つのメトリックのためだけの作業です。他にもメトリックを作成する必要がある場合にどれだけの作業になるかを考えてみてください。この作業をすべてのメトリックに対してすべてのホストで行うとなったら、きっとうんざりするでしょう。IPMI は帯域外ツールであることから、もっと賢い方法があるはずだと思いませんか?まさに、そうした方法があるのです。


帯域外プラグイン (ホスト・スプーフィング)

ホスト・スプーフィングは、必要なツールに過ぎません。ここでは強力な gmetric を使用して、このツールにどのホスト上で実行しているのかを指示します。gmetric とは、Ganglia に情報を挿入するためのコマンドライン・ツールです。この方法では、どんな対象をも監視することができます。

gmetric の最大の利点は何かと言うと、すでに作成されているスクリプトが山ほどあることです。

ここでは、学習体験となるように、ipmitool を実行してマシンにリモート・アクセスする方法をどのようにして変更するかを説明します。

  1. ipmitool がそれ自体の帯域外で機能することを確認します。

私は BMC (ターゲット・マシン上のチップ) を設定してあるので、この BMC 上で IPMI コマンドを実行することができます。例えば、私の監視ホストは redhouse という名前です。この redhouse からクラスター内にあるその他すべてのノードを監視するとしたら、gmetad を実行する場所、そしてすべての Ganglia 情報にアクセスするために Web ブラウザーに指定する場所は、この redhouse となります。

クラスター内のノードのなかに、x01 というホスト名のノードがあります。x01 の BMC は、host x01-bmc に名前解決される IP アドレスを持つように設定されています。このホストに、以下のようにリモート・アクセスしてみます。

# ipmitool -I lanplus -H x01-bmc -U USERID -P PASSW0RD sdr dump \ /tmp/x01.sdr
Dumping Sensor Data Repository to '/tmp/x01.sdr'
# ipmitool -I lanplus -H x01-bmc -U USERID -P PASSW0RD -S /tmp/x01.sdr \ sdr type 
                                                                            Temperature
Ambient Temp     | 32h | ok  | 12.1 | 20 degrees C
CPU 1 Temp       | 98h | ok  |  3.1 | 20 degrees C
CPU 2 Temp       | 99h | ok  |  3.2 | 21 degrees C

これでアクセスできることがわかったので、gmetric に入力するためのスクリプトに、このコマンドを組み込みます。

  1. gmetric に入力するために ipmitool を使用するスクリプトを作成します。

以下の /usr/local/bin/ipmi-ganglia.pl というスクリプトを作成したので、これを監視サーバーに配置します。

#!/usr/bin/perl
# vallard@us.ibm.com
use strict;  # to keep things clean... er cleaner
use Socket;  # to resolve host names into IP addresses

# code to clean up after forks
use POSIX ":sys_wait_h";
# nodeFile: is just a plain text file with a list of nodes:
# e.g:
# node01
# node02
# ...
# nodexx
my $nodeFile = "/usr/local/bin/nodes";
# gmetric binary
my $gmetric = "/usr/bin/gmetric";
#ipmitool binary
my $ipmi = "/usr/bin/ipmitool";
# userid for BMCs
my $u = "xcat";
# password for BMCs
my $p = "f00bar";
# open the nodes file and iterate through each node
open(FH, "$nodeFile") or die "can't open $nodeFile";
while(my $node = <FH>){
  # fork so each remote data call is done in parallel
  if(my $pid = fork()){
    # parent process
    next;
  }
  # child process begins here
  chomp($node);  # get rid of new line
  # resolve node's IP address for spoofing
  my $ip;
  my $pip = gethostbyname($node);
  if(defined $pip){
    $ip = inet_ntoa($pip);
  }else{
    print "Can't get IP for $node!\n";
    exit 1;
  }
  # check if the SDR cache file exists.
  my $ipmiCmd;
  unless(-f "/tmp/$node.sdr"){
    # no SDR cache, so try to create it...
    $ipmiCmd = "$ipmi -I lan -H $node-bmc -U $u -P $p sdr dump /tmp/$node.sdr";
    `$ipmiCmd`;
  }
  if(-f "/tmp/$node.sdr"){
    # run the command against the cache so that its faster
    $ipmiCmd = "$ipmi -I lan -H $node-bmc -U $u -P $p -S /tmp/$node.sdr sdr type 
                                                                       Temperature ";
    # put all the output into the @out array
    my @out = `$ipmiCmd`;
    # iterate through each @out entry.
    foreach(@out){
      # each output line looks like this:
      # Ambient Temp     | 32h | ok  | 12.1 | 25 degrees C
      # so we parse it out
      chomp(); # get rid of the new line
      # grap the first and 5th fields.  (Description and Temp)
      my ($descr, undef, undef, undef,$temp) = split(/\|/);
      # get rid of white space in description
      $descr =~ s/ //g;
      # grap just the temp, (We assume C anyway)
      $temp = (split(' ', $temp))[0];
      # make sure that temperature is a number:
      if($temp =~ /^\d+/ ){
        #print "$node: $descr $temp\n";
        my $gcmd = "$gmetric -n '$descr' -v $temp -t int16 -u Celcius -S $ip:$node";
        `$gcmd`;
      }
    }
  }
  # Child Thread done and exits.
  exit;
}
# wait for all forks to end...
while(waitpid(-1,WNOHANG) != -1){
  1;
}

すべての構文解析を別とすれば、このスクリプトは ipmitool コマンドを実行して温度の値を取得し、メトリックごとに gmetric コマンドを実行して値を Ganglia に入力するだけです。

  1. このスクリプトをクーロン・ジョブとして実行します。

crontab -e を実行します。私は 30 分ごとに実行するように、30 * * * * /usr/local/bin/ipmi-ganglia.sh というエントリーを追加しましたが、実行間隔はこれより長くても、短くても構いません。

  1. Ganglia を開いて結果を確認します。

Ganglia Web ブラウザーを開いて、いずれかのノードのグラフを見ると、ノードがスプーフィングされて各ノード・エントリーで更新されたことがわかります。

図 6. no_group メトリック
no_group メトリック

スプーフィングの欠点の 1 つは、カテゴリーが no_group メトリック・グループに分類されることです。gmetric には、このグループ分けを帯域内バージョンでの場合のようにわかりやすく変更する方法はなさそうです。


次回の予告

この記事では、Ganglia と Nagios をオープンソースの監視ソフトウェアとして個別に使用する場合と、連携させて使用する場合とで達成可能な内容を概説しました。Ganglia のインストール/構成手順を説明した後、アプリケーションの特性を理解する上で Ganglia がどのように役立つかを例示し、最後に帯域内スクリプトを使って Ganglia を拡張する方法、そして帯域外スクリプトをホスト・スプーフィングと併せて使用する方法を説明しました。

滑り出しとしては好調ですが、この記事が答えたのは、システム・エンジニアが投げかける監視についての質問だけです。つまり、システム全体のパフォーマンスを表示してマシンの使用状況を確認したり、マシンが常にアイドル状態なのか、あるいは処理能力の 60 パーセントを使っているのかを判断したりすることはできるようになりました。また、温度が最も高いマシン、最も低いマシンを見分け、ラックの配置を改善できるかどうかを調べることもできます。

この 2 回連載の第 2 回では、Nagios をセットアップして Ganglia と統合する方法を説明します。具体的な内容は以下のとおりです。

  • Nagios をインストールし、アラートのための基本的なセットアップを行う方法
  • スイッチやその他のインフラストラクチャーを監視する方法
  • Nagios をアラート機能として Ganglia に統合する方法

さらに第 2 回では、監視システム全体を拡張して実行中のジョブやその他のインフラストラクチャーを監視する方法も説明します。これらの追加作業を行うことで、さまざまなグループからの監視についての質問にも答えられるようになるはずです。

参考文献

学ぶために

製品や技術を入手するために

  • 前提条件の libconfuse-2.6.-1.fc9 ソース RPM を入手してください。
  • Ganglia 3.1.1 を入手してください。
  • Tobias Oetiker (略歴) によって作成された RRDTool (Round Robin Database Tool) が提供するエンジンは、多数のハイパフォーマンス監視ツールに対応します。
  • gmetric は情報を Ganglia に挿入するためのコマンドライン・ツールです。このツールは多くのスクリプトを利用してホスト・スプーフィングを支援します。
  • 監視ツールには、以下もあります。
  • developerWorks から直接ダウンロードできる IBM ソフトウェアの試用版を使用して、Linux で次の開発プロジェクトを構築してください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux, Open source
ArticleID=380507
ArticleTitle=Ganglia と Nagios: 第 1 回 Ganglia でエンタープライズ・クラスターを監視する
publish-date=03042009