Troubleshooting Using Cloudera Manager #cwt2015

Troubleshootingusing Cloudera Managerテクニカルサポートの現場から

Daisuke Kobayashi | Customer Operations Engineer

2 © Cloudera, Inc. All rights reserved.

⾃⼰紹介•  ⼩林⼤輔 (@d1ce_)•  Cloudera⼊社四年⽬•  カスタマーオペレーションズエンジニア == テクニカルサポート•  本番環境でHadoopクラスタを運⽤するお客様のトラブルシューティングのお

⼿伝い•  コンポーネントはいろいろ

•  HDFS/HBase•  Security•  Cloudera Manager•  etc


アジェンダ•  Hadoopサポートの歴史•  トラブルシューティングを⽀えるCloudera Managerの紹介•  実例から学ぶトラブルシューティングのフロー•  Cloudera Manager Tips

8 ©Cloudera, Inc. All rights reserved.

Hadoopサポートの歴史 at Clouderav0.0 >> v0.5 >> v1.0 >> v2.0!


Hadoopサポートの歴史 v0.0•  2008~2010年頃•  管理ツールなし•  ログや設定は⼿動取得 / コンソールで直接確認•  未知の問題ばかりで根本原因も不明•  環境依存の問題が多い•  ドキュメント不⾜


Hadoopサポートの歴史 v0.5•  2011年頃•  Cloudera Manager が登場•  バージョン3.5•  バグだらけ

•  画⾯共有ツール•  サポートチームの規模•  4~10⼈


Hadoopサポートの歴史 v1.0•  2012年頃•  Cloudera Manager 4 の登場•  グラフの⽣成が安定するようになった•  ホストインスペクタによる⾃動診断

•  サポートチームの規模•  ~30⼈


Hadoopサポートの歴史 v2.0•  2014年以降•  Cloudera Manager 5 の登場•  多数のフィードバックを反映

•  お客様•  コンサルティングチーム•  サポートチーム•  開発チーム

•  チャート機能の改善•  スタックトレースやヒープダンプの取得•  ホストインスペクタによる豊富な診断•  ドキュメントが充実


Hadoopサポートの歴史 v2.0•  サポートチームの規模•  100⼈以上•  世界中のお客様を世界中のチームでカバー

ブダペストミュンヘン

ロンドン

チェンナイ

上海東京

メルボルン

サンパウロ

ローリーニューヨークボストン

オースティン

デンバーフェニックスサンフランシスコ

パロアルト

シアトル


Cloudera Managerお客様のトラブルシューティングを⽀える強⼒な道具


Cloudera Manager is ...•  Hadoopクラスタを構築(インストール)運⽤するためのGUIツール•  設定の⼀括管理、クラスタの診断、チャートなど豊富な機能•  クラスタ管理者の運⽤負荷を軽減するためのツール


Cloudera Manager is ...•  CLIツールではない•  起動停⽌、アップグレードはすべてGUIからの操作 (REST APIはある)•  内部で実⾏されているコマンドは確認可能

•  クエリ実⾏やワークフロー管理ツールではない•  スレッドダンプやヒープダンプを解析してくれるツールではない•  取得はGUIから可能


Hadoopクラスタのトラブルシューティング戦略は全体から細部へ...


全体から細部へ


1. HDFSのヘルスアラート•  シナリオ•  HDFSのヘルスチェックで深刻(Critical)なアラートメールを受信

•  ヘルスチェックのメッセージから原因を辿るフローを説明します


1. HDFSのヘルスアラート



•  チェックポイントが14時間も⾛っていない

•  デフォルトは1時間



スタンバイネームノードのプロセスが

停⽌していた


2. HBaseのトラブルシューティング•  シナリオ•  Cloudera Managerをチェックしたら、HBaseのヘルスチェックが⾚くなって

いた•  Long GCによる停⽌であることを特定するまでのフロー


2. HBaseのトラブルシューティング



リージョンサーバプロセス停⽌時のログ(最後の数⾏)

停⽌時刻は午後4時38分頃



Stderrはプロセス起動までに読み込んだ環境変数や実際に実⾏されたコマンドが出⼒さ

れる



リージョンサーバ起動コマンド



プロセスが停⽌されていることはわかるが

原因は不明



標準出⼒



•  原因を特定するため、リージョンサーバのログを遡る必要がある•  停⽌時にFATALレベルのメッセージが出ることが多い


2. HBaseのトラブルシューティングFATALレベルのログのみ抽出

停⽌の2分前に初めて出たもの



付近のログを表⽰する



•  停⽌直前に400秒ものLong GCが発⽣していた可能性


2. HBaseのトラブルシューティング•  Cloudera Manager で特定できるのはここまで•  ログを解析し、原因究明をするのはサポートの仕事•  ログはローカルにダウンロードできる


