インフラエンジニアのためのHadoop情報 状態監視その2 [Hadoop]
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はこうなる。
ARG1、ARG2はDataNodeのときと同じ。
services.cfgの例は
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に以下の行を追加する。
そして、Nagios側のcommands.cfgはこうなる。
ARG1には、nrpeコマンドの識別子「check_checkpoint」を代入するので、services.cfgの例は
Nagios監視の最後にHadoopのHDFSについてです。HadoopのHDFSは、付属ツールの
「hadoop fsck」コマンドを実行すると、HDFSブロックの整合性やレプリケーションの状態、
DataNode数などが表示されます。
実行例)
最後の行に、「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に以下を追加。
Nagiosサーバ側の設定もいつものように。
commands.cfg
services.cfg
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情報 状態監視その1 [Hadoop]
Hadoopを運用するノードもそれなりの台数になってくると、ノードの稼動状態を監視する
必要が出てきます。10台以上にもなるとそれぞれにログインしてプロセスを確認するのも
かなり面倒です。
ここでは、監視ツールとしてポピュラーな「Nagios」を使って、Hadoopノードを監視する
方法について書いておきます。
使うのは「check_http」コマンドです。このコマンドは、指定ポートに接続してhttpを
getして、得られるレスポンス文字列を調べて状態を判定します。
これを使ってHadoopの各サービスの状態を見てみましょう。
NameNode用のWebUI(http://[NameNodeのIP]:50070/dfshealth.jsp)には、レスポンス中に
「NameNode」の文字列が入っています。
この文字列を取得できたら、少なくともNameNodeは止まってはいないと判断できます。
このチェックを実現するNagiosのcommands.cfgの設定は以下のようになります。
引数ARG1にはポート番号50070が入るので、service.cfgは以下のようになる。
JobTrackerも同じようにチェックできます。こちらは、「Map/Reduce」という文字列をチェック。
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はこうなる。
ARG1、ARG2にはDataNodeの台数を指定し、それぞれ指定台数を下回る(ノード停止)と
「WARNING」、「CRITICAL」のアラートを発生する。
services.cfgの例は
となり、この場合は稼動しているDataNodeの台数が15台以下になると「WARNING」アラートが、
13台以下になると、「CRITICAL」アラートが出る。
必要が出てきます。10台以上にもなるとそれぞれにログインしてプロセスを確認するのも
かなり面倒です。
ここでは、監視ツールとしてポピュラーな「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情報 障害復旧のために [Hadoop]
これまでの障害復旧の話で分かるように、Hadoopの障害復旧には、NameNodeのメタデータが
きちんとバックアップされて、いつでも復旧のために使えることが大事です。
ここで少しメタデータついて記しておきます。
HadoopのNameNodeメタデータとは、ファイルシステムに関する情報のことで、通常はNameNode
のメモリ上にあり、チェックポイントごとに編集ログと同期されて、専用のファイルに記録
されます。
専用のファイルとは、edits、fsimage、fstimeの3つあり、それぞれ編集ログ、ファイル情報
チェックポイント時刻情報となります。
editsファイルはファイルへの操作が発生するたびログが記録され、どんどん大きくなって
いきます。editsファイルのログをファイル情報であるfsimageに適用するのは、Secondary
NameNodeの仕事です。PrimaryNameNodeがfsimageを更新するのは、再起動のときだけです。
SecondaryNameNodeは(デフォルトで)1時間おきのチェックポイントでPrimaryNameNodeから
edits,fsimageを取得して、edits中の編集ログをfsimageへ適用し、PrimaryNameNodeへ返却
します。その際、適用済みファイルをSecondaryNameNodeの所定のディレクトリにコピーされ
ます。
このコピーされたedits、fsimage、fstimeの3つのファイルを定期的に他のディレクトリなり
他のホストへ退避しておくと良いでしょう。退避するときには以前のファイルを履歴として
保存するようにしておけば、ある程度任意の時点のファイル構造へ戻すことができます。
参考までに、SendondaryNameNodeのチェックポイント適用済みファイルを指定ディレクトリへ
退避するバッチファイルを挙げておきます。
http://github.com/so-net-developer/Hadoop/blob/master/scripts/nmbackup.pl
きちんとバックアップされて、いつでも復旧のために使えることが大事です。
ここで少しメタデータついて記しておきます。
HadoopのNameNodeメタデータとは、ファイルシステムに関する情報のことで、通常はNameNode
のメモリ上にあり、チェックポイントごとに編集ログと同期されて、専用のファイルに記録
されます。
専用のファイルとは、edits、fsimage、fstimeの3つあり、それぞれ編集ログ、ファイル情報
チェックポイント時刻情報となります。
editsファイルはファイルへの操作が発生するたびログが記録され、どんどん大きくなって
いきます。editsファイルのログをファイル情報であるfsimageに適用するのは、Secondary
NameNodeの仕事です。PrimaryNameNodeがfsimageを更新するのは、再起動のときだけです。
SecondaryNameNodeは(デフォルトで)1時間おきのチェックポイントでPrimaryNameNodeから
edits,fsimageを取得して、edits中の編集ログをfsimageへ適用し、PrimaryNameNodeへ返却
します。その際、適用済みファイルをSecondaryNameNodeの所定のディレクトリにコピーされ
ます。
このコピーされたedits、fsimage、fstimeの3つのファイルを定期的に他のディレクトリなり
他のホストへ退避しておくと良いでしょう。退避するときには以前のファイルを履歴として
保存するようにしておけば、ある程度任意の時点のファイル構造へ戻すことができます。
参考までに、SendondaryNameNodeのチェックポイント適用済みファイルを指定ディレクトリへ
退避するバッチファイルを挙げておきます。
http://github.com/so-net-developer/Hadoop/blob/master/scripts/nmbackup.pl
インフラエンジニアのためのHadoop情報 障害復旧その2 [Hadoop]
PrimaryNameNodeの障害が取り除けず、サーバをあきらめてSecondaryNameNodeをPrimary
として入れ替える場合の手順を紹介します。
この場合は、クラスタ中のホストが指し示していたプライマリNameNodeのアドレスを、これまで
SecondaryNameNodeだったアドレスに切り替えます。手順を以下に示します。セカンダリをプラ
イマリに昇格するイメージです。
PrimaryNameNodeは停止しているものとする。(停止していない場合は停止する)
SecondaryNameNodeを停止します。
チェックポイントのメタデータをNameNodeのメタデータとしてコピーする。
NameNodeのアドレスを変更する。(srv2.example.comが新しいPrimaryNameNode)
新プライマリNameNodeとして起動する。
他のデータノードでも、新プライマリNameNodeのアドレスを参照するように変更する。
全てのデータノードで以下の設定を変更します。
DataNodeの起動直後に、fsckコマンドを実行すると「Under replicate」のエラーが出
ます。しばらくすると再配置が行われ、エラーは解消します。
として入れ替える場合の手順を紹介します。
この場合は、クラスタ中のホストが指し示していたプライマリ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 $ sudo /sbin/service hadoop-0.20-datanode restart fs.default.name hdfs://srv2.example.com:8020
DataNodeの起動直後に、fsckコマンドを実行すると「Under replicate」のエラーが出
ます。しばらくすると再配置が行われ、エラーは解消します。
インフラエンジニアのためのHadoop情報 障害復旧その1 [Hadoop]
Hadoopの障害の中でも、あらかじめ復旧手順を確認しておかなければいけないとすれば、
やはりNameNodeでしょう。
PrimaryNameNodeが停止するとHadoopクラスタは利用できなくなります。
fsコマンドでエラーが返ってくるようなら、NameNodeに問題が発生している場合があります。
NameNodeの障害を放置しておくと、HDFS上のデータが破損してしまう恐れがあるので、異常を
見つけたら速やかに復旧しましょう。
以下の例は、PrimaryNameNodeが停止した場合のエラーです。
PrimaryNameNodeの障害を取り除くことが出来たなら、Hadoopクラスタの復旧手順に入ります。
NameNodeが起動中の場合は、停止します。
メタデータの状態を確認します。
editsファイルが4バイトを超えていたり、fsimageが小さすぎたりする場合は、SecondaryNameNode
との通信が途中で切断された場合があります。そのような状態のまま、クラスタの再起動をする
と、最悪HDFS上のファイルが見えなくなってしまいます。
SecondaryNameNodeから取得したメタデータのバックアップを使用して復旧させましょう。
メタデータが正常に戻ったらNameNodeを起動します。
HDFSの状態を確認します。
やはり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]
Hadoopに新しいノードを追加して、古いノードを退役させたり、メンテナンスで一時的にクラスタから外したりしたい場合の手順を示します。
DataNodeをHadoopクラスタからいきなり外す(サービス停止やIP断)と、レプリケーション数が足りなくなり、「Under replicate」エラーが出たり、MapReduceタスクがエラーで終了したりします。いずれはHadoopがノード障害として自動で解消しますが、無駄なエラーや想定外の複製トラフィックは避けたいものです。
Hadoopではそんな時のために、予め取り外すノードを指定しておき、担当ブロックを残りノードで引き継いだのち、安全に取り外す機能があります。
作業はPrimaryNameNodeで行います。
/etc/hadoop-0.20/conf.cluster/にhosts.excludeなるファイルを作成して、取り外すノードのアドレスを記入します。(srv3.example.comが取り外したいノード)
このhosts.excludeファイルをhdfs-site.xmlファイル内に指定します。
ノード情報を更新します。
WebUI(http://srv1.example.com:50070/)画面の「Decommissioning Nodes」にexclude指定したサーバの数が表示されます。また、「Number of Under-Replicated Blocks」に再配置対象のブロック数が表示されます。
「Decommissioning Nodes」の欄が0になり、「Dead Node」となれば、DataNodeを取り外すことができます。
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.xmldfs.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を取り外すことができます。
インフラエンジニアのためのHadoop情報 DataNodeの追加 [Hadoop]
PrimaryNameNode,SecondaryNameNode,JobTracker,TaskTracker,DataNodeが一揃い出来たところ
で、スケールアウトをしてみましょう。
具体的には、DataNode及び、TaskTrackerを担当するノードを増やします。
DataNode、TaskTrackerを1台追加する手順を示します。
まずは、擬似分散用に構築した手順に従って、1台でHadoopが動く環境を準備し、クラスタ構築手順に従って、alternativeの設定までやっておきます。
これをDataNode、TaskTrackerノードとして、今現在動いているクラスタ環境に登録します。
クラスタ環境用の設定は、動いているクラスタ環境のノードからコピーします。
srv1.example.comから、追加するノードへ設定をコピーする例です。
設定ファイルがコピーできたら、サービスを起動します。
起動を確認します。
起動が完了したら、NameNodeとの通信が始まり、クラスタ環境へノードが追加されたことを確認できるはずです。
PrimaryNameNodeへログインしてfsckコマンドを使って確認します。fsckコマンドはHDFS上のファイルシステムの整合性を調べて結果を表示します。そのとき登録されているDataNodeの数も表示されます。
また、HDFS用のWebUIでも確認できます。ブラウザで以下のURLを指定して確認してみましょう。
http://[PrimaryNameNodeのアドレス]:50070
こちらの画面では、追加されたDataNode上にあるHDFSブロック数も確認できます。(追加直後は0のはず)
サービスが起動しない場合は、まず起動ログを確認してください。
たいていの場合、dfsディレクトリが存在しないか、適切なパーミッションが設定されていません。
CDH2をインストールして、擬似分散をテストしてあれば、適切に設定されているはずですが、インストールしたままテストを実施していないと、ディレクトリが作成されません。
以下のように、ディレクトリを作成し、パーミッションを設定してください。
1台での起動テストで、テストデータを登録した場合はdfsディレクトリ内のファイルを削除してください。
Hadoopのconfディレクトリがclusterのものに切り替わっているかどうか確認してください。
で、スケールアウトをしてみましょう。
具体的には、DataNode及び、TaskTrackerを担当するノードを増やします。
DataNode、TaskTrackerを1台追加する手順を示します。
まずは、擬似分散用に構築した手順に従って、1台で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
1台での起動テストで、テストデータを登録した場合は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
インフラエンジニアのためのHadoop情報 NameNodeバックアップ [Hadoop]
SecondaryNameNodeを起動したので、NameNodeのメタデータをバックアップしてみましょう。
バックアップは/var/lib/hadoop-0.20/cache/hadoop/dfs/namesecondary/previous.checkpoint配下にあるファイルをどこかへコピーするだけです。
メタデータのバックアップが取れたところで、リストアをしてみましょう。
リストアは、SecondaryNameNodeで取得したメタデータをPrimaryNameNodeに読み込ませます。
PrimaryNameNodeで作業を実施します。
PrimaryNameNodeを停止します。
バックアップデータを展開します。
PrimaryNameNodeを起動します。
バックアップは/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