HDFSネームノードのHAについて #hcj13w
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

HDFSネームノードのHAについて #hcj13w

on

  • 3,501 views

Hadoop Conference Japan 2013 Winter で発表した、ネームノードHA についての資料です。10分だったのでかなり限定的な説明に終わっています。

Hadoop Conference Japan 2013 Winter で発表した、ネームノードHA についての資料です。10分だったのでかなり限定的な説明に終わっています。

Statistics

Views

Total Views
3,501
Views on SlideShare
2,963
Embed Views
538

Actions

Likes
6
Downloads
77
Comments
0

2 Embeds 538

http://open-groove.net 510
https://twitter.com 28

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

HDFSネームノードのHAについて #hcj13w Presentation Transcript

  • 1. High Availability for the HDFS NameNode Cloudera 2013年1月21日1
  • 2. 自己紹介• 小林 大輔(@daisukebe_)• カスタマーオペレーションズエンジニアとして テクニカルサポート業務を担当• email: daisuke@cloudera.com
  • 3. ネームノードHAとは?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. クォーラムベースジャーナリングについて12
  • 13. クォーラムベースジャーナリング • ネームノードのメタデータ(editsログ)を 複数の場所で保管 • ネームノードはクライアントとして、 editsを書き込む • 複数の書き込み先のうち、過半数 (クォーラム数)のノードに成功すれば editsはコミットとみなす13
  • 14. クォーラムベースジャーナリングの導入 NameNode Quorum JournalManager14
  • 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 JounalNode31
  • 32. NameNode NameNode Quorum Quorum JournalManager JournalManager JounalNode JounalNode JounalNode32
  • 33. NameNode NameNode Quorum Quorum JournalManager JournalManager どのネームノードがアクティブなのか JournalNodeが判断できなければ 両ノードからの書き込みを許してしまう JounalNode JounalNode JounalNode33
  • 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 JounalNode41
  • 42. エポック番号によるフェンシング NameNode NameNode Quorum Quorum JournalManager JournalManager 2 2 2 JounalNode JounalNode JounalNode42
  • 43. エポック番号によるフェンシング 俺、”1” だわ 俺、”2” だわ NameNode NameNode Quorum Quorum JournalManager JournalManager 1 2 2 2 2 JounalNode JounalNode JounalNode43
  • 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 JounalNode45
  • 46. まとめ • クォーラムベースジャーナリングを使用 したネームノードHAを紹介しました • editsを複数ノードで分散して保存するこ とで信頼性が高まっています • エポック番号を使用することで、両ネー ムノードから書き込みが発生することを 防いでいます。46
  • 47. 宣伝 • Cloudera Managerを使用することで ネームノードHAへの移行が非常に簡単に できます • Cloudera社のブースでデモを行なって いるので、立ち寄ってみてください47
  • 48. 48