...

講演資料ダウンロード - Cloudera World Tokyo 2016

by user

on
Category: Documents
23

views

Report

Comments

Transcript

講演資料ダウンロード - Cloudera World Tokyo 2016
Cloudera Manager を⽤いた
Hadoop のトラブルシューティング
テクニカルサポートの現場から
Daisuke Kobayashi | Customer Operations Engineer
⾃⼰紹介
•  ⼩林⼤輔 (@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, Inc. All rights reserved.
2
障害対応時に必要な情報
•  どんなログがでているか
•  どのバージョンを使⽤しているか
•  どのような設定で動かしているか
•  発⽣前に変更した設定はあるか
•  いつ、何をしたときに発⽣したか
•  発⽣頻度は?
•  推奨構成となっているか
•  使⽤しているコンポーネントは?
•  これまでにどのような対応を実施したか
© Cloudera, Inc. All rights reserved.
12
障害対応時に必要な情報
•  どんなログがでているか
•  どのバージョンを使⽤しているか
•  どのような設定で動かしているか
•  発⽣前に変更した設定はあるか
•  いつ、何をしたときに発⽣したか
•  発⽣頻度は?
•  推奨構成となっているか
•  使⽤しているコンポーネントは?
•  これまでにどのような対応を実施したか
© Cloudera, Inc. All rights reserved.
13
本講演では
Cloudera Manager (CM) を使って
1.  障害を回避するためにできること
2.  障害が発⽣したときに Cloudera サポートチームが
•  何をみて
•  どのように
•  問題解決しているのか
を紹介します
© Cloudera, Inc. All rights reserved.
14
昨年のセッション
© Cloudera, Inc. All rights reserved.
15
昨年のセッションをベースに講演します
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
© Cloudera, Inc. All rights reserved.
16
トラブルシューティングに先⽴って
必要となる前提知識の確認
©Cloudera, Inc. All rights reserved.
17
サポート要件の確認
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 でそれぞれ独⽴したドライブを⽤意すること
© Cloudera, Inc. All rights reserved.
18
サポート要件の確認
http://www.cloudera.com/documentation/enterprise/release-notes/topics/rn_consolidated_pcm.html
•  ネットワーク要件
•  複数 NIC の利⽤は未サポート
•  ホスト同⼠は FQDN で通信できるよう確認すること
•  ファイアーウォールは無効化すること
© Cloudera, Inc. All rights reserved.
19
ホストインスペクタの定期実⾏
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_mc_host_inspector.html
•  必須要件のチェックが⼊っている
•  ホスト間の名前解決の確認
•  THP や swappiness 設定状況の検知
•  バージョン不整合の検知
かならず全てグリーンにすること
© Cloudera, Inc. All rights reserved.
20
CMが利⽤するポート
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ig_ports_cm.html
注: この他にもコンポーネント間の通信⽤に
ランダムにエフェメラルポートを利⽤
© Cloudera, Inc. All rights reserved.
21
CMが利⽤するポート
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ig_ports_cm.html
• 
• 
CDHのプロセスはすべてsupervisordが管理
CM⾃⾝はHDFSのデータやHiveメタストアの
情報を持たない
© Cloudera, Inc. All rights reserved.
22
CMが⽣成する設定ファイル
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_intro_primer.html
•  クライアント設定
•  /etc/XXX/conf (etc/hadoop/conf, /etc/hive/conf, ...)
•  ネームノードやデータノードなどのサーバープロセスは参照しない
•  サーバーサイド設定
•  CM 経由での再起動時に新たな
ディレクトリが⽣成される
•  ⾃動再起動時は以前のディレクトリを
使⽤
© Cloudera, Inc. All rights reserved.
23
CMが⽣成するログファイル
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ag_view_server_logs.html
•  CM Server
•  /var/log/cloudera-scm-server
•  GUI からも確認可能
© Cloudera, Inc. All rights reserved.
24
CMが⽣成するログファイル
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ag_view_agent_logs.html
•  CM Agent
•  /var/log/cloudera-scm-agent
•  GUI からも確認可能
© Cloudera, Inc. All rights reserved.
25
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 からも確認可能
© Cloudera, Inc. All rights reserved.
26
CMが⽣成するログファイル
•  GUI からも確認可能
© Cloudera, Inc. All rights reserved.
27
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 以上必要
© Cloudera, Inc. All rights reserved.
28
アップグレードにあたって
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 アップグレード
© Cloudera, Inc. All rights reserved.
29
アップグレードにあたって
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ag_upgrading_os.html
•  ホスト OS のアップグレード
•  CM/CDH のアップグレードと同時に⾏う場合は、OS を先に実施すること
•  マイナーアップグレード(推奨)
•  ワーカーノードの OS アップグレードはメンテナンス時間やブロック数に応じて
デコミッションするかしないかの戦略を⽴てる必要がある
© Cloudera, Inc. All rights reserved.
30
チャートの活⽤
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_dg_chart_time_series_data.html
© Cloudera, Inc. All rights reserved.
31
クラウドのリファレンスアーキテクチャ
http://www.cloudera.com/documentation/other/reference-architecture.html
© Cloudera, Inc. All rights reserved.
32
全体から細部へ
http://www.cloudera.co.jp/blog/quality-assurance-at-cloudera-runningupgrading-to-new-releases-on-our-own-edh-cluster.html
© Cloudera, Inc. All rights reserved.
33
全体から細部へ
http://www.cloudera.co.jp/blog/quality-assurance-at-cloudera-runningupgrading-to-new-releases-on-our-own-edh-cluster.html
© Cloudera, Inc. All rights reserved.
34
全体から細部へ
http://www.cloudera.co.jp/blog/quality-assurance-at-cloudera-runningupgrading-to-new-releases-on-our-own-edh-cluster.html
© Cloudera, Inc. All rights reserved.
35
トラブルシューティングの実際
©Cloudera, Inc. All rights reserved.
36
障害の三⼤原因
•  製品バグ
•  ハードウェアの問題
•  ユーザーのオペミス
© Cloudera, Inc. All rights reserved.
37
障害の三⼤原因
•  製品バグ
•  ハードウェアの問題
•  ユーザーのオペミス
© Cloudera, Inc. All rights reserved.
38
#1 ブロック数が急増した原因は?
#1 ブロック数が急増した原因は?
•  事象
•  データノードが OutOfMemoryError で停⽌する事象が頻発
•  データノードが保持するブロック数が100万近くに達したというアラート
•  CM は単⼀データノードが50万以上のブロックを保持しているとアラートを出す
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ht_datanode.html
© Cloudera, Inc. All rights reserved.
40
#1 ブロック数が急増した原因は?
•  事象
•  データノードが OutOfMemoryError で停⽌する事象が頻発
•  データノードが保持するブロック数が100万近くに達したというアラート
•  CM は単⼀データノードが50万以上のブロックを保持しているとアラートを出す
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ht_datanode.html
•  確認事項
•  本当にブロック数が急増していれば OOME は起こり得る
•  いつ増加を始めた?
•  そもそも異常なことなのか?
•  損失したブロックはないか?
© Cloudera, Inc. All rights reserved.
45
#1 ブロック数が急増した原因は?
•  事象
•  データノードが OutOfMemoryError で停⽌する事象が頻発
•  データノードが保持するブロック数が100万近くに達したというアラート
•  CM は単⼀データノードが50万以上のブロックを保持しているとアラートを出す
http://www.cloudera.com/documentation/enterprise/latest/topics/cm_ht_datanode.html
•  確認事項
•  本当にブロック数が急増していれば OOME は起こり得る
•  いつ増加を始めた?
•  そもそも異常なことなのか?
??
•  損失したブロックはないか?
hdfs fsck?
© Cloudera, Inc. All rights reserved.
46
#1 ブロック数はいつ増加し始めたのか
1.  現在のブロック数を確認する
•  ネームノード WebU Iのデータノード⼀覧ページから確認できる
2.  ブロック数の増加傾向を確認する
•  tsquey を投げる?
SELECT blocks_total WHERE entityName rlike "hdfs.*" AND category = SERVICE
•  事前定義されたチャートからも確認できる
•  HDFS --> チャートライブラリ --> Blocks and Files
© Cloudera, Inc. All rights reserved.
47
#1 ブロック数の増加傾向を確認する
•  チャートで表⽰するタイムレンジは柔軟に選択できる
•  ⽉、⽇、時間、分レベルで調整可能
•  今回は「1⽇」「7⽇間」「30⽇間」
の3パターンで取得
© Cloudera, Inc. All rights reserved.
48
1⽇
© Cloudera, Inc. All rights reserved.
49
7⽇間
© Cloudera, Inc. All rights reserved.
50
30⽇間
© Cloudera, Inc. All rights reserved.
51
1⽇
過去24時間で
⼤きな変化は
なし
7⽇間
3⽇前からブロック
数の急増を確認
現在は3倍以上
30⽇間
過去⼀ヶ⽉でみると
今回の増加は
異常にみえる
© Cloudera, Inc. All rights reserved.
53
#1 ブロック数の急増はなぜ起きたか
•  営業チームに連絡が⼊っていないか確認
•  新たなデータソースの追加予定はあったか?
•  クラスタの利⽤⽤途は以前と変わっていないか?
•  ブロック数が増えたことはわかったが、データ量は増えているか?
•  2PB 近いデータが何の予告もなしに投⼊されたとは考えにくい
•  ⼩さいファイルが⼤量投⼊された可能性が⾼い
•  CM からチャートを確認
•  HDFS のサービスページに事前定義されたチャートがある
© Cloudera, Inc. All rights reserved.
54
#1 データ量は増えているか
30⽇間
⼀切増えていない
© Cloudera, Inc. All rights reserved.
56
#1 結論
•  状況のまとめ
•  過去3⽇間の間に 2000万近いブロックが追加された
•  クラスタ全体のデータ量は増えていない
•  損失したブロックはない
•  small files problem が発⽣していることを通知
http://blog.cloudera.com/blog/2009/02/the-small-files-problem/
•  お客さま側でユーザー毎の利⽤状況を確認してもらい、クラスタ
利⽤者が⼤量のファイルを投⼊していたことが判明
© Cloudera, Inc. All rights reserved.
57
#2 70万個のブロックが損失した原因は?
#2 70万個のブロックが損失した理由は?
•  事象
•  データノードのホットスワップ後、70万以上のブロック損失が検知された
© Cloudera, Inc. All rights reserved.
59
#2 ホットスワップについて
http://www.cloudera.com/documentation/enterprise/latest/topics/admin_dn_swap.html
•  データノードでディスク障害が発⽣したとき
•  従来のステップ
データノードをデコミッションして
2.  データノードを停⽌して
3.  ディスクを交換して
4.  データノードを再起動
1. 
© Cloudera, Inc. All rights reserved.
60
#2 ホットスワップについて
http://www.cloudera.com/documentation/enterprise/latest/topics/admin_dn_swap.html
•  データノードでディスク障害が発⽣したとき
•  従来のステップ
データノードをデコミッションして
2.  データノードを停⽌して
3.  ディスクを交換して
4.  データノードを再起動
1. 
ブロックの転送は
ネットワークと
ディスクI/Oを
消費する上
時間がかかる
© Cloudera, Inc. All rights reserved.
61
#2 ホットスワップについて
http://www.cloudera.com/documentation/enterprise/latest/topics/admin_dn_swap.html
•  データノードでディスク障害が発⽣したとき
•  従来のステップ
データノードをデコミッションして
2.  データノードを停⽌して
3.  ディスクを交換して
4.  データノードを再起動
1. 
•  データノードのホットスワップ機能を使うと
1.  対象のディレクトリを削除して
2.  データノードのリフレッシュを実⾏(デコミッションや停⽌が不要)
3.  新たなディスクを追加して
4.  データノードのリフレッシュを実⾏
© Cloudera, Inc. All rights reserved.
62
#2 問題の発⽣状況
•  データノードに2種類の設定グループが存在
デフォルトグループ
dfs.datanode.data.dir に12本のディスク
/data2
/data3
/data4
.
.
.
/data13
カスタムグループ
dfs.datanode.data.dir に12本のディスク
/data1
/data2
/data3
.
.
.
/data12
© Cloudera, Inc. All rights reserved.
63
#2 問題の発⽣状況
•  実際は・・・
•  過去のリフレッシュ時にデフォルトグループのデータノードに /data1 が追加
デフォルトグループ
dfs.datanode.data.dir に12本のディスク
/data1
/data2
/data3
/data4
.
.
/data13
カスタムグループ
dfs.datanode.data.dir に12本のディスク
/data1
/data2
/data3
.
.
.
/data12
© Cloudera, Inc. All rights reserved.
64
#2 問題の発⽣状況
•  リフレッシュ後 /data1 に⼊っていたブロックがMISSING となり
検知された
デフォルトグループ
dfs.datanode.data.dir に12本のディスク
/data1
/data2
/data2
/data3
/data3
refresh後
/data4
/data4
.
.
.
.
/data13
/data13
カスタムグループ
dfs.datanode.data.dir に12本のディスク
/data1
/data2
/data3
.
.
.
/data12
© Cloudera, Inc. All rights reserved.
65
#2 ひとまず問題を解決するために
1.  デフォルトグループのデータノードの設定に /data1 を追加
2.  データノードを⼀台ずつ再起動することでブロックが検知され解消
デフォルトグループ
dfs.datanode.data.dir に12本のディスク
/data1
/data1
/data2
/data2
/data2
/data3
/data3
/data3
/data4
/data4
/data4
.
.
.
.
.
.
/data13
/data13
/data13
カスタムグループ
dfs.datanode.data.dir に12本のディスク
/data1
/data2
/data3
.
.
.
/data12
© Cloudera, Inc. All rights reserved.
66
#2 なぜこんな問題が起きたのか?
•  発⽣タイミングの特定
•  何を⾒るか
1.  データノードログ
2.  CM Server ログ
--> CM で実施するほぼすべてのオペレーションはログに記録される
3.  CM Agent ログ
--> ディレクトリの作成、権限設定は Agent の仕事なのでログに記録される
4.  設定履歴 (
のみ)
--> いつ、誰が、何を変更したのか記録されている
© Cloudera, Inc. All rights reserved.
67
#2 データノードログの確認
•  ディレクトリ名で grep して特定
/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/
© Cloudera, Inc. All rights reserved.
68
#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/
© Cloudera, Inc. All rights reserved.
69
#2 CM Serverログの確認
•  ディレクトリ名で grep して特定
/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}
© Cloudera, Inc. All rights reserved.
70
#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}
© Cloudera, Inc. All rights reserved.
71
#2 CM Agentログの確認
•  ディレクトリ名で grep して特定
/var/log/cloudera-scm-agent/cloudera-scm-agent.log
[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
© Cloudera, Inc. All rights reserved.
72
#2 CM Agentログの確認
•  CM Server からの命令をうけて CM Agent がディレクトリを⽤意
/var/log/cloudera-scm-agent/cloudera-scm-agent.log
[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
•  Agent が作成したディレクトリを使⽤してデータノードは
ブロックを書き込む
© Cloudera, Inc. All rights reserved.
73
#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-customerexperience-even-better.html
•  サブスクリプションご購⼊のお客さまのクラスタから送られてくるクラスタの情報
•  ログ、設定(履歴含む)、ホスト情報、イベント情報などを含む
© Cloudera, Inc. All rights reserved.
74
#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-customerexperience-even-better.html
•  サブスクリプションご購⼊のお客さまのクラスタから送られてくるクラスタの情報
•  ログ、設定(履歴含む)、ホスト情報、イベント情報などを含む
© Cloudera, Inc. All rights reserved.
75
#2 設定変更履歴の確認
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,/
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"
© Cloudera, Inc. All rights reserved.
76
#2 設定変更履歴の確認
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,/
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"
© Cloudera, Inc. All rights reserved.
77
#2 結論
•  当⽇午前にユーザー⾃⾝が実施した設定変更により /data1 が追加
•  その後 /data1 が削除されたため⼀部のブロックがロストと
レポートされた
•  /data1 とその中のブロック⾃⾝は残っていたため実際のデータ
ロストには⾄らなかった
•  ホットスワップではディスクの削除はサポートしていないため
デコミッションして不要なディレクトリ設定を排除するよう案内
http://www.cloudera.com/documentation/enterprise/latest/topics/admin_dn_swap.html
© Cloudera, Inc. All rights reserved.
78
最後に ~ 本⽇紹介したドキュメントリンク集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
© Cloudera, Inc. All rights reserved.
79
最後に ~ 本⽇紹介したドキュメントリンク集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
http://www.cloudera.co.jp/blog/secrets-of-cloudera-support-impala-and-search-make-the-customerexperience-even-better.html
•  サポート社内のHadoopクラスタについて
http://www.cloudera.co.jp/blog/quality-assurance-at-cloudera-runningupgrading-to-new-releases-on-ourown-edh-cluster.html
© Cloudera, Inc. All rights reserved.
80
Thank you
© Cloudera, Inc. All rights reserved.
81
Fly UP