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

1

High Availability for the HDFS NameNode

Cloudera 株式会社カスタマーオペレーションズエンジニア小林大輔2013 年 1 月 21 日

自己紹介

• 小林大輔 (@daisukebe_)• カスタマーオペレーションズエンジニアとして

テクニカルサポート業務を担当• email: [email protected]

mailto:[email protected]

3

ネームノード HA とは？

4

従来のネームノードの問題点

• 従来の Hadoop ではネームノードは単一障害点(SPOF) だった

• ネームノードは、ファイルシステムのメタデータを管理している (edits ログ /fsimage など )

• ネームノードがダウンしたらデータが読み込めず、クラスタ自体が利用不可になる

5

従来のネームノードの問題点

• 従来の Hadoop ではネームノードは単一障害点(SPOF) だった

• ネームノードは、ファイルシステムのメタデータを管理している (edits ログ /fsimage など )

• ネームノードがダウンしたらデータが読み込めず、クラスタ自体が利用不可になる

HA 対応してほしいという需要

6

ネームノード HA の要件

• メタデータの保存先として、カスタムハードウェアに依存しないこと

• アクティブ / スタンバイ構成において、メタデータの同期が容易であること

• デプロイが容易であること• スプリットブレインシンドロームを避けられる

こと• SPOF がないこと• 既存の Hadoop クラスタの資産を無駄にしないこ

と

7


要は

8


( 比較的 ) 簡単に既存の Hadoop の仕組みを

無駄にすることなくHA 構成を作れること

9

ネームノード HA

• Apache Hadoop2.0 ではネームノード HA が導入されました

• CDH4.1 にも含まれてます

10

ネームノード HA

• クォーラムベースジャーナリング• 外部のハードウェアに依存しない

• 自動フェイルオーバー• 障害発生時にも自動で切り替え可能

11

今日は、、

• クォーラムベースジャーナリング• 外部のハードウェアに依存しない

• 自動フェイルオーバー• 障害発生時にも自動で切り替え可能

12

クォーラムベースジャーナリングについて

13

クォーラムベースジャーナリング

• ネームノードのメタデータ (edits ログ ) を複数の場所で保管

• ネームノードはクライアントとして、 edits を書き込む

• 複数の書き込み先のうち、過半数( クォーラム数 ) のノードに成功すればedits はコミットとみなす

14

NameNode

QuorumJournalManager

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

15

NameNode



edits ログの書き込み先として、ジャーナルノード (JN) の導入

16

NameNode



複数のノード上でスタンドアロンのデーモンが動作

17

NameNode



各 JN はローカルディスクに edits を書き込む

18

NameNode



追加でノードが必要なわけではないアクティブ / スタンバイネームノード、jobtracker( 比較的信頼性の高いノード )

の 3 台にデプロイ

19


クライアント側はクォーラムジャーナルマネージャ (QJM)

NameNode


20


各ネームノード上にデプロイ

NameNode


21

では、、

edits はどのように

書き込まれるのか？

22

edits 書き込みのフロー

ネームノードはedits をローカルディスクに書き込む

Localdisk

23


書き込みよろー

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

24


書き込んだった

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

edits の書き込みに成功したとみなす

25


書き込んだったクォーラム数未満の JN からしか成功の ACK が返ってこなければ

edits の書き込みに失敗したとみなす

26

ところで、、

ネームノード HA はアクティブ / スタンバイ構成

27

ところで、、

両ネームノードから edits が書き込まれる恐れはないの？

28

これは、、

両ネームノードから同時に書き込んでしまうと

データに不整合が生じてしまう

29

ファイルシステムとしての信頼性が損なわれる

30

最悪データ破損も招きかねないので

非常に危険！

31

JounalNode JounalNode JounalNode

NameNode


NameNode


32


NameNode


NameNode


33


NameNode


NameNode


どのネームノードがアクティブなのかJournalNode が判断できなければ

両ノードからの書き込みを許してしまう

34

そこで、、

クォーラムベースジャーナリングにはフェンシングの

仕組みがある

35

そこで、、

フェンシング：edits を書き込めるネームノードは

常にただ 1 つだけであることを保証する仕組み

36

QJM のフェンシング

エポック番号を使う

37

エポック番号

JN がアクティブネームノードを

一意に識別するために使う番号

38

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

• アクティブになるたびに新しいエポック番号が割り振られる

• 両ネームノードが同時に同じエポック番号をもつことはない

• JN は最新のエポック番号を保存する

39


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

40

エポック番号によるフェンシングネームノード 1 ネームノード 2

時間時間

起動時

1

2

3

フェイルオーバー

フェイルオーバー

アクティブになった

41



NameNode


NameNode


42



NameNode


NameNode


2 2 2

43



NameNode


NameNode


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

21

2 2 2

44



NameNode


NameNode


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

す

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

す

45



NameNode


NameNode


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

成功する

書き込めた！

46

まとめ

• クォーラムベースジャーナリングを使用したネームノード HA を紹介しました

• edits を複数ノードで分散して保存することで信頼性が高まっています

• エポック番号を使用することで、両ネームノードから書き込みが発生することを防いでいます。

47

宣伝

• Cloudera Manager を使用することでネームノード HA への移行が非常に簡単にできます

• Cloudera 社のブースでデモを行なっているので、立ち寄ってみてください

48

Documents

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