hadoopアドベントカレンダー2011 2日目 小ネタ2つ

Hadoop

クレジットカード現金化詐欺【業界人が教える口コミ情報】, 2日目の12/2を担当する@です。

今回は最近気がついた小ネタを2つ書きたいと思います。

  • SSHはHDFS操作やジョブ実行には無関係
  • NameNodeの謎ファイル

なおこれから書くのはHadoop 0.20系の話です。

まず最初のやつですが、SSHはHDFS操作やジョブ実行には無関係です。

僕は以前SSHで各ノードにログインして分散実行するシステムにかかわったことがあるせいか、分散処理というとSSHという先入観がありました。

また象本2版9章でもSSHでパスワードなしログインできるよう設定するという話が書かれています。

しかしHDFSの処理に関して象本2版3章を読んだり、ジョブ実行に関して象本2版6章を読んでもSSHの話は出てきません。

ジョブはデータローカリティを意識して実行されるようになっており、分散キャッシュ経由で実行jarをデータが置いてあるノードに配布して実行ですしね。

ソース読んでもSSHに関わるような記述は見つからないです。

そうSSHはHDFS操作やジョブ実行には無関係なのです。

SSHが関係しているのはHadoopの制御スクリプトだけです。start-dfs.shとかね。

象本2版9章をよく読むとその辺が書かれています。思いこみは怖いですね。

ただHadoopクラスタ管理上の問題からSSHパスワードなしログインは設定するもんかもしれないですね。


２番目はNameNodeの謎ファイルです。

その前にまずNameNodeはSPOF（単一障害点）です。

Hadoop 0.23ではNameNodeはHA化されるようですが、0.20系ではそのような仕組みはありません。

そのためHA化するためにはHadoopとは別の仕掛けを使う必要があります。

有名なのはDRBD+HeartBeatです。Hadoop徹底入門にも書いてありますね。HeartBeatのバージョンが2系でちょっと古いですが参考になります。

ちなみにHA化するとNameNodeをリソースエージェント経由で起動する必要があって結構面倒です。

DRBDやHeartBeatの通信を2重化する必要もあるでしょうし。

DRBDでHDFSのメタデータを保護します。つまり${dfs.name.dir}以下のディレクトリを保護します。

${dfs.name.dir}以下のディレクトリ構造は下記のようになっています。in_use.lockは動作中に存在しているロックファイルですね。

${dfs.name.dir}/
               /current/
                       /VERSION
                       /edits
                       /fsimage
                       /fstime
               /image/
                       /fsimage
               /in_use.lock

${dfs.name.dir}/current/以下の4ファイル(VERSION, edits, fsimage, fstime)については象本2版10章に詳しいです。

簡単に言うとeditsが編集ログでfsimageがファイルシステムのイメージです。

HDFSクライアントが何か操作するとeditsに書きこまれます。ほっとくとeditsは肥大化するのでfsimageにマージする必要があります。

これが何時かというとチェックポイントのタイミングでeditsがfsimageにマージされます。

SecondaryNameNodeは1時間おき、もしくは、editsが64MBを超えたらチェックポイント処理が走ります。

ソースだとSecondaryNameNodeクラスのdoCheckpointメソッドですね。

ちなみにSecondaryNameNode経由の復旧はお手軽です。

最悪1時間分のデータは失われますが、HA化するコストが高過ぎる場合は割り切りもありかと。

ただHDFSに突っ込むまえの生データは信頼性のあるところに置くのが良いと思います。

HDFSのデータは無くなっても生データからいつでも復旧できる（ただし時間はかかるだろうけど）という状態にしておいた方が良いと思います。


で、NameNodeの謎ファイルですが（遅、それは${dfs.name.dir}/image/fsimageです。

まずこれは無いとNameNodeが起動しません。ですが、HDFSのメタデータが入っているわけではありません。

万が一間違って消してしまった場合は、別のテスト用クラスタでNameNodeをformatして作ったimage/fsimageを持ってくれば大丈夫だと思います。試してないけどたぶん。

これはバイナリファイルですが、下記の文字列が含まれているぐらいです。あとはディレクトリレイアウトのバージョン（0.20なら-19）ぐらい。

This file is INTENTIONALLY CORRUPTED so that versions of Hadoop prior to 0.13 (which are incompatible with this directory layout) will fail to start.

ソースでいうとStorageクラスのwriteCorruptedDataメソッド。

どうもHadoop 0.13（ディレクトリレイアウトが非互換）より前のバージョンで起動できないように意図的に作ったファイルのようです。

下記JIRAにあるようにHadoop 0.22（いつ出るんだｗ）では消されるようです。

[HDFS-259] Remove intentionally corrupt 0.13 directory layout creation - ASF JIRA

以上、とりとめもなかったですが、2点小ネタを書いてみました。


明日の12/3はid:marblejenka, @さんです。


ちなみにまだまだアドベントカレンダーの空きがあります。このままだとid:shiumachi, @さんが無双することになるのでHadooperの方はエントリーしていただけると嬉しいです。ブログじゃなくてつぶやきでもかまいませんのでご検討くださいな。65535人は無理でも25人ならなんとかいけると良いなあと思ってます。