SlideShare a Scribd company logo
1 of 67
Download to read offline
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:	
  daisuke@cloudera.com	
  
•  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.

More Related Content

What's hot

Python 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそうPython 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそうRyuji Tsutsui
 
Rancher/Kubernetes入門ハンズオン資料~第2回さくらとコンテナの夕べ #さくらの夕べ 番外編
 Rancher/Kubernetes入門ハンズオン資料~第2回さくらとコンテナの夕べ #さくらの夕べ 番外編 Rancher/Kubernetes入門ハンズオン資料~第2回さくらとコンテナの夕べ #さくらの夕べ 番外編
Rancher/Kubernetes入門ハンズオン資料~第2回さくらとコンテナの夕べ #さくらの夕べ 番外編Masahito Zembutsu
 
NetApp XCP データ移行ツールインストールと設定
NetApp XCP データ移行ツールインストールと設定NetApp XCP データ移行ツールインストールと設定
NetApp XCP データ移行ツールインストールと設定Kan Itani
 
OCIランタイムの筆頭「runc」を俯瞰する
OCIランタイムの筆頭「runc」を俯瞰するOCIランタイムの筆頭「runc」を俯瞰する
OCIランタイムの筆頭「runc」を俯瞰するKohei Tokunaga
 
Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編Yuki Morishita
 
サンプルアプリケーションで学ぶApache Cassandraを使ったJavaアプリケーションの作り方
サンプルアプリケーションで学ぶApache Cassandraを使ったJavaアプリケーションの作り方サンプルアプリケーションで学ぶApache Cassandraを使ったJavaアプリケーションの作り方
サンプルアプリケーションで学ぶApache Cassandraを使ったJavaアプリケーションの作り方Yuki Morishita
 
Linux の hugepage の開発動向
Linux の hugepage の開発動向Linux の hugepage の開発動向
Linux の hugepage の開発動向Naoya Horiguchi
 
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線Motonori Shindo
 
PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会
PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会
PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会Shigeru Hanada
 
事例で学ぶApache Cassandra
事例で学ぶApache Cassandra事例で学ぶApache Cassandra
事例で学ぶApache CassandraYuki Morishita
 
『機械学習による故障予測・異常検知 事例紹介とデータ分析プロジェクト推進ポイント』
『機械学習による故障予測・異常検知 事例紹介とデータ分析プロジェクト推進ポイント』『機械学習による故障予測・異常検知 事例紹介とデータ分析プロジェクト推進ポイント』
『機械学習による故障予測・異常検知 事例紹介とデータ分析プロジェクト推進ポイント』The Japan DataScientist Society
 
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方歩 柴田
 
Cassandraとh baseの比較して入門するno sql
Cassandraとh baseの比較して入門するno sqlCassandraとh baseの比較して入門するno sql
Cassandraとh baseの比較して入門するno sqlYutuki r
 
Hadoopのシステム設計・運用のポイント
Hadoopのシステム設計・運用のポイントHadoopのシステム設計・運用のポイント
Hadoopのシステム設計・運用のポイントCloudera Japan
 

What's hot (20)

Python 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそうPython 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそう
 
Rancher/Kubernetes入門ハンズオン資料~第2回さくらとコンテナの夕べ #さくらの夕べ 番外編
 Rancher/Kubernetes入門ハンズオン資料~第2回さくらとコンテナの夕べ #さくらの夕べ 番外編 Rancher/Kubernetes入門ハンズオン資料~第2回さくらとコンテナの夕べ #さくらの夕べ 番外編
Rancher/Kubernetes入門ハンズオン資料~第2回さくらとコンテナの夕べ #さくらの夕べ 番外編
 
NetApp XCP データ移行ツールインストールと設定
NetApp XCP データ移行ツールインストールと設定NetApp XCP データ移行ツールインストールと設定
NetApp XCP データ移行ツールインストールと設定
 
OCIランタイムの筆頭「runc」を俯瞰する
OCIランタイムの筆頭「runc」を俯瞰するOCIランタイムの筆頭「runc」を俯瞰する
OCIランタイムの筆頭「runc」を俯瞰する
 
