会場の後ろでマサカリを振り回しているエバンジェリストがいた「 HDFS HA セミナー」に行ってきました

今日は、Hadoopを高可用化「HDFS HAセミナー」のご案内 on Zusaar に参加してきました。と、いうわけでいつものとおりブログを書いておこうと思います。マサカリを振り回しているエバンジェリストがいたｗ勉強会でしたが、個人的には CDH4 の運用経験がなかったので大変勉強になった会でした。

f:id:garage-kid:20130530233342p:image:w620

アジェンダは以下のとおりで、

【アジェンダ】

18:15 受付開始

18:30 開会・ご挨拶

18:35「HDFSのHAアークテクチャー」　Cloudera株式会社カスタマーオペレーションズエンジニア　小林大輔氏

19:45「NameNodeHAの導入背景と運用状況」株式会社サイバーエージェント CAMP事業部システムグループ　上原誠氏

20:15 Q&A

20:30 閉会

では、まず所感から

個人的にはもともと CDH3 なユーザだとしたら CDH4 にしなければならない要件のある人は、現状そう多くはないと思っているんですが、もし仮に CDH4 を導入するならば、 HDFS HA は導入したほうがいい内容だなというのが理解出来ました。（共有ディスクが不要で、かつ自動フェールオーバーができる、そして計画的メンテを組みやすくなった）

