Hadoopの運用について書いてみる

Hadoop

CROSS 2014の分散処理システムCROSSってのをUSTREAMで聞いてたらHadoopの運用の話が出てたのでその辺の話について書いてみようと思います。

ひとくちにHadoopの運用っていっても業務形態（自分達で運用して自分達で使うのか、Treasure Dataのようにお客さんに使ってもらう環境なのかなど）、ユースケース（サービス側のストレージとして使っているのか、バックエンドのログ分析に使っているのかなど）や規模（ノード数が数十台なのか数百台なのか数千台なのかなど）やシステム構成（オンプレミスなのかAWS使っているのかなど）によっても色々と違ってくると思います。

僕が見ているHadoopクラスタはオンプレミスでログ分析用に使っていてデータ量はなかなかに多いです。HBaseやHiveも使っているのですが、ここではHadoopというかHDFSとMapReduceの話にしぼりましょう。

僕の環境の場合は障害で一番よくあるのはHDD障害です。一時期は毎日のように起きてました。mapとreduceのスロット数を減らしたらぱったり障害が起きなくなったんだけど、最近また増えてきてちょっとアレ。ていうか新規に増設したマシンで起きているんですよね。事前にインフラ側でストレステストをやってくれているようなんですけどリアルのストレスには耐えられないディスクもあるようです。

HDD障害時にdecommissionはしてません。理由はデータ量が多く時間がかかりすぎるから。単にデーモン止めるだけです。decommissionしないと交換したHDDとそうでないHDDでデータ使用率がアンバランスになっちゃうんですがそのままにしてます。CDH4.3にも入った[HDFS-1804] Add a new block-volume device choosing policy that looks at free space - ASF JIRAが使えるなら大丈夫でしょうが、僕の環境はHadoop 1.2.1なのです。

あとdfs.datanode.failed.volumes.toleratedに1を設定しているので2つ以上のディスクに障害が発生しない限りはdatanodeは動き続けるようにしています。

JMX経由でメトリクスとって独自のグラフツールでグラフ化してますが、あんまりチェックしてないですね。。。これをチェックした方が良いとかありましたら教えてください。

例えばJMXの項目でMissingBlocksがありますけどhadoop fsckしてHEALTHYなのにJMXのMissingBlocksが0より大きいとかあって対応関係がよくわからんですね。なんか勘違いしているんだと思うけど。。。

hadoop fsckの結果としてのmissing blockの経験はdfs.replicationを1にしてHDD障害が起きたときとか、dfs.data.dirの設定をミスったときにありますけどそれ以外は無いかな。fluent-plugin-webhdfsでHDFSに書き込んでいるときにバッファ溢れが起きてhadoop fsckの結果としてcorrupt blockになったことはあります。append noオプションをつけるように変えたりとかも試しましたが、これはこれでNameNodeにGCが起きてRegionServerが6台ダウンとかあったのでちょっと止めてます。いろいろ設定いじってたので因果関係は無いかもしれませんが。

ともあれHDFSの状態があまりよくないからfluentdでバッファ溢れが起きてるんだと思いますが詳細は不明です。ネットワーク周りで少し問題があったのでもしそれが原因ならスイッチ増強をしたのでそれで改善すればいいなーと思ってます。

missing blockはもしかしたら設定ミスが原因かもしれないので復旧出来るかもしれませんが、corrupt blockを復旧する方法は知りません。

DataNodeが突然ダウンしたっていうのはあったような気がしますが、そんなには無いですね。HBaseのRegionServerはよくダウンしますけど。

NameNodeダウンは１回経験してます。原因はHDD溢れという古典的なものです。

次にMapReduceがらみですけど、JobTrackerのフリーズみたいなのは2回ぐらい経験しました。原因ははっきりしないですけど、最近起きたやつはmap数が大量（例：３万とか）のジョブを複数submitしてOutOfMemoryになっていたのでその辺が原因なのかなと思います。

TaskTrackerが突然ダウンしたって経験は無いですね。ただshuffleが遅くなったので再起動したってのはあります。

なおTaskTrackerを再起動するとmapred.local.dirで指定したディレクトリを初期化するみたいでJobTrackerに認識されるまで時間がかかる（場合によっては1時間以上かかる）のでディレクトリを別名にrenameしてからTaskTrackerを起動してました。rmだと時間かかるけどmvなら一瞬だからですね。

JobTrackerのメトリクスもJMXで取ってます。running_mapsとrunning_reducesを見るとどの時間帯がジョブが混雑しているか分かります。僕の環境だと夜間バッチ実行中の一番混雑している時間帯ではスロットをフルに使い切ってましたね。

まあそんな感じです。他の人はどんな感じなんだろ。Hadoop運用飲み会をグリフォン（じゃなくてもいいけど）でやったら面白いかな。