#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 でそれぞれ独⽴したドライブを⽤意すること


サポート要件の確認http://www.cloudera.com/documentation/enterprise/release-notes/topics/rn_consolidated_pcm.html

•  ネットワーク要件•  複数 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が利⽤するポートhttp://www.cloudera.com/documentation/enterprise/latest/topics/cm_ig_ports_cm.html

•  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 からも確認可能


CMが⽣成するログファイルhttp://www.cloudera.com/documentation/enterprise/latest/topics/cm_ag_view_agent_logs.html

•  CM Agent•  /var/log/cloudera-scm-agent •  GUI からも確認可能


CMが⽣成するログファイルhttp://www.cloudera.com/documentation/enterprise/latest/topics/cm_intro_primer.html

CDH プロセスの実⾏コマンドログ •  NameNode の例

•  /var/run/cloudera-scm-agent/process/xx-hdfs-NAMENODE/logs

•  何が出⼒されているか•  プロセス起動にあたり読み込んだ環境変数と実⾏コマンド•  OutOfMemoryError 発⽣時のログ

•  GUI からも確認可能


CMが⽣成するログファイル•  GUI からも確認可能


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 ブロック数が急増した原因は？


#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 files 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

デフォルトグループ


カスタムグループ


#2 問題の発⽣状況•  実際は・・・•  過去のリフレッシュ時にデフォルトグループのデータノードに /data1 が追加

dfs.datanode.data.dir に12本のディスク/data1 /data2 /data3 /data4 . . /data13





#2 問題の発⽣状況•  リフレッシュ後 /data1 に⼊っていたブロックがMISSING となり検知された

dfs.datanode.data.dir に12本のディスク/data1 /data2 /data2 /data3 /data3 /data4 /data4 . . . . /data13 /data13




refresh後


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

dfs.datanode.data.dir に12本のディスク/data1 /data1 /data2 /data2 /data2 /data3 /data3 /data3 /data4 /data4 /data4 . . . . . . /data13 /data13 /data13





#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:///data10/dfs/dn,file:///data11/dfs/dn,file:///data12/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,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:///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,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:///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:///data10/dfs/dn,file:///data11/dfs/dn,file:///data12/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,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:///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,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ログの確認•  ディレクトリ名で grep して特定

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ログの確認•  ディレクトリ名で grep して特定

[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

•  サブスクリプションご購⼊のお客さまのクラスタから送られてくるクラスタの情報•  ログ、設定（履歴含む）、ホスト情報、イベント情報などを含む


#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

•  サブスクリプションご購⼊のお客さまのクラスタから送られてくるクラスタの情報•  ログ、設定（履歴含む）、ホスト情報、イベント情報などを含む


#2 設定変更履歴の確認

["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,/data3/dfs/dn,/data4/dfs/dn,/data5/dfs/dn,/data6/dfs/dn,/data7/dfs/dn,/data8/dfs/dn,/data9/dfs/dn" ["message"] "Role config group 'DataNode Default Group' config update from API." ["userName"] ”user1"

Wednesday October 05, 2016 11:43:52 am


#2 設定変更履歴の確認

["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,/data3/dfs/dn,/data4/dfs/dn,/data5/dfs/dn,/data6/dfs/dn,/data7/dfs/dn,/data8/dfs/dn,/data9/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 とその中のブロック⾃⾝は残っていたため実際のデータロストには⾄らなかった

•  ホットスワップではディスクの削除はサポートしていないためデコミッションして不要なディレクトリ設定を排除するよう案内http://www.cloudera.com/documentation/enterprise/latest/topics/admin_dn_swap.html


最後に ~ 本⽇紹介したドキュメントリンク集1 ~•  サポート要件

http://www.cloudera.com/documentation/enterprise/release-notes/topics/rn_consolidated_pcm.html

•  ホストインスペクタhttp://www.cloudera.com/documentation/enterprise/latest/topics/cm_mc_host_inspector.html

•  CMが使⽤するポート⼀覧http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ig_ports_cm.html

•  CMアーキテクチャと設定の説明http://www.cloudera.com/documentation/enterprise/latest/topics/cm_intro_primer.html

•  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 http://www.cloudera.com/documentation/enterprise/latest/topics/cm_intro_primer.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.htmlhttp://www.cloudera.co.jp/blog/secrets-of-cloudera-support-impala-and-search-make-the-customer-experience-even-better.html

•  サポート社内のHadoopクラスタについてhttp://www.cloudera.co.jp/blog/quality-assurance-at-cloudera-runningupgrading-to-new-releases-on-our-own-edh-cluster.html


Thank you

Data & Analytics

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