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

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


要は

7


(比較的)簡単に
既存の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


書き込みよろー

QJMは、logSync()メソッドを使用して
すべてのJNへeditsを同期する

23


書き込んだった

クォーラム数のJNから書き込んだった
成功のACKが返ると
editsの書き込みに成功したとみなす

24


クォーラム数未満の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


32

NameNode NameNode

Quorum Quorum

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


33

そこで、、

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

34

そこで、、

フェンシング：
editsを書き込めるネームノードは
常にただ1つだけであることを
保証する仕組み

35

QJMのフェンシング

エポック番号を使う

36

エポック番号

JNが
アクティブネームノードを
一意に識別するために
使う番号

37

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

• アクティブになるたびに新しい
エポック番号が割り振られる
• 両ネームノードが同時に同じエポック
番号をもつことはない
• JNは最新のエポック番号を保存する

38


時系列でみてみると...

39

ネームノード1 ネームノード2
起動時

1 アクティブになっ
た
フェイルオーバー

2
フェイルオーバー

3

時間時間

40


NameNode NameNode

Quorum Quorum


41


NameNode NameNode

Quorum Quorum

2 2 2

42


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

Quorum Quorum

1
2

2 2 2

43


NameNode NameNode

Quorum Quorum

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


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


書き込めた！
NameNode NameNode

Quorum Quorum

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


45

まとめ

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

46

宣伝

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

47

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (8)

Mehr von Cloudera Japan

Mehr von Cloudera Japan (20)

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