HDFS HA セミナー #hadoop

HDFS HAのアーキテクチャと詳細 2013/05/30 HDFS HAセミナー Cloudera 株式会社小林大輔

開始に先立って

•  今日お話しすること •  現在のHDFSは安心してお使いいただけます

•  CDH4から導入されたHDFS HAのご紹介と技術詳細 •  特に4.1以降のQuorum Journal Managerの仕組み

•  今日お話ししないこと •  HDFS自体の仕組みや運用 •  HDFS以外のコンポーネントの説明

自己紹介

•  小林大輔 •  2012年9月 Cloudera 入社 •  カスタマーオペレーションズエンジニア •  主に国内外のテクニカルサポート業務を担当 •  email: daisuke@cloudera.com •  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上)

1. 課題

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

•  障害の検知が大変

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

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

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

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

•  HW, SW, Network

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

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

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

とを確認

ZooKeeper

host2 host1

ZooKeeper ZooKeeper

ZooKeeper

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

host2 host1

ZooKeeper ZooKeeper

ZooKeeper

host2 host1

ZooKeeper ZooKeeper

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

ZooKeeper

host2 host1

ZooKeeper ZooKeeper

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

ZooKeeper

host2 host1

ZooKeeper ZooKeeper

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

host2 host1

ZooKeeper ZooKeeper

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

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

時間時間

起動時

フェイルオーバー

フェイルバック

アクティブになった

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

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

3. エポック番号

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

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

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

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

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

JounalNode JounalNode　 JounalNode

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

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

JounalNode JounalNode　 JounalNode　

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

JounalNode　 JounalNode　 JounalNode　 1 2 2

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

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

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

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

ネームノードA

ネームノードB

書き込みたい

ネームノードA

ネームノードB

書き込みたい

ネームノードA

ネームノードB

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

入れる

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

ネームノードA

ネームノードB

書き込み失敗…

書き込み成功

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

アジェンダ

HDFS HAのシステム構成

ZooKeeper

ZooKeeper ZooKeeper

HDFS HAのシステム構成

ZooKeeper

ZooKeeper ZooKeeper

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

いんだろう？

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

JounalNode

ジョブトラッカー

host1 host2 host3

ZooKeeper

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 を利用します。

Reserved.

HDFS HA セミナー #hadoop

Technology

Hdfs 2016-hadoop-summit-dublin-v1

Hdfs raid migration to hadoop 1.x

Design and Evolution of the Apache Hadoop File System(HDFS) · Apache Hadoop FileSystem (HDFS) Committer and PMC Member Core contributor since Hadoop’s infancy Facebook (Hadoop,

Hadoop with Python - apphosting.io · 2016-10-11 · Hadoop Distributed File System (HDFS) The Hadoop Distributed File System (HDFS) is a Java-based dis‐ tributed, scalable, and

HDFS: Hadoop Distributed FS

Hadoop with Python - Amazon Web Services · CHAPTER 1 Hadoop Distributed File System (HDFS) The Hadoop Distributed File System (HDFS) is a Java-based dis‐ tributed, scalable, and

Hadoop HDFS and Oracle

Hadoop File system (HDFS)

HADOOP Interacting with HDFS - Meetupfiles.meetup.com/18978602/University Program - Interacting With HDFS.pdf · HADOOP Interacting with HDFS 1 For University Program on Apache Hadoop

Hadoop Interacting with HDFS

Hadoop Session 2 : HDFS

Hadoop & HDFS Final

20130313 OSCA Hadoopセミナー

HDFS Hadoop Distributed File System

Big Data, Hadoop, HDFS

HDFS: Hadoop Distributed File Systemeecs.csuohio.edu/~sschung/cis612/LectureNotes_HadoopFinal_1.pdf · Hadoop Distributed File System (HDFS) p: HDFS • HDFS Consists of data blocks

Hadoop, HDFS, MapReduce and Pig

Introduction to Hadoop and HDFS

Hadoop HDFS Concepts

Überblick Hadoop Einführung HDFS und MapReduce - doag.org · Inhalt Seite 3 1 Apache Hadoop 2 Hadoop Distributed File System (HDFS) 3 MapReduce Überblick Hadoop 4 MapReduce im