某エバンジェリストが本当に恐怖のマサカリを振り回していて ((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙでした

次回からは、わたしたちとしては対策として同シリーズの勇者の剣を持参したほうがいいんでしょうかｗ

ちなみに恐怖のマサカリのレビューにはかなりウケました。必見かと。

以降よりわたしのノートになります。

18:30　開会・ご挨拶

HDFS の SPOF 問題を解決するために HDFS HA が生まれたが、なかなか活用が難しいと思うので、その仕組みを紹介したい。

18:35　「HDFSのHAアークテクチャー」　Cloudera株式会社カスタマーオペレーションズエンジニア　小林大輔氏

スライドへのリンクは ➤ こちら

話すこと：
- 現在のHDFSは安心してお使いいただけますよ、と
- 特にQuorum Journal Manager の仕組みを説明する。
今日は話さないこと：
- HDFS自体の仕組みや運用
- HDFS以外のコンポーネントの説明

➤ なぜHDFS HAが開発されたのか

HDFS は master-slave 構成
- 実際の Data は DN に配置されている、そして meta data は NN に格納されている

Client は NN に実データのありかを問い合わせて、その後、その DN にデータをとりにいく
DN については落ちたとしても replication factor の設定次第でデータ欠損は起こらない
しかし、 NN は落ちるとそれでおしまいだった SPOF

＊＊＊＊＊

既存の問題点
- NN がシングルスターであるため、SPOFだった
- ダウンした場合にはHadoopクラスタのデータにアクセスできなかった
- パッチ適用など計画的なメンテナンスも難しかった

➤ HDFS HA を構成する要素

HDFS HA は三段階の開発フェーズをへた

SBN の導入
自動フェイルオーバーの導入
Quorum Journal Manager の導入

＊＊＊＊＊

SBN の導入
- NN をふたつにしようという発想。
- しかし edits, fsimage などはふたつもつわけにはいかないので共有ディスクにもたないといけなかった
- 課題
  - NASが必要である
  - 障害の検知が大変
  - サードパーティによる障害検知、手動フェイルオーバーが必要
自動フェイルオーバーの導入
- アクティブNNの障害を自動検知する仕組みの導入、HW, SW, NW
- 2つのコンポーネントが必要
  - ZK と ZKFC
  - ZK はアクティブNNの障害検知
    次にどのNNがアクティブになるべきか
  - ZKFC
    NNごとにひとつ必要
    NNの状態を監視
- フェイルオーバーのシナリオの説明（スライドをみたい）
- 課題
  - 編集ログが SPOF（共有ディレクトリはNFSに依存）
  - NFSが抱える課題
  - SAN/NAS といった外部HWを必要とする
  - そのための監視も必要
- 共有ストレージの改良
  - 第一要件
    特別なHWを必要としないこと
    複雑なカスタムフェンシング構成を必要としないこと
    ストレージにSPOFが存在せず、分散構成とすること
  - 第二要件
    耐障害性をもつこと
    一部のノードに障害が起こっても問題にならない
    パフォーマンス劣化を起こさないこと
    既存のHW資産を利用すること (NN、SBN)
- 課題2
  - スプリットブレインシンドローム
  - NW分断が発生し、ひとつのサービスが同時に複数起動してしまうこと
  - 両NNが同じタイミングで自分自身をActiveとみなしてEditsの書き込みを行ってしまう状況
  - データ破壊の懸念（スプリットプレインの説明のスライド）
Quorum Journal Managerの導入
- 2つのコンポーネント
  - Quorum Journal Manager
  - Edits書き込みのClientとして動作
- Journal Node
  - 3 つ以上の奇数個必要、共有ディスクの代替として働くことができる
- NN はこれまでどおり、ローカルディスクにEditsをローカルディスクに書き込む
  - Quorum Journal Manager が各 Journal node にその Edits を同期する
- [Tips]
  - 各NNはエポック番号という自然数をもつ
  - FO時や再起動時にひとつづつ増加
  - NN間で順序づけを提供
  - より大きなエポック番号をもつほうが常にアクティブとなるようにしている
  - promised epoch:
    すべての JN がもつ最新のエポック番号
    NNがアクティブになるたびにJNのエポック番号を取得し、ひとつ増加させる
  - NNが起動したいと思ったら、JNからエポック番号を取得する、NNはエポック番号をインクリメントしてJNに返す。2つ以上のJNからそのエポック番号を承認しましたよ、と返信が返ってきた時 NN が起動する
  - Edits の編集の際にもエポック番号は使われる
    その仕組をスライドで説明（資料をあとでみたい）

➤ 実際の HFDS HA 構成例について

HDFS HA の構成例
- 最小構成は 3 台（全台、従来の NN に求められていたのと同様に信頼性の高い HW を選択すること）

ZK, ZKFC, ANN, JN
ZK, ZKFC, SBN, JN
ZK, ZKFC, JT, JN

➤最後に

現在のHDFSは十分に信頼性の高いFSになっている
国内外問わず、多くのEnterprise環境で使われている
スピーカーの経験の限りデータ欠損という話はきいたことがない

➤QA

Q1. FOをしたときの遅延はどれほどあるものなのか？

ほとんどない、1秒足らずでFOする
HDFS HA が hot standby であることが大きい

Q2. HDFS Federation の HA との比較はあるか？

Federation を組んだ状態で HA になる

Q3. ANN のプロセスが死んだ場合、それは down だと認識されるのか？

Yes、すぐに FO する

Q4. CDH4.2から SNN はなくなった？

なくなってはいない、 HA を使わない人は依然いるので。

Q5. CDH4.3でHA何かかわった？

基本変更はない Bugfix のみ

Q6 . JT HAは？

この構成を応用している
ZK, ZKFC を使う

Q7. フェンシングについて

QJM のおかげでフェンシング必要ないということになるんだが、エポック番号だけではFOに失敗する場合がある
sshfence, shell は依然必要

Q8. HWレベルでのフェンシングは？

それは不要

Q9. JN について

JNが不能な状態になったら QJM がそれを検知する
不足分は QJM が補う

Q10. JN の復旧

一台壊れて、他に新たに立てたい場合は、現状生きている JN から最新の Edits を sync することで復旧できる

Q11. QJM はどうやってあたらしく追加された JN を検知するのか？

確認して折り返してくれるらしい

Q12. Demoはないですか？

HA になってない環境にあらたに HA を導入したり、と。
すでに HA になっている環境の Demo 、Cloudera Manager で
CM でHAの有効無効の変更は簡単

Q13. NTPサーバは必須か？

同じ時刻を同期する必要があるのでもちろん必要。
HA 関係なく Hadoop Cluster は時刻同期は必要。
CM は時刻同期ができていなければ、その警告がなされるようになっている

Q14. エポック番号を確認する方法はありますか？

CMからは現状できない
サーバローカルから確認はできる text file に書かれている

19:45　「NameNodeHAの導入背景と運用状況」株式会社サイバーエージェント CAMP事業部システムグループ　上原誠氏

スライドへのリンクは ➤ こちら

➤ 自己紹介

twitter: @pioho07 / facebook: makoto.uehara.39

➤NN HA 導入背景

Ameba での Hadoop の使い方
2007年から使っている Amebro のアクセス解析
ログ解析基盤を CDH3 を使って。
2012、オンライン用途でのグラフデータを扱うデータストア、HBaseも使用
2013、ミニグラフHBase、レコメンドHBase、CDH4を使用

＊＊＊＊＊

2010まではオンラインでの使用はなかった、社内にとじていた
2012以降からオンラインでの使用がはじまった、停止することがサービス断につながる使い方もはじめた

＊＊＊＊＊

ながらく NN は SPOF だった
- NN に障害がおこると何が起こるかという説明
- HDFS が起動しなくなり、各エコシステムの MR, HBase が機能しなくなる
NNがなかったときには、冗長性を2つほど検討した
- OSS(Heartbeat, Pacemaker, ORDB, kemari)
  - メリット：事例は多かった
  - デメリット：設計、構築が複雑になりがち、時間もなかった(結果断念)
- HW FT(Fault Torerance)
  - メリット：HWレベルの冗長性なので安心、メモリ情報もロストしない
  - デメリット：高い（6-700万とにかく高い）、メンテができない