HDFS NameNodeの利用ディスク容量肥大の対処(Amazon EMRのケース)

課題

EMRの単一のクラスタを長い期間運用していると/mnt/var/lib/hadoop/dfs-name/currentが肥大してくるケースがある。EMR(Hadoop2.4.xの場合)では/home/hadoop/conf/hdfs-site.xml下記のような指定があるので、当該ディレクトリはHDFS NameNodeのディレクトリであることがわかる。

<property>
	<name>dfs.name.dir</name>
	<value>/mnt/var/lib/hadoop/dfs-name</value>
</property>

仕組みと原因

このCurrentというディレクトリの中にはfsimageと呼ばれるHDFSのスナップショットファイルとeditsと呼ばれるジャーナルファイルが保存されている。他にもいろいろあるが、この2つがおもにディスク容量を食う原因。

• fsimage
• HDFSのメタデータのスナップショット
• dfs.namenode.num.checkpoints.retainedで何世代とっておくかが指定されている
• デフォルト値は2。EMRではそのままデフォルト値が採用されている。
• edits
• スナップショット以降のジャーナルファイル
• dfs.namenode.num.extra.edits.retainedでとっておくジャーナルの操作数？を指定されている
• デフォルト値は1,000,000。こちらもEMRではデフォルト値が採用されている。

ある条件を満たすとeditsがfsimageにコンパクションされていく。
ちゃんと自分で検証できていないが、2者のうち、特にeditsが肥大化しやすいとのこと。なので、こいつをいかに抑制するかがポイントの模様。

いちおう、Apache本家のhdfs-default.xmlの解説をみると、下記のように書いてはあるので、無限に肥大していくわけではないはず。

Typically each edit is on the order of a few hundred bytes, so the default of 1 million edits should be on the order of hundreds of MBs or low GBs.

対策

いくつか考えられる

1. editsの保存操作数を抑制する

dfs.namenode.num.extra.edits.retainedもしくはdfs.namenode.max.extra.edits.segments.retainedの値でeditsに保存される操作数を抑制する。

2. コンパクションの間隔を縮める

Clouderaのドキュメントには下記のように書いてあるので、　dfs.namenode.checkpoint.periodもしくはdfs.namenode.checkpoint.txnsを調整して、コンパクションの間隔をコントロールする。

checkpointing is triggered by one of two conditions: if enough time has elapsed since the last checkpoint (dfs.namenode.checkpoint.period), or if enough new edit log transactions have accumulated (dfs.namenode.checkpoint.txns). The checkpointing node periodically checks if either of these conditions are met (dfs.namenode.checkpoint.check.period),

確認できていないこと

コンパクションが発生したあとに、古いeditsがちゃんと捨てられるかどうかはためせていない。

注意点

下記のClouderaのドキュメントにもあるが、Secondary NameNodeやStandby NameNodeがあれば、そちらでコンパクションを実施するという記述があるが、EMRは現状(2015/5時点)で、NameNodeはシングル構成なので注意。

参考資料

• A guide to checkpointing in Hadoop
• hdfs-default.xml
• Hadoop 第3版 10章 Hadoopの管理 10.1 HDFS

Disclaimar

このポストは個人のメモであり、わたしの雇用者を代表する意見やドキュメントではありません。