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