SlideShare una empresa de Scribd logo
1 de 48
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

Más contenido relacionado

La actualidad más candente

インフラエンジニアのためのcassandra入門
インフラエンジニアのためのcassandra入門インフラエンジニアのためのcassandra入門
インフラエンジニアのためのcassandra入門Akihiro Kuwano
 
Apache BigtopによるHadoopエコシステムのパッケージング(Open Source Conference 2021 Online/Osaka...
Apache BigtopによるHadoopエコシステムのパッケージング(Open Source Conference 2021 Online/Osaka...Apache BigtopによるHadoopエコシステムのパッケージング(Open Source Conference 2021 Online/Osaka...
Apache BigtopによるHadoopエコシステムのパッケージング(Open Source Conference 2021 Online/Osaka...NTT DATA Technology & Innovation
 
Apache Hadoop YARNとマルチテナントにおけるリソース管理
Apache Hadoop YARNとマルチテナントにおけるリソース管理Apache Hadoop YARNとマルチテナントにおけるリソース管理
Apache Hadoop YARNとマルチテナントにおけるリソース管理Cloudera Japan
 
Hadoop/Spark を使うなら Bigtop を使い熟そう! ~並列分散処理基盤のいま、から Bigtop の最近の取り組みまで一挙ご紹介~(Ope...
Hadoop/Spark を使うなら Bigtop を使い熟そう! ~並列分散処理基盤のいま、から Bigtop の最近の取り組みまで一挙ご紹介~(Ope...Hadoop/Spark を使うなら Bigtop を使い熟そう! ~並列分散処理基盤のいま、から Bigtop の最近の取り組みまで一挙ご紹介~(Ope...
Hadoop/Spark を使うなら Bigtop を使い熟そう! ~並列分散処理基盤のいま、から Bigtop の最近の取り組みまで一挙ご紹介~(Ope...NTT DATA Technology & Innovation
 
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)Noritaka Sekiyama
 
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)NTT DATA OSS Professional Services
 
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...NTT DATA Technology & Innovation
 
1000台規模のHadoopクラスタをHive/Tezアプリケーションにあわせてパフォーマンスチューニングした話
1000台規模のHadoopクラスタをHive/Tezアプリケーションにあわせてパフォーマンスチューニングした話1000台規模のHadoopクラスタをHive/Tezアプリケーションにあわせてパフォーマンスチューニングした話
1000台規模のHadoopクラスタをHive/Tezアプリケーションにあわせてパフォーマンスチューニングした話Yahoo!デベロッパーネットワーク
 
Apache Bigtopによるオープンなビッグデータ処理基盤の構築(オープンデベロッパーズカンファレンス 2021 Online 発表資料)
Apache Bigtopによるオープンなビッグデータ処理基盤の構築(オープンデベロッパーズカンファレンス 2021 Online 発表資料)Apache Bigtopによるオープンなビッグデータ処理基盤の構築(オープンデベロッパーズカンファレンス 2021 Online 発表資料)
Apache Bigtopによるオープンなビッグデータ処理基盤の構築(オープンデベロッパーズカンファレンス 2021 Online 発表資料)NTT DATA Technology & Innovation
 
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線Motonori Shindo
 
40分でわかるHadoop徹底入門 (Cloudera World Tokyo 2014 講演資料)
40分でわかるHadoop徹底入門 (Cloudera World Tokyo 2014 講演資料) 40分でわかるHadoop徹底入門 (Cloudera World Tokyo 2014 講演資料)
40分でわかるHadoop徹底入門 (Cloudera World Tokyo 2014 講演資料) hamaken
 
事例で学ぶApache Cassandra
事例で学ぶApache Cassandra事例で学ぶApache Cassandra
事例で学ぶApache CassandraYuki Morishita
 
分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)
分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)
分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)NTT DATA Technology & Innovation
 
CloudFront経由でのCORS利用
CloudFront経由でのCORS利用CloudFront経由でのCORS利用
CloudFront経由でのCORS利用Yuta Imai
 
ポスト・ラムダアーキテクチャの切り札? Apache Hudi(NTTデータ テクノロジーカンファレンス 2020 発表資料)
ポスト・ラムダアーキテクチャの切り札? Apache Hudi(NTTデータ テクノロジーカンファレンス 2020 発表資料)ポスト・ラムダアーキテクチャの切り札? Apache Hudi(NTTデータ テクノロジーカンファレンス 2020 発表資料)
ポスト・ラムダアーキテクチャの切り札? Apache Hudi(NTTデータ テクノロジーカンファレンス 2020 発表資料)NTT DATA Technology & Innovation
 
Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編Yuki Morishita
 
マイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPCマイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPCdisc99_
 
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjugYahoo!デベロッパーネットワーク
 
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方Yoshiyasu SAEKI
 

La actualidad más candente (20)

Apache Hadoopの新機能Ozoneの現状
Apache Hadoopの新機能Ozoneの現状Apache Hadoopの新機能Ozoneの現状
Apache Hadoopの新機能Ozoneの現状
 
インフラエンジニアのためのcassandra入門
インフラエンジニアのためのcassandra入門インフラエンジニアのためのcassandra入門
インフラエンジニアのためのcassandra入門
 
Apache BigtopによるHadoopエコシステムのパッケージング(Open Source Conference 2021 Online/Osaka...
Apache BigtopによるHadoopエコシステムのパッケージング(Open Source Conference 2021 Online/Osaka...Apache BigtopによるHadoopエコシステムのパッケージング(Open Source Conference 2021 Online/Osaka...
Apache BigtopによるHadoopエコシステムのパッケージング(Open Source Conference 2021 Online/Osaka...
 
Apache Hadoop YARNとマルチテナントにおけるリソース管理
Apache Hadoop YARNとマルチテナントにおけるリソース管理Apache Hadoop YARNとマルチテナントにおけるリソース管理
Apache Hadoop YARNとマルチテナントにおけるリソース管理
 
Hadoop/Spark を使うなら Bigtop を使い熟そう! ~並列分散処理基盤のいま、から Bigtop の最近の取り組みまで一挙ご紹介~(Ope...
Hadoop/Spark を使うなら Bigtop を使い熟そう! ~並列分散処理基盤のいま、から Bigtop の最近の取り組みまで一挙ご紹介~(Ope...Hadoop/Spark を使うなら Bigtop を使い熟そう! ~並列分散処理基盤のいま、から Bigtop の最近の取り組みまで一挙ご紹介~(Ope...
Hadoop/Spark を使うなら Bigtop を使い熟そう! ~並列分散処理基盤のいま、から Bigtop の最近の取り組みまで一挙ご紹介~(Ope...
 
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
 
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
 
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
 
1000台規模のHadoopクラスタをHive/Tezアプリケーションにあわせてパフォーマンスチューニングした話
1000台規模のHadoopクラスタをHive/Tezアプリケーションにあわせてパフォーマンスチューニングした話1000台規模のHadoopクラスタをHive/Tezアプリケーションにあわせてパフォーマンスチューニングした話
1000台規模のHadoopクラスタをHive/Tezアプリケーションにあわせてパフォーマンスチューニングした話
 
Apache Bigtopによるオープンなビッグデータ処理基盤の構築(オープンデベロッパーズカンファレンス 2021 Online 発表資料)
Apache Bigtopによるオープンなビッグデータ処理基盤の構築(オープンデベロッパーズカンファレンス 2021 Online 発表資料)Apache Bigtopによるオープンなビッグデータ処理基盤の構築(オープンデベロッパーズカンファレンス 2021 Online 発表資料)
Apache Bigtopによるオープンなビッグデータ処理基盤の構築(オープンデベロッパーズカンファレンス 2021 Online 発表資料)
 
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
 
40分でわかるHadoop徹底入門 (Cloudera World Tokyo 2014 講演資料)
40分でわかるHadoop徹底入門 (Cloudera World Tokyo 2014 講演資料) 40分でわかるHadoop徹底入門 (Cloudera World Tokyo 2014 講演資料)
40分でわかるHadoop徹底入門 (Cloudera World Tokyo 2014 講演資料)
 
事例で学ぶApache Cassandra
事例で学ぶApache Cassandra事例で学ぶApache Cassandra
事例で学ぶApache Cassandra
 
分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)
分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)
分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)
 
CloudFront経由でのCORS利用
CloudFront経由でのCORS利用CloudFront経由でのCORS利用
CloudFront経由でのCORS利用
 
ポスト・ラムダアーキテクチャの切り札? Apache Hudi(NTTデータ テクノロジーカンファレンス 2020 発表資料)
ポスト・ラムダアーキテクチャの切り札? Apache Hudi(NTTデータ テクノロジーカンファレンス 2020 発表資料)ポスト・ラムダアーキテクチャの切り札? Apache Hudi(NTTデータ テクノロジーカンファレンス 2020 発表資料)
ポスト・ラムダアーキテクチャの切り札? Apache Hudi(NTTデータ テクノロジーカンファレンス 2020 発表資料)
 
Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編
 
マイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPCマイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPC
 
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
 
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
 

Destacado

IIJ GIOを支える統合運用監視基盤
IIJ GIOを支える統合運用監視基盤IIJ GIOを支える統合運用監視基盤
IIJ GIOを支える統合運用監視基盤IIJ
 
HDFS HA セミナー #hadoop
HDFS HA セミナー #hadoopHDFS HA セミナー #hadoop
HDFS HA セミナー #hadoopCloudera Japan
 
Docker勉強会2017 実践編 スライド
Docker勉強会2017 実践編 スライドDocker勉強会2017 実践編 スライド
Docker勉強会2017 実践編 スライドShiojiri Ohhara
 
Simplify and Secure your Hadoop Environment with Hortonworks and Centrify
Simplify and Secure your Hadoop Environment with Hortonworks and CentrifySimplify and Secure your Hadoop Environment with Hortonworks and Centrify
Simplify and Secure your Hadoop Environment with Hortonworks and CentrifyHortonworks
 
Hadoop and Kerberos
Hadoop and KerberosHadoop and Kerberos
Hadoop and KerberosYuta Imai
 
AWSマネージドサービスをフル活用したヘルスケアIoTプラットフォーム
AWSマネージドサービスをフル活用したヘルスケアIoTプラットフォームAWSマネージドサービスをフル活用したヘルスケアIoTプラットフォーム
AWSマネージドサービスをフル活用したヘルスケアIoTプラットフォームHiroki Takeda
 
Dockerイメージの理解とコンテナのライフサイクル
Dockerイメージの理解とコンテナのライフサイクルDockerイメージの理解とコンテナのライフサイクル
Dockerイメージの理解とコンテナのライフサイクルMasahito Zembutsu
 
Docker入門 - 基礎編 いまから始めるDocker管理
Docker入門 - 基礎編 いまから始めるDocker管理Docker入門 - 基礎編 いまから始めるDocker管理
Docker入門 - 基礎編 いまから始めるDocker管理Masahito Zembutsu
 

Destacado (9)

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

Más de Cloudera Japan

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

Más de Cloudera Japan (20)

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