Más contenido relacionado
La actualidad más candente (20)
Similar a 本当にあったHadoopの恐い話 Blockはどこへきえた？ （Hadoop / Spark Conference Japan 2016 ライトニングトーク発表資料） (8)
Más de NTT DATA OSS Professional Services (13)
本当にあったHadoopの恐い話 Blockはどこへきえた？ （Hadoop / Spark Conference Japan 2016 ライトニングトーク発表資料）
- 1. Copyright © 2016 NTT DATA Corporation
Hadoop/Spark Conference Japan 2016
ライトニングトーク
2016年2月8日
株式会社ＮＴＴデータ
山下 真一
本当にあったHadoopの恐い話
Blockはどこへきえた？
- 2. 2Copyright © 2016 NTT DATA Corporation
トラブルはいつも金曜日
夏の暑い日、いつもどおり出社した私に一本の電話が...
ははーん。またサーバが多数故障したの？と質問すると...
なんと！問題は深刻だった。。。
HDFSに保存していたブロックが消えました…
特にサーバは故障していませんし
DataNodeも切り離されていません
- 3. 3Copyright © 2016 NTT DATA Corporation
何はともあれ、まずはログ
消えたブロックの一覧はNameNodeのWeb画面で確認できる。
この情報からNameNodeのログを調べた。消えたブロックを追いかけて追いかけて。。。
(調査対象 : トラブル発生日から直近1か月分のHDFS関連のログ)
すると分かったことは３点。
1. 事象発生前に、メンテ中だったDataNodeを組み込んだ。組み込んだDataNodeはメ
ンテ前のブロックを保持していた。
2. DataNodeのログには、NameNodeからのブロック削除指示の後、再度ブロックを追
加するようなメッセージが出力されている。特にNameNodeから追加指示は飛んで
いないので、何故？
3. DataNodeでの当該ブロックの削除は、指示を受けた2時間後に完了している、何
故？
矛盾を抱えつつも、ログの出力内容＋Hadoopソースコードから事象を組み立てた。
- 4. 4Copyright © 2016 NTT DATA Corporation
おさらい : HDFSのレプリケーションについて
HDFSのブロックは、設定されたレプリケーション数を維持する
ように動作する
1. 設定されているレプリケーション数よりも少ない状態の場合
→ レプリケーション数に達するまで作成
2. 設定されているレプリケーション数よりも多い状態の場合
→ レプリケーション数に達するまでレプリカ削除
今回の動作は、2. に関連する動作に着目。
- 5. 5Copyright © 2016 NTT DATA Corporation
Hadoop内部の動作 - DataNodeのブロックを削除する流れ１
DataNode
deleteBlock
ブロック
管理情報
対象ブロック情報を
ブロック管理情報
から除去
DataNodeが扱っている
ブロック一覧をメモリ上
で記録
remove
ブロック削除
用スレッド
対象ブロックの
実データ削除指示
Block
×
削除
非同期で削除
- 6. 6Copyright © 2016 NTT DATA Corporation
Hadoop内部の動作 - DataNodeの定期的なタスク
DataNode
deleteBlock
ブロック
管理情報
remove remove
ブロック削除
用スレッド
対象ブロックの
実データ削除指示
Block
×
削除
削除に時間が掛かる
(処理・IOネックなどが原因)
実データ
チェックスレッド
check
再登録再登録
定期的に実行
(別名: DirectoryScanner)
消したはずのブ
ロック情報が再
び管理される
- 7. 7Copyright © 2016 NTT DATA Corporation
Hadoop内部の動作 - DataNodeの定期的なタスク
DataNode
ブロック
管理情報
remove remove
ブロック削除
用スレッド
対象ブロックの
実データ削除指示
Block
×
削除
Directory
Scanner
check
再登録再登録
ブロック情報
報告スレッド
定期的に実行
(別名: BlockReport)
管理情報
チェック
ブロック情報を
NameNodeに送信
消したはずのブ
ロック情報が
NameNodeに
送信される
- 8. 8Copyright © 2016 NTT DATA Corporation
誤ったブロック情報がHadoopクラスタ全体に伝播する
NameNodeイベント
(ブロック管理情報)
DataNode1 DataNode2 DataNode3 DataNode4
実体
管理
情報
実体
管理
情報
実体
管理
情報
実体
管理
情報
1
超過レプリカにより
DataNode4に削除指示
○ ○ ○ ○ ○ ○ ○ ○
2
DN4で問題発生、再度超過レ
プリカ、DN2に削除指示 ○ ○ ○ ○ ○ ○ × ○
3
DN2で問題発生、3度超過レ
プリカ、DN1に削除指示 ○ ○ × ○ ○ ○ × ○
4
DN1で問題発生、4度超過レ
プリカ、DN3に削除指示 × ○ × ○ ○ ○ × ○
5
DN3で問題発生、5度超過レ
プリカ、DN4に削除指示 × ○ × ○ × ○ × ○
6 DN4 BlockReport × ○ × ○ × ○ × ×
7 DN1 BlockReport × ○ × × × ○ × ×
8 DN3 BlockReport × × × × × ○ × ×
9 DN2 BlockReport × × × × × × × ×
10 MissingBlock状態 × × × × × × × ×
- 9. 9Copyright © 2016 NTT DATA Corporation
Hadoopの非同期処理の不十分な実装が引き起こした問題…
レプリカが全消失
↓
高負荷状態（CPU・ディスク）が
長時間続いていたため発生しやすかった
(ブロック削除に2時間掛かった点はまさにこれ)
(※ この事象起因でレプリカ全消失までいかなくても、一時的にレプリカ
数が不足したブロックもある)
- 10. 10Copyright © 2016 NTT DATA Corporation
安心してください
はいってますよ！
ではこの問題は未だに発生するのか？
HDFS-6833
Apache Hadoop
2.7.1～
HDP
2.3～
CDH
5.5～
※ベースは2.6系だがBackport済
※ Hadoop1系(例: CDH3など)では発生しません。
- 11. 11Copyright © 2016 NTT DATA Corporation
まとめ
Hadoop = サーバのリソースを使い倒すことが前提の構成
• でも、高負荷状態は、いろいろな問題を引き起こしやすい
• でも、大量データを扱うと、いろいろな問題を引き起こしやすい
問題は発生することを前提とした、運用スタイルを整えること
• HDFS上データが欠損しても再生成できる仕組み(、または割り切ること)
• ログ精査、リソース情報の取得
あまり、サーバをいじめないでくださいね。
• サーバスペックに応じた、やさしい設定・リソース割り当て
• 無邪気なアプリケーションは、まずは手元の環境＆少量データで確認してね！
バージョン選定は大切
• 問題の改修は、新しいバージョン優先
• 根が深い問題は中々改修されづらい＆バックポートされにくい