Yahoo! JAPANにおけるApache Cassandraへの取り組み
Yahoo! JAPANにおけるApache Cassandraへの取り組みYahoo! JAPANにおけるApache Cassandraへの取り組み
Yahoo! JAPANにおけるApache Cassandraへの取り組み
 
PostgreSQLレプリケーション徹底紹介
PostgreSQLレプリケーション徹底紹介PostgreSQLレプリケーション徹底紹介
PostgreSQLレプリケーション徹底紹介
 
Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編
 
Consistent hash
Consistent hashConsistent hash
Consistent hash
 
サンプルアプリケーションで学ぶApache Cassandraを使ったJavaアプリケーションの作り方
サンプルアプリケーションで学ぶApache Cassandraを使ったJavaアプリケーションの作り方サンプルアプリケーションで学ぶApache Cassandraを使ったJavaアプリケーションの作り方
サンプルアプリケーションで学ぶApache Cassandraを使ったJavaアプリケーションの作り方
 
Linux の hugepage の開発動向
Linux の hugepage の開発動向Linux の hugepage の開発動向
Linux の hugepage の開発動向
 
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
 
PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会
PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会
PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会
 
事例で学ぶApache Cassandra
事例で学ぶApache Cassandra事例で学ぶApache Cassandra
事例で学ぶApache Cassandra
 
『機械学習による故障予測・異常検知 事例紹介とデータ分析プロジェクト推進ポイント』
『機械学習による故障予測・異常検知 事例紹介とデータ分析プロジェクト推進ポイント』『機械学習による故障予測・異常検知 事例紹介とデータ分析プロジェクト推進ポイント』
『機械学習による故障予測・異常検知 事例紹介とデータ分析プロジェクト推進ポイント』
 
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajpAt least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
 
これがCassandra
これがCassandraこれがCassandra
これがCassandra
 
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
 
Cassandraとh baseの比較して入門するno sql
Cassandraとh baseの比較して入門するno sqlCassandraとh baseの比較して入門するno sql
Cassandraとh baseの比較して入門するno sql
 
Hadoop ~Yahoo! JAPANの活用について~
Hadoop ~Yahoo! JAPANの活用について~Hadoop ~Yahoo! JAPANの活用について~
Hadoop ~Yahoo! JAPANの活用について~
 
Hadoopのシステム設計・運用のポイント
Hadoopのシステム設計・運用のポイントHadoopのシステム設計・運用のポイント
Hadoopのシステム設計・運用のポイント
 

Similar to HDFS HA セミナー #hadoop

HDFS Supportaiblity Improvements
HDFS Supportaiblity ImprovementsHDFS Supportaiblity Improvements
HDFS Supportaiblity ImprovementsCloudera Japan
 
Hadoop 2.6の最新機能(Cloudera World Tokyo 2014 LT講演資料)
Hadoop 2.6の最新機能(Cloudera World Tokyo 2014 LT講演資料)Hadoop 2.6の最新機能(Cloudera World Tokyo 2014 LT講演資料)
Hadoop 2.6の最新機能(Cloudera World Tokyo 2014 LT講演資料)NTT DATA OSS Professional Services
 
Hadoopビッグデータ基盤の歴史を振り返る #cwt2015
Hadoopビッグデータ基盤の歴史を振り返る #cwt2015Hadoopビッグデータ基盤の歴史を振り返る #cwt2015
Hadoopビッグデータ基盤の歴史を振り返る #cwt2015Cloudera Japan
 
Hadoop Trends & Hadoop on EC2
Hadoop Trends & Hadoop on EC2Hadoop Trends & Hadoop on EC2
Hadoop Trends & Hadoop on EC2Yifeng Jiang
 
Hadoopデータプラットフォーム #cwt2013
Hadoopデータプラットフォーム #cwt2013Hadoopデータプラットフォーム #cwt2013
Hadoopデータプラットフォーム #cwt2013Cloudera Japan
 
HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)
HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)
HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)NTT DATA OSS Professional Services
 
