NameNode の再構築について

[Saburo]

こんにちは、saburo と申します。

commo...@hadoop.apache.org にメールしたら、こちらを紹介されました。
日本語で出来るので助かります。

<本題>
もし、NameNode が何らかの理由で復活出来なくなった場合を想定して、残存する DataNodeから NameNode の fsimage を再構築する方法が無いか模索しています。
どなたかご存知の方、若しくは参照先をご存じの方が居ればご教授願います。

<詳細>
既に、NameNode は Corosync + pacemaker + DRBD でリアルタイム同期が行われる環境は実証実験済みですので、こういったケースが必要になる事は"稀"とは思います。
但し、想定としては"何があるか解らない"と言う面も考慮したい為、最悪 手元に残った DataNode のデータのみから、NameNode を再構築する手段も確立出来ればと思い質問させて頂きました。

確認済みの作業としては、
1. NameNode を初期化 し、
2. dfs/name/current/ VERSION の namespaceID を 残存の DataNodeと一致させ、
3. NameNode を起動し、
4. DataNode を起動

は実施してみましたが、hadoop fs -ls をしても空っぽでした。
元々正常に動いていた環境でしたので、DataNode がNameNode へ接続出来ていない、と言う訳でも無いと思います。

一寸、他にアイディアも無い為、質問をさせて頂きます。

よろしくお願いします。

[Sho Shimauchi]

saburo 様、

はじめまして、嶋内と申します。

結論から言いますと、fsimage を DataNode(DN) のデータのみで再構築する方法はありません。

NameNode(NN) で保持されているメタデータファイル fsimage には、名前空間とそれに対応する実ブロックのマップ情報が格納されています。

例えば、/user/tom/file001.txt というファイルを HDFS 上にアップロードして配置したとします。

(ここではファイルサイズは1ブロックに収まるものとします)

クライアントからアップロード操作が行われると、HDFS はその物理データを複製していくつかのDN(デフォルトは3つ)に配置します。

このときに例えば dn1/dn2/dn3 というDNにブロックが配置されたとしましょう。

NN は /user/tom/file001.txt が dn1/dn2/dn3 のどのブロックに対応しているのかをマッピングします。

この情報を格納したものが fsimage です。

この仕様から考えると、もし DN からメタデータを復元しようとするならば、それぞれの DN は上記のマップ情報を保持していなければいけないはずです。

ところが実際はそのように設計されておらず、DN はメタデータを保持しません。

ですので、fsimage を失った場合、その HDFS 上のデータはどうやっても復元することができません。

こういった事態を回避するために、fsimage を冗長化する必要があります。

最もリーズナブルかつ効率的な方法は、dfs.name.dir に複数のディレクトリを指定することです。

dfs.name.dir にはカンマ区切りで複数のディレクトリを指定できます。/path/to/nn1,/path/to/nn2

ポピュラーな方法としては、3つのディレクトリを指定し、2つはローカルに、1つはNFSに書き込むという方法があります。

通常の場合はそれで問題ないかと思います。

参考までに、弊社 Cloudera のお客様で saburo さんがご心配なさっているような事象に遭われたお客様は現在のところいらっしゃいません。

2012/4/19 Saburo <sf0...@gmail.com>

--

Sho Shimauchi

Customer Operations Engineer, Cloudera

Global Site: http://www.cloudera.com/

Japan Site: http://www.cloudera.co.jp/

[藤岡三郎]

嶋内 さま

レスポンスありがとうございます。

Hadoop 内部はまだ調査していませんでしたが、そうですか、NG ですか。
まぁ、仕様から言って一寸厳しそうな面は想定していましたが。


<<懸念事項>>
この件について私が懸念している点は、
1. Hadoop の障害で fsimage を壊す (あまり考えたくないですが)
2. HDD Storage Driver の障害で書込みに失敗し、ファイルを壊す
   (実は過去これに遭遇した事があります)

課金情報のようなものを Hadoop で管理する事は無い為、若干の
ファイルロストは割り切れますが、全て失う事は流石に困ります。

現在行っている DRBD による複製や、ご推奨頂いた dfs.name.dir
による複数指定するパターンは、"壊れたデータを複製"する可能性
もあり、最後の手段として、DataNode から NameNode を再構築する
事を考えたのですが、一寸厳しいようですね。


<<想定される対策>>
LVM 辺りを使って、定期的にスナップを取る事を再考します。
スナップ->最新 間の情報は失われますが、"全喪失"ではありま
せんし、多分 削除や更新された DataNode のデータを除き、
スナップの段階までは戻れると思いますので。

もし他に、何か妥当なアイディアがあればご推奨下さい。

よろしくお願いします。

2012年4月19日16:55 Sho Shimauchi <s...@cloudera.com>:

[Yoshiharu Mori]

盛と申します。

> <<想定される対策>>
> LVM 辺りを使って、定期的にスナップを取る事を再考します。
> スナップ->最新 間の情報は失われますが、"全喪失"ではありま
> せんし、多分 削除や更新された DataNode のデータを除き、
> スナップの段階までは戻れると思いますので。
>
> もし他に、何か妥当なアイディアがあればご推奨下さい。

定期的にHTTP経由でfsimageとeditsのコピーを取得してはいかがでしょうか。

fsimage=>http://<node>:50070/getimage?getimage=1
edits =>http://<node>:50070/getimage?getedit=1

--
Yoshiharu Mori <y-m...@sraoss.co.jp>
SRA OSS, Inc Japan http://www.sraoss.co.jp
TEL: 03-5979-2701
FAX: 03-5979-2702

[Tatsuo Kawasaki]

藤岡さん

こんにちは、川崎と申します。

盛さんも書いていらっしゃいますが、メタデータについては
別のマシンにバックアップを（例えば複数世代）取ることをお勧めします。

（Hadoopのバージョンにもよりますが）例えばSecondary NameNodeは
定期的にNameNodeからfsimage/editsを取得しています。

嶋内さんが書いている dfs.name.dir には複数箇所（NFS領域なども含めて）を
指定してハードウェア障害に対応しておき、fsimage/editsの破損については
定期的にバックアップを取るのがよろしいかと思います。

LVMのスナップショットについてですが、LVM自身の問題やボリュームが破損する
ことを考えると、別途バックアップは必要かと。
（こちらはHDFSのデータの話ですよね、、違ったらすみません）

--
Tatsuo Kawasaki
kawasaki at wwing.net

2012/4/20 藤岡三郎 <sf0...@gmail.com>:

[藤岡三郎]

川崎さま、森さま

レスポンスありがとうございます。

> fsimage=>http://<node>:50070/getimage?getimage=1
> edits  =>http://<node>:50070/getimage?getedit=1

これは知りませんでした。
HTTP 経由で snap が取得出来るんですね。

であれば、wget あたりを使って定期的に取得させて
しまうのが、一番手っ取り早そうですね。

> LVMのスナップショットについてですが、LVM自身の問題や
> ボリュームが破損することを考えると、別途バックアップは必要かと。
> （こちらはHDFSのデータの話ですよね、、違ったらすみません）

川崎さま、いろいろ指摘ありがとうございます。
ご指摘通り HDFS の話です。現時点ではこれが主用途なので。

最初、1)LVM でスナップを取って、2)それを非同期で他のサーバ
へコピー、と考えましたが、fsimage の更新完了と同期する
保証がありませんので、森さま指摘のように、webUIでスナップ
を取った方が確実ですかね。

Secondary NameNode は、(全く別の理由で)評価は割愛しています
ので、今回は見送らせて頂きます。

著しい性能への影響などが無ければ、http 経由でのスナップ
定期取得の方向で検討したいと思います。

ありがとうございました。

2012年4月20日11:55 Tatsuo Kawasaki <kawa...@wwing.net>: