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

1. 1
HDFS
HAのアーキテクチャと詳細
2013/05/30
HDFS
HAセミナー
Cloudera
株式会社 小林大輔

2. 開始に先立って
• 今日お話しすること
• 現在のHDFSは安心してお使いいただけます
• CDH4から導入されたHDFS
HAのご紹介と技術詳細
• 特に4.1以降のQuorum
Journal
Managerの仕組み
• 今日お話ししないこと
• HDFS自体の仕組みや運用
• HDFS以外のコンポーネントの説明
2
©2013 Cloudera, Inc. All Rights
Reserved.

3. 自己紹介
• 小林 大輔
• 2012年9月
Cloudera
入社
• カスタマーオペレーションズエンジニア
• 主に国内外のテクニカルサポート業務を担当
• email:
daisuke@cloudera.com
• twiFer:
daisukebe_
3
©2013 Cloudera, Inc. All Rights
Reserved.

4. アジェンダ
• なぜHDFS
HAが開発されたか
• HDFS
HAを構成する要素について
• 実際のHDFS
HA構成例について
4
©2013 Cloudera, Inc. All Rights
Reserved.

5. • なぜHDFS
HAが開発されたか
• HDFS
HAを構成する要素について
• 実際のHDFS
HAシステム構成について
5
©2013 Cloudera, Inc. All Rights
Reserved.
アジェンダ

6. なぜHDFS
HAが開発されたか（HDFSのおさらい）
6
©2013 Cloudera, Inc. All Rights
Reserved.
データノード
ネームノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データ
データ
データ
データ
データ
データ
データ
データ
データ
クライアント
メタデータ

7. 7
©2013 Cloudera, Inc. All Rights
Reserved.
データノード
ネームノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データ
データ
データ
データ
データ
データ
データ
データ
データ
クライアント
メタデータ
1.
ネームノードにデータの
格納場所を尋ねる
なぜHDFS
HAが開発されたか（HDFSのおさらい）

8. 8
©2013 Cloudera, Inc. All Rights
Reserved.
データノード
ネームノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データ
データ
データ
データ
データ
データ
データ
データ
データ
クライアント
メタデータ
2.
実データの格納先を教える
なぜHDFS
HAが開発されたか（HDFSのおさらい）

9. 9
©2013 Cloudera, Inc. All Rights
Reserved.
データノード
ネームノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データ
データ
データ
データ
データ
データ
データ
データ
データ
クライアント
メタデータ
3.
データノードから
実データを読み書きする
なぜHDFS
HAが開発されたか（HDFSのおさらい）

10. 10
©2013 Cloudera, Inc. All Rights
Reserved.
データノード
ネームノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データ
データ
データ
データ
データ
データ
データ
データ
データ
クライアント
メタデータ
なぜHDFS
HAが開発されたか（HDFSのおさらい）
DOWN!!
もしひとつのデータノードが
ダウンしても…

11. 11
©2013 Cloudera, Inc. All Rights
Reserved.
データノード
ネームノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データ
データ
データ
データ
データ
データ
データ
データ
データ
クライアント
メタデータ
なぜHDFS
HAが開発されたか（HDFSのおさらい）
DOWN!!
クライアントは他の
データノードにあるレプリカを
参照することができる

12. 12
©2013 Cloudera, Inc. All Rights
Reserved.
データノード
ネームノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データ
データ
データ
データ
データ
データ
データ
データ
データ
クライアント
メタデータ
なぜHDFS
HAが開発されたか（HDFSのおさらい）
DOWN!!
クライアントは他の
データノードにあるレプリカを
参照することができる
=
スレーブノードには耐障害性があり
実データを失うことはない

13. 13
©2013 Cloudera, Inc. All Rights
Reserved.
データノード
ネームノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データ
データ
データ
データ
データ
データ
データ
データ
データ
クライアント
メタデータ
DOWN!!
ネームノードがダウンすると…
なぜHDFS
HAが開発されたか（HDFSのおさらい）

14. 14
©2013 Cloudera, Inc. All Rights
Reserved.
データノード
ネームノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データ
データ
データ
データ
データ
データ
データ
データ
データ
クライアント
メタデータ
DOWN!!
クライアントはデータの
格納先がわからず、データの
読み書きができなくなる
なぜHDFS
HAが開発されたか（HDFSのおさらい）

15. 15
©2013 Cloudera, Inc. All Rights
Reserved.
データノード
ネームノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データ
データ
データ
データ
データ
データ
データ
データ
データ
クライアント
メタデータ
DOWN!!
クライアントはデータの
格納先がわからず、データの
読み書きができなくなる
=
HDFSの課題
なぜHDFS
HAが開発されたか（HDFSのおさらい）

16. 16
©2013 Cloudera, Inc. All Rights
Reserved.
データノード
ネームノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データ
データ
データ
データ
データ
データ
データ
データ
データ
クライアント
メタデータ
DOWN!!
ネームノード
メタデータ
なぜHDFS
HAが開発されたか（HDFSの問題点）
片方がダウンしても、代替ノードへ
切り替え、クラスタダウンを防げると嬉しい

17. • 問題点
• ネームノードがシングルマスターであるため、SPoF(単一障
害点)だった
• ダウンした場合にはHadoopクラスタのデータにアクセスで
きなくなる
• パッチ適用など計画的なメンテナンスも難しい状況
17
©2013 Cloudera, Inc. All Rights
Reserved.
なぜHDFS
HAが開発されたか（HDFSの問題点）

18. • なぜHDFS
HAが開発されたか
• HDFS
HAを構成する要素について
• 実際のHDFS
HA構成について
18
©2013 Cloudera, Inc. All Rights
Reserved.
アジェンダ

19. HDFS
HAの構成要素
HDFS
HAは3段階の開発フェーズを経た
1. スタンバイネームノード(SBN)の導入
2. 自動フェイルオーバーの導入
3. QuorumJournalManagerの導入
共有ストレージの改善
19
©2013 Cloudera, Inc. All Rights
Reserved.

20. 1.
スタンバイネームノードの導入
• アクティブ切り替え用ホットスタンバイネームノード
• 編集ログはNFS上に保存して共有
• 手動フェイルオーバーのみ対応
20
©2013 Cloudera, Inc. All Rights
Reserved.

21. 1.
スタンバイネームノードの導入
21
©2013 Cloudera, Inc. All Rights
Reserved.
アクティブ
ネームノード
スタンバイ
ネームノード
編集ログ
(NFS上)

22. ©2012 Cloudera, Inc. All Rights
Reserved.
22
1.
課題
• NASが必要である点
• 管理が複雑で高価
• 障害の検知が大変
• サードパーティ製品による障害検知、手動フェイルオー
バーが必要
• ネームノードの障害自体は稀だが…

23. 2.
自動フェイルオーバーの導入
• アクティブネームノードの障害を自動検知する仕組
みを導入
• HW,
SW,
Network
• 障害検知後、自動的にスタンバイネームノードへフェ
イルオーバーする仕組みを導入
23
©2013 Cloudera, Inc. All Rights
Reserved.

24. 2.
自動フェイルオーバーの導入
• ZooKeeper(ZK)
• アクティブネームノードの障害検知
• 次にどのネームノードがアクティブになるべきかを選定
• ZooKeeperFailoverController(ZKFC)
• ネームノード毎にひとつ必要
• ネームノードの状態を監視
• フェイルオーバー時に旧アクティブノードが停止しているこ
とを確認
24
©2013 Cloudera, Inc. All Rights
Reserved.

25. ZooKeeper
2.
自動フェイルオーバーの導入
25
©2013 Cloudera, Inc. All Rights
Reserved.
アクティブ
ネームノード
ZKFC
スタンバイ
ネームノード
ZKFC
host2
host1
ZooKeeper
ZooKeeper
編集ログ
(NFS上)

26. ZooKeeper
2.
自動フェイルオーバーのシナリオ
26
©2013 Cloudera, Inc. All Rights
Reserved.
アクティブ
ネームノード
ZKFC
スタンバイ
ネームノード
ZKFC
host2
host1
ZooKeeper
ZooKeeper
編集ログ
(NFS上)

27. ZooKeeper
2.
自動フェイルオーバーのシナリオ
27
©2013 Cloudera, Inc. All Rights
Reserved.
アクティブ
ネームノード
ZKFC
スタンバイ
ネームノード
ZKFC
host2
host1
ZooKeeper
ZooKeeper
DOWN
1.
host1のネームノードが
ダウンすると…
編集ログ
(NFS上)

28. ZooKeeper
2.
自動フェイルオーバーのシナリオ
28
©2013 Cloudera, Inc. All Rights
Reserved.
アクティブ
ネームノード
ZKFC
スタンバイ
ネームノード
ZKFC
host2
host1
ZooKeeper
ZooKeeper
DOWN
NNが
ダウンした!
2.
ZKFCが検知
編集ログ
(NFS上)

29. ZooKeeper
2.
自動フェイルオーバーのシナリオ
29
©2013 Cloudera, Inc. All Rights
Reserved.
アクティブ
ネームノード
ZKFC
スタンバイ
ネームノード
ZKFC
host2
host1
ZooKeeper
ZooKeeper
DOWN
3.
ZKFCが障害を通知
編集ログ
(NFS上)

30. ZooKeeper
2.
自動フェイルオーバーのシナリオ
30
©2013 Cloudera, Inc. All Rights
Reserved.
アクティブ
ネームノード
ZKFC
ZKFC
host2
host1
ZooKeeper
ZooKeeper
DOWN
スタンバイ
ネームノード
4.
ZooKeeperはhost2の
NNをアクティブとみなす
編集ログ
(NFS上)

31. ZooKeeper
2.
自動フェイルオーバーのシナリオ
31
©2013 Cloudera, Inc. All Rights
Reserved.
アクティブ
ネームノード
ZKFC
ZKFC
host2
host1
ZooKeeper
ZooKeeper
DOWN
スタンバイ
ネームノード
5.
host2のZKFCはhost1の
NNが停止していることを確認
編集ログ
(NFS上)

32. ZooKeeper
2.
自動フェイルオーバーのシナリオ
32
©2013 Cloudera, Inc. All Rights
Reserved.
アクティブ
ネームノード
ZKFC
アクティブ
ネームノード
ZKFC
host2
host1
ZooKeeper
ZooKeeper
6.
host2のNNがアクティブ
として起動する(フェイルオーバー完了)
DOWN
編集ログ
(NFS上)

33. 2.
課題1
• 編集ログがSPoF
• 共有ディレクトリはやはりNFSに依存している
• NFS
が抱える課題
• SAN/NAS
といった外部ハードウェアを必要とする
• そのための監視も必要
• NFS
クライアントが抱える不具合
33
©2013 Cloudera, Inc. All Rights
Reserved.

34. 共有ストレージの改良
• 第一要件
• 特別な HW
を必要としないこと
• 複雑なカスタムフェンシング構成を必要としないこと
• ストレージに SPoF が存在せず、分散構成とすること
34
©2013 Cloudera, Inc. All Rights
Reserved.

35. 共有ストレージの改良
• 第二要件
• 障害耐性をもつこと
• 一部のノードに障害が発生しても問題とならない
• (N-­‐1)/2 までの耐障害性
• パフォーマンス劣化を招かないこと
• 書き込みが並列に行え、書き込みが遅いノードの影響を受けない
こと
• 既存のハードウェア資産を利用すること
• ネームノード、スタンバイネームノードなど
35
©2013 Cloudera, Inc. All Rights
Reserved.

36. 2.
課題2
©2012 Cloudera, Inc. All Rights
Reserved.
36
• スプリットブレインシンドローム
• 一般的には、ネットワーク分断が発生し、ひとつのサービ
スが同時に複数起動してしまうこと
• 両ネームノードが同じタイミングで自分自身をアクティブと
見なして編集ログの書き込みを行う状況
• データ破壊やクラスタの停止を引き起こす危険な状態
• 常にひとつのネームノードしか書き込みを行わないこ
とを保証しなければならない

37. 2.
スプリットブレインシンドローム
37
©2013 Cloudera, Inc. All Rights
Reserved.
アクティブ
ネームノード
ZKFC
ZKFC
host2
host1
1.
host1
-­‐>
host2へ
フェイルオーバー後…
DOWN
アクティブ
ネームノード
編集ログ
(NFS上)

38. 2.
スプリットブレインシンドローム
38
©2013 Cloudera, Inc. All Rights
Reserved.
アクティブ
ネームノード
ZKFC
ZKFC
host2
host1
2.
host1のNNがアクティブとして
起動してしまうと…
アクティブ
ネームノード
編集ログ
(NFS上)

39. 2.
スプリットブレインシンドローム
39
©2013 Cloudera, Inc. All Rights
Reserved.
アクティブ
ネームノード
ZKFC
ZKFC
host2
host1
3.
同時に同じファイルに書き込みを行い
データの破壊を招く
アクティブ
ネームノード
編集ログ
(NFS上)

40. 2.
スプリットブレインシンドローム
40
©2013 Cloudera, Inc. All Rights
Reserved.
アクティブ
ネームノード
ZKFC
ZKFC
host2
host1
4.
host1のアクティブノードが
決して編集ログを書き込めないよう
保証しなければならない
=
フェンシング
アクティブ
ネームノード
編集ログ
(NFS上)

41. 3.
Quorum
Journal
Managerの導入
• Quorum
Journal
Manager(QJM)
• 編集ログ書き込みのクライアントとして動作
• JournalNode(JN)
• 編集ログ書き込みのサーバーデーモン
• 奇数個のノード上で動作させる必要がある
• ローカルディスク上に編集ログを格納
41
©2013 Cloudera, Inc. All Rights
Reserved.

42. 3.
Quorum
Journal
Managerの導入
©2012 Cloudera, Inc. All Rights
Reserved.
42
JounalNode
JounalNode
JounalNode
アクティブ
ネームノード
Quorum
JournalManager
ローカル
ディスク
ローカル
ディスク
ローカル
ディスク

43. 3.
編集ログ書き込みの仕組み
©2012 Cloudera, Inc. All Rights
Reserved.
43
JounalNode
JounalNode
JounalNode
ローカル
ディスク
ローカル
ディスク
1.
編集ログの書き込み
ローカル
ディスク
ローカル
ディスク
アクティブ
ネームノード
Quorum
JournalManager

44. 3.編集ログ書き込みの仕組み
©2012 Cloudera, Inc. All Rights
Reserved.
44
JounalNode
JounalNode
JounalNode
ローカル
ディスク
2.
同期
ローカル
ディスク
ローカル
ディスク
ローカル
ディスク
1.
編集ログの書き込み
アクティブ
ネームノード
Quorum
JournalManager

45. 3.編集ログ書き込みの仕組み
©2012 Cloudera, Inc. All Rights
Reserved.
45
JounalNode
JounalNode
JounalNode
ローカル
ディスク
2.
同期
3.
ローカルディスクへの
書き込み
ローカル
ディスク
ローカル
ディスク
アクティブ
ネームノード
Quorum
JournalManager
ローカル
ディスク
1.
編集ログの書き込み

46. 3.編集ログ書き込みの仕組み
©2012 Cloudera, Inc. All Rights
Reserved.
46
JounalNode
JounalNode
JounalNode
ローカル
ディスク
2.
同期
3.
ローカルディスクへの
書き込み
ローカル
ディスク
ローカル
ディスク
4.
書き込み成功
アクティブ
ネームノード
Quorum
JournalManager
ローカル
ディスク
1.
編集ログの書き込み

47. 3.編集ログ書き込みの仕組み
©2012 Cloudera, Inc. All Rights
Reserved.
47
JounalNode
JounalNode
JounalNode
ローカル
ディスク
2.
同期
3.
ローカルディスクへの
書き込み
ローカル
ディスク
ローカル
ディスク
4.
書き込み成功
5.
過半数からのノードで
書き込みに成功することで
ネームノードとして書き込みに
成功したとみなす
アクティブ
ネームノード
Quorum
JournalManager
ローカル
ディスク
1.
編集ログの書き込み

48. 3.
エポック番号
©2012 Cloudera, Inc. All Rights
Reserved.
48
• 各ネームノードはエポック番号という自然数をもつ
• フェイルオーバー時や再起動時にひとつずつ増加
• ネームノード間で順序付けを提供
ネームノード1
ネームノード2
時間
時間
起動時
1
2
3
フェイルオーバー
フェイルバック
アクティブになった
より大きな
エポック番号を
もつネームノード
がアクティブノード

49. 3.
エポック番号
©2012 Cloudera, Inc. All Rights
Reserved.
49
• promised
epoch: すべてのJournalNodeが持つ最新
のエポック番号
• ネームノードがアクティブになるたびに、JournalNode
のエポック番号を取得し、ひとつ増加する
• この作業が定足数(ここでは過半数)のJournalNodeで成功
しなければアクティブネームノードになれない
• ふたつのネームノードが同時にこの作業を行なっても、必
ずひとつのネームノードしか定足数を獲得できない

50. 3.
エポック番号によるフェンシング1
©2012 Cloudera, Inc. All Rights
Reserved.
50
JounalNode
JounalNode
JounalNode
1.
すべてのJournalNodeの
エポック番号を確認
1
1
1
1
1
1
アクティブ
ネームノード
Quorum
JournalManager
アクティブとして
起動したい