サポートメンバは見た! Hadoopバグワースト10 (adoop / Spark Conference Japan 2016 ライトニングトーク発表資料)
サポートメンバは見た! Hadoopバグワースト10 (adoop / Spark Conference Japan 2016 ライトニングトーク発表資料)サポートメンバは見た! Hadoopバグワースト10 (adoop / Spark Conference Japan 2016 ライトニングトーク発表資料)
サポートメンバは見た! Hadoopバグワースト10 (adoop / Spark Conference Japan 2016 ライトニングトーク発表資料)NTT DATA OSS Professional Services
 
Beginner must-see! A future that can be opened by learning Hadoop
Beginner must-see! A future that can be opened by learning HadoopBeginner must-see! A future that can be opened by learning Hadoop
Beginner must-see! A future that can be opened by learning HadoopDataWorks Summit
 
「新製品 Kudu 及び RecordServiceの概要」 #cwt2015
「新製品 Kudu 及び RecordServiceの概要」 #cwt2015「新製品 Kudu 及び RecordServiceの概要」 #cwt2015
「新製品 Kudu 及び RecordServiceの概要」 #cwt2015Cloudera Japan
 
Apache Kuduは何がそんなに「速い」DBなのか? #dbts2017
Apache Kuduは何がそんなに「速い」DBなのか? #dbts2017Apache Kuduは何がそんなに「速い」DBなのか? #dbts2017
Apache Kuduは何がそんなに「速い」DBなのか? #dbts2017Cloudera Japan
 
分散処理基盤Apache Hadoopの現状と、NTTデータのHadoopに対する取り組み
分散処理基盤Apache Hadoopの現状と、NTTデータのHadoopに対する取り組み分散処理基盤Apache Hadoopの現状と、NTTデータのHadoopに対する取り組み
分散処理基盤Apache Hadoopの現状と、NTTデータのHadoopに対する取り組みNTT DATA OSS Professional Services
 
Hadoop~Yahoo!Japanの活用について
Hadoop~Yahoo!Japanの活用についてHadoop~Yahoo!Japanの活用について
Hadoop~Yahoo!Japanの活用についてkaminashi
 
今注目のSpark SQL、知っておきたいその性能とは 20151209 OSC Enterprise
今注目のSpark SQL、知っておきたいその性能とは 20151209 OSC Enterprise今注目のSpark SQL、知っておきたいその性能とは 20151209 OSC Enterprise
今注目のSpark SQL、知っておきたいその性能とは 20151209 OSC EnterpriseYusukeKuramata
 
Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)
Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)
Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)Cloudera Japan
 
ATN No.1 MapReduceだけでない!? Hadoopとその仲間たち
ATN No.1 MapReduceだけでない!? Hadoopとその仲間たちATN No.1 MapReduceだけでない!? Hadoopとその仲間たち
ATN No.1 MapReduceだけでない!? Hadoopとその仲間たちAdvancedTechNight
 
NTTデータ流 Hadoop活用のすすめ ~インフラ構築・運用の勘所~
NTTデータ流 Hadoop活用のすすめ ~インフラ構築・運用の勘所~NTTデータ流 Hadoop活用のすすめ ~インフラ構築・運用の勘所~
NTTデータ流 Hadoop活用のすすめ ~インフラ構築・運用の勘所~NTT DATA OSS Professional Services
 
基礎から学ぶ超並列SQLエンジンImpala #cwt2015
基礎から学ぶ超並列SQLエンジンImpala #cwt2015基礎から学ぶ超並列SQLエンジンImpala #cwt2015
基礎から学ぶ超並列SQLエンジンImpala #cwt2015Cloudera Japan
 

Similar to HDFS HA セミナー #hadoop (20)

HDFS Supportaiblity Improvements
HDFS Supportaiblity ImprovementsHDFS Supportaiblity Improvements
HDFS Supportaiblity Improvements
 
Apache Hadoop HDFSの最新機能の紹介(2018)#dbts2018
Apache Hadoop HDFSの最新機能の紹介(2018)#dbts2018Apache Hadoop HDFSの最新機能の紹介(2018)#dbts2018
Apache Hadoop HDFSの最新機能の紹介(2018)#dbts2018
 
Hadoop 2.6の最新機能(Cloudera World Tokyo 2014 LT講演資料)
Hadoop 2.6の最新機能(Cloudera World Tokyo 2014 LT講演資料)Hadoop 2.6の最新機能(Cloudera World Tokyo 2014 LT講演資料)
Hadoop 2.6の最新機能(Cloudera World Tokyo 2014 LT講演資料)
 
