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_


アジェンダ

•  なぜHDFS HAが開発されたか •  HDFS HAを構成する要素について •  実際のHDFS HA構成例について


•  なぜHDFS HAが開発されたか •  HDFS HAを構成する要素について •  実際のHDFS HAシステム構成について


アジェンダ

なぜHDFS HAが開発されたか（HDFSのおさらい）


データノード

ネームノード

データノードデータノードデータノードデータノードデータノードデータノードデータノードデータノード

データデータデータ



クライアント

メタデータ


データノード

ネームノード





クライアント

メタデータ

1. ネームノードにデータの格納場所を尋ねる



データノード

ネームノード





クライアント

メタデータ 2. 実データの格納先を教える



データノード

ネームノード





クライアント

メタデータ 3. データノードから実データを読み書きする



データノード

ネームノード





クライアント

メタデータ


DOWN!!

もしひとつのデータノードがダウンしても…


データノード

ネームノード





クライアント

メタデータ


DOWN!!

クライアントは他のデータノードにあるレプリカを参照することができる


データノード

ネームノード





クライアント

メタデータ


DOWN!!

クライアントは他のデータノードにあるレプリカを参照することができる = スレーブノードには耐障害性があり実データを失うことはない


データノード

ネームノード





クライアント

メタデータ DOWN!! ネームノードがダウンすると…



データノード

ネームノード





クライアント

メタデータ DOWN!! クライアントはデータの

格納先がわからず、データの読み書きができなくなる



データノード

ネームノード





クライアント

メタデータ DOWN!! クライアントはデータの

格納先がわからず、データの読み書きができなくなる

= HDFSの課題



データノード

ネームノード





クライアント

メタデータ DOWN!!

ネームノード

メタデータ

なぜHDFS HAが開発されたか（HDFSの問題点）

片方がダウンしても、代替ノードへ切り替え、クラスタダウンを防げると嬉しい

•  問題点 •  ネームノードがシングルマスターであるため、SPoF(単一障

害点)だった •  ダウンした場合にはHadoopクラスタのデータにアクセスで

きなくなる •  パッチ適用など計画的なメンテナンスも難しい状況


なぜHDFS HAが開発されたか（HDFSの問題点）

•  なぜHDFS HAが開発されたか •  HDFS HAを構成する要素について •  実際のHDFS HA構成について


アジェンダ

HDFS HAの構成要素

HDFS HAは3段階の開発フェーズを経た 1.  スタンバイネームノード(SBN)の導入 2.  自動フェイルオーバーの導入 3.  QuorumJournalManagerの導入

共有ストレージの改善


1. スタンバイネームノードの導入

•  アクティブ切り替え用ホットスタンバイネームノード •  編集ログはNFS上に保存して共有 •  手動フェイルオーバーのみ対応


1. スタンバイネームノードの導入


アクティブネームノード

スタンバイネームノード

編集ログ (NFS上)

©2012 Cloudera, Inc. All Rights Reserved. 22

1. 課題

•  NASが必要である点 •  管理が複雑で高価

•  障害の検知が大変

•  サードパーティ製品による障害検知、手動フェイルオーバーが必要

•  ネームノードの障害自体は稀だが…

2. 自動フェイルオーバーの導入

•  アクティブネームノードの障害を自動検知する仕組みを導入

•  HW, SW, Network

•  障害検知後、自動的にスタンバイネームノードへフェイルオーバーする仕組みを導入



•  ZooKeeper(ZK) •  アクティブネームノードの障害検知 •  次にどのネームノードがアクティブになるべきかを選定

•  ZooKeeperFailoverController(ZKFC) •  ネームノード毎にひとつ必要 •  ネームノードの状態を監視 •  フェイルオーバー時に旧アクティブノードが停止しているこ

とを確認


ZooKeeper




ZKFC


ZKFC

host2 host1

ZooKeeper ZooKeeper


ZooKeeper

2. 自動フェイルオーバーのシナリオ



ZKFC


ZKFC

host2 host1

ZooKeeper ZooKeeper


ZooKeeper




ZKFC


ZKFC

host2 host1

ZooKeeper ZooKeeper

DOWN

1. host1のネームノードがダウンすると…


ZooKeeper




ZKFC


ZKFC

host2 host1

ZooKeeper ZooKeeper

DOWN

NNがダウンした! 2. ZKFCが検知


ZooKeeper




ZKFC


ZKFC

host2 host1

ZooKeeper ZooKeeper

DOWN

3. ZKFCが障害を通知


ZooKeeper




ZKFC ZKFC

host2 host1

ZooKeeper ZooKeeper

DOWN スタンバイネームノード

4. ZooKeeperはhost2の NNをアクティブとみなす


ZooKeeper




ZKFC ZKFC

host2 host1

ZooKeeper ZooKeeper

DOWN スタンバイネームノード

5. host2のZKFCはhost1の NNが停止していることを確認


ZooKeeper




ZKFC


ZKFC

host2 host1

ZooKeeper ZooKeeper

6. host2のNNがアクティブとして起動する(フェイルオーバー完了)

DOWN


2. 課題1

•  編集ログがSPoF •  共有ディレクトリはやはりNFSに依存している

•  NFS が抱える課題 •  SAN/NAS といった外部ハードウェアを必要とする •  そのための監視も必要 •  NFS クライアントが抱える不具合


共有ストレージの改良

•  第一要件 •  特別な HW を必要としないこと •  複雑なカスタムフェンシング構成を必要としないこと •  ストレージに SPoF が存在せず、分散構成とすること


共有ストレージの改良

•  第二要件 •  障害耐性をもつこと

•  一部のノードに障害が発生しても問題とならない •  (N-‐1)/2 までの耐障害性

•  パフォーマンス劣化を招かないこと •  書き込みが並列に行え、書き込みが遅いノードの影響を受けない

こと

•  既存のハードウェア資産を利用すること •  ネームノード、スタンバイネームノードなど


2. 課題2


•  スプリットブレインシンドローム •  一般的には、ネットワーク分断が発生し、ひとつのサービ

スが同時に複数起動してしまうこと •  両ネームノードが同じタイミングで自分自身をアクティブと

見なして編集ログの書き込みを行う状況 •  データ破壊やクラスタの停止を引き起こす危険な状態

•  常にひとつのネームノードしか書き込みを行わないことを保証しなければならない

2. スプリットブレインシンドローム



ZKFC ZKFC

host2 host1

1. host1 -‐> host2へフェイルオーバー後…

DOWN アクティブネームノード

編集ログ(NFS上)




ZKFC ZKFC

host2 host1

2. host1のNNがアクティブとして起動してしまうと…






ZKFC ZKFC

host2 host1

3. 同時に同じファイルに書き込みを行いデータの破壊を招く






ZKFC ZKFC

host2 host1

4. host1のアクティブノードが決して編集ログを書き込めないよう保証しなければならない = フェンシング



3. Quorum Journal Managerの導入

•  Quorum Journal Manager(QJM) •  編集ログ書き込みのクライアントとして動作

•  JournalNode(JN) •  編集ログ書き込みのサーバーデーモン •  奇数個のノード上で動作させる必要がある •  ローカルディスク上に編集ログを格納


3. Quorum Journal Managerの導入


JounalNode JounalNode JounalNode


Quorum JournalManager

ローカルディスク



3. 編集ログ書き込みの仕組み





1. 編集ログの書き込み





3.編集ログ書き込みの仕組み




2. 同期




1. 編集ログの書き込みアクティブ

ネームノード






2. 同期

3. ローカルディスクへの書き込み




Quorum JournalManager ローカル

ディスク






2. 同期




4. 書き込み成功



ディスク






2. 同期




4. 書き込み成功

5. 過半数からのノードで書き込みに成功することでネームノードとして書き込みに成功したとみなす



ディスク


3. エポック番号


•  各ネームノードはエポック番号という自然数をもつ •  フェイルオーバー時や再起動時にひとつずつ増加 •  ネームノード間で順序付けを提供

ネームノード1 ネームノード2

時間時間

起動時

1

2

3

フェイルオーバー

フェイルバック

アクティブになった

より大きなエポック番号を

もつネームノードがアクティブノード

3. エポック番号


•  promised epoch: すべてのJournalNodeが持つ新のエポック番号

•  ネームノードがアクティブになるたびに、JournalNodeのエポック番号を取得し、ひとつ増加する

•  この作業が定足数(ここでは過半数)のJournalNodeで成功しなければアクティブネームノードになれない

•  ふたつのネームノードが同時にこの作業を行なっても、必ずひとつのネームノードしか定足数を獲得できない

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


JounalNode JounalNode　 JounalNode

1. すべてのJournalNodeのエポック番号を確認

1 1 1

1 1 1



アクティブとして起動したい



JounalNode JounalNode　 JounalNode　

2 2 2

1 1 1



2. 取得したエポック番号をひとつ増加させ、再度すべての JournalNodeへ送信



JounalNode　 JounalNode　 JounalNode　 1 2 2



2

3. 定足数のJournalNode が受け入れると、アクティブネームノードになれる

アクティブとして起動完了



•  編集ログの書き込み時にもエポック番号を使う •  ネームノードが編集ログを同期するとき、常に自分が持っているエポック番号を一緒に送る

•  編集ログの書き込みに成功するためには、JournalNodeにエポック番号が新だと認識してもらう必要がある

ネームノードA


ネームノードB





2 1

書き込みたい

書き込みたい

2 2 2

ネームノードA


ネームノードB





書き込みたい

書き込みたい

2 2 2

2 1

ネームノードA


ネームノードB





ネームノードAの書き込みを受け

入れる

ネームノードAの書き込みを受け入れる

2 2 2

2 1




ネームノードA


ネームノードB


書き込み失敗…

書き込み成功

2 2 2

2 1

•  なぜHDFS HAが開発されたか •  HDFS HAを構成する要素について •  実際のHDFS HA構成について


アジェンダ

HDFS HAのシステム構成


ZooKeeper


ZKFC


ZKFC

ZooKeeper ZooKeeper


HDFS HAのシステム構成


ZooKeeper


ZKFC


ZKFC

ZooKeeper ZooKeeper


•  何台必要なんだろう？ •  マシンスペックはどうすればい

いんだろう？

HDFS HAのシステム構成(例)



ZKFC


JounalNode

ジョブトラッカー

host1 host2 host3

ZooKeeper

ZKFC

JounalNode

ZooKeeper

JounalNode

ZooKeeper

今日お話ししたこと

•  なぜHDFS HAが開発されたか •  HDFS HAを構成する要素について •  実際のHDFS HAシステム構成について


後に

•  現在のHDFSは、十分に信頼性のあるファイルシステムです

•  国内外問わず、多くのお客様にエンタープライズ環境でご使用頂いています

•  弊社のディストリビューション(CDH)は誰でも無料で使用できます。↓からダウンロードしてみてください hFps://ccp.cloudera.com/display/SUPPORT/Downloads


Appendix: Q&A(ハイライト)

Q. フェイルオーバー時の遅延について

A. ネームノードのダウンは ZKFC が 1秒で検知し、すぐにフェイルオーバします。これは、スタンバイネームノードがホットスタンバイで常にメモリ上にメタ情報を保持しているためです。 Q. QJM はどの JN が置き換わったのかどうやって検知しているのか

A. JN のホスト名は hdfs-‐site.xml で管理しています。そのため、ホスト名が変わっていなければ他の JN から編集ログを同期して新たな JN 起動すれば QJM 側との通信は継続するので問題ありません。ホスト名が変わってしまった場合は、HDFS を停止して設定を変更後、起動する必要があります。

Q. 普通のフェンシングだと管理ポートを叩いてダウンさせるが、不要か？

A. ハードウェアレベルでのフェンシングは不要です。


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 クラスタを構築する上で、強く推奨します。


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.

hdfs ha セミナー #hadoop

Technology