Hadoop ソースコードリーディング第11回に行ってきたよ
Hadoopソースコードリーディング 第11回のメモを共有しよう #hadoopreading
http://d.hatena.ne.jp/garage-kid/20120730/hadoopreading11
メモ共有です。
上記エントリを参考に補ったり、補わせてもらったりしました。
■CDH4に入った新機能 NameNode HA の実力を試してみました （NTTデータ 山下 真一 氏）
CDH3の場合
・hearbeat + DRBD
・facebookが提供しているAvoterNode
課題
切り替わった瞬間にmapreduceが中断
切り替わった後に、もう一回実行しなおさなければならない
mapred.jobtracker.restart.recoverがあるがCDH3では動かない
namenode立ち上げ後、元のように使うには時間がかかる（ブロック数が多ければ多いほど）
そこで、namenode HA(CDH4から提供)
NFSでeditsファイルを共有
zkfc(ZooKeeper FailoverController)がフェンシング
name nodeが落ちた場合
active側が落ちる
active側のzkfcが検知
新しいのname nodeを選ばせる
落ちた方のname nodeの疎通確認
フェンシング
新しいname nodeをactiveに
新しいname nodeの情報通知
ホットスタンバイ形式で動いている
秒単位のオーダーで動く
active側のzkfcが壊れた場合
zkfcでロックが消失
スタンバイ側のnamenodeに切り替え
zkの状態を更新
mapreduce実行中に故障→問題なし
HDFS操作中に故障→問題なし
NFS故障では待機系のサーバ切り替えは不可能
どっちのname nodeもプロセス停止
namenode HAのポイント
２種類フェンシング方法がある
・sshfence
sshでログイン→コマンドでプロセス停止
fuser -v -k -n tcp <NN RPC port>実行(デフォルトポートは8020)
・shellfece
自分で作ったシェルでプロセス停止
両方のフェンシングを設定しておくこと(なんらかの理由でそもそもsshログインできなかった場合に備えて）
ソフトマウントすること
ハードマウントだとNIC異常時に応答がかえってこなくてそのまま終了になる場合がある
NFS自身の対策
HA化が必要
複数のNFSのマウント先に記述する実装が必要
→今のところ、仕様上できない
フェデレーション
namespace単位でHA実現は可能
設定
fs.default.name
アクセス先のnamespaceを入れる
dfs.namesarvive
Full GC発生時の考慮
タイムアウトの設定は意識すること
namenode HAは現用、待機系ともにメタ、ブロック情報はヒープメモリで持ってるので、注意
Full GCやってるときはサービス停止してるがそれ以外は停止しない
namenodeのメタ領域
1.0から少し変わっている
fsimage
保存世代数を設定できる
dfs.namenode.chekcpoint.retained
チェックポイント間隔
dfs.namenode.checkpoint.period
edits
保存世代数 100万世代(デフォルト)
dfs.namenode.num.extra.edits.retained
チェックポイント間隔が短くなった
namenode HAのメリット
mapreduceが継続できる
ダウンタイムが数秒
namenode HAデメリット
モニターする仕組みが足りてない
webインターフェースで見れるものがない
NFSサーバがシングルポイント
設定するプロパティが増える
構成や設定は十分検証が必要
HAという意味ではBookKeeperを持つべき
ほかの手段と組み合わせるという手も
Fault Tolerance
■複数ＤＣで運用するhadoop/hiveデータ解析（GMOインターネット 新里 祐教 @hirotakaster 氏）
http://www.slideshare.net/hirotaka/data-analytics-with-hadoop-hive-on-multiple-data-centers
複数拠点それぞれにnamenodeを置いている
自前の集計用スケジューラ
クライアントはそれらをマネージするシステムから実行単位等(hourly,daily...)を操作する
dailyで２０ＴＢオーバーのトラフィック
Hive + MySQL でデータ解析
テーブルのカラムを変更する際には、tmpテーブルを作って対応
データフロー
いったん来たログを突っ込むログサーバー１２００台
データをつっこむのはhiveのload dataを使ってパーティション指定(date,log_number)でつっこむ
定期的にhadoop arciveを使ってnamenodeがメモリオーバーしないようにしている
マネジメントシステム
zabbixで監視
manage用のネットワークを立てている
namenodeのメモリ等を監視
トラブルシューティング
単純に全スロットにメモリさしてもよろしくない
パフォーマンスがすごい低下する
分析の再実行
バックアップ、リカバリー
NFS使ってた
ver2だとサイズ２Ｇ以上のサイズは受け渡しできない
今はＮＦＳ＋metadataのbackupをtazで保存
Hiveに完全依存してはいない
mapredeceを自分で書いたりもしてる
１５０並列ほど
CPU 5,600
DCをまたいだ処理はしてない
ネットワーク帯域よりもレイテンシがネックとなりすごい遅い
解析済みデータはアーカイブ行き
HDFS上で管理する意味はない