Hadoopビッグデータ基盤の歴史を振り返る #cwt2015
Hadoopビッグデータ基盤の歴史を振り返る #cwt2015Hadoopビッグデータ基盤の歴史を振り返る #cwt2015
Hadoopビッグデータ基盤の歴史を振り返る #cwt2015
 
Hadoop Trends & Hadoop on EC2
Hadoop Trends & Hadoop on EC2Hadoop Trends & Hadoop on EC2
Hadoop Trends & Hadoop on EC2
 
Hadoopデータプラットフォーム #cwt2013
Hadoopデータプラットフォーム #cwt2013Hadoopデータプラットフォーム #cwt2013
Hadoopデータプラットフォーム #cwt2013
 
HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)
HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)
HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)
 
Apache Big Data Miami 2017 - Hadoop Source Code Reading #23 #hadoopreading
Apache Big Data Miami 2017 - Hadoop Source Code Reading #23 #hadoopreadingApache Big Data Miami 2017 - Hadoop Source Code Reading #23 #hadoopreading
Apache Big Data Miami 2017 - Hadoop Source Code Reading #23 #hadoopreading
 
サポートメンバは見た! Hadoopバグワースト10 (adoop / Spark Conference Japan 2016 ライトニングトーク発表資料)
サポートメンバは見た! Hadoopバグワースト10 (adoop / Spark Conference Japan 2016 ライトニングトーク発表資料)サポートメンバは見た! Hadoopバグワースト10 (adoop / Spark Conference Japan 2016 ライトニングトーク発表資料)
サポートメンバは見た! Hadoopバグワースト10 (adoop / Spark Conference Japan 2016 ライトニングトーク発表資料)
 
Beginner must-see! A future that can be opened by learning Hadoop
Beginner must-see! A future that can be opened by learning HadoopBeginner must-see! A future that can be opened by learning Hadoop
Beginner must-see! A future that can be opened by learning Hadoop
 
Hadoopエコシステムのデータストア振り返り
Hadoopエコシステムのデータストア振り返りHadoopエコシステムのデータストア振り返り
Hadoopエコシステムのデータストア振り返り
 
「新製品 Kudu 及び RecordServiceの概要」 #cwt2015
「新製品 Kudu 及び RecordServiceの概要」 #cwt2015「新製品 Kudu 及び RecordServiceの概要」 #cwt2015
「新製品 Kudu 及び RecordServiceの概要」 #cwt2015
 
Apache Kuduは何がそんなに「速い」DBなのか? #dbts2017
Apache Kuduは何がそんなに「速い」DBなのか? #dbts2017Apache Kuduは何がそんなに「速い」DBなのか? #dbts2017
Apache Kuduは何がそんなに「速い」DBなのか? #dbts2017
 
分散処理基盤Apache Hadoopの現状と、NTTデータのHadoopに対する取り組み
分散処理基盤Apache Hadoopの現状と、NTTデータのHadoopに対する取り組み分散処理基盤Apache Hadoopの現状と、NTTデータのHadoopに対する取り組み
分散処理基盤Apache Hadoopの現状と、NTTデータのHadoopに対する取り組み
 
Hadoop~Yahoo!Japanの活用について
Hadoop~Yahoo!Japanの活用についてHadoop~Yahoo!Japanの活用について
Hadoop~Yahoo!Japanの活用について
 
今注目のSpark SQL、知っておきたいその性能とは 20151209 OSC Enterprise
今注目のSpark SQL、知っておきたいその性能とは 20151209 OSC Enterprise今注目のSpark SQL、知っておきたいその性能とは 20151209 OSC Enterprise
今注目のSpark SQL、知っておきたいその性能とは 20151209 OSC Enterprise
 
Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)
Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)
Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)
 
ATN No.1 MapReduceだけでない!? Hadoopとその仲間たち
ATN No.1 MapReduceだけでない!? Hadoopとその仲間たちATN No.1 MapReduceだけでない!? Hadoopとその仲間たち
ATN No.1 MapReduceだけでない!? Hadoopとその仲間たち
 
