CDH4.0.0のNameNode HAを触ってみて

Hadoop Source Code
Reading 11th

CDH4.0.0のNameNode HAを触ってみて

07/30/2012
NTT DATA Corporation
Shinichi Yamashita

Copyright © 2012 NTT DATA Corporation

自己紹介

• Shinichi Yamashita (山下真一)
• ＮＴＴデータでHadoopを扱っている...

• 仕事での最近の取り組み
• サポート関係
• エコシステム評価
• 案件対応
• 最近思っていること
• すそ野を広げることは大切だ！
Copyright © 2012 NTT DATA Corporation 2

おさらい: HDFSの可用性

• DataNode ・・・障害発生時にサービス継続できる仕組み ○
• ブロック（ファイルを一定サイズで分割されているもの）を
分割、レプリカを保存
• NameNodeとの通信により、異常が発生した場合に、レプ
リカ再配置が自動的に実行
• NameNode ・・・ダウン = HDFSサービスの停止 ×

• 四六時中データ操作、ジョブ実行するようなケースで
は、HDFSサービス停止は頭が痛い
• 連鎖的な後続処理の遅延
• 分析等処理遅延による機会損失

Common method of the availability of NameNode

• CDH3, Hadoop 1.0 ...
• Pacemaker + DRBD (Cold-Standby) : share NN-meta directory
• AvatarNode (Facebook)

HDFS

NameNode NameNode
mirror
DRBD DRBD
Clustering
Control Pacemaker Pacemaker Control

Active Standby

Issues on common method of the availability of NameNode

• Re-run of MapReduce Job during NameNode fail over
• 実行されているジョブはやり直し
• mapred.jobtracker.restart.recover で途中から実行できる ?

• Safe mode time to start NameNode service
• less 10min : 3 - 100 DataNodes
• 30min – 60min : 100+ DataNodes (10+ million blocks) ...

• クラスタ起動やジョブの再実行など、あるべき姿に戻すための時間は
必要


NameNode HA (Hadoop 2.0)

• Hadoop 2.0 では、NameNode HAが鋭意開発中
• CDH 4.0.0 では、足回りにNFSを利用する方式でリリース済み
・NameNodeプロセスの監視 ZooKeeper quorum
NameNode(Act,
・フェンシング実行 Sby) 状態の管理
・Act, Sbyへの状態遷を実行
ZooKeeper ZooKeeper

監視 ZKFC フェンシング ZKFC
NameNode NameNode
チェックポイント通信
Active edits共有 Standby
NFS
共有ディスク

DataNode DataNode DataNode

・・・


NameNode異常発生時の切り替え

• たとえば、ActiveのNameNodeプロセスが故障・消滅した場合
2. ZKFCがZKに
7. 新NameNode
NameNodeサービ quorum ZooKeeper 情報通知
ス停止を通知
ZKでのロック解放
4. 旧ActNN疎通確認
ZooKeeper ZooKeeper
3. 新NameNode選
旧ActNNをSbyに
択指示変更しようと試行
5. フェンシング
ZKFC ZKFC
フェンシング

NameNode NameNode
Active->消失 Standby->Active
6. NameNode
edits共有
1. ZKFCが Act系に切り替え
NFS
NameNodeの異共有ディスク
常を検知

DataNode DataNode 現用系のZKFCがロックを
DataNode
解放し、待機系のZKFCか
らフェンシングを実行
・・・

ZKFC異常発生時の切り替え

• たとえば、Active系のZKFCがプロセス故障の場合
quorum ZooKeeper 1. ZKFC消失
確認

ZooKeeper ZooKeeper 2. 新NameNode決
定
4. ZooKeeper状態
ZKFC 更新
ZKFC
3.NameNode状態
NameNode 切り替え NameNode
Active->Standby Standby->Active
edits共有

NFS
共有ディスク

DataNode DataNode DataNode
待機系のZKFCが
NameNodeのActiveと
・・・
Standbyを切り替える

いくつかの故障を想定して動作させてみる

ZooKeeper ×3でQuorum DataNode ×3
処理用LAN

ZKFC ZKFC

NameNode NameNode

現用系 NFSサーバ待機系
NFSはsoft
マウント IPMI IPMI

運用LAN

※ 本方式を利用する場合、待機系NameNodeがSecondaryNameNodeの役割を果たす

いくつかの故障を想定して動作させてみる

<確認結果> ※ 多重故障は、考慮していない

No 異常待機系への切り替え
1 現用系NameNodeプロセス故障 ○
2 現用系ZKFCプロセス故障 ○
3 現用系NameNodeサーバ故障 ○
両系
4 現用系NameNodeサービスLAN故障 ○ NameNode
プロセス停止
5 現用系NameNodeディスク故障 ○
6 NFSサーバ故障 ×
7 MapReduceジョブ実行中の現用系故障 ○ 処理継続
8 HDFS操作中の現用系故障 ○

