SlideShare a Scribd company logo
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
                     JournalManager




14
クォーラムベースジャーナリングの導入


                                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         JounalNode




31
NameNode                    NameNode

             Quorum                   Quorum
         JournalManager           JournalManager




     JounalNode           JounalNode         JounalNode




32
NameNode                    NameNode

             Quorum                   Quorum
         JournalManager           JournalManager



        どのネームノードがアクティブなのか
          JournalNodeが判断できなければ
        両ノードからの書き込みを許してしまう

     JounalNode           JounalNode         JounalNode




33
そこで、、



     クォーラムベースジャーナリング
        にはフェンシングの
         仕組みがある



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         JounalNode




41
エポック番号によるフェンシング


              NameNode                    NameNode

                Quorum                   Quorum
            JournalManager           JournalManager




                2                    2                   2
        JounalNode           JounalNode         JounalNode




42
エポック番号によるフェンシング

     俺、”1” だわ                                                        俺、”2” だわ
                      NameNode                    NameNode

                        Quorum                   Quorum
                    JournalManager           JournalManager

                                     1
                                                 2




                        2                    2                   2
                JounalNode           JounalNode         JounalNode




43
エポック番号によるフェンシング


              NameNode                    NameNode

                Quorum                   Quorum
            JournalManager           JournalManager


                                                    “1” は低いので却下
                                                “2” の書き込みを採用しま
                                                          す



        JounalNode           JounalNode         JounalNode

                                     “1” は低いので却下
                                 “2” の書き込みを採用しま
                                           す
44
エポック番号によるフェンシング

                                                         書き込めた!
              NameNode                    NameNode

                Quorum                   Quorum
            JournalManager           JournalManager



               クォーラム数からのレスポンスを
                得ることで、editsの書き込みに
                     成功する

        JounalNode           JounalNode         JounalNode




45
まとめ

     •   クォーラムベースジャーナリングを使用
         したネームノードHAを紹介しました
     •   editsを複数ノードで分散して保存するこ
         とで信頼性が高まっています
     •   エポック番号を使用することで、両ネー
         ムノードから書き込みが発生することを
         防いでいます。



46
宣伝

     •   Cloudera Managerを使用することで
         ネームノードHAへの移行が非常に簡単に
         できます
     •   Cloudera社のブースでデモを行なって
         いるので、立ち寄ってみてください




47
48

More Related Content

PPTX
Hadoop -NameNode HAの仕組み-
PPTX
Hadoop -ResourceManager HAの仕組み-
PDF
HDFSのスケーラビリティの限界を突破するためのさまざまな取り組み | Hadoop / Spark Conference Japan 2019 #hc...
PDF
Hadoopの概念と基本的知識
PDF
Apache Bigtop3.2 (仮)(Open Source Conference 2022 Online/Hiroshima 発表資料)
PDF
#cwt2016 Cloudera Managerを用いた Hadoop のトラブルシューティング
PDF
Hadoop入門
PPTX
Apache BigtopによるHadoopエコシステムのパッケージング(Open Source Conference 2021 Online/Osaka...
Hadoop -NameNode HAの仕組み-
Hadoop -ResourceManager HAの仕組み-
HDFSのスケーラビリティの限界を突破するためのさまざまな取り組み | Hadoop / Spark Conference Japan 2019 #hc...
Hadoopの概念と基本的知識
Apache Bigtop3.2 (仮)(Open Source Conference 2022 Online/Hiroshima 発表資料)
#cwt2016 Cloudera Managerを用いた Hadoop のトラブルシューティング
Hadoop入門
Apache BigtopによるHadoopエコシステムのパッケージング(Open Source Conference 2021 Online/Osaka...

What's hot (20)

PDF
データインターフェースとしてのHadoop ~HDFSとクラウドストレージと私~ (NTTデータ テクノロジーカンファレンス 2019 講演資料、2019...
PDF
Cephのベンチマークをしました
PDF
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
PPTX
ポスト・ラムダアーキテクチャの切り札? Apache Hudi(NTTデータ テクノロジーカンファレンス 2020 発表資料)
PDF
Apache Hadoop YARNとマルチテナントにおけるリソース管理
PDF
YugabyteDBを使ってみよう - part2 -(NewSQL/分散SQLデータベースよろず勉強会 #2 発表資料)
PDF
MongoDB概要:金融業界でのMongoDB
PPTX
BigtopでHadoopをビルドする(Open Source Conference 2021 Online/Spring 発表資料)
PDF
分散処理基盤Apache Hadoop入門とHadoopエコシステムの最新技術動向 (オープンソースカンファレンス 2015 Tokyo/Spring 講...
PDF
Hadoopのシステム設計・運用のポイント
PDF
アーキテクチャから理解するPostgreSQLのレプリケーション
PDF
ZabbixのAPIを使って運用を楽しくする話
PDF
AlmaLinux と Rocky Linux の誕生経緯&比較
PDF
Spring Cloud Data Flow の紹介 #streamctjp
PDF
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
PDF
macOSの仮想化技術について ~Virtualization-rs Rust bindings for virtualization.framework ~
PDF
40分でわかるHadoop徹底入門 (Cloudera World Tokyo 2014 講演資料)
PPTX
大規模データ活用向けストレージレイヤソフトのこれまでとこれから(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)
PDF
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
PPTX
Metaspace
データインターフェースとしてのHadoop ~HDFSとクラウドストレージと私~ (NTTデータ テクノロジーカンファレンス 2019 講演資料、2019...
Cephのベンチマークをしました
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
ポスト・ラムダアーキテクチャの切り札? Apache Hudi(NTTデータ テクノロジーカンファレンス 2020 発表資料)
Apache Hadoop YARNとマルチテナントにおけるリソース管理
YugabyteDBを使ってみよう - part2 -(NewSQL/分散SQLデータベースよろず勉強会 #2 発表資料)
MongoDB概要:金融業界でのMongoDB
BigtopでHadoopをビルドする(Open Source Conference 2021 Online/Spring 発表資料)
分散処理基盤Apache Hadoop入門とHadoopエコシステムの最新技術動向 (オープンソースカンファレンス 2015 Tokyo/Spring 講...
Hadoopのシステム設計・運用のポイント
アーキテクチャから理解するPostgreSQLのレプリケーション
ZabbixのAPIを使って運用を楽しくする話
AlmaLinux と Rocky Linux の誕生経緯&比較
Spring Cloud Data Flow の紹介 #streamctjp
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
macOSの仮想化技術について ~Virtualization-rs Rust bindings for virtualization.framework ~
40分でわかるHadoop徹底入門 (Cloudera World Tokyo 2014 講演資料)
大規模データ活用向けストレージレイヤソフトのこれまでとこれから(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
Metaspace
Ad

Viewers also liked (9)

PDF
IIJ GIOを支える統合運用監視基盤
 
PDF
HDFS HA セミナー #hadoop
PDF
第37回「Dockerのユースケースと将来」(2014/10/30 on しすなま!)
PDF
Docker勉強会2017 実践編 スライド
PDF
Simplify and Secure your Hadoop Environment with Hortonworks and Centrify
PDF
Hadoop and Kerberos
PDF
AWSマネージドサービスをフル活用したヘルスケアIoTプラットフォーム
PDF
Dockerイメージの理解とコンテナのライフサイクル
PDF
Docker入門 - 基礎編 いまから始めるDocker管理
IIJ GIOを支える統合運用監視基盤
 
HDFS HA セミナー #hadoop
第37回「Dockerのユースケースと将来」(2014/10/30 on しすなま!)
Docker勉強会2017 実践編 スライド
Simplify and Secure your Hadoop Environment with Hortonworks and Centrify
Hadoop and Kerberos
AWSマネージドサービスをフル活用したヘルスケアIoTプラットフォーム
Dockerイメージの理解とコンテナのライフサイクル
Docker入門 - 基礎編 いまから始めるDocker管理
Ad

More from Cloudera Japan (20)

PPTX
Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)
PPTX
機械学習の定番プラットフォームSparkの紹介
PPTX
HDFS Supportaiblity Improvements
PDF
分散DB Apache Kuduのアーキテクチャ DBの性能と一貫性を両立させる仕組み 「HybridTime」とは
PDF
Apache Impalaパフォーマンスチューニング #dbts2018
PDF
HBase Across the World #LINE_DM
PDF
Cloudera のサポートエンジニアリング #supennight
PDF
Train, predict, serve: How to go into production your machine learning model
PDF
Apache Kuduを使った分析システムの裏側
PDF
Cloudera in the Cloud #CWT2017
PDF
先行事例から学ぶ IoT / ビッグデータの始め方
PPTX
Clouderaが提供するエンタープライズ向け運用、データ管理ツールの使い方 #CW2017
PDF
How to go into production your machine learning models? #CWT2017
PDF
Apache Kudu - Updatable Analytical Storage #rakutentech
PPTX
Hue 4.0 / Hue Meetup Tokyo #huejp
PDF
Apache Kuduは何がそんなに「速い」DBなのか? #dbts2017
PDF
Cloudera Data Science WorkbenchとPySparkで 好きなPythonライブラリを 分散で使う #cadeda
PDF
Cloudera + MicrosoftでHadoopするのがイイらしい。 #CWT2016
PDF
Cloud Native Hadoop #cwt2016
PDF
大規模データに対するデータサイエンスの進め方 #CWT2016
Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)
機械学習の定番プラットフォームSparkの紹介
HDFS Supportaiblity Improvements
分散DB Apache Kuduのアーキテクチャ DBの性能と一貫性を両立させる仕組み 「HybridTime」とは
Apache Impalaパフォーマンスチューニング #dbts2018
HBase Across the World #LINE_DM
Cloudera のサポートエンジニアリング #supennight
Train, predict, serve: How to go into production your machine learning model
Apache Kuduを使った分析システムの裏側
Cloudera in the Cloud #CWT2017
先行事例から学ぶ IoT / ビッグデータの始め方
Clouderaが提供するエンタープライズ向け運用、データ管理ツールの使い方 #CW2017
How to go into production your machine learning models? #CWT2017
Apache Kudu - Updatable Analytical Storage #rakutentech
Hue 4.0 / Hue Meetup Tokyo #huejp
Apache Kuduは何がそんなに「速い」DBなのか? #dbts2017
Cloudera Data Science WorkbenchとPySparkで 好きなPythonライブラリを 分散で使う #cadeda
Cloudera + MicrosoftでHadoopするのがイイらしい。 #CWT2016
Cloud Native Hadoop #cwt2016
大規模データに対するデータサイエンスの進め方 #CWT2016

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

  • 1. High Availability for the HDFS NameNode Cloudera 2013年1月21日 1
  • 2. 自己紹介 • 小林 大輔(@daisukebe_) • カスタマーオペレーションズエンジニアとして テクニカルサポート業務を担当 • email: daisuke@cloudera.com
  • 4. 従来のネームノードの問題点 • 従来のHadoopではネームノードは単一障害点 (SPOF)だった • ネームノードは、ファイルシステムのメタデータ を管理している(editsログ/fsimageなど) • ネームノードがダウンしたらデータが読み込めず、 クラスタ自体が利用不可になる 4
  • 5. 従来のネームノードの問題点 • 従来のHadoopではネームノードは単一障害点 (SPOF)だった • ネームノードは、ファイルシステムのメタデータ を管理している(editsログ/fsimageなど) • ネームノードがダウンしたらデータが読み込めず、 クラスタ自体が利用不可になる HA対応してほしいという需要 5
  • 6. ネームノードHAの要件 • メタデータの保存先として、カスタムハード ウェアに依存しないこと • アクティブ/スタンバイ構成において、メタデー タの同期が容易であること • デプロイが容易であること • スプリットブレインシンドロームを避けられる こと • SPOFがないこと • 既存のHadoopクラスタの資産を無駄にしないこ と 6
  • 8. ネームノードHAの要件 (比較的)簡単に 既存のHadoopの仕組みを 無駄にすることなく HA構成を作れること 8
  • 9. ネームノードHA • Apache Hadoop2.0では ネームノードHAが導入されました • CDH4.1にも含まれてます 9
  • 10. ネームノードHA • クォーラムベースジャーナリング • 外部のハードウェアに依存しない • 自動フェイルオーバー • 障害発生時にも自動で切り替え可能 10
  • 11. 今日は、、 • クォーラムベースジャーナリング • 外部のハードウェアに依存しない • 自動フェイルオーバー • 障害発生時にも自動で切り替え可能 11
  • 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. 48