NTTデータ流 Hadoop活用のすすめ ~インフラ構築・運用の勘所~
NTTデータ流 Hadoop活用のすすめ ~インフラ構築・運用の勘所~NTTデータ流 Hadoop活用のすすめ ~インフラ構築・運用の勘所~
NTTデータ流 Hadoop活用のすすめ ~インフラ構築・運用の勘所~
 
基礎から学ぶ超並列SQLエンジンImpala #cwt2015
基礎から学ぶ超並列SQLエンジンImpala #cwt2015基礎から学ぶ超並列SQLエンジンImpala #cwt2015
基礎から学ぶ超並列SQLエンジンImpala #cwt2015
 

More from Cloudera Japan

機械学習の定番プラットフォームSparkの紹介
機械学習の定番プラットフォームSparkの紹介機械学習の定番プラットフォームSparkの紹介
機械学習の定番プラットフォームSparkの紹介Cloudera Japan
 
分散DB Apache Kuduのアーキテクチャ DBの性能と一貫性を両立させる仕組み 「HybridTime」とは
分散DB Apache KuduのアーキテクチャDBの性能と一貫性を両立させる仕組み「HybridTime」とは分散DB Apache KuduのアーキテクチャDBの性能と一貫性を両立させる仕組み「HybridTime」とは
分散DB Apache Kuduのアーキテクチャ DBの性能と一貫性を両立させる仕組み 「HybridTime」とはCloudera Japan
 
Apache Impalaパフォーマンスチューニング #dbts2018
Apache Impalaパフォーマンスチューニング #dbts2018Apache Impalaパフォーマンスチューニング #dbts2018
Apache Impalaパフォーマンスチューニング #dbts2018Cloudera Japan
 
Apache Hadoop YARNとマルチテナントにおけるリソース管理
Apache Hadoop YARNとマルチテナントにおけるリソース管理Apache Hadoop YARNとマルチテナントにおけるリソース管理
Apache Hadoop YARNとマルチテナントにおけるリソース管理Cloudera Japan
 
HBase Across the World #LINE_DM
HBase Across the World #LINE_DMHBase Across the World #LINE_DM
HBase Across the World #LINE_DMCloudera Japan
 
Cloudera のサポートエンジニアリング #supennight
Cloudera のサポートエンジニアリング #supennightCloudera のサポートエンジニアリング #supennight
Cloudera のサポートエンジニアリング #supennightCloudera Japan
 
Train, predict, serve: How to go into production your machine learning model
Train, predict, serve: How to go into production your machine learning modelTrain, predict, serve: How to go into production your machine learning model
Train, predict, serve: How to go into production your machine learning modelCloudera Japan
 
Apache Kuduを使った分析システムの裏側
Apache Kuduを使った分析システムの裏側Apache Kuduを使った分析システムの裏側
Apache Kuduを使った分析システムの裏側Cloudera Japan
 
Cloudera in the Cloud #CWT2017
Cloudera in the Cloud #CWT2017Cloudera in the Cloud #CWT2017
Cloudera in the Cloud #CWT2017Cloudera Japan
 
先行事例から学ぶ IoT / ビッグデータの始め方
先行事例から学ぶ IoT / ビッグデータの始め方先行事例から学ぶ IoT / ビッグデータの始め方
先行事例から学ぶ IoT / ビッグデータの始め方Cloudera Japan
 
Clouderaが提供するエンタープライズ向け運用、データ管理ツールの使い方 #CW2017
Clouderaが提供するエンタープライズ向け運用、データ管理ツールの使い方 #CW2017Clouderaが提供するエンタープライズ向け運用、データ管理ツールの使い方 #CW2017
Clouderaが提供するエンタープライズ向け運用、データ管理ツールの使い方 #CW2017Cloudera Japan
 
How to go into production your machine learning models? #CWT2017
How to go into production your machine learning models? #CWT2017How to go into production your machine learning models? #CWT2017
How to go into production your machine learning models? #CWT2017Cloudera Japan
 
Apache Kudu - Updatable Analytical Storage #rakutentech
Apache Kudu - Updatable Analytical Storage #rakutentechApache Kudu - Updatable Analytical Storage #rakutentech
Apache Kudu - Updatable Analytical Storage #rakutentechCloudera Japan
 
