#cwt2016 Cloudera Managerを用いた Hadoop のトラブルシューティング

Cloudera Manager を⽤いた
Hadoop のトラブルシューティング
テクニカルサポートの現場から
Daisuke Kobayashi | Customer Operations Engineer

2© Cloudera, Inc. All rights reserved.
⾃⼰紹介
•  ⼩林⼤輔 (@d1ce_)
•  Cloudera ⼊社五年⽬
•  カスタマーオペレーションズエンジニア == テクニカルサポート
•  過去の主な講演
•  Hadoop Operations (2013)
http://www.slideshare.net/Cloudera_jp/b3-hadoop-operations-20131107
•  HBaseサポート最前線 (2015)
http://www.slideshare.net/Cloudera_jp/hbase-hbaseca
•  Troubleshooting Using Cloudera Manager (2015)
http://www.slideshare.net/Cloudera_jp/troubleshooting-using-cloudera-manager-cwt2015

障害対応時に必要な情報
•  どんなログがでているか
•  どのバージョンを使⽤しているか
•  どのような設定で動かしているか
•  発⽣前に変更した設定はあるか
•  いつ、何をしたときに発⽣したか
•  発⽣頻度は？
•  推奨構成となっているか
•  使⽤しているコンポーネントは？
•  これまでにどのような対応を実施したか

本講演では
Cloudera Manager (CM) を使って
1.  障害を回避するためにできること
2.  障害が発⽣したときに Cloudera サポートチームが
•  何をみて
•  どのように
•  問題解決しているのか
を紹介します

昨年のセッション

昨年のセッションをベースに講演します
Troubleshooting Using Cloudera Manager #cwt2015
http://www.slideshare.net/Cloudera_jp/troubleshooting-using-cloudera-manager-cwt2015
How Cloudera Manager Makes Hadoop Troubleshooting Easy
http://qiita.com/d1ce_/items/9dd13a71f574ad1000af

17©Cloudera, Inc. All rights reserved.
トラブルシューティングに先⽴って
必要となる前提知識の確認

サポート要件の確認
http://www.cloudera.com/documentation/enterprise/release-notes/topics/rn_consolidated_pcm.html
•  サポートOS/Database/JDK のバージョンを確認すること
•  ディスク要件
•  DataNode や Kafkaのノード
•  独⽴したディスクを使⽤すること (JBOD)
•  DataNode のドライブは SSD/HDD 混在の構成もサポート (CDH 5.4 以上)
http://www.cloudera.com/documentation/enterprise/latest/topics/admin_heterogeneous_storage_oview.html
•  new! DataNode 内ディスク間バランシングも対応 (CDH 5.8.2 以上)
https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HDFSDiskbalancer.html
•  マスターノード
•  NameNode/JournalNode/ZooKeeper でそれぞれ独⽴したドライブを⽤意すること

サポート要件の確認
•  ネットワーク要件
•  複数 NIC の利⽤は未サポート
•  ホスト同⼠は FQDN で通信できるよう確認すること
•  ファイアーウォールは無効化すること

ホストインスペクタの定期実⾏
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_mc_host_inspector.html
•  必須要件のチェックが⼊っている
•  ホスト間の名前解決の確認
•  THP や swappiness 設定状況の検知
•  バージョン不整合の検知
かならず全てグリーンにすること

CMが利⽤するポート
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ig_ports_cm.html
注: この他にもコンポーネント間の通信⽤に
ランダムにエフェメラルポートを利⽤

CMが利⽤するポート
•  CDHのプロセスはすべてsupervisordが管理
•  CM⾃⾝はHDFSのデータやHiveメタストアの
情報を持たない

CMが⽣成する設定ファイル
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_intro_primer.html
•  クライアント設定
•  /etc/XXX/conf (etc/hadoop/conf, /etc/hive/conf, ...)
•  ネームノードやデータノードなどのサーバープロセスは参照しない
•  サーバーサイド設定
•  CM 経由での再起動時に新たな
ディレクトリが⽣成される
•  ⾃動再起動時は以前のディレクトリを
使⽤

CMが⽣成するログファイル
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ag_view_server_logs.html
•  CM Server
•  /var/log/cloudera-scm-server
•  GUI からも確認可能

