• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
HDFSネームノードのHAについて #hcj13w
 

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

on

  • 3,036 views

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

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

Statistics

Views

Total Views
3,036
Views on SlideShare
2,573
Embed Views
463

Actions

Likes
5
Downloads
71
Comments
0

2 Embeds 463

http://open-groove.net 437
https://twitter.com 26

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 HDFSネームノードのHAについて #hcj13w Presentation Transcript

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