So-net Developer Blog

TaskTrackerもDataNodeと同じように監視できます。
JobTrackerのWebUI(http://[JobTrackerのIP]:50030/jobtracker.jsp)画面中に表示されている
TaskTrackerのノード数を確認することで監視を行います。
チェックプログラムはこちら。

http://github.com/so-net-developer/Hadoop/blob/master/scripts/check_hadoop-task.pl
http://exchange.nagios.org/directory/Plugins/Others/check-Hadoop-tasktrackers/details

commands.cfgはこうなる。

define command {
       command_name  check_remote_tasktracker
       command_line   /usr/local/bin/check_hadoop-task.pl $HOSTADDRESS$ $ARG1$ $ARG2$
       }

ARG1、ARG2はDataNodeのときと同じ。
services.cfgの例は

define service {
       use             generic-service
       host_name       [JobTrackerホスト名]
       service_description     check_remote_tasktracker
       contact_groups                  admins
       check_command   check_remote_tasktracker!15!13
       }

SecondaryNameNodeの稼動状況の確認は、ステータスを確認する機能が見当たらないので、
メタデータファイルの更新状況を確認して判断します。
ファイルの更新は、SecondaryNameNode内で行われるので、Nagiosサーバからそれを直接見に
いくことができません。そこでNagios用nrpeの登場です。
監視対象のSecondaryNameNode側にnrpeを設定してNagiosサーバに通知してもらいます。
SecondaryNameNodeへのnrpeのインストール、基本設定は済ませてください。
メタデータファイルの更新状況を確認するスクリプトを以下に挙げておきます。

http://github.com/so-net-developer/Hadoop/blob/master/scripts/secondarynamenode_check.sh
http://exchange.nagios.org/directory/Plugins/Others/check-Hadoop-secondarynamenode/details

120分以上更新されていないファイルが見つかったら、SecondaryNameNodeのチェックポイントに
異常が発生しているとみなして、アラートを発します。
SecondaryNameNode上のnrpeの設定ファイルnrpe.cfgに以下の行を追加する。

command[check_checkpoint]=/usr/local/bin/secondarynamenode_check.sh

そして、Nagios側のcommands.cfgはこうなる。

define command {
       command_name    check_nrpe_secondarynamenode
       command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
       }

ARG1には、nrpeコマンドの識別子「check_checkpoint」を代入するので、services.cfgの例は

define service {
       use             generic-service
       host_name       sdh02
       service_description     check_nrpe_secondarynamenode
       contact_groups                  admins
       check_command   check_nrpe_secondarynamenode!check_checkpoint
       }

Nagios監視の最後にHadoopのHDFSについてです。HadoopのHDFSは、付属ツールの
「hadoop fsck」コマンドを実行すると、HDFSブロックの整合性やレプリケーションの状態、
DataNode数などが表示されます。
実行例）

$ hadoop fsck /
Total size:    2235588327935 B
Total dirs:    127
Total files:   454
Total blocks (validated):      33584 (avg. block size 66567065 B)
Minimally replicated blocks:   33584 (100.0 %)
Over-replicated blocks:        0 (0.0 %)
Under-replicated blocks:       0 (0.0 %)
Mis-replicated blocks:         0 (0.0 %)
Default replication factor:    3
Average block replication:     3.001608
Corrupt blocks:                0
Missing replicas:              0 (0.0 %)
Number of data-nodes:          16
Number of racks:               1


The filesystem under path '/' is HEALTHY

最後の行に、「HEALTHY」と出てくると安心します。
どうせだから、これもNagiosで監視してしまいましょう。
nrpeでコマンドを起動し、「HEALTHY」が表示されなければ、アラートをあげるようにします。
nrpeでfsckコマンドを起動して、「HEALTHY」表示を確認するチェックスクリプトはこちら。

http://github.com/so-net-developer/Hadoop/blob/master/scripts/check_hdfs.sh
http://exchange.nagios.org/directory/Plugins/Others/check-Hadoop-HDFS-healthy/details

(hadoopコマンドにパスが通っていること、HDFSブロック数が非常に多いとnrpeのタイムアウトに注意)

nrpeはPrimaryNameNodeで動かします。（そこでしかfsckが通らないから）
nrpeの設定ファイルnrpe.cfgに以下を追加。

command[check_hdfs]=/usr/local/bin/check_hdfs.sh

Nagiosサーバ側の設定もいつものように。
commands.cfg

define command {
       command_name    check_nrpe_hdfs
       command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -t 30
       }

services.cfg

define service {
       use             generic-service
       host_name       sdh01
       service_description     check_nrpe_hdfs
       contact_groups                  admins
       check_command   check_nrpe_hdfs!check_hdfs
       }

Hadoopを運用するノードもそれなりの台数になってくると、ノードの稼動状態を監視する
必要が出てきます。１０台以上にもなるとそれぞれにログインしてプロセスを確認するのも
かなり面倒です。
ここでは、監視ツールとしてポピュラーな「Nagios」を使って、Hadoopノードを監視する
方法について書いておきます。
使うのは「check_http」コマンドです。このコマンドは、指定ポートに接続してhttpを
getして、得られるレスポンス文字列を調べて状態を判定します。
これを使ってHadoopの各サービスの状態を見てみましょう。
NameNode用のWebUI(http://[NameNodeのIP]:50070/dfshealth.jsp)には、レスポンス中に
「NameNode」の文字列が入っています。
この文字列を取得できたら、少なくともNameNodeは止まってはいないと判断できます。
このチェックを実現するNagiosのcommands.cfgの設定は以下のようになります。

define command {
       command_name  check_remote_namenode
       command_line   $USER1$/check_http -H $HOSTADDRESS$ -u http://$HOSTADDRESS$:$ARG1$/dfshealth.jsp -p $ARG1$ -r NameNode
       }

引数ARG1にはポート番号50070が入るので、service.cfgは以下のようになる。

define service {
       use             generic-service
       host_name       [NameNodeホスト名]
       service_description     check_remote_namenode
       contact_groups                  admins
       check_command   check_remote_namenode!50070
       }

JobTrackerも同じようにチェックできます。こちらは、「Map/Reduce」という文字列をチェック。

define command {
       command_name  check_remote_jobtracker
       command_line   $USER1$/check_http -H $HOSTADDRESS$ -u http://$HOSTADDRESS$:$ARG1$/jobtracker.jsp -p $ARG1$ -r Map/Reduce
       }

define service {
       use             generic-service
       host_name       [JobTrackerホスト名]
       service_description     check_remote_jobtracker
       contact_groups                  admins
       check_command   check_remote_jobtracker!50030
       }

DataNodeを監視したい場合は、各ノードにはWebUIが無いので、NameNodeの
WebUI(http://[NameNodeのIP]:50070/dfshealth.jsp)の画面から、稼動中の台数を示す文字列を
拾ってチェックします。
チェックプログラムはこちら。

http://github.com/so-net-developer/Hadoop/blob/master/scripts/check_hadoop-dfs.pl
http://exchange.nagios.org/directory/Plugins/Others/check-Hadoop-datanodes/details

commands.cfgはこうなる。

define command {
       command_name  check_remote_datanode
       command_line   /usr/local/bin/check_hadoop-dfs.pl $HOSTADDRESS$ $ARG1$ $ARG2$
       }

ARG1、ARG2にはDataNodeの台数を指定し、それぞれ指定台数を下回る（ノード停止）と
「WARNING」、「CRITICAL」のアラートを発生する。
services.cfgの例は

define service {
       use             generic-service
       host_name       [NameNodeホスト名]
       service_description     check_remote_datanode
       contact_groups                  admins
       check_command   check_remote_datanode!15!13
       }

となり、この場合は稼動しているDataNodeの台数が15台以下になると「WARNING」アラートが、
13台以下になると、「CRITICAL」アラートが出る。

これまでの障害復旧の話で分かるように、Hadoopの障害復旧には、NameNodeのメタデータが
きちんとバックアップされて、いつでも復旧のために使えることが大事です。
ここで少しメタデータついて記しておきます。
HadoopのNameNodeメタデータとは、ファイルシステムに関する情報のことで、通常はNameNode
のメモリ上にあり、チェックポイントごとに編集ログと同期されて、専用のファイルに記録
されます。
専用のファイルとは、edits、fsimage、fstimeの３つあり、それぞれ編集ログ、ファイル情報
チェックポイント時刻情報となります。
editsファイルはファイルへの操作が発生するたびログが記録され、どんどん大きくなって
いきます。editsファイルのログをファイル情報であるfsimageに適用するのは、Secondary
NameNodeの仕事です。PrimaryNameNodeがfsimageを更新するのは、再起動のときだけです。
SecondaryNameNodeは（デフォルトで）1時間おきのチェックポイントでPrimaryNameNodeから
edits,fsimageを取得して、edits中の編集ログをfsimageへ適用し、PrimaryNameNodeへ返却
します。その際、適用済みファイルをSecondaryNameNodeの所定のディレクトリにコピーされ
ます。
このコピーされたedits、fsimage、fstimeの３つのファイルを定期的に他のディレクトリなり
他のホストへ退避しておくと良いでしょう。退避するときには以前のファイルを履歴として
保存するようにしておけば、ある程度任意の時点のファイル構造へ戻すことができます。
参考までに、SendondaryNameNodeのチェックポイント適用済みファイルを指定ディレクトリへ
退避するバッチファイルを挙げておきます。

http://github.com/so-net-developer/Hadoop/blob/master/scripts/nmbackup.pl

PrimaryNameNodeの障害が取り除けず、サーバをあきらめてSecondaryNameNodeをPrimary
として入れ替える場合の手順を紹介します。
この場合は、クラスタ中のホストが指し示していたプライマリNameNodeのアドレスを、これまで
SecondaryNameNodeだったアドレスに切り替えます。手順を以下に示します。セカンダリをプラ
イマリに昇格するイメージです。
PrimaryNameNodeは停止しているものとする。（停止していない場合は停止する）

$ sudo /sbin/service hadoop-0.20-namenode stop

SecondaryNameNodeを停止します。

$ sudo /sbin/serivce hadoop-0.20-secondarynamenode stop

チェックポイントのメタデータをNameNodeのメタデータとしてコピーする。

$ cd /var/lib/hadoop-0.20/cache/hadoop/dfs/name/current
$ sudo cp ../../namesecondary/previous.checkpoint/* .

NameNodeのアドレスを変更する。（srv2.example.comが新しいPrimaryNameNode)

$ sudo vi /etc/hadoop-0.20/conf/core-site.xml

 
   fs.default.name
   hdfs://srv1.example.com:8020
 
　　　↓
 
   fs.default.name
   hdfs://srv2.example.com:8020
 

新プライマリNameNodeとして起動する。

$ sudo /sbin/service hadoop-0.20-namenode start

他のデータノードでも、新プライマリNameNodeのアドレスを参照するように変更する。
全てのデータノードで以下の設定を変更します。

$ sudo vi /etc/hadoop-0.20/conf/core-site.xml

 
   fs.default.name
   hdfs://srv1.example.com:8020
 
　　　↓
 
   fs.default.name
   hdfs://srv2.example.com:8020
 

$ sudo /sbin/service hadoop-0.20-datanode restart

DataNodeの起動直後に、fsckコマンドを実行すると「Under replicate」のエラーが出
ます。しばらくすると再配置が行われ、エラーは解消します。

Hadoopの障害の中でも、あらかじめ復旧手順を確認しておかなければいけないとすれば、
やはりNameNodeでしょう。
PrimaryNameNodeが停止するとHadoopクラスタは利用できなくなります。
fsコマンドでエラーが返ってくるようなら、NameNodeに問題が発生している場合があります。
NameNodeの障害を放置しておくと、HDFS上のデータが破損してしまう恐れがあるので、異常を
見つけたら速やかに復旧しましょう。
以下の例は、PrimaryNameNodeが停止した場合のエラーです。

$ hadoop fs -ls
10/07/06 18:18:06 INFO ipc.Client: Retrying connect to server: srv1/192.168.1.1:8020.
 Already tried 0
time(s).
10/07/06 18:18:07 INFO ipc.Client: Retrying connect to server: srv1/192.168.1.1:8020.
 Already tried 1
time(s).

PrimaryNameNodeの障害を取り除くことが出来たなら、Hadoopクラスタの復旧手順に入ります。
NameNodeが起動中の場合は、停止します。

$ sudo /sbin/service hadoop-0.20-namenode stop

メタデータの状態を確認します。

$ cd /var/lib/hadoop-0.20/cache/hadoop/dfs/name/current/
$ ls -la
drwxrwxr-x 2 hadoop hadoop   4096  7月  6 18:18 .
drwxrwxr-x 4 hadoop hadoop   4096  7月  6 18:18 ..
-rw-rw-r-- 1 hadoop hadoop    101  7月  6 18:18 VERSION
-rw-rw-r-- 1 hadoop hadoop      4  7月  6 18:18 edits
-rw-rw-r-- 1 hadoop hadoop 833380  7月  6 18:18 fsimage
-rw-rw-r-- 1 hadoop hadoop      8  7月  6 18:18 fstime

editsファイルが4バイトを超えていたり、fsimageが小さすぎたりする場合は、SecondaryNameNode
との通信が途中で切断された場合があります。そのような状態のまま、クラスタの再起動をする
と、最悪HDFS上のファイルが見えなくなってしまいます。
SecondaryNameNodeから取得したメタデータのバックアップを使用して復旧させましょう。

$ tar cvf /mnt/backup/namenode-bak.tar *

メタデータが正常に戻ったらNameNodeを起動します。

$ sudo /sbin/service hadoop-0.20-namenode start

HDFSの状態を確認します。

$ hadoop fsck /
:
Over-replicated blocks:        0 (0.0 %)
Under-replicated blocks:       0 (0.0 %)
Mis-replicated blocks:         0 (0.0 %)
Default replication factor:    3
Average block replication:     3.0
Corrupt blocks:                0
Missing replicas:              0 (0.0 %)
Number of data-nodes:          4
Number of racks:               1


The filesystem under path '/' is HEALTHY

Hadoopに新しいノードを追加して、古いノードを退役させたり、メンテナンスで一時的にクラスタから外したりしたい場合の手順を示します。
DataNodeをHadoopクラスタからいきなり外す（サービス停止やIP断）と、レプリケーション数が足りなくなり、「Under replicate」エラーが出たり、MapReduceタスクがエラーで終了したりします。いずれはHadoopがノード障害として自動で解消しますが、無駄なエラーや想定外の複製トラフィックは避けたいものです。
Hadoopではそんな時のために、予め取り外すノードを指定しておき、担当ブロックを残りノードで引き継いだのち、安全に取り外す機能があります。
作業はPrimaryNameNodeで行います。
/etc/hadoop-0.20/conf.cluster/にhosts.excludeなるファイルを作成して、取り外すノードのアドレスを記入します。(srv3.example.comが取り外したいノード）

$ vi hosts.exclude
srv3.example.com

このhosts.excludeファイルをhdfs-site.xmlファイル内に指定します。

$ sudo vi hdfs-site.xml

   dfs.hosts.exclude
   /etc/hadoop-0.20/conf/hosts.exclude

ノード情報を更新します。

$ hadoop dfsadmin -refreshNodes

WebUI(http://srv1.example.com:50070/)画面の「Decommissioning Nodes」にexclude指定したサーバの数が表示されます。また、「Number of Under-Replicated Blocks」に再配置対象のブロック数が表示されます。
「Decommissioning Nodes」の欄が0になり、「Dead Node」となれば、DataNodeを取り外すことができます。

PrimaryNameNode,SecondaryNameNode,JobTracker,TaskTracker,DataNodeが一揃い出来たところ
で、スケールアウトをしてみましょう。
具体的には、DataNode及び、TaskTrackerを担当するノードを増やします。
DataNode、TaskTrackerを１台追加する手順を示します。
まずは、擬似分散用に構築した手順に従って、１台でHadoopが動く環境を準備し、クラスタ構築手順に従って、alternativeの設定までやっておきます。
これをDataNode、TaskTrackerノードとして、今現在動いているクラスタ環境に登録します。
クラスタ環境用の設定は、動いているクラスタ環境のノードからコピーします。
srv1.example.comから、追加するノードへ設定をコピーする例です。

$ mkdir /tmp/conf
$ cd /tmp/conf
$ scp srv1.example.com:/etc/hadoop-0.20/conf/* .
$ sudo chown hadoop:hadoop *
$ cp * /etc/hadoop-0.20/conf/

設定ファイルがコピーできたら、サービスを起動します。

$ sudo /sbin/service hadoop-0.20-datanode start
$ sudo /sbin/service hadoop-0.20-tasktracker start

起動を確認します。

$ sudo /usr/java/jdk1.6.0_20/bin/jps
20836 DataNode
21720 TaskTracker

起動が完了したら、NameNodeとの通信が始まり、クラスタ環境へノードが追加されたことを確認できるはずです。
PrimaryNameNodeへログインしてfsckコマンドを使って確認します。fsckコマンドはHDFS上のファイルシステムの整合性を調べて結果を表示します。そのとき登録されているDataNodeの数も表示されます。

$ hadoop fsck /
 :
 Number of data-nodes:          4
 Number of racks:               1

また、HDFS用のWebUIでも確認できます。ブラウザで以下のURLを指定して確認してみましょう。
http://[PrimaryNameNodeのアドレス]:50070
こちらの画面では、追加されたDataNode上にあるHDFSブロック数も確認できます。（追加直後は0のはず）
サービスが起動しない場合は、まず起動ログを確認してください。

$ sudo cat /var/log/hadoop-0.20/hadoop-hadoop-datanode-xxx.example.com.log

たいていの場合、dfsディレクトリが存在しないか、適切なパーミッションが設定されていません。
CDH2をインストールして、擬似分散をテストしてあれば、適切に設定されているはずですが、インストールしたままテストを実施していないと、ディレクトリが作成されません。
以下のように、ディレクトリを作成し、パーミッションを設定してください。

$ sudo mkdir /var/lib/hadoop-0.20
$ sudo chown hadoop:hadoop /var/lib/hadoop-0.20
$ sudo chmod 1777 /var/lib/hadoop-0.20/cache

１台での起動テストで、テストデータを登録した場合はdfsディレクトリ内のファイルを削除してください。

$ sudo rm -rf /var/lib/hadoop-0.20/cache/hadoop/dfs/data

Hadoopのconfディレクトリがclusterのものに切り替わっているかどうか確認してください。

$ sudo /usr/sbin/alternatives --display hadoop-0.20-conf

SecondaryNameNodeを起動したので、NameNodeのメタデータをバックアップしてみましょう。
バックアップは/var/lib/hadoop-0.20/cache/hadoop/dfs/namesecondary/previous.checkpoint配下にあるファイルをどこかへコピーするだけです。

$ cd /var/lib/hadoop-0.20/cache/hadoop/dfs/namesecondary/previous.checkpoint
$ ls
VERSION  edits  fsimage  fstime
$ tar cvf /mnt/backup/namenode-bak.tar *

メタデータのバックアップが取れたところで、リストアをしてみましょう。
リストアは、SecondaryNameNodeで取得したメタデータをPrimaryNameNodeに読み込ませます。
PrimaryNameNodeで作業を実施します。
PrimaryNameNodeを停止します。

$ sudo /sbin/service/hadoop-0.20-namenode stop

バックアップデータを展開します。

$ cd /var/lib/hadoop-0.20/cache/hadoop/dfs/name/current
$ sudo tar xvf /mnt/backup/namenode-bak.tar

PrimaryNameNodeを起動します。

$ sudo /sbin/service/hadoop-0.20-namenode start