Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

本当にあったHadoopの恐い話 Blockはどこへきえた? (Hadoop / Spark Conference Japan 2016 ライトニングトーク発表資料)

2,824 views

Published on

Hadoop / Spark Conference Japan 2016 (2016/02/08)
ライトニングトーク発表資料

■本当にあったHadoopの恐い話 Blockはどこへきえた?
山下 真一(NTTデータ)

イベントページ
http://hadoop.apache.jp/hcj2016-program/

Published in: Technology
  • Be the first to comment

本当にあったHadoopの恐い話 Blockはどこへきえた? (Hadoop / Spark Conference Japan 2016 ライトニングトーク発表資料)

  1. 1. Copyright © 2016 NTT DATA Corporation Hadoop/Spark Conference Japan 2016 ライトニングトーク 2016年2月8日 株式会社NTTデータ 山下 真一 本当にあったHadoopの恐い話 Blockはどこへきえた?
  2. 2. 2Copyright © 2016 NTT DATA Corporation トラブルはいつも金曜日 夏の暑い日、いつもどおり出社した私に一本の電話が... ははーん。またサーバが多数故障したの?と質問すると... なんと!問題は深刻だった。。。 HDFSに保存していたブロックが消えました… 特にサーバは故障していませんし DataNodeも切り離されていません
  3. 3. 3Copyright © 2016 NTT DATA Corporation 何はともあれ、まずはログ 消えたブロックの一覧はNameNodeのWeb画面で確認できる。 この情報からNameNodeのログを調べた。消えたブロックを追いかけて追いかけて。。。 (調査対象 : トラブル発生日から直近1か月分のHDFS関連のログ) すると分かったことは3点。 1. 事象発生前に、メンテ中だったDataNodeを組み込んだ。組み込んだDataNodeはメ ンテ前のブロックを保持していた。 2. DataNodeのログには、NameNodeからのブロック削除指示の後、再度ブロックを追 加するようなメッセージが出力されている。特にNameNodeから追加指示は飛んで いないので、何故? 3. DataNodeでの当該ブロックの削除は、指示を受けた2時間後に完了している、何 故? 矛盾を抱えつつも、ログの出力内容+Hadoopソースコードから事象を組み立てた。
  4. 4. 4Copyright © 2016 NTT DATA Corporation おさらい : HDFSのレプリケーションについて  HDFSのブロックは、設定されたレプリケーション数を維持する ように動作する 1. 設定されているレプリケーション数よりも少ない状態の場合 → レプリケーション数に達するまで作成 2. 設定されているレプリケーション数よりも多い状態の場合 → レプリケーション数に達するまでレプリカ削除 今回の動作は、2. に関連する動作に着目。
  5. 5. 5Copyright © 2016 NTT DATA Corporation Hadoop内部の動作 - DataNodeのブロックを削除する流れ1 DataNode deleteBlock ブロック 管理情報 対象ブロック情報を ブロック管理情報 から除去 DataNodeが扱っている ブロック一覧をメモリ上 で記録 remove ブロック削除 用スレッド 対象ブロックの 実データ削除指示 Block × 削除 非同期で削除
  6. 6. 6Copyright © 2016 NTT DATA Corporation Hadoop内部の動作 - DataNodeの定期的なタスク DataNode deleteBlock ブロック 管理情報 remove remove ブロック削除 用スレッド 対象ブロックの 実データ削除指示 Block × 削除 削除に時間が掛かる (処理・IOネックなどが原因) 実データ チェックスレッド check 再登録再登録 定期的に実行 (別名: DirectoryScanner) 消したはずのブ ロック情報が再 び管理される
  7. 7. 7Copyright © 2016 NTT DATA Corporation Hadoop内部の動作 - DataNodeの定期的なタスク DataNode ブロック 管理情報 remove remove ブロック削除 用スレッド 対象ブロックの 実データ削除指示 Block × 削除 Directory Scanner check 再登録再登録 ブロック情報 報告スレッド 定期的に実行 (別名: BlockReport) 管理情報 チェック ブロック情報を NameNodeに送信 消したはずのブ ロック情報が NameNodeに 送信される
  8. 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. 9. 9Copyright © 2016 NTT DATA Corporation Hadoopの非同期処理の不十分な実装が引き起こした問題… レプリカが全消失 ↓ 高負荷状態(CPU・ディスク)が 長時間続いていたため発生しやすかった (ブロック削除に2時間掛かった点はまさにこれ) (※ この事象起因でレプリカ全消失までいかなくても、一時的にレプリカ 数が不足したブロックもある)
  10. 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. 11. 11Copyright © 2016 NTT DATA Corporation まとめ  Hadoop = サーバのリソースを使い倒すことが前提の構成 • でも、高負荷状態は、いろいろな問題を引き起こしやすい • でも、大量データを扱うと、いろいろな問題を引き起こしやすい  問題は発生することを前提とした、運用スタイルを整えること • HDFS上データが欠損しても再生成できる仕組み(、または割り切ること) • ログ精査、リソース情報の取得  あまり、サーバをいじめないでくださいね。 • サーバスペックに応じた、やさしい設定・リソース割り当て • 無邪気なアプリケーションは、まずは手元の環境&少量データで確認してね!  バージョン選定は大切 • 問題の改修は、新しいバージョン優先 • 根が深い問題は中々改修されづらい&バックポートされにくい
  12. 12. Copyright © 2011 NTT DATA Corporation Copyright © 2016 NTT DATA Corporation

×