51. 3.
エポック番号によるフェンシング1
©2012 Cloudera, Inc. All Rights
Reserved.
51
JounalNode
JounalNode
JounalNode
2
2
2
1
1
1
アクティブ
ネームノード
Quorum
JournalManager
2.
取得したエポック番号を
ひとつ増加させ、再度すべての
JournalNodeへ送信

52. 3.
エポック番号によるフェンシング1
©2012 Cloudera, Inc. All Rights
Reserved.
52
JounalNode
JounalNode
JounalNode
1
2
2
アクティブ
ネームノード
Quorum
JournalManager
2
3.
定足数のJournalNode
が受け入れると、アクティブ
ネームノードになれる
アクティブとして
起動完了

53. 3.
エポック番号によるフェンシング2
©2012 Cloudera, Inc. All Rights
Reserved.
53
• 編集ログの書き込み時にもエポック番号を使う
• ネームノードが編集ログを同期するとき、常に自分が
持っているエポック番号を一緒に送る
• 編集ログの書き込みに成功するためには、
JournalNodeにエポック番号が最新だと認識してもら
う必要がある

54. ネームノードA
Quorum
JournalManager
ネームノードB
Quorum
JournalManager
3.
エポック番号によるフェンシング2
©2012 Cloudera, Inc. All Rights
Reserved.
54
JounalNode
JounalNode
JounalNode
2
1
書き込み
たい
書き込み
たい
2
2
2

55. ネームノードA
Quorum
JournalManager
ネームノードB
Quorum
JournalManager
3.
エポック番号によるフェンシング2
©2012 Cloudera, Inc. All Rights
Reserved.
55
JounalNode
JounalNode
JounalNode
書き込み
たい
書き込み
たい
2
2
2
2
1

56. ネームノードA
Quorum
JournalManager
ネームノードB
Quorum
JournalManager
3.
エポック番号によるフェンシング2
©2012 Cloudera, Inc. All Rights
Reserved.
56
JounalNode
JounalNode
JounalNode
ネームノードAの
書き込みを受け
入れる
ネームノードA
の書き込みを
受け入れる
2
2
2
2
1

57. 3.
エポック番号によるフェンシング2
©2012 Cloudera, Inc. All Rights
Reserved.
57
JounalNode
JounalNode
JounalNode
ネームノードA
Quorum
JournalManager
ネームノードB
Quorum
JournalManager
書き込み失敗…
書き込み成功
2
2
2
2
1

58. • なぜHDFS
HAが開発されたか
• HDFS
HAを構成する要素について
• 実際のHDFS
HA構成について
58
©2013 Cloudera, Inc. All Rights
Reserved.
アジェンダ

59. HDFS
HAのシステム構成
©2012 Cloudera, Inc. All Rights
Reserved.
59
ZooKeeper
アクティブ
ネームノード
ZKFC
スタンバイ
ネームノード
ZKFC
ZooKeeper
ZooKeeper
JounalNode
JounalNode
JounalNode

60. HDFS
HAのシステム構成
©2012 Cloudera, Inc. All Rights
Reserved.
60
ZooKeeper
アクティブ
ネームノード
ZKFC
スタンバイ
ネームノード
ZKFC
ZooKeeper
ZooKeeper
JounalNode
JounalNode
JounalNode
• 何台必要なんだろう？
• マシンスペックはどうすればい
いんだろう？

61. HDFS
HAのシステム構成(例)
©2012 Cloudera, Inc. All Rights
Reserved.
61
アクティブ
ネームノード
ZKFC
スタンバイ
ネームノード
JounalNode
ジョブトラッカー
host1
host2
host3
ZooKeeper
ZKFC
JounalNode
ZooKeeper
JounalNode
ZooKeeper

62. 今日お話ししたこと
• なぜHDFS
HAが開発されたか
• HDFS
HAを構成する要素について
• 実際のHDFS
HAシステム構成について
62
©2013 Cloudera, Inc. All Rights
Reserved.

63. 最後に
• 現在のHDFSは、十分に信頼性のあるファイルシステ
ムです
• 国内外問わず、多くのお客様にエンタープライズ環
境でご使用頂いています
• 弊社のディストリビューション(CDH)は誰でも無料で使
用できます。↓からダウンロードしてみてください
hFps://ccp.cloudera.com/display/SUPPORT/Downloads
63
©2013 Cloudera, Inc. All Rights
Reserved.

64. 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 Rights
Reserved.

65. 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 Rights
Reserved.

66. 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 Rights
Reserved.

67. 67
©2013 Cloudera, Inc. All Rights
Reserved.