decommission、rebalance
decommission
DataNode をクラスタから削除したい場合、前回書いたようにノードを停止してしまえば目的は果たせるけれど、停止により複製数が満たなくなるブロックができてしまい、自動複製されるまでにさらにノードが死んだりしたらデータ喪失になりかねない。
これを回避する目的で、decommission という仕組みがあるらしい。これは、複製を先に実行してからノードが停止される仕組みとなっている。
あるノードを decommission させるには、conf/hdfs-site.xml にあらかじめ
dfs.hosts.exclude /path/to/exclude
のように dfs.hosts.exclude パラメータに削除対象のノードを記述するファイルを指定しておく必要がある。そして、そのファイルには一行にひとつ、削除ノードの FQDN もしくは IP を記述する（必要あれば、ポート番号も）。その後、
./bin/hadoop dfsadmin -refreshNodes
を実行する。decommission 進行中であれば、NameNode の WebUI では、該当ノードは "Decommission In Progress" と表示される。複製が完了すれば、Live Nodes からは消えて、Dead Nodes になる（Dead Nodes にはならずに完全に消えると思っていたのだけど、そうでないみたい）。また、該当ノード上の DataNode プロセスも停止する。
一方で、TaskTracker については同じような仕組みが無いように見えるので、強制停止するしかないのだろうか？もっとも、データが失われることにはつながらないのでいいのかな？
rebalance
新規にデータを追加したりすると、ノード毎のディスク使用状況にはばらつきがでる。新しいファイルは空いているノードに積極的に配置されるようであるが、ばらつきは自動的には解消されないらしい。
これを解消する（リバランスする）には、FAQ（の項番６）によるといくつか方法があるようである。
- 使用率の高いファイルをコピーして、オリジナルを消して、コピーしたもののファイル名をオリジナルに戻す。
- ファイルの複製数を上げて、複製が済んでから、複製数を戻す。
- ノードを停止させて、しばらくしてから復帰させる。複製数が設定値より高くなっているファイルが、元のノードから削除されたりしてバランスがとれるということ、らしい。
- bin/start-balancer.sh を実行する。
最後の start-balancer を実行するのがよさげなので、これを使ってみた。
$ ./bin/start-balancer.sh <threshold>
のように実行する。threshold はディスク使用率のばらつきを指定するような感じみたい。たとえば 5 を指定すれば、使用率（%）のばらつきが 5 ポイントの範囲内になるみたい。正しい情報は、Balancer クラスの JavaDoc に記述されている。
またリバランス時に使用される帯域幅は、
dfs.balance.bandwidthPerSec
で設定できるようである。