http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ag_view_agent_logs.html
•  CM Agent
•  /var/log/cloudera-scm-agent

CDH プロセスの実⾏コマンドログ
•  NameNode の例
•  /var/run/cloudera-scm-agent/process/xx-hdfs-NAMENODE/logs
•  何が出⼒されているか
•  プロセス起動にあたり読み込んだ環境変数と実⾏コマンド
•  OutOfMemoryError 発⽣時のログ

CMが利⽤するデータベース
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ig_installing_configuring_dbs.html
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ig_reqs_space.html
•  RDBMS を利⽤するプロセス
•  CM Server (組み込み PostgreSQL を使⽤すると警告がでます)
•  Activity Monitor (MRv1のみ)
•  Reports Manager / Navigator ( のみ)
•  LevelDB を利⽤するプロセス
•  Service Monitor (/var/lib/cloudera-service-monitor/)
•  Host Monitor (/var/lib/cloudera-host-monitor/)
•  それぞれ最低 10GB 以上必要

アップグレードにあたって
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ag_upgrading_cm.html
•  かならず CM を先にアップグレードすること
•  CM のマイナーバージョン >= CDH のマイナーバージョンを維持すること
•  マイナーバージョン: バージョン番号 X.Y.Z の X.Y を指す
•  CM <= CDH は未サポート & 最悪の場合まともに動きません
CM アップグレード CDH アップグレード

アップグレードにあたって
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ag_upgrading_os.html
•  ホスト OS のアップグレード
•  CM/CDH のアップグレードと同時に⾏う場合は、OS を先に実施すること
•  マイナーアップグレード（推奨）
•  ワーカーノードの OS アップグレードはメンテナンス時間やブロック数に応じて
デコミッションするかしないかの戦略を⽴てる必要がある

チャートの活⽤
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_dg_chart_time_series_data.html

クラウドのリファレンスアーキテクチャ
http://www.cloudera.com/documentation/other/reference-architecture.html

全体から細部へ
http://www.cloudera.co.jp/blog/quality-assurance-at-cloudera-runningupgrading-to-new-releases-on-our-own-edh-cluster.html

36©Cloudera, Inc. All rights reserved.
トラブルシューティングの実際

障害の三⼤原因
•  製品バグ
•  ハードウェアの問題
•  ユーザーのオペミス

#1 ブロック数が急増した原因は？

•  事象
•  データノードが OutOfMemoryError で停⽌する事象が頻発
•  データノードが保持するブロック数が100万近くに達したというアラート
•  CM は単⼀データノードが50万以上のブロックを保持しているとアラートを出す
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ht_datanode.html

•  事象
•  確認事項
•  本当にブロック数が急増していれば OOME は起こり得る
•  いつ増加を始めた？
•  そもそも異常なことなのか？
•  損失したブロックはないか？

•  事象
•  確認事項
•  本当にブロック数が急増していれば OOME は起こり得る
•  いつ増加を始めた？
•  そもそも異常なことなのか？
•  損失したブロックはないか？
??
hdfs fsck?

#1 ブロック数はいつ増加し始めたのか
1.  現在のブロック数を確認する
•  ネームノード WebU Iのデータノード⼀覧ページから確認できる
2.  ブロック数の増加傾向を確認する
•  tsquey を投げる？
SELECT blocks_total WHERE entityName rlike "hdfs.*" AND category = SERVICE
•  事前定義されたチャートからも確認できる
•  HDFS --> チャートライブラリ --> Blocks and Files

#1 ブロック数の増加傾向を確認する
•  チャートで表⽰するタイムレンジは柔軟に選択できる
•  ⽉、⽇、時間、分レベルで調整可能
•  今回は「1⽇」「7⽇間」「30⽇間」
の3パターンで取得

1⽇

7⽇間

30⽇間

1⽇
7⽇間
30⽇間
過去24時間で
⼤きな変化は
なし
3⽇前からブロック
数の急増を確認
現在は3倍以上
過去⼀ヶ⽉でみると
今回の増加は
異常にみえる

#1 ブロック数の急増はなぜ起きたか
•  営業チームに連絡が⼊っていないか確認
•  新たなデータソースの追加予定はあったか？
•  クラスタの利⽤⽤途は以前と変わっていないか？
•  ブロック数が増えたことはわかったが、データ量は増えているか？
•  2PB 近いデータが何の予告もなしに投⼊されたとは考えにくい
•  ⼩さいファイルが⼤量投⼊された可能性が⾼い
•  CM からチャートを確認
•  HDFS のサービスページに事前定義されたチャートがある

#1 データ量は増えているか
30⽇間⼀切増えていない

#1 結論
•  状況のまとめ
•  過去3⽇間の間に 2000万近いブロックが追加された
•  クラスタ全体のデータ量は増えていない
•  損失したブロックはない
•  small ﬁles problem が発⽣していることを通知
http://blog.cloudera.com/blog/2009/02/the-small-files-problem/
•  お客さま側でユーザー毎の利⽤状況を確認してもらい、クラスタ
利⽤者が⼤量のファイルを投⼊していたことが判明

#2 70万個のブロックが損失した原因は？

#2 70万個のブロックが損失した理由は？
•  事象
•  データノードのホットスワップ後、70万以上のブロック損失が検知された

#2 ホットスワップについて
http://www.cloudera.com/documentation/enterprise/latest/topics/admin_dn_swap.html
•  データノードでディスク障害が発⽣したとき
•  従来のステップ
1.  データノードをデコミッションして
2.  データノードを停⽌して
3.  ディスクを交換して
4.  データノードを再起動

ブロックの転送は
ネットワークと
ディスクI/Oを
消費する上
時間がかかる

•  データノードのホットスワップ機能を使うと
1.  対象のディレクトリを削除して
2.  データノードのリフレッシュを実⾏（デコミッションや停⽌が不要）
3.  新たなディスクを追加して
4.  データノードのリフレッシュを実⾏

#2 問題の発⽣状況
•  データノードに2種類の設定グループが存在
dfs.datanode.data.dir に12本のディスク
/data2
/data3
/data4
.
.
.
/data13
デフォルトグループ
/data1
/data2
/data3
.
.
.
/data12
カスタムグループ

•  実際は・・・
•  過去のリフレッシュ時にデフォルトグループのデータノードに /data1 が追加
/data1
/data2
/data3
/data4
.
.
/data13
/data1
/data2
/data3
.
.
.
/data12

•  リフレッシュ後 /data1 に⼊っていたブロックがMISSING となり
検知された
/data1
/data2 /data2
/data3 /data3
/data4 /data4
. .
. .
/data13 /data13
/data1
/data2
/data3
.
.
.
/data12
refresh後

#2 ひとまず問題を解決するために
1.  デフォルトグループのデータノードの設定に /data1 を追加
2.  データノードを⼀台ずつ再起動することでブロックが検知され解消
/data1 /data1
/data2 /data2 /data2
. . .
. . .
/data1
/data2
/data3
.
.
.
/data12

#2 なぜこんな問題が起きたのか？
•  発⽣タイミングの特定
•  何を⾒るか
1.  データノードログ
2.  CM Server ログ
--> CM で実施するほぼすべてのオペレーションはログに記録される
3.  CM Agent ログ
--> ディレクトリの作成、権限設定は Agent の仕事なのでログに記録される
4.  設定履歴 ( のみ)
--> いつ、誰が、何を変更したのか記録されている

#2 データノードログの確認
•  ディレクトリ名で grep して特定
2016-10-05 22:20:09,021 INFO org.apache.hadoop.conf.ReconfigurableBase: Change property:
dfs.datanode.data.dir from "file:///data10/dfs/dn,file:///data11/dfs/dn,file:///data12/dfs/dn,file:///
data13/dfs/dn,file:///data2/dfs/dn,file:///data3/dfs/dn,file:///data4/dfs/dn,file:///data5/dfs/
dn,file:///data6/dfs/dn,file:///data7/dfs/dn,file:///data8/dfs/dn,file:///data9/dfs/dn" to "file:///
dn,file:///data4/dfs/dn,file:///data5/dfs/dn,file:///data6/dfs/dn,file:///data7/dfs/dn,file:///data8/
dfs/dn,file:///data9/dfs/dn,file:///data1/dfs/dn".
2016-10-05 22:20:09,021 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: Reconfiguring
dfs.datanode.data.dir to file:///data10/dfs/dn,file:///data11/dfs/dn,file:///data12/dfs/dn,file:///
dn,file:///data7/dfs/dn,file:///data8/dfs/dn,file:///data9/dfs/dn,file:///data1/dfs/dn
2016-10-05 22:20:09,056 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: Adding new volumes:
[DISK]file:/data1/dfs/dn/
/var/log/hadoop-hdfs/hadoop-cmf-HDFS-1-DATANODE-xxxx.log.out

#2 データノードログの確認
•  データノードが間違いなく /data1 を使⽤していたことを確認
/var/log/hadoop-hdfs/hadoop-cmf-HDFS-1-DATANODE-xxxx.log.out
2016-10-05 22:20:09,021 INFO org.apache.hadoop.conf.ReconfigurableBase: Change property:
dfs.datanode.data.dir from "file:///data10/dfs/dn,file:///data11/dfs/dn,file:///data12/dfs/dn,file:///
dn,file:///data6/dfs/dn,file:///data7/dfs/dn,file:///data8/dfs/dn,file:///data9/dfs/dn" to "file:///
dn,file:///data4/dfs/dn,file:///data5/dfs/dn,file:///data6/dfs/dn,file:///data7/dfs/dn,file:///data8/
dfs/dn,file:///data9/dfs/dn,file:///data1/dfs/dn".
2016-10-05 22:20:09,021 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: Reconfiguring
dfs.datanode.data.dir to file:///data10/dfs/dn,file:///data11/dfs/dn,file:///data12/dfs/dn,file:///
dn,file:///data7/dfs/dn,file:///data8/dfs/dn,file:///data9/dfs/dn,file:///data1/dfs/dn
2016-10-05 22:20:09,056 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: Adding new volumes:
[DISK]file:/data1/dfs/dn/

#2 CM Serverログの確認
2016-10-05 22:20:03,406 INFO 630935751@scm-web-121355:com.cloudera.cmf.service.ServiceHandlerRegistry:
Executing role command RefreshDataNode BasicCmdArgs{args=[]}. Service: DbService{id=36, name=hdfs}
Role: DbRole{id=412, name=hdfs-DATANODE-87bdc0df8fa3dc718873de138b3f301b, hostName=example.com}
/var/log/cloudera-scm-server/cloudera-scm-server.log

#2 CM Serverログの確認
•  CM UI からリフレッシュを実⾏したときに記録される
/var/log/cloudera-scm-server/cloudera-scm-server.log
2016-10-05 22:20:03,406 INFO 630935751@scm-web-121355:com.cloudera.cmf.service.ServiceHandlerRegistry:
Executing role command RefreshDataNode BasicCmdArgs{args=[]}. Service: DbService{id=36, name=hdfs}
Role: DbRole{id=412, name=hdfs-DATANODE-87bdc0df8fa3dc718873de138b3f301b, hostName=example.com}

#2 CM Agentログの確認
[05/Oct/2016 22:20:04 +0000] 48933 MainThread agent INFO Chowning /data1/dfs/dn to hdfs (496) hadoop (497)
[05/Oct/2016 22:20:04 +0000] 48933 MainThread agent INFO Chmod'ing /data1/dfs/dn to 0755
[05/Oct/2016 22:20:04 +0000] 48933 MainThread agent INFO Created /data1/dfs/dn
/var/log/cloudera-scm-agent/cloudera-scm-agent.log

#2 CM Agentログの確認
•  CM Server からの命令をうけて CM Agent がディレクトリを⽤意
•  Agent が作成したディレクトリを使⽤してデータノードは
ブロックを書き込む
[05/Oct/2016 22:20:04 +0000] 48933 MainThread agent INFO Chowning /data1/dfs/dn to hdfs (496) hadoop (497)
[05/Oct/2016 22:20:04 +0000] 48933 MainThread agent INFO Chmod'ing /data1/dfs/dn to 0755
[05/Oct/2016 22:20:04 +0000] 48933 MainThread agent INFO Created /data1/dfs/dn
/var/log/cloudera-scm-agent/cloudera-scm-agent.log

#2 設定変更履歴の確認
•  CM UI から確認する
•  HDFS --> 設定--> 履歴およびロールバック
•  診断データから確認する
•  診断データ
http://www.cloudera.co.jp/blog/enterprise-support-diagnostics-data.html
http://www.cloudera.co.jp/blog/secrets-of-cloudera-support-impala-and-search-make-the-customer-
experience-even-better.html
•  サブスクリプションご購⼊のお客さまのクラスタから送られてくるクラスタの情報
•  ログ、設定（履歴含む）、ホスト情報、イベント情報などを含む

•  CM UI から確認する
•  HDFS --> 設定--> 履歴およびロールバック
•  診断データから確認する
http://www.cloudera.co.jp/blog/enterprise-support-diagnostics-data.html
•  サブスクリプションご購⼊のお客さまのクラスタから送られてくるクラスタの情報
•  ログ、設定（履歴含む）、ホスト情報、イベント情報などを含む

["configs",0,"groupName"] "hdfs-DATANODE-BASE"
["configs",0,"newValue"] "/data10/dfs/dn,/data11/dfs/dn,/data12/dfs/dn,/data2/dfs/dn,/data3/dfs/dn,/
data4/dfs/dn,/data5/dfs/dn,/data6/dfs/dn,/data7/dfs/dn,/data8/dfs/dn,/data9/dfs/dn,/data1/dfs/dn"
["configs",0,"oldValue"] "/data10/dfs/dn,/data11/dfs/dn,/data12/dfs/dn,/data13/dfs/dn,/data2/dfs/dn,/
["message"] "Role config group 'DataNode Default Group' config update from API."
["userName"] ”user1"
Wednesday October 05, 2016 11:43:52 am

["configs",0,"groupName"] "hdfs-DATANODE-BASE"
["configs",0,"newValue"] "/data10/dfs/dn,/data11/dfs/dn,/data12/dfs/dn,/data2/dfs/dn,/data3/dfs/dn,/
["configs",0,"oldValue"] "/data10/dfs/dn,/data11/dfs/dn,/data12/dfs/dn,/data13/dfs/dn,/data2/dfs/dn,/
["message"] "Role config group 'DataNode Default Group' config update from API."
["userName"] ”user1"
Wednesday October 05, 2016 11:43:52 am

#2 結論
•  当⽇午前にユーザー⾃⾝が実施した設定変更により /data1 が追加
•  その後 /data1 が削除されたため⼀部のブロックがロストと
レポートされた
•  /data1 とその中のブロック⾃⾝は残っていたため実際のデータ
ロストには⾄らなかった
•  ホットスワップではディスクの削除はサポートしていないため
デコミッションして不要なディレクトリ設定を排除するよう案内

最後に ~ 本⽇紹介したドキュメントリンク集1 ~
•  サポート要件
•  ホストインスペクタ
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_mc_host_inspector.html
•  CMが使⽤するポート⼀覧
•  CMアーキテクチャと設定の説明
•  CMが⽣成するログファイル
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ag_view_server_logs.html
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ag_view_agent_logs.html
•  CMが利⽤するデータベース
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ig_installing_configuring_dbs.html
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ig_reqs_space.html

最後に ~ 本⽇紹介したドキュメントリンク集2 ~
•  アップグレード関連
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ag_upgrading_cm.html
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ag_upgrading_os.html
•  チャートの説明
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_dg_chart_time_series_data.html
•  クラウドのリファレンスアーキテクチャ
http://www.cloudera.com/documentation/other/reference-architecture.html
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ag_data_collection.html
•  サポート社内のHadoopクラスタについて
http://www.cloudera.co.jp/blog/quality-assurance-at-cloudera-runningupgrading-to-new-releases-on-our-
own-edh-cluster.html

Thank you

#cwt2016 Cloudera Managerを用いた Hadoop のトラブルシューティング

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie #cwt2016 Cloudera Managerを用いた Hadoop のトラブルシューティング

Ähnlich wie #cwt2016 Cloudera Managerを用いた Hadoop のトラブルシューティング (20)

Mehr von Cloudera Japan

Mehr von Cloudera Japan (10)

#cwt2016 Cloudera Managerを用いた Hadoop のトラブルシューティング