処理継続


NameNode HAのポイントその１

その１ : フェンシング方法 (o.a.h.ha.NodeFencerクラス)
(1)sshfence (o.a.h.ha.SshFenceByTcpPortクラス)
• 異常発生時に、SSHで現用系サーバに接続、fuserコマンドでNameNodeプロセス
を停止
• 実行されるコマンド : fuser –v –k –n tcp <現用系NameNode RPCポート>
(2)shellfence (o.a.h.ha.ShellCommandFencerクラス)
• 各自で用意したシェルスクリプトによって、現用系を停止
• 今回は、IPMI経由でサーバを停止するスクリプトを用意

• フェンシングを実行する場合は、sshfence + shellfenceの組み合わせ
が大切です(sshfenceだけでは×)
• shellfenceは、複数のシェルスクリプトを利用することが可能、対処の影響度が小
さい順番に実行すること


NameNode HAのポイントその２

その２ : NFSサーバ

(1)マウント設定 : ソフトマウントでマウントすること
• ハードマウントの場合、NFS接続のNIC異常の場合に無応答になる
ケースあり
• Cloudera 推奨設定 tcp,soft,intr,timeo=60,retrans=10

(2)NFSサーバ自身の対策
• 現在の実装では、単一故障点(SPOF)であるためHA化が必要
• 複数のNFSサーバのマウント先に記述するような実装が必要か？


NameNode HAのポイントその３

その３ : フェデレーションとの関係
• Namespace単位で、HA環境を実現することは可能

• 設定
• fs.defaultFS (fs.default.name)
• アクセス先となるNamespace名を入れる
• dfs.nameservices : それぞれのNamespaceを定義
• フェデレーション実施時には、カンマ区切りで記述(特にDataNode)
• dfs.ha.namenodes.<Namespace名> : HA対象のNameNode識別名
• dfs.namenode.rpc-address.<Namespace名>.<NameNode識別名>
• dfs.namenode.http-address. <Namespace名>.<NameNode識別名>


NameNode HAのポイントその４

その４ : Full GC発生時の考慮 : タイムアウト設定は意識すること

• NameNode HAでは現用系、待機系ともにメタ情報、ブロック情報を
ヒープメモリで管理する
• 待機系のNameNodeは、従来のSecondaryNameNodeのようにチェッ
クポイント(editsをfsimageにマージ、現用系に転送)を実施する
• 大量データ削除などにより、両系で同時にFull GCが発生する可能性
がある・・・かもしれない
• 両系同時にFull GCが発生する場合は、Full GCから復活すればサービ
スを継続できる(現用系が先の復旧の場合はもちろん、待機系でも)

• とはいえ、ha.health-monitor.rpc-timeout.ms プロパティにより
NameNodeで発生するFull GC時間をもとにタイムアウト値を変更する
ことで対処できる(デフォルト60000ミリ秒)

NameNode HAのポイントその５

その５ : NameNodeメタ領域 : 1.0系から少々変わっています

• fsimage : 保存世代数を設定できる
• 保存世代数 : 2世代 (dfs.namenode.num.checkpoints.retained)
• チェックポイント間隔 : 3600秒(dfs.namenode.checkpoint.period)

• edits : 間隔が短くなった
• 保存世代数 : 1,000,000世代(dfs.namenode.num.extra.edits.retained)
• チェックポイント間隔 : 120,000ミリ秒 (dfs.ha.log-roll.period)

edits保存世代数など、値をチューニングして利用したほうが良いようなパ
ラメータも有り


雑感

• MapReduceジョブが継続できるという点は魅力的
• これまでの方式で切り替わるタイミングでジョブ実行中が結構な割
合であったため
• 切り替え後のあるべき姿への復旧で結構時間を要しているため
• 守るべきポイントがNFSに変わっただけ(むしろ増えた)
• NFSサーバにHAクラスタミドルを適用する？
• 複数のNFSサーバに書き込んでどれか１つでも成功すればOKな仕
組みがあれば、、、
• モニターする仕組みも足りないので、作りこむ必要あり
• ZKFCの情報取得
• チェックポイント動作の状況確認

• さらにプロパティが増えた

まとめ

• NameNode HAは、NFSでもOKであれば利用できそうか...？

• 構成や設定は、十分検証したうえで決めること

• 本当のHAという意味では、おとなしくBookKeeperを待つべき

• もっと別の技術を組み合わせるという方法も
• フォールトトレラント技術？


Thank you!



CDH4.0.0のNameNode HAを触ってみて

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to CDH4.0.0のNameNode HAを触ってみて

Similar to CDH4.0.0のNameNode HAを触ってみて (20)

More from NTT DATA OSS Professional Services

More from NTT DATA OSS Professional Services (20)

Recently uploaded

Recently uploaded (9)

CDH4.0.0のNameNode HAを触ってみて