hdfsネームノードのhaについて #hcj13w
Post on 28-May-2015
3.736 Views
Preview:
DESCRIPTION
TRANSCRIPT
1
High Availability for the HDFS NameNode
Cloudera 株式会社 カスタマーオペレーションズエンジニア小林 大輔2013 年 1 月 21 日
自己紹介
• 小林 大輔 (@daisukebe_)• カスタマーオペレーションズエンジニアとして
テクニカルサポート業務を担当• email: daisuke@cloudera.com
3
ネームノード HA とは？
4
従来のネームノードの問題点
• 従来の Hadoop ではネームノードは単一障害点(SPOF) だった
• ネームノードは、ファイルシステムのメタデータを管理している (edits ログ /fsimage など )
• ネームノードがダウンしたらデータが読み込めず、クラスタ自体が利用不可になる
5
従来のネームノードの問題点
• 従来の Hadoop ではネームノードは単一障害点(SPOF) だった
• ネームノードは、ファイルシステムのメタデータを管理している (edits ログ /fsimage など )
• ネームノードがダウンしたらデータが読み込めず、クラスタ自体が利用不可になる
HA 対応してほしいという需要
6
ネームノード HA の要件
• メタデータの保存先として、カスタムハードウェアに依存しないこと
• アクティブ / スタンバイ構成において、メタデータの同期が容易であること
• デプロイが容易であること• スプリットブレインシンドロームを避けられる
こと• SPOF がないこと• 既存の Hadoop クラスタの資産を無駄にしないこ
と
7
ネームノード HA の要件
要は
8
ネームノード HA の要件
( 比較的 ) 簡単に既存の Hadoop の仕組みを
無駄にすることなくHA 構成を作れること
9
ネームノード HA
• Apache Hadoop2.0 ではネームノード HA が導入されました
• CDH4.1 にも含まれてます
10
ネームノード HA
• クォーラムベースジャーナリング• 外部のハードウェアに依存しない
• 自動フェイルオーバー• 障害発生時にも自動で切り替え可能
11
今日は、、
• クォーラムベースジャーナリング• 外部のハードウェアに依存しない
• 自動フェイルオーバー• 障害発生時にも自動で切り替え可能
12
クォーラムベースジャーナリングについて
13
クォーラムベースジャーナリング
• ネームノードのメタデータ (edits ログ ) を複数の場所で保管
• ネームノードはクライアントとして、 edits を書き込む
• 複数の書き込み先のうち、過半数( クォーラム数 ) のノードに成功すればedits はコミットとみなす
14
NameNode
QuorumJournalManager
クォーラムベースジャーナリングの導入
15
NameNode
QuorumJournalManager
クォーラムベースジャーナリングの導入
edits ログの書き込み先として、ジャーナルノード (JN) の導入
16
NameNode
QuorumJournalManager
クォーラムベースジャーナリングの導入
複数のノード上でスタンドアロンのデーモンが動作
17
NameNode
QuorumJournalManager
クォーラムベースジャーナリングの導入
各 JN はローカルディスクに edits を書き込む
18
NameNode
QuorumJournalManager
クォーラムベースジャーナリングの導入
追加でノードが必要なわけではないアクティブ / スタンバイネームノード、jobtracker( 比較的信頼性の高いノード )
の 3 台にデプロイ
19
クォーラムベースジャーナリングの導入
クライアント側はクォーラムジャーナルマネージャ (QJM)
NameNode
QuorumJournalManager
20
クォーラムベースジャーナリングの導入
各ネームノード上にデプロイ
NameNode
QuorumJournalManager
21
では、、
edits はどのように
書き込まれるのか？
22
edits 書き込みのフロー
ネームノードはedits をローカルディスクに書き込む
Localdisk
23
edits 書き込みのフロー
書き込みよろー
QJM は、 logSync() メソッドを使用してすべての JN へ edits を同期する
24
edits 書き込みのフロー
書き込んだった
書き込んだったクォーラム数の JN から成功の ACK が返ると
edits の書き込みに成功したとみなす
25
edits 書き込みのフロー
書き込んだったクォーラム数未満の JN からしか成功の ACK が返ってこなければ
edits の書き込みに失敗したとみなす
26
ところで、、
ネームノード HA はアクティブ / スタンバイ構成
27
ところで、、
両ネームノードから edits が書き込まれる恐れはないの？
28
これは、、
両ネームノードから同時に書き込んでしまうと
データに不整合が生じてしまう
29
ファイルシステムとしての信頼性が損なわれる
30
最悪データ破損も招きかねないので
非常に危険！
31
JounalNode JounalNode JounalNode
NameNode
QuorumJournalManager
NameNode
QuorumJournalManager
32
JounalNode JounalNode JounalNode
NameNode
QuorumJournalManager
NameNode
QuorumJournalManager
33
JounalNode JounalNode JounalNode
NameNode
QuorumJournalManager
NameNode
QuorumJournalManager
どのネームノードがアクティブなのかJournalNode が判断できなければ
両ノードからの書き込みを許してしまう
34
そこで、、
クォーラムベースジャーナリングにはフェンシングの
仕組みがある
35
そこで、、
フェンシング：edits を書き込めるネームノードは
常にただ 1 つだけであることを保証する仕組み
36
QJM のフェンシング
エポック番号を使う
37
エポック番号
JN がアクティブネームノードを
一意に識別するために使う番号
38
エポック番号によるフェンシング
• アクティブになるたびに新しいエポック番号が割り振られる
• 両ネームノードが同時に同じエポック番号をもつことはない
• JN は最新のエポック番号を保存する
39
エポック番号によるフェンシング
時系列でみてみると ...
40
エポック番号によるフェンシングネームノード 1 ネームノード 2
時間 時間
起動時
1
2
3
フェイルオーバー
フェイルオーバー
アクティブになった
41
エポック番号によるフェンシング
JounalNode JounalNode JounalNode
NameNode
QuorumJournalManager
NameNode
QuorumJournalManager
42
エポック番号によるフェンシング
JounalNode JounalNode JounalNode
NameNode
QuorumJournalManager
NameNode
QuorumJournalManager
2 2 2
43
エポック番号によるフェンシング
JounalNode JounalNode JounalNode
NameNode
QuorumJournalManager
NameNode
QuorumJournalManager
俺、” 1” だわ 俺、” 2” だわ
21
2 2 2
44
エポック番号によるフェンシング
JounalNode JounalNode JounalNode
NameNode
QuorumJournalManager
NameNode
QuorumJournalManager
“1” は低いので却下“2” の書き込みを採用しま
す
“1” は低いので却下“2” の書き込みを採用しま
す
45
エポック番号によるフェンシング
JounalNode JounalNode JounalNode
NameNode
QuorumJournalManager
NameNode
QuorumJournalManager
クォーラム数からのレスポンスを得ることで、 edits の書き込みに
成功する
書き込めた！
46
まとめ
• クォーラムベースジャーナリングを使用したネームノード HA を紹介しました
• edits を複数ノードで分散して保存することで信頼性が高まっています
• エポック番号を使用することで、両ネームノードから書き込みが発生することを防いでいます。
47
宣伝
• Cloudera Manager を使用することでネームノード HA への移行が非常に簡単にできます
• Cloudera 社のブースでデモを行なっているので、立ち寄ってみてください
48
top related