#garagekidztweetz

読者です 読者をやめる 読者になる 読者になる

#garagekidztweetz

id:garage-kid@76whizkidz のライフログ・ブログ!

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

conference hadoop CDH lifelog

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

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

【アジェンダ】
  • 18:15 受付開始
  • 18:30 開会・ご挨拶
  • 18:35「HDFSのHAアークテクチャー」 Cloudera株式会社 カスタマーオペレーションズエンジニア 小林大輔氏
  • 19:45「NameNodeHAの導入背景と運用状況」株式会社サイバーエージェント CAMP事業部 システムグループ 上原 誠氏
  • 20:15 Q&A
  • 20:30 閉会

では、まず所感から

  • 個人的にはもともと CDH3 なユーザだとしたら CDH4 にしなければならない要件のある人は、現状そう多くはないと思っているんですが、もし仮に CDH4 を導入するならば、 HDFS HA は導入したほうがいい内容だなというのが理解出来ました。(共有ディスクが不要で、かつ自動フェールオーバーができる、そして計画的メンテを組みやすくなった)
  • 某エバンジェリストが本当に恐怖のマサカリを振り回していて ((((;゚Д゚))))ガクガクブルブル でした
    • 次回からは、わたしたちとしては対策として同シリーズの勇者の剣を持参したほうがいいんでしょうかw
    • ちなみに恐怖のマサカリのレビューにはかなりウケました。必見かと。

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

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 は三段階の開発フェーズをへた
  1. SBN の導入
  2. 自動フェイルオーバー の導入
  3. Quorum Journal Manager の導入

*****

  1. SBN の導入
    • NN をふたつにしようという発想。
    • しかし edits, fsimage などはふたつもつわけにはいかないので共有ディスクにもたないといけなかった
    • 課題
      • NASが必要である
      • 障害の検知が大変
      • サードパーティによる障害検知、手動フェイルオーバーが必要
  2. 自動フェイルオーバーの導入
    • アクティブ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の書き込みを行ってしまう状況
      • データ破壊の懸念(スプリットプレインの説明のスライド)
  3. 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 を選択すること)
  1. ZK, ZKFC, ANN, JN
  2. ZK, ZKFC, SBN, JN
  3. 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万とにかく高い)、メンテができない

*****

  • その後、 CDH4 で NN HA がリリース
    • CDH 4.0.0 , NAS が必要で断念
    • CDH 4.1.0 で検証し、導入
      • NFS のかわりに QJM

*****

  • 仕組みや考え方は他のClusterwareと同様
  • そんなむずかしくなかった、と

*****

  • 障害試験は概ね良好だった
    • NN プロセスダウン
    • はまったところ
    • フェンシングの設定→ photo

*****

  • 運用のオペレーションもシンプル
    • hdfs haadmin -failover

*****

  • 構成はどうなったのか? photo
➤NN HA 運用状況
  • 特に HA 構成にしたことによってトラブルは発生していない
    • ZK, ZKFC も良好

*****

  • 経験した障害
    • NW トラフィックが高騰し、 NN が FO したことはあった
    • ZKFC と ZK の通信が途絶えてタイムアウト、 NN の FO が起きた
    • これによる目に見えるサービス影響はなかった

*****

  • 結局 HA どうなの?
    • 計画メンテができるという点が、すごく大きなメリットだとおもう
    • 今後はマストでしょう、と
➤QA

Q1. slave node をどういったタイミングで増やしていくのか?

  • 何を気にしてみているか?
  • 基本的には容量、 MR も気にするなら CPU 負荷

Q2. Hadoop の監視

  • Ganglia で取れる監視項目を精査している

Q3. Hertbeat や ORDB での HA から CDH の HA に移行したほうがいいですか? - @pioho07 さんから直に指摘をいただき追記

  • Hertbeat や ORDB は運用する上でオペレータが複数のOSSを理解する必要があり、バグ踏む可能性もあるのでよりシンプルなCDHのHAを推奨します。verupのタイミングがあれば是非!実績が出ていてお勧めできる機能です、とのこと。

参考2:

では、今日はこんなところで。

こちらもあわせてどうぞ