Hue 4.0 / Hue Meetup Tokyo #huejp
Hue 4.0 / Hue Meetup Tokyo #huejpHue 4.0 / Hue Meetup Tokyo #huejp
Hue 4.0 / Hue Meetup Tokyo #huejpCloudera Japan
 
Cloudera Data Science WorkbenchとPySparkで 好きなPythonライブラリを 分散で使う #cadeda
Cloudera Data Science WorkbenchとPySparkで 好きなPythonライブラリを 分散で使う #cadedaCloudera Data Science WorkbenchとPySparkで 好きなPythonライブラリを 分散で使う #cadeda
Cloudera Data Science WorkbenchとPySparkで 好きなPythonライブラリを 分散で使う #cadedaCloudera Japan
 
Cloudera + MicrosoftでHadoopするのがイイらしい。 #CWT2016
Cloudera + MicrosoftでHadoopするのがイイらしい。 #CWT2016Cloudera + MicrosoftでHadoopするのがイイらしい。 #CWT2016
Cloudera + MicrosoftでHadoopするのがイイらしい。 #CWT2016Cloudera Japan
 
Cloud Native Hadoop #cwt2016
Cloud Native Hadoop #cwt2016Cloud Native Hadoop #cwt2016
Cloud Native Hadoop #cwt2016Cloudera Japan
 
大規模データに対するデータサイエンスの進め方 #CWT2016
大規模データに対するデータサイエンスの進め方 #CWT2016大規模データに対するデータサイエンスの進め方 #CWT2016
大規模データに対するデータサイエンスの進め方 #CWT2016Cloudera Japan
 
#cwt2016 Apache Kudu 構成とテーブル設計
#cwt2016 Apache Kudu 構成とテーブル設計#cwt2016 Apache Kudu 構成とテーブル設計
#cwt2016 Apache Kudu 構成とテーブル設計Cloudera Japan
 
#cwt2016 Cloudera Managerを用いた Hadoop のトラブルシューティング
#cwt2016 Cloudera Managerを用いた Hadoop のトラブルシューティング #cwt2016 Cloudera Managerを用いた Hadoop のトラブルシューティング
#cwt2016 Cloudera Managerを用いた Hadoop のトラブルシューティング Cloudera Japan
 

More from Cloudera Japan (20)

機械学習の定番プラットフォームSparkの紹介
機械学習の定番プラットフォームSparkの紹介機械学習の定番プラットフォームSparkの紹介
機械学習の定番プラットフォームSparkの紹介
 
分散DB Apache Kuduのアーキテクチャ DBの性能と一貫性を両立させる仕組み 「HybridTime」とは
分散DB Apache KuduのアーキテクチャDBの性能と一貫性を両立させる仕組み「HybridTime」とは分散DB Apache KuduのアーキテクチャDBの性能と一貫性を両立させる仕組み「HybridTime」とは
分散DB Apache Kuduのアーキテクチャ DBの性能と一貫性を両立させる仕組み 「HybridTime」とは
 
Apache Impalaパフォーマンスチューニング #dbts2018
Apache Impalaパフォーマンスチューニング #dbts2018Apache Impalaパフォーマンスチューニング #dbts2018
Apache Impalaパフォーマンスチューニング #dbts2018
 
Apache Hadoop YARNとマルチテナントにおけるリソース管理
Apache Hadoop YARNとマルチテナントにおけるリソース管理Apache Hadoop YARNとマルチテナントにおけるリソース管理
Apache Hadoop YARNとマルチテナントにおけるリソース管理
 
HBase Across the World #LINE_DM
HBase Across the World #LINE_DMHBase Across the World #LINE_DM
HBase Across the World #LINE_DM
 
Cloudera のサポートエンジニアリング #supennight
Cloudera のサポートエンジニアリング #supennightCloudera のサポートエンジニアリング #supennight
Cloudera のサポートエンジニアリング #supennight
 
Train, predict, serve: How to go into production your machine learning model
Train, predict, serve: How to go into production your machine learning modelTrain, predict, serve: How to go into production your machine learning model
Train, predict, serve: How to go into production your machine learning model
 
