Hadoopのディスクあふれ対策(補足) - 科学と非科学の迷宮

最近流行りのディスク容量があふれたときの挙動、Hadoop編を書こうと思ったらwyukawaさんが既に書いてくださったのでやめました。
……と思ったのですが、せっかくなので id:wyukawa さんが書いてない箇所を補足してみようと思います。

( この記事は @kernel023 にレビューしてもらっています。ありがとうございます )

wyukawaさんの記事へのコメント

まずHBaseを使っている場合はcompactionがある関係上Disk使用率は50%以内に抑えておくのが無難だと思います。この辺はCassandraと同じですね。

全データを同時にコンパクションするケースはまずないので無理に50%以下に抑えなくていいとは思いますが、意識はしておいた方がいいですね。
私は60%での警告を推奨しますが、この辺はケースバイケースです。
MapReduce の出力結果など、いきなり容量増える場合もありますし、サーバが飛べば総容量は減りますから、HBase を使っていない場合でも容量ぎりぎりに使うことは推奨しません。

次にNameNodeの場合はdfs.name.dirで指定したディレクトリにメタデータを書くわけですが、このパーティションがDisk Fullになった場合はNameNodeがdownします。大変危険ですので注意しましょう。

dfs.name.dir は CDH3 / Hadoop 1.x 系のプロパティです。CDH4 / Hadoop 2.x 系だと dfs.namenode.name.dir になります。
dfs.namenode.name.dir を複数指定している場合、いずれか一つに書き込みが成功すれば警告のみでダウンしません。
WebUIからは、メタデータを書き込めないディレクトリは failed と表示されます。
edits の書き込みは、QJMベースにしていれば複数台中過半数に書き込めていれば大丈夫です。
例えば3台のジャーナルノード(JN)があれば、1台のディスクがあふれてもサービス継続します。

hadoop fs -rmで削除してもTrashが有効になっている（fs.trash.intervalが設定されている）場合は.Trashにmvするだけなのでそこも消しましょう。

hdfs dfs -expunge で Trash を空に出来ます。

Hadoop のデータ使用量

大体以下のような感じで容量を食います。

NN
- メタデータ及びedits
- ログ
2NN 及びスタンバイNN
- NNと同じだけのデータ及びバックアップのメタデータ(デフォルト2世代、dfs.namenode.num.checkpoints.retainedで調整可能)
- つまり(アクティブ)NNより容量が多いので注意！
ジャーナルノード(JN)
- edits
- ログ
DN
- 実データ
- ログ

NN

そもそもメタデータ(fsimage)はメモリ上にロードしなければいけないのでせいぜい数十GBが限界。
editsは処理内容によりますが、きちんとチェックポイントが稼動していれば数GBも見ておけば十分かと。大抵の場合100GBもいくことはないと思います。
問題はログで、数百ノード〜1000ノードクラスになると数分あたり1GBなんていう恐ろしいスピードで生成されていきます。
あっという間にパンクするので注意しましょう。
ログの管理については後述。

NNについて重要なのは、100GBぐらいの容量は割と普通に使うということです。
DNに比べてディスク容量少なくていいからといって、133GB の HDD とかで RAID1 組んだりしてるとディスクあふれて落ちる場合がありますのでご注意ください。

DN

ディスク内バランシングについては wyukawa さんが書いた通り。
一時データのつもりでレプリカファクター1とかで書き込んだりしているとあっさり偏りますので、ディスク監視とこまめなバランサー稼働をこころがけましょう。

5ブロック分の書き込み容量を確保できないDNは、NNから書き込み不能DNとみなされますので、HDFSの書き込みであふれることはないです。

「Hadoop はDN 1台死んだって問題ないからそんなに心配しなくてもいいんじゃね？」
と思う人がいるかもしれませんが、もしうまいことばらけて書き込んでる場合は他のDNもディスクがいっぱいになってるはずなのでわりと状況は深刻です。
HDFSの総容量は常にチェックしておきましょう。

ログ

Hadoop 1.x 及び CDH3 系はデフォルトが DRFA です。
つまり、1日ごとにローテーションしていく形式です。
これにより、ある日のログだけ異様に膨らむということが起こりえます。
CDH4 / Hadoop 2.x 系はデフォルトが RFA でサイズ固定になっています。(デフォルト 256MB * 20ファイル = 5GB)
ログあふれが起こりにくくなっている反面、ログが流れやすいので注意が必要です。

CDH4 で MapReduce1 を使っている人は、MR1だけがデフォルト CDH3 準拠、つまり DRFA になっていることに注意してください。

参考

Hadoopのシステム設計・運用のポイント from Cloudera Japan

捕捉

よく考えたらオリジナルは「容量が少ないというアラートが飛んできたときにどうするか」なので、上記の内容だとただの予防ですね。
とりあえず思いつくのを二つ。

ログ消しましょう

RFA だと昔よりログあふれしにくくなったとはいえ、緊急事態のときには真っ先に削除する対象なのは変わらないでしょう。
クラスタ内に入って Hive を起動している場合、ローカルファイルシステムの /tmp/${ユーザ名}/ 以下に hive.log などのログ一式が収まっていますので、パーティション分けていない場合はこれも消しましょう(微々たるものですが)