• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
HDFS HA セミナー #hadoop
 

HDFS HA セミナー #hadoop

on

  • 4,714 views

2013/05/30に開催した、HDFS HA(High Availability: ...

2013/05/30に開催した、HDFS HA(High Availability: 高可用性)セミナーの資料です。同じくご登壇頂いた、株式会社サイバーエージェントの上原誠様の資料は↓です。
http://www.slideshare.net/makotouehara39/cl-st-20130530nnha

Statistics

Views

Total Views
4,714
Views on SlideShare
3,575
Embed Views
1,139

Actions

Likes
18
Downloads
96
Comments
0

7 Embeds 1,139

https://bozuman.cybozu.com 598
http://open-groove.net 447
https://twitter.com 49
https://bozuman.s.cybozu.com 42
http://oracle.sociview.com 1
http://s.deeeki.com 1
http://mym.corp.yahoo.co.jp 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

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 セミナー #hadoop HDFS HA セミナー #hadoop Presentation Transcript

    • 1HDFS  HAのアーキテクチャと詳細  2013/05/30  HDFS  HAセミナー    Cloudera  株式会社 小林大輔  
    • 開始に先立って  •  今日お話しすること  •  現在のHDFSは安心してお使いいただけます  •  CDH4から導入されたHDFS  HAのご紹介と技術詳細  •  特に4.1以降のQuorum  Journal  Managerの仕組み  •  今日お話ししないこと  •  HDFS自体の仕組みや運用  •  HDFS以外のコンポーネントの説明  2©2013 Cloudera, Inc. All RightsReserved.
    • 自己紹介  •  小林 大輔  •  2012年9月  Cloudera  入社  •  カスタマーオペレーションズエンジニア  •  主に国内外のテクニカルサポート業務を担当  •  email:  daisuke@cloudera.com  •  twiFer:  daisukebe_  3©2013 Cloudera, Inc. All RightsReserved.
    • アジェンダ  •  なぜHDFS  HAが開発されたか  •  HDFS  HAを構成する要素について  •  実際のHDFS  HA構成例について 4©2013 Cloudera, Inc. All RightsReserved.
    • •  なぜHDFS  HAが開発されたか  •  HDFS  HAを構成する要素について  •  実際のHDFS  HAシステム構成について 5©2013 Cloudera, Inc. All RightsReserved.アジェンダ  
    • なぜHDFS  HAが開発されたか(HDFSのおさらい)  6©2013 Cloudera, Inc. All RightsReserved.データノード  ネームノード        データノード    データノード    データノード  データノード    データノード     データノード  データノード    データノード    データ  データ  データ  データ  データ  データ  データ  データ  データ  クライアント  メタデータ  
    • 7©2013 Cloudera, Inc. All RightsReserved.データノード  ネームノード        データノード    データノード    データノード  データノード    データノード     データノード  データノード    データノード    データ  データ  データ  データ  データ  データ  データ  データ  データ  クライアント  メタデータ  1.  ネームノードにデータの  格納場所を尋ねる なぜHDFS  HAが開発されたか(HDFSのおさらい)  
    • 8©2013 Cloudera, Inc. All RightsReserved.データノード  ネームノード        データノード    データノード    データノード  データノード    データノード     データノード  データノード    データノード    データ  データ  データ  データ  データ  データ  データ  データ  データ  クライアント  メタデータ  2.  実データの格納先を教える なぜHDFS  HAが開発されたか(HDFSのおさらい)  
    • 9©2013 Cloudera, Inc. All RightsReserved.データノード  ネームノード        データノード    データノード    データノード  データノード    データノード     データノード  データノード    データノード    データ  データ  データ  データ  データ  データ  データ  データ  データ  クライアント  メタデータ  3.  データノードから  実データを読み書きする なぜHDFS  HAが開発されたか(HDFSのおさらい)  
    • 10©2013 Cloudera, Inc. All RightsReserved.データノード  ネームノード        データノード    データノード    データノード  データノード    データノード     データノード  データノード    データノード    データ  データ  データ  データ  データ  データ  データ  データ  データ  クライアント  メタデータ  なぜHDFS  HAが開発されたか(HDFSのおさらい)  DOWN!! もしひとつのデータノードが  ダウンしても…
    • 11©2013 Cloudera, Inc. All RightsReserved.データノード  ネームノード        データノード    データノード    データノード  データノード    データノード     データノード  データノード    データノード    データ  データ  データ  データ  データ  データ  データ  データ  データ  クライアント  メタデータ  なぜHDFS  HAが開発されたか(HDFSのおさらい)  DOWN!! クライアントは他の  データノードにあるレプリカを  参照することができる
    • 12©2013 Cloudera, Inc. All RightsReserved.データノード  ネームノード        データノード    データノード    データノード  データノード    データノード     データノード  データノード    データノード    データ  データ  データ  データ  データ  データ  データ  データ  データ  クライアント  メタデータ  なぜHDFS  HAが開発されたか(HDFSのおさらい)  DOWN!! クライアントは他の  データノードにあるレプリカを  参照することができる    =  スレーブノードには耐障害性があり  実データを失うことはない
    • 13©2013 Cloudera, Inc. All RightsReserved.データノード  ネームノード        データノード    データノード    データノード  データノード    データノード     データノード  データノード    データノード    データ  データ  データ  データ  データ  データ  データ  データ  データ  クライアント  メタデータ DOWN!! ネームノードがダウンすると… なぜHDFS  HAが開発されたか(HDFSのおさらい)  
    • 14©2013 Cloudera, Inc. All RightsReserved.データノード  ネームノード        データノード    データノード    データノード  データノード    データノード     データノード  データノード    データノード    データ  データ  データ  データ  データ  データ  データ  データ  データ  クライアント  メタデータ DOWN!! クライアントはデータの  格納先がわからず、データの  読み書きができなくなる なぜHDFS  HAが開発されたか(HDFSのおさらい)  
    • 15©2013 Cloudera, Inc. All RightsReserved.データノード  ネームノード        データノード    データノード    データノード  データノード    データノード     データノード  データノード    データノード    データ  データ  データ  データ  データ  データ  データ  データ  データ  クライアント  メタデータ DOWN!! クライアントはデータの  格納先がわからず、データの  読み書きができなくなる    =  HDFSの課題 なぜHDFS  HAが開発されたか(HDFSのおさらい)  
    • 16©2013 Cloudera, Inc. All RightsReserved.データノード  ネームノード        データノード    データノード    データノード  データノード    データノード     データノード  データノード    データノード    データ  データ  データ  データ  データ  データ  データ  データ  データ  クライアント  メタデータ DOWN!! ネームノード        メタデータ  なぜHDFS  HAが開発されたか(HDFSの問題点)  片方がダウンしても、代替ノードへ  切り替え、クラスタダウンを防げると嬉しい
    • •  問題点  •  ネームノードがシングルマスターであるため、SPoF(単一障害点)だった  •  ダウンした場合にはHadoopクラスタのデータにアクセスできなくなる  •  パッチ適用など計画的なメンテナンスも難しい状況  17©2013 Cloudera, Inc. All RightsReserved.なぜHDFS  HAが開発されたか(HDFSの問題点)  
    • •  なぜHDFS  HAが開発されたか  •  HDFS  HAを構成する要素について  •  実際のHDFS  HA構成について 18©2013 Cloudera, Inc. All RightsReserved.アジェンダ  
    • HDFS  HAの構成要素  HDFS  HAは3段階の開発フェーズを経た  1.  スタンバイネームノード(SBN)の導入  2.  自動フェイルオーバーの導入  3.  QuorumJournalManagerの導入  共有ストレージの改善  19©2013 Cloudera, Inc. All RightsReserved.
    • 1.  スタンバイネームノードの導入  •  アクティブ切り替え用ホットスタンバイネームノード  •  編集ログはNFS上に保存して共有  •  手動フェイルオーバーのみ対応  20©2013 Cloudera, Inc. All RightsReserved.
    • 1.  スタンバイネームノードの導入  21©2013 Cloudera, Inc. All RightsReserved.アクティブ  ネームノード  スタンバイ  ネームノード  編集ログ (NFS上)
    • ©2012 Cloudera, Inc. All RightsReserved.22  1.  課題  •  NASが必要である点  •  管理が複雑で高価  •  障害の検知が大変 •  サードパーティ製品による障害検知、手動フェイルオーバーが必要  •  ネームノードの障害自体は稀だが…  
    • 2.  自動フェイルオーバーの導入  •  アクティブネームノードの障害を自動検知する仕組みを導入  •  HW,  SW,  Network  •  障害検知後、自動的にスタンバイネームノードへフェイルオーバーする仕組みを導入  23©2013 Cloudera, Inc. All RightsReserved.
    • 2.  自動フェイルオーバーの導入  •  ZooKeeper(ZK)  •  アクティブネームノードの障害検知  •  次にどのネームノードがアクティブになるべきかを選定  •  ZooKeeperFailoverController(ZKFC)  •  ネームノード毎にひとつ必要  •  ネームノードの状態を監視  •  フェイルオーバー時に旧アクティブノードが停止していることを確認  24©2013 Cloudera, Inc. All RightsReserved.
    • ZooKeeper 2.  自動フェイルオーバーの導入  25©2013 Cloudera, Inc. All RightsReserved.アクティブ  ネームノード  ZKFC  スタンバイ  ネームノード  ZKFC  host2 host1 ZooKeeper ZooKeeper 編集ログ (NFS上)
    • ZooKeeper 2.  自動フェイルオーバーのシナリオ  26©2013 Cloudera, Inc. All RightsReserved.アクティブ  ネームノード  ZKFC  スタンバイ  ネームノード  ZKFC  host2 host1 ZooKeeper ZooKeeper 編集ログ (NFS上)
    • ZooKeeper 2.  自動フェイルオーバーのシナリオ  27©2013 Cloudera, Inc. All RightsReserved.アクティブ  ネームノード  ZKFC  スタンバイ  ネームノード  ZKFC  host2 host1 ZooKeeper ZooKeeper DOWN 1.  host1のネームノードが  ダウンすると… 編集ログ (NFS上)
    • ZooKeeper 2.  自動フェイルオーバーのシナリオ  28©2013 Cloudera, Inc. All RightsReserved.アクティブ  ネームノード  ZKFC  スタンバイ  ネームノード  ZKFC  host2 host1 ZooKeeper ZooKeeper DOWN NNが  ダウンした! 2.  ZKFCが検知 編集ログ (NFS上)
    • ZooKeeper 2.  自動フェイルオーバーのシナリオ  29©2013 Cloudera, Inc. All RightsReserved.アクティブ  ネームノード  ZKFC  スタンバイ  ネームノード  ZKFC  host2 host1 ZooKeeper ZooKeeper DOWN 3.  ZKFCが障害を通知 編集ログ (NFS上)
    • ZooKeeper 2.  自動フェイルオーバーのシナリオ  30©2013 Cloudera, Inc. All RightsReserved.アクティブ  ネームノード  ZKFC   ZKFC  host2 host1 ZooKeeper ZooKeeper DOWN スタンバイ  ネームノード  4.  ZooKeeperはhost2の  NNをアクティブとみなす 編集ログ (NFS上)
    • ZooKeeper 2.  自動フェイルオーバーのシナリオ  31©2013 Cloudera, Inc. All RightsReserved.アクティブ  ネームノード  ZKFC   ZKFC  host2 host1 ZooKeeper ZooKeeper DOWN スタンバイ  ネームノード  5.  host2のZKFCはhost1の  NNが停止していることを確認 編集ログ (NFS上)
    • ZooKeeper 2.  自動フェイルオーバーのシナリオ  32©2013 Cloudera, Inc. All RightsReserved.アクティブ  ネームノード  ZKFC  アクティブ  ネームノード  ZKFC  host2 host1 ZooKeeper ZooKeeper 6.  host2のNNがアクティブ  として起動する(フェイルオーバー完了) DOWN 編集ログ (NFS上)
    • 2.  課題1  •  編集ログがSPoF  •  共有ディレクトリはやはりNFSに依存している  •  NFS  が抱える課題  •  SAN/NAS  といった外部ハードウェアを必要とする  •  そのための監視も必要  •  NFS  クライアントが抱える不具合  33©2013 Cloudera, Inc. All RightsReserved.
    • 共有ストレージの改良  •  第一要件  •  特別な HW  を必要としないこと  •  複雑なカスタムフェンシング構成を必要としないこと  •  ストレージに SPoF が存在せず、分散構成とすること  34©2013 Cloudera, Inc. All RightsReserved.
    • 共有ストレージの改良  •  第二要件  •  障害耐性をもつこと  •  一部のノードに障害が発生しても問題とならない  •  (N-­‐1)/2 までの耐障害性  •  パフォーマンス劣化を招かないこと  •  書き込みが並列に行え、書き込みが遅いノードの影響を受けないこと  •  既存のハードウェア資産を利用すること  •  ネームノード、スタンバイネームノードなど  35©2013 Cloudera, Inc. All RightsReserved.
    • 2.  課題2  ©2012 Cloudera, Inc. All RightsReserved.36•  スプリットブレインシンドローム  •  一般的には、ネットワーク分断が発生し、ひとつのサービスが同時に複数起動してしまうこと  •  両ネームノードが同じタイミングで自分自身をアクティブと見なして編集ログの書き込みを行う状況  •  データ破壊やクラスタの停止を引き起こす危険な状態  •  常にひとつのネームノードしか書き込みを行わないことを保証しなければならない  
    • 2.  スプリットブレインシンドローム  37©2013 Cloudera, Inc. All RightsReserved.アクティブ  ネームノード  ZKFC   ZKFC  host2 host1 1.  host1  -­‐>  host2へ  フェイルオーバー後… DOWN アクティブ  ネームノード  編集ログ(NFS上)  
    • 2.  スプリットブレインシンドローム  38©2013 Cloudera, Inc. All RightsReserved.アクティブ  ネームノード  ZKFC   ZKFC  host2 host1 2.  host1のNNがアクティブとして  起動してしまうと… アクティブ  ネームノード  編集ログ(NFS上)  
    • 2.  スプリットブレインシンドローム  39©2013 Cloudera, Inc. All RightsReserved.アクティブ  ネームノード  ZKFC   ZKFC  host2 host1 3.  同時に同じファイルに書き込みを行い  データの破壊を招く アクティブ  ネームノード  編集ログ(NFS上)  
    • 2.  スプリットブレインシンドローム  40©2013 Cloudera, Inc. All RightsReserved.アクティブ  ネームノード  ZKFC   ZKFC  host2 host1 4.  host1のアクティブノードが  決して編集ログを書き込めないよう  保証しなければならない  =  フェンシング  アクティブ  ネームノード  編集ログ(NFS上)  
    • 3.  Quorum  Journal  Managerの導入  •  Quorum  Journal  Manager(QJM)  •  編集ログ書き込みのクライアントとして動作  •  JournalNode(JN)  •  編集ログ書き込みのサーバーデーモン  •  奇数個のノード上で動作させる必要がある  •  ローカルディスク上に編集ログを格納  41©2013 Cloudera, Inc. All RightsReserved.
    • 3.  Quorum  Journal  Managerの導入  ©2012 Cloudera, Inc. All RightsReserved.42JounalNode JounalNode JounalNode アクティブ  ネームノード  Quorum  JournalManager ローカルディスク ローカルディスク ローカルディスク
    • 3.  編集ログ書き込みの仕組み  ©2012 Cloudera, Inc. All RightsReserved.43JounalNode JounalNode JounalNode ローカルディスク ローカルディスク 1.  編集ログの書き込み ローカルディスク ローカルディスク アクティブ  ネームノード  Quorum  JournalManager
    • 3.編集ログ書き込みの仕組み  ©2012 Cloudera, Inc. All RightsReserved.44JounalNode JounalNode JounalNode ローカルディスク 2.  同期 ローカルディスク ローカルディスク ローカルディスク 1.  編集ログの書き込み アクティブ  ネームノード  Quorum  JournalManager
    • 3.編集ログ書き込みの仕組み  ©2012 Cloudera, Inc. All RightsReserved.45JounalNode JounalNode JounalNode ローカルディスク 2.  同期 3.  ローカルディスクへの  書き込み ローカルディスク ローカルディスク アクティブ  ネームノード  Quorum  JournalManager ローカルディスク 1.  編集ログの書き込み
    • 3.編集ログ書き込みの仕組み  ©2012 Cloudera, Inc. All RightsReserved.46JounalNode JounalNode JounalNode ローカルディスク 2.  同期 3.  ローカルディスクへの  書き込み ローカルディスク ローカルディスク 4.  書き込み成功 アクティブ  ネームノード  Quorum  JournalManager ローカルディスク 1.  編集ログの書き込み
    • 3.編集ログ書き込みの仕組み  ©2012 Cloudera, Inc. All RightsReserved.47JounalNode JounalNode JounalNode ローカルディスク 2.  同期 3.  ローカルディスクへの  書き込み ローカルディスク ローカルディスク 4.  書き込み成功 5.  過半数からのノードで  書き込みに成功することで  ネームノードとして書き込みに  成功したとみなす  アクティブ  ネームノード  Quorum  JournalManager ローカルディスク 1.  編集ログの書き込み
    • 3.  エポック番号  ©2012 Cloudera, Inc. All RightsReserved.48•  各ネームノードはエポック番号という自然数をもつ  •  フェイルオーバー時や再起動時にひとつずつ増加  •  ネームノード間で順序付けを提供  ネームノード1 ネームノード2 時間 時間 起動時 1 2 3 フェイルオーバー フェイルバック アクティブになった より大きな  エポック番号を  もつネームノードがアクティブノード
    • 3.  エポック番号  ©2012 Cloudera, Inc. All RightsReserved.49•  promised  epoch: すべてのJournalNodeが持つ最新のエポック番号  •  ネームノードがアクティブになるたびに、JournalNodeのエポック番号を取得し、ひとつ増加する  •  この作業が定足数(ここでは過半数)のJournalNodeで成功しなければアクティブネームノードになれない  •  ふたつのネームノードが同時にこの作業を行なっても、必ずひとつのネームノードしか定足数を獲得できない  
    • 3.  エポック番号によるフェンシング1  ©2012 Cloudera, Inc. All RightsReserved.50JounalNode   JounalNode    JounalNode  1.  すべてのJournalNodeの  エポック番号を確認 1 1 1 1 1 1 アクティブ  ネームノード  Quorum  JournalManager アクティブとして  起動したい
    • 3.  エポック番号によるフェンシング1  ©2012 Cloudera, Inc. All RightsReserved.51JounalNode   JounalNode    JounalNode   2 2 2 1 1 1 アクティブ  ネームノード  Quorum  JournalManager 2.  取得したエポック番号を  ひとつ増加させ、再度すべての  JournalNodeへ送信
    • 3.  エポック番号によるフェンシング1  ©2012 Cloudera, Inc. All RightsReserved.52JounalNode    JounalNode    JounalNode   1 2 2 アクティブ  ネームノード  Quorum  JournalManager 2 3.  定足数のJournalNode  が受け入れると、アクティブ  ネームノードになれる アクティブとして  起動完了
    • 3.  エポック番号によるフェンシング2  ©2012 Cloudera, Inc. All RightsReserved.53•  編集ログの書き込み時にもエポック番号を使う  •  ネームノードが編集ログを同期するとき、常に自分が持っているエポック番号を一緒に送る  •  編集ログの書き込みに成功するためには、JournalNodeにエポック番号が最新だと認識してもらう必要がある  
    • ネームノードA  Quorum  JournalManager ネームノードB  Quorum  JournalManager 3.  エポック番号によるフェンシング2  ©2012 Cloudera, Inc. All RightsReserved.54JounalNode   JounalNode   JounalNode  2 1 書き込みたい 書き込みたい 2 2 2
    • ネームノードA  Quorum  JournalManager ネームノードB  Quorum  JournalManager 3.  エポック番号によるフェンシング2  ©2012 Cloudera, Inc. All RightsReserved.55JounalNode   JounalNode   JounalNode  書き込みたい 書き込みたい 2 2 2 2 1
    • ネームノードA  Quorum  JournalManager ネームノードB  Quorum  JournalManager 3.  エポック番号によるフェンシング2  ©2012 Cloudera, Inc. All RightsReserved.56JounalNode   JounalNode   JounalNode  ネームノードAの書き込みを受け入れる ネームノードAの書き込みを  受け入れる 2 2 2 2 1
    • 3.  エポック番号によるフェンシング2  ©2012 Cloudera, Inc. All RightsReserved.57JounalNode   JounalNode   JounalNode  ネームノードA  Quorum  JournalManager ネームノードB  Quorum  JournalManager 書き込み失敗… 書き込み成功 2 2 2 2 1
    • •  なぜHDFS  HAが開発されたか  •  HDFS  HAを構成する要素について  •  実際のHDFS  HA構成について 58©2013 Cloudera, Inc. All RightsReserved.アジェンダ  
    • HDFS  HAのシステム構成  ©2012 Cloudera, Inc. All RightsReserved.59ZooKeeper アクティブ  ネームノード  ZKFC  スタンバイ  ネームノード  ZKFC  ZooKeeper ZooKeeper JounalNode JounalNode JounalNode
    • HDFS  HAのシステム構成  ©2012 Cloudera, Inc. All RightsReserved.60ZooKeeper アクティブ  ネームノード  ZKFC  スタンバイ  ネームノード  ZKFC  ZooKeeper ZooKeeper JounalNode JounalNode JounalNode •  何台必要なんだろう?  •  マシンスペックはどうすればいいんだろう?  
    • HDFS  HAのシステム構成(例)  ©2012 Cloudera, Inc. All RightsReserved.61アクティブ  ネームノード  ZKFC  スタンバイ  ネームノード  JounalNode ジョブトラッカー  host1 host2 host3 ZooKeeper ZKFC  JounalNode ZooKeeper JounalNode ZooKeeper
    • 今日お話ししたこと  •  なぜHDFS  HAが開発されたか  •  HDFS  HAを構成する要素について  •  実際のHDFS  HAシステム構成について 62©2013 Cloudera, Inc. All RightsReserved.
    • 最後に  •  現在のHDFSは、十分に信頼性のあるファイルシステムです  •  国内外問わず、多くのお客様にエンタープライズ環境でご使用頂いています  •  弊社のディストリビューション(CDH)は誰でも無料で使用できます。↓からダウンロードしてみてください  hFps://ccp.cloudera.com/display/SUPPORT/Downloads 63©2013 Cloudera, Inc. All RightsReserved.
    • Appendix:  Q&A(ハイライト)  Q.  フェイルオーバー時の遅延について A.  ネームノードのダウンは ZKFC  が 1秒で検知し、すぐにフェイルオーバします。これは、スタンバイネームノードがホットスタンバイで常にメモリ上にメタ情報を保持しているためです。    Q.  QJM  はどの JN  が置き換わったのかどうやって検知しているのか A.  JN  のホスト名は hdfs-­‐site.xml  で管理しています。そのため、ホスト名が変わっていなければ他の JN  から編集ログを同期して新たな JN  起動すればQJM  側との通信は継続するので問題ありません。ホスト名が変わってしまった場合は、HDFS  を停止して設定を変更後、起動する必要があります。 Q.  普通のフェンシングだと管理ポートを叩いてダウンさせるが、不要か? A.  ハードウェアレベルでのフェンシングは不要です。 64©2013 Cloudera, Inc. All RightsReserved.
    • Appendix:  Q&A  Q.  QJM  において、フェンシング(sshfence,  shellfence)  はなくても使用可能なのか? A.  フェイルオーバー時に、ZKFC  が ANN  に対してフェンシングが必要です。書き込みのフェンシングは QJM  がカバーしています。 Q.  JN  の運用について。過半数の JN  が結果を返せば業務継続するだろうが、遅延が発生した場合に JN  のデータが完全に同期していなかった場合はどうやって補填するのか? A.  QJM  側が補填します。 Q.  JN  は全て完全に最新情報を持っていると言っていいか? A.  完全同期かは不明だが、タイミングさえ考慮しなければいずれ復旧します。 Q.  1台 JN  が壊れて復旧した場合の動作は? 他の生きている正常な JN  から rsync  などで同期します。    Q.  SNN  がなくなったときにチェックポイントはどうするか? A.  SBN  が行います。 Q.  NTPサーバは必須か? A.  Hadoop クラスタを構築する上で、強く推奨します。 65©2013 Cloudera, Inc. All RightsReserved.
    • Appendix:  Q&A  Q.  試験するときにエポック番号は確認できるか? JN のメトリクスで確認可能です。また、トレースレベルのログにも出力されます。   Q.  HDFS  Federaaon  との比較 A.  各名前空間ごとに HDFS  HA  を構成します。 Q.  NN  のプロセス自体は1度でも死んでしまうとフェイルオーバ対象になるか A.  はい、1度でダウンだと検知する仕組みになっている Q.  CDH4.2  以降は、セカンダリネームノードは不要? A.  CDHでは obsolete  にはなっていません。 Q.  CDH4.3  で HA  構成は変わった? A.  変わりません。バグ fix  のみです。 Q.  JT  HA  はどうなった? A.  HDFS  HA  の仕組みを踏襲し、ZK  と ZKFC  を利用します。 66©2013 Cloudera, Inc. All RightsReserved.
    • 67©2013 Cloudera, Inc. All RightsReserved.