Downloaded 127 times
Uploaded byCloudera Japan
HDFSネームノードのHAについて #hcj13w
Hadoop Conference Japan 2013 Winter で発表した、ネームノードHA についての資料です。10分だったのでかなり限定的な説明に終わっています。
HDFSネームノードのHAについて #hcj13w
- 1. High Availability forthe HDFS NameNode Cloudera 2013年1月21日 1
- 2. 自己紹介 • 小林 大輔(@daisukebe_) •カスタマーオペレーションズエンジニアとして テクニカルサポート業務を担当 • email: daisuke@cloudera.com
- 3.
- 4. 従来のネームノードの問題点 • 従来のHadoopではネームノードは単一障害点 (SPOF)だった • ネームノードは、ファイルシステムのメタデータ を管理している(editsログ/fsimageなど) • ネームノードがダウンしたらデータが読み込めず、 クラスタ自体が利用不可になる 4
- 5. 従来のネームノードの問題点 • 従来のHadoopではネームノードは単一障害点 (SPOF)だった • ネームノードは、ファイルシステムのメタデータ を管理している(editsログ/fsimageなど) • ネームノードがダウンしたらデータが読み込めず、 クラスタ自体が利用不可になる HA対応してほしいという需要 5
- 6. ネームノードHAの要件 • メタデータの保存先として、カスタムハード ウェアに依存しないこと • アクティブ/スタンバイ構成において、メタデー タの同期が容易であること • デプロイが容易であること • スプリットブレインシンドロームを避けられる こと • SPOFがないこと • 既存のHadoopクラスタの資産を無駄にしないこ と 6
- 7. ネームノードHAの要件 要は 7
- 8. ネームノードHAの要件 (比較的)簡単に 既存のHadoopの仕組みを 無駄にすることなく HA構成を作れること 8
- 9. ネームノードHA • Apache Hadoop2.0では ネームノードHAが導入されました • CDH4.1にも含まれてます 9
- 10. ネームノードHA • クォーラムベースジャーナリング • 外部のハードウェアに依存しない • 自動フェイルオーバー • 障害発生時にも自動で切り替え可能 10
- 11. 今日は、、 • クォーラムベースジャーナリング • 外部のハードウェアに依存しない • 自動フェイルオーバー • 障害発生時にも自動で切り替え可能 11
- 12.
- 13. クォーラムベースジャーナリング • ネームノードのメタデータ(editsログ)を 複数の場所で保管 • ネームノードはクライアントとして、 editsを書き込む • 複数の書き込み先のうち、過半数 (クォーラム数)のノードに成功すれば editsはコミットとみなす 13
- 14. クォーラムベースジャーナリングの導入 NameNode Quorum JournalManager 14
- 15. クォーラムベースジャーナリングの導入 NameNode editsログの書き込み先として、Quorum JournalManager ジャーナルノード(JN)の導入 15
- 16. クォーラムベースジャーナリングの導入 NameNode 複数のノード上で Quorum JournalManager スタンドアロンのデーモンが動作 16
- 17. クォーラムベースジャーナリングの導入 NameNode 各JNは Quorum JournalManager ローカルディスクにeditsを書き込む 17
- 18. クォーラムベースジャーナリングの導入 NameNode 追加でノードが必要なわけではない アクティブ/スタンバイネームノード、 Quorum jobtracker(比較的信頼性の高いノード) JournalManager の3台にデプロイ 18
- 19. クォーラムベースジャーナリングの導入 NameNode Quorum JournalManager クライアント側は クォーラムジャーナルマネージャ(QJM) 19
- 20. クォーラムベースジャーナリングの導入 NameNode Quorum JournalManager 各ネームノード上にデプロイ 20
- 21. では、、 editsは どのように 書き込まれるのか？ 21
- 22. edits書き込みのフロー Local disk ネームノードは editsをローカルディスクに書き込む 22
- 23. edits書き込みのフロー 書き込みよろー QJMは、logSync()メソッドを使用して すべてのJNへeditsを同期する 23
- 24. edits書き込みのフロー 書き込んだった クォーラム数のJNから 書き込んだった 成功のACKが返ると editsの書き込みに成功したとみなす 24
- 25. edits書き込みのフロー クォーラム数未満のJNからしか 書き込んだった 成功のACKが返ってこなければ editsの書き込みに失敗したとみなす 25
- 26. ところで、、 ネームノードHAは アクティブ/スタンバイ構成 26
- 27. ところで、、 両ネームノードからeditsが 書き込まれる恐れはないの？ 27
- 28. これは、、 両ネームノードから 同時に書き込んでしまうと データに不整合が生じてしまう 28
- 29. ファイルシステムとしての 信頼性が損なわれる 29
- 30. 最悪 データ破損も招きかねないので 非常に危険！ 30
- 31. NameNode NameNode Quorum Quorum JournalManager JournalManager JounalNode JounalNode JounalNode 31
- 32. NameNode NameNode Quorum Quorum JournalManager JournalManager JounalNode JounalNode JounalNode 32
- 33. NameNode NameNode Quorum Quorum JournalManager JournalManager どのネームノードがアクティブなのか JournalNodeが判断できなければ 両ノードからの書き込みを許してしまう JounalNode JounalNode JounalNode 33
- 34. そこで、、 クォーラムベースジャーナリング にはフェンシングの 仕組みがある 34
- 35. そこで、、 フェンシング： editsを書き込めるネームノードは 常にただ1つだけであることを 保証する仕組み 35
- 36. QJMのフェンシング エポック番号を使う 36
- 37. エポック番号 JNが アクティブネームノードを 一意に識別するために 使う番号 37
- 38. エポック番号によるフェンシング • アクティブになるたびに新しい エポック番号が割り振られる • 両ネームノードが同時に同じエポック 番号をもつことはない • JNは最新のエポック番号を保存する 38
- 39. エポック番号によるフェンシング 時系列でみてみると... 39
- 40. エポック番号によるフェンシング ネームノード1 ネームノード2 起動時 1 アクティブになっ た フェイルオーバー 2 フェイルオーバー 3 時間 時間 40
- 41. エポック番号によるフェンシング NameNode NameNode Quorum Quorum JournalManager JournalManager JounalNode JounalNode JounalNode 41
- 42. エポック番号によるフェンシング NameNode NameNode Quorum Quorum JournalManager JournalManager 2 2 2 JounalNode JounalNode JounalNode 42
- 43. エポック番号によるフェンシング 俺、”1” だわ 俺、”2” だわ NameNode NameNode Quorum Quorum JournalManager JournalManager 1 2 2 2 2 JounalNode JounalNode JounalNode 43
- 44. エポック番号によるフェンシング NameNode NameNode Quorum Quorum JournalManager JournalManager “1” は低いので却下 “2” の書き込みを採用しま す JounalNode JounalNode JounalNode “1” は低いので却下 “2” の書き込みを採用しま す 44
- 45. エポック番号によるフェンシング 書き込めた！ NameNode NameNode Quorum Quorum JournalManager JournalManager クォーラム数からのレスポンスを 得ることで、editsの書き込みに 成功する JounalNode JounalNode JounalNode 45
- 46. まとめ • クォーラムベースジャーナリングを使用 したネームノードHAを紹介しました • editsを複数ノードで分散して保存するこ とで信頼性が高まっています • エポック番号を使用することで、両ネー ムノードから書き込みが発生することを 防いでいます。 46
- 47. 宣伝 • Cloudera Managerを使用することで ネームノードHAへの移行が非常に簡単に できます • Cloudera社のブースでデモを行なって いるので、立ち寄ってみてください 47
- 48.