2. HBaseのトラブルシューティング•  典型的な例•  フラグメンテーション解消のためのFull GC

•  GCログには promotion failure というメッセージが出⼒•  ホットスポットの発⽣や過剰なSCAN処理が影響しているケースが多い•  参考: HBaseサポート最前線 http://www.slideshare.net/Cloudera_jp/hbase-hbaseca


もっと複雑なケース...すべてのケースで根本原因まできれいにたどり着けるわけではない


3. ジョブのパフォーマンスボトルネックの特定•  シナリオ•  ジョブのパフォーマンスが著しく悪い•  100近くのジョブが10時間以上RUNNINGのまま停滞•  400以上のジョブがSCHEDULEDのまま実⾏されない•  2-3⽇継続して発⽣している

•  Cloudera Managerのチャート機能で切り分けを⾏った例を紹介


3. ジョブのパフォーマンスボトルネックの特定•  チャートとは•  メトリクスの経時変化をグラフ化して表⽰•  任意のタイムスケールを設定することで

チャートの範囲を前後に移動および拡⼤縮⼩して負荷状況などの確認が可能

•  独⾃⾔語 (tsquery:time series query)を⽤いてカスタムチャートを作成可能


3. ジョブのパフォーマンスボトルネックの特定1.  ログの精査•  ResourceManager / NodeManager のログにはエラーが未出⼒•  ContainerログからHDFS I/O待ちであることを確認

2.  コマンドラインから確認•  1GB の dfs -put が3分経っても完了しない

•  複製数を1に指定すると成功•  複製数がデフォルトの3だと極端に遅い

•  最近追加したデータノードが別ラックに存在•  rack awarenessが未設定

>> 原因はHDFSレイヤ以下にある


3. ジョブのパフォーマンスボトルネックの特定1.  ログの精査•  データノードのログにはエラーなし•  JVMの負荷による影響もなし

•  負荷発⽣時の例JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 1657ms ....

2.  設定の精査•  ネームノード/データノードのスレッド数は⼗分•  推奨値から⼤幅に逸脱していない

>> データノードのメトリクスを確認


3. ジョブのパフォーマンスボトルネックの特定

画⾯ショットは取得までのイメージ (お客様環境のものではありません)



DataNodes間のパケットラウンドトリップタイム (RTT) を確認




ジョブの遅延が⾒られた頃からDN全体でRTT平均時間の上昇を確認



カスタムチャートを作成




候補を補完




すべてのデータノードでRTTが極端に悪化していることを確認


3. ジョブのパフォーマンスボトルネックの特定•  原因•  ネットワーク側に問題がありブロック転送に⼤幅な遅延が発⽣•  タスクが完了するまでに時間がかかり、ジョブ⾃体の停滞を招いていた


Cloudera Manager Tips運⽤上知っておくべきこと


1. サービスとロールの区別•  サービス•  HDFS, YARN, HBase, ...•  Apacheプロジェクト名とほぼ⼀致

•  ロール•  NameNode, DataNode, NodeManager, ...•  サービスを構成するプロセス

•  表⽰されるメニューが違うので注意


1. サービスとロールの区別サービスメニュー (HDFS)


1. サービスとロールの区別ロールメニュー (NameNode)


2. サーバ設定とクライアント設定•  サーバ設定•  NameNode や DataNode などのロールが起動時に読み込む設定•  起動後に動的に変更することはできない (再起動が必要)•  /var/run/cloudera-scm-agent/process 以下に配布される

•  クライアント設定•  hdfs dfs や hbase shell、beeline などユーザが実⾏するコマンド起動時に

読み込む設定•  基本的には /etc/XXX/conf 以下に配布される


3. Auto Configuration•  Cloudera Manager はクラスタの構成に応じて⾃動的に設定を調整•  ヒープサイズやスレッド数など

•  詳しいロジックは下記ドキュメントを参照

http://www.cloudera.com/content/www/en-us/documentation/enterprise/latest/topics/cm_mc_autoconfig.html


まとめ•  トラブルシューティングの戦略は全体から細部へ•  Cloudera Manager はトラブルシューティングの強⼒なツール•  が⾒つかっても焦らずにドリルダウンして対応しましょう


最後に•  Clouderaでは毎⽉Cloudera Manager勉強会を開催しています興味のある⽅は [email protected] までご連絡ください•  もっと基本的な使い⽅から知りたい⽅•  もっと幅広く機能を知りたい⽅

•  Cloudera Managerのダウンロードはこちらから (無料)http://www.cloudera.com/content/www/en-us/downloads.html


エンタープライズセールス⼤規模システムに関わる営業ができる⼈歓迎

セールスエンジニア技術の価値を伝えることに興味がある⼈歓迎

We are hiring!

[email protected]


Thank you

Troubleshooting Using Cloudera Manager #cwt2015

Technology

Transcript of Troubleshooting Using Cloudera Manager #cwt2015