Apache Kuduを使った分析システムの裏側
Apache Kuduを使った分析システムの裏側Apache Kuduを使った分析システムの裏側
Apache Kuduを使った分析システムの裏側
 
Cloudera in the Cloud #CWT2017
Cloudera in the Cloud #CWT2017Cloudera in the Cloud #CWT2017
Cloudera in the Cloud #CWT2017
 
先行事例から学ぶ IoT / ビッグデータの始め方
先行事例から学ぶ IoT / ビッグデータの始め方先行事例から学ぶ IoT / ビッグデータの始め方
先行事例から学ぶ IoT / ビッグデータの始め方
 
Clouderaが提供するエンタープライズ向け運用、データ管理ツールの使い方 #CW2017
Clouderaが提供するエンタープライズ向け運用、データ管理ツールの使い方 #CW2017Clouderaが提供するエンタープライズ向け運用、データ管理ツールの使い方 #CW2017
Clouderaが提供するエンタープライズ向け運用、データ管理ツールの使い方 #CW2017
 
How to go into production your machine learning models? #CWT2017
How to go into production your machine learning models? #CWT2017How to go into production your machine learning models? #CWT2017
How to go into production your machine learning models? #CWT2017
 
Apache Kudu - Updatable Analytical Storage #rakutentech
Apache Kudu - Updatable Analytical Storage #rakutentechApache Kudu - Updatable Analytical Storage #rakutentech
Apache Kudu - Updatable Analytical Storage #rakutentech
 
Hue 4.0 / Hue Meetup Tokyo #huejp
Hue 4.0 / Hue Meetup Tokyo #huejpHue 4.0 / Hue Meetup Tokyo #huejp
Hue 4.0 / Hue Meetup Tokyo #huejp
 
Cloudera Data Science WorkbenchとPySparkで 好きなPythonライブラリを 分散で使う #cadeda
Cloudera Data Science WorkbenchとPySparkで 好きなPythonライブラリを 分散で使う #cadedaCloudera Data Science WorkbenchとPySparkで 好きなPythonライブラリを 分散で使う #cadeda
Cloudera Data Science WorkbenchとPySparkで 好きなPythonライブラリを 分散で使う #cadeda
 
Cloudera + MicrosoftでHadoopするのがイイらしい。 #CWT2016
Cloudera + MicrosoftでHadoopするのがイイらしい。 #CWT2016Cloudera + MicrosoftでHadoopするのがイイらしい。 #CWT2016
Cloudera + MicrosoftでHadoopするのがイイらしい。 #CWT2016
 
Cloud Native Hadoop #cwt2016
Cloud Native Hadoop #cwt2016Cloud Native Hadoop #cwt2016
Cloud Native Hadoop #cwt2016
 
大規模データに対するデータサイエンスの進め方 #CWT2016
大規模データに対するデータサイエンスの進め方 #CWT2016大規模データに対するデータサイエンスの進め方 #CWT2016
大規模データに対するデータサイエンスの進め方 #CWT2016
 
#cwt2016 Apache Kudu 構成とテーブル設計
#cwt2016 Apache Kudu 構成とテーブル設計#cwt2016 Apache Kudu 構成とテーブル設計
#cwt2016 Apache Kudu 構成とテーブル設計
 
#cwt2016 Cloudera Managerを用いた Hadoop のトラブルシューティング
#cwt2016 Cloudera Managerを用いた Hadoop のトラブルシューティング #cwt2016 Cloudera Managerを用いた Hadoop のトラブルシューティング
#cwt2016 Cloudera Managerを用いた Hadoop のトラブルシューティング
 

Recently uploaded

2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor arts yokohama
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdfAyachika Kitazaki
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)ssuser539845
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-LoopへTetsuya Nihonmatsu
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfMatsushita Laboratory
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦Sadao Tokuyama
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~arts yokohama
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法ssuser370dd7
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見Shumpei Kishi
 

Recently uploaded (12)

2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
 
What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
 
2024 03 CTEA
2024 03 CTEA2024 03 CTEA
2024 03 CTEA
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
 
2024 04 minnanoito
2024 04 minnanoito2024 04 minnanoito
2024 04 minnanoito
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
 

HDFS HA セミナー #hadoop

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