HBaseサポート最前線
HBase徹底入門刊行記念セミナー
Daisuke Kobayashi | Customer Operations Engineer
2© 2014 Cloudera, Inc. All rights reserved.
自己紹介
• 小林大輔
• 2012年入社
• カスタマーオペレーションズエンジニア
• いわゆるカスタマーサポート
• 日本国内のすべてのお客様、海外のお客様(24x7)のトラブルシューティングの
お手伝い
• 担当製品: HDFS, HBase, Cloudera Manager, Security, Solr etc.
• email: daisuke@cloudera.com
• twitter: d1ce_
3© 2014 Cloudera, Inc. All rights reserved.
今日話すこと
• ClouderaサポートとHBase
• クラスタ構築時の注意点
• HBaseトラブルシューティング例
(特に断りがない限り、CDH5.2.1をベースに話します)
4© 2014 Cloudera and/or its affiliates. All rights reserved.
ClouderaサポートとHBase
5© 2014 Cloudera, Inc. All rights reserved.
2010年からHBaseの製品サ
ポートを開始。トラブル
シューティングから機能改善
まで多くの対応を行ってきた
HBaseはスケールアウトする。
お客様のビジネスの発展によ
り、総サポートノード数も増
加中
サポートを購入したお客様の
半数以上が利用。国内でも金
融、製造業、ゲーム業界のお
客様をサポート
HBaseサポートは5年目 総サポートノード数 HBaseの使用率
5年 20000ノー
ド
60%
ClouderaサポートとHBase
6© 2014 Cloudera, Inc. All rights reserved.
CSI
全文検索
システム
スタックトレース
検索システム
ClouderaサポートとHBase
• Clouderaでは社内サポートシステムにHBaseを採用
参考: https://blog.cloudera.com/blog/2012/12/secrets-of-cloudera-support-the-champagne-strategy/
7© 2014 Cloudera, Inc. All rights reserved.
CSI
全文検索
システム
スタックトレース
検索システム
ClouderaサポートとHBase
• サポートエンジニアはまずCSIからクラスタの全体像を把握する
8© 2014 Cloudera, Inc. All rights reserved.
CSI
全文検索
システム
スタックトレース
検索システム
ClouderaサポートとHBase
• 過去事例は調査における貴重な資源
参考: http://blog.cloudera.com/blog/2013/09/secrets-of-cloudera-support-impala-and-search-make-the-customer-experience-even-better/
9© 2014 Cloudera, Inc. All rights reserved.
CSI
全文検索
システム
スタックトレース
検索システム
ClouderaサポートとHBase
• 類似のスタックトレースを検索できる仕組みもある
参考: http://blog.cloudera.com/blog/2014/02/secrets-of-cloudera-support-inside-our-own-enterprise-data-hub/
10© 2014 Cloudera and/or its affiliates. All rights reserved.
クラスタ構築時の注意点
11© 2014 Cloudera, Inc. All rights reserved.
クラスタ構築時の注意点
• THP(Transparent Huge Page)は無効にする
• 有効になっていると深刻なパフォーマンス劣化を招きます [1]
• リージョン数の見積もり、モニタリングは慎重に
• リージョンが多すぎるとMTTR (Mean Time to Recovery: 平均修復時間)の増加、
パフォーマンス劣化につながります
• HBase徹底入門を読みましょう
• 2015/01時点で最新の情報が網羅されている
• 実際の構築経験をベースに執筆されている
[1] http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/cdh_admin_performance.html を確認
12© 2014 Cloudera, Inc. All rights reserved.
適切なリージョン数の見積もり
リージョンサーバヒープサイズ 10GB
フラッシュサイズ (hbase.hregion.memstore.flush.size) 128MB
Memstoreサイズ (hbase.regionserver.global.memstore.upperLimit) 0.4  4GB
Memstoreサイズ (4GB) / フラッシュサイズ (128MB)
• Memstoreサイズと書き込み量から見積もる
13© 2014 Cloudera, Inc. All rights reserved.
適切なリージョン数の見積もり
リージョンサーバヒープサイズ 10GB
フラッシュサイズ (hbase.hregion.memstore.flush.size) 128MB
Memstoreサイズ (hbase.regionserver.global.memstore.upperLimit) 0.4  4GB
Memstoreサイズ (4GB) / フラッシュサイズ (128MB)
= サーバあたりのリージョン数 (32)
• Memstoreサイズと書き込み量から見積もる
14© 2014 Cloudera, Inc. All rights reserved.
適切なリージョン数の見積もり
((全データ量 * 1024) / リージョンサイズ (10GB)) / リージョンサーバ数 (100台)
全データ量 50TB
リージョンサイズ (hbase.hregion.max.filesize) 10GB
リージョンサーバ数 100
• 全データ量とリージョンサーバ数から見積もる
15© 2014 Cloudera, Inc. All rights reserved.
適切なリージョン数の見積もり
((全データ量 * 1024) / リージョンサイズ (10GB)) / リージョンサーバ数 (100台)
= サーバあたりのリージョン数 (102)
全データ量 50TB
リージョンサイズ (hbase.hregion.max.filesize) 10GB
リージョンサーバ数 100
• 全データ量とリージョンサーバ数から見積もる
16© 2014 Cloudera, Inc. All rights reserved.
リージョンスプリットポリシー
• ConstantSizeRegionSplitPolicy
• CDH4.1 (0.92) までのスプリットポリシー
• 一定のサイズに達したリージョンを分割
• IncreasingToUpperBoundRegionSplitPolicy
• CDH4.2 (0.94) 以降でデフォルトのスプリットポリシー
• 以下の条件を比較し、小さい方を上限として採用
1. リージョン数 (同一サーバ上、同一テーブル内) ^ 3 ([2]) * フラッシュサイズ * 2
2. hbase.hregion.max.filesizeの設定値
• リージョンをクラスタ全体へ分散し、パフォーマンスの向上を図ることが目的
• ローリング再起動 (デコミッション) 時にリージョン数が増加する場合あり [3]
[2] CDH5.0以前、5.1以降で算出式が変更されているので注意。詳しくはHBASE-10501
[3] 一時的にリージョン数が減ることが原因。詳しくはHBASE-12451
17© 2014 Cloudera, Inc. All rights reserved.
リージョンスプリットポリシー
• ConstantSizeRegionSplitPolicy
• CDH4.1 (0.92) までのスプリットポリシー
• 一定のサイズに達したリージョンを分割
• IncreasingToUpperBoundRegionSplitPolicy
• CDH4.2 (0.94) 以降でデフォルトのスプリットポリシー
• 以下の条件を比較し、小さい方を上限として採用
1. リージョン数 (同一サーバ上、同一テーブル内) ^ 3 ([2]) * フラッシュサイズ * 2
2. hbase.hregion.max.filesizeの設定値
• リージョンをクラスタ全体へ分散し、パフォーマンスの向上を図ることが目的
• ローリング再起動 (デコミッション) 時にリージョン数が増加する場合あり [3]
[2] CDH5.0以前、5.1以降で算出式が変更されているので注意。詳しくはHBASE-10501
[3] 一時的にリージョン数が減ることが原因。詳しくはHBASE-12451
18© 2014 Cloudera, Inc. All rights reserved.
リージョンスプリットポリシー
• ConstantSizeRegionSplitPolicy
• CDH4.1 (0.92) までのスプリットポリシー
• 一定のサイズに達したリージョンを分割
• IncreasingToUpperBoundRegionSplitPolicy
• CDH4.2 (0.94) 以降でデフォルトのスプリットポリシー
• 以下の条件を比較し、小さい方を上限として採用
1. リージョン数 (同一サーバ上、同一テーブル内) ^ 3 ([2]) * フラッシュサイズ * 2
2. hbase.hregion.max.filesizeの設定値
• リージョンをクラスタ全体へ分散し、パフォーマンスの向上を図ることが目的
• ローリング再起動 (デコミッション) 時にリージョン数が増加する場合あり [3]
[2] CDH5.0以前、5.1以降で算出式が変更されているので注意。詳しくはHBASE-10501
[3] 一時的にリージョン数が減ることが原因。詳しくはHBASE-12451
19© 2014 Cloudera and/or its affiliates. All rights reserved.
HBaseクラスタのトラブルシューティング
20© 2014 Cloudera, Inc. All rights reserved.
トラブルシューティング
• HBaseクラスタにおけるトラブルの種類
1. リージョン不整合
処理中に突然サーバの電源が落ち、メタ情報に食い違いが生じたなど
2. 高負荷時のGC
特に書き込み過多の場合はGCチューニングが必要となる
3. ホットスポット
21© 2014 Cloudera, Inc. All rights reserved.
トラブルシューティング
• HBaseクラスタにおけるトラブルの種類
1. リージョン不整合
処理中に突然サーバの電源が落ち、メタ情報に食い違いが生じたなど
2. 高負荷時のGC
特に書き込み過多の場合はGCチューニングが必要となる
3. ホットスポット
22© 2014 Cloudera, Inc. All rights reserved.
トラブルシューティング(1)
• リージョン不整合の検知
• hbckユーティリティ [1]
• hbck -details > /tmp/hbase-`date`.txt
• 主に以下の検査を行う
1. Region Consistency (一貫性)
• META、HDFS内の.regioninfo、実際のリージョンアサイン状況がすべて合致しているか
2. Integrity (整合性)
• 複数のリージョンでキーの範囲が重複していないか
• キーの順序が後退していないか
• リージョン間に穴が空いていないか
• 最後に表示される不整合件数が0であればOK
0 inconsistencies detected
[1] 詳細は http://hbase.apache.org/book.html#hbck.in.depth
23© 2014 Cloudera, Inc. All rights reserved.
トラブルシューティング(1)
• まずはRegion Consistencyの確認、修復を行う
• 不整合の例
1. Region X, key=Y, not on HDFS or in hbase:meta but deployed on Z
キーYで始まるリージョンXがHDFS/META上に存在しないにも関わらず
リージョンサーバZにアサインされている
2. Region X on HDFS, but not listed in hbase:meta or deployed on any
region server
リージョンXはHDFSに存在するが、METAになくどのリージョンサーバにも
アサインされていない
3. Region X should not be deployed according to META, but is deployed
on Z
METAの情報によるとリージョンXはアサインされるべきではないが、リー
ジョンサーバZにデプロイされている
24© 2014 Cloudera, Inc. All rights reserved.
トラブルシューティング(1)
• 修復コマンド
• hbck –fixAssignments -fixMeta
• 実行前に直前の状況をファイルに出力しておくこと
• 実行後は再度 hbck -details を実行してアサインの不整合が修復され
ているか確認する
注意: 0.90時代の -fix オプションは -fixAssignments に置き換えられま
した。後方互換性のためオプションとしては残っていますが、後者を
利用すること。
25© 2014 Cloudera, Inc. All rights reserved.
トラブルシューティング(1)
• Integrityの確認、修復
• 不整合の例
ERROR ... Multiple regions have the same startkey
複数のリージョンが同じ開始キーを持っている
• 修復コマンド
• hbase hbck -repairHoles
注意: hbckには他にもオプションがありますが、HDFSの内容を操作
するオプションも含まれます。動作を把握しない状況で使用するのは
危険です
26© 2014 Cloudera, Inc. All rights reserved.
トラブルシューティング(2)
• Garbage Collection
• リージョンサーバは高負荷時にGCの影響を受けやすい
• GCによる影響を疑うときのキーワード: slept
• 詳細発生時刻付近に以下のメッセージが出力されていないか確認する
1. We slept 67160ms instead of 3000ms, this is likely due to a long garbage collecting pause
and it's usually bad
2. Detected pause in JVM or host machine (eg GC): pause of approximately 62182ms
GC pool 'ParNew' had collection(s): count=3 time=69ms
GC pool 'ConcurrentMarkSweep' had collection(s): count=2 time=62425ms
• old世代のGCに60秒以上かかっている
• GCログから詳細を確認する
27© 2014 Cloudera, Inc. All rights reserved.
トラブルシューティング(2)
• 下記オプションを追加することでより詳細なログを出力
-XX:+PrintPromotionFailure (promotion failedの詳細出力)
-XX:PrintFLSStatistics=1 (連続領域の最大サイズなど詳細を出力)
-XX:+PrintTenuringDistribution (new領域のオブジェクトの遷移を出力)
• 典型的なFull GC発生のシナリオ
• promotion failed
old領域に十分な連続領域が確保できず、new領域からのオブジェクトの移動に
失敗した(断片化が原因)
• concurrent mode failure
old世代の回収が間に合わず、空き領域が不足していると判断された
参考資料:
http://shop.oreilly.com/product/0636920028499.do
http://blog.cloudera.com/blog/2011/02/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-1/
28© 2014 Cloudera, Inc. All rights reserved.
promotion failed
new
generation
old
generation
29© 2014 Cloudera, Inc. All rights reserved.
promotion failed
new
generation
old
generation
new世代のGC (Stop-the-World)
30© 2014 Cloudera, Inc. All rights reserved.
promotion failed
new
generation
old
generation
new世代のGC後
31© 2014 Cloudera, Inc. All rights reserved.
promotion failed
new
generation
old
generation
new世代のGC (Stop-the-World)、old世代のGC (アプリケーションと並行)を繰り返す
32© 2014 Cloudera, Inc. All rights reserved.
promotion failed
new
generation
old
generation
new世代のGC (Stop-the-World)、old世代のGC (アプリケーションと並行)を繰り返す
33© 2014 Cloudera, Inc. All rights reserved.
promotion failed
書き込み負荷が高まり、Memstoreのフラッシュが多発
34© 2014 Cloudera, Inc. All rights reserved.
promotion failed
オブジェクトの移動 (promotion) に失敗 (failed)
35© 2014 Cloudera, Inc. All rights reserved.
promotion failed
• CMSはオブジェクトのマージ(コンパクション)
を行わないため、断片化が発生する
• new世代からのオブジェクトを配置できる連続
領域がなくなる
• 全アプリケーションスレッドを止めFull GCが
発生する
36© 2014 Cloudera, Inc. All rights reserved.
promotion failed対策
• グラフ化
• x軸: 時刻
• y軸: GB
• 赤: 空き領域
(free space)
• 青: 最大連続領域
(max chunk)
• old世代の空き領域は6GB程度確保
• 連続領域(max chunk)は1GB強で推移
37© 2014 Cloudera, Inc. All rights reserved.
promotion failed対策
• グラフ化
• x軸: 時刻
• y軸: GB
• 赤: 空き領域
(free space)
• 青: 最大連続領域
(max chunk)
• max chunkが急減したタイミングでpromotion
failedが発生し、リージョンサーバが停止
38© 2014 Cloudera, Inc. All rights reserved.
promotion failed対策
1. GCログからmax chunkサイズの推移状況を確認
2. 障害発生時に残っていたchunk分では足りなかった
• 今回のケースでは1GBほど
3. ヒープサイズを1GB-2GB増やし、再度経過観察を行う
39© 2014 Cloudera, Inc. All rights reserved.
Cloudera Managerのチャート機能
40© 2014 Cloudera, Inc. All rights reserved.
まとめ
41© 2014 Cloudera, Inc. All rights reserved.
まとめ 祝!
42© 2014 Cloudera, Inc. All rights reserved.
Thank you

HBaseサポート最前線 #hbase_ca

  • 1.
  • 2.
    2© 2014 Cloudera,Inc. All rights reserved. 自己紹介 • 小林大輔 • 2012年入社 • カスタマーオペレーションズエンジニア • いわゆるカスタマーサポート • 日本国内のすべてのお客様、海外のお客様(24x7)のトラブルシューティングの お手伝い • 担当製品: HDFS, HBase, Cloudera Manager, Security, Solr etc. • email: daisuke@cloudera.com • twitter: d1ce_
  • 3.
    3© 2014 Cloudera,Inc. All rights reserved. 今日話すこと • ClouderaサポートとHBase • クラスタ構築時の注意点 • HBaseトラブルシューティング例 (特に断りがない限り、CDH5.2.1をベースに話します)
  • 4.
    4© 2014 Clouderaand/or its affiliates. All rights reserved. ClouderaサポートとHBase
  • 5.
    5© 2014 Cloudera,Inc. All rights reserved. 2010年からHBaseの製品サ ポートを開始。トラブル シューティングから機能改善 まで多くの対応を行ってきた HBaseはスケールアウトする。 お客様のビジネスの発展によ り、総サポートノード数も増 加中 サポートを購入したお客様の 半数以上が利用。国内でも金 融、製造業、ゲーム業界のお 客様をサポート HBaseサポートは5年目 総サポートノード数 HBaseの使用率 5年 20000ノー ド 60% ClouderaサポートとHBase
  • 6.
    6© 2014 Cloudera,Inc. All rights reserved. CSI 全文検索 システム スタックトレース 検索システム ClouderaサポートとHBase • Clouderaでは社内サポートシステムにHBaseを採用 参考: https://blog.cloudera.com/blog/2012/12/secrets-of-cloudera-support-the-champagne-strategy/
  • 7.
    7© 2014 Cloudera,Inc. All rights reserved. CSI 全文検索 システム スタックトレース 検索システム ClouderaサポートとHBase • サポートエンジニアはまずCSIからクラスタの全体像を把握する
  • 8.
    8© 2014 Cloudera,Inc. All rights reserved. CSI 全文検索 システム スタックトレース 検索システム ClouderaサポートとHBase • 過去事例は調査における貴重な資源 参考: http://blog.cloudera.com/blog/2013/09/secrets-of-cloudera-support-impala-and-search-make-the-customer-experience-even-better/
  • 9.
    9© 2014 Cloudera,Inc. All rights reserved. CSI 全文検索 システム スタックトレース 検索システム ClouderaサポートとHBase • 類似のスタックトレースを検索できる仕組みもある 参考: http://blog.cloudera.com/blog/2014/02/secrets-of-cloudera-support-inside-our-own-enterprise-data-hub/
  • 10.
    10© 2014 Clouderaand/or its affiliates. All rights reserved. クラスタ構築時の注意点
  • 11.
    11© 2014 Cloudera,Inc. All rights reserved. クラスタ構築時の注意点 • THP(Transparent Huge Page)は無効にする • 有効になっていると深刻なパフォーマンス劣化を招きます [1] • リージョン数の見積もり、モニタリングは慎重に • リージョンが多すぎるとMTTR (Mean Time to Recovery: 平均修復時間)の増加、 パフォーマンス劣化につながります • HBase徹底入門を読みましょう • 2015/01時点で最新の情報が網羅されている • 実際の構築経験をベースに執筆されている [1] http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/cdh_admin_performance.html を確認
  • 12.
    12© 2014 Cloudera,Inc. All rights reserved. 適切なリージョン数の見積もり リージョンサーバヒープサイズ 10GB フラッシュサイズ (hbase.hregion.memstore.flush.size) 128MB Memstoreサイズ (hbase.regionserver.global.memstore.upperLimit) 0.4  4GB Memstoreサイズ (4GB) / フラッシュサイズ (128MB) • Memstoreサイズと書き込み量から見積もる
  • 13.
    13© 2014 Cloudera,Inc. All rights reserved. 適切なリージョン数の見積もり リージョンサーバヒープサイズ 10GB フラッシュサイズ (hbase.hregion.memstore.flush.size) 128MB Memstoreサイズ (hbase.regionserver.global.memstore.upperLimit) 0.4  4GB Memstoreサイズ (4GB) / フラッシュサイズ (128MB) = サーバあたりのリージョン数 (32) • Memstoreサイズと書き込み量から見積もる
  • 14.
    14© 2014 Cloudera,Inc. All rights reserved. 適切なリージョン数の見積もり ((全データ量 * 1024) / リージョンサイズ (10GB)) / リージョンサーバ数 (100台) 全データ量 50TB リージョンサイズ (hbase.hregion.max.filesize) 10GB リージョンサーバ数 100 • 全データ量とリージョンサーバ数から見積もる
  • 15.
    15© 2014 Cloudera,Inc. All rights reserved. 適切なリージョン数の見積もり ((全データ量 * 1024) / リージョンサイズ (10GB)) / リージョンサーバ数 (100台) = サーバあたりのリージョン数 (102) 全データ量 50TB リージョンサイズ (hbase.hregion.max.filesize) 10GB リージョンサーバ数 100 • 全データ量とリージョンサーバ数から見積もる
  • 16.
    16© 2014 Cloudera,Inc. All rights reserved. リージョンスプリットポリシー • ConstantSizeRegionSplitPolicy • CDH4.1 (0.92) までのスプリットポリシー • 一定のサイズに達したリージョンを分割 • IncreasingToUpperBoundRegionSplitPolicy • CDH4.2 (0.94) 以降でデフォルトのスプリットポリシー • 以下の条件を比較し、小さい方を上限として採用 1. リージョン数 (同一サーバ上、同一テーブル内) ^ 3 ([2]) * フラッシュサイズ * 2 2. hbase.hregion.max.filesizeの設定値 • リージョンをクラスタ全体へ分散し、パフォーマンスの向上を図ることが目的 • ローリング再起動 (デコミッション) 時にリージョン数が増加する場合あり [3] [2] CDH5.0以前、5.1以降で算出式が変更されているので注意。詳しくはHBASE-10501 [3] 一時的にリージョン数が減ることが原因。詳しくはHBASE-12451
  • 17.
    17© 2014 Cloudera,Inc. All rights reserved. リージョンスプリットポリシー • ConstantSizeRegionSplitPolicy • CDH4.1 (0.92) までのスプリットポリシー • 一定のサイズに達したリージョンを分割 • IncreasingToUpperBoundRegionSplitPolicy • CDH4.2 (0.94) 以降でデフォルトのスプリットポリシー • 以下の条件を比較し、小さい方を上限として採用 1. リージョン数 (同一サーバ上、同一テーブル内) ^ 3 ([2]) * フラッシュサイズ * 2 2. hbase.hregion.max.filesizeの設定値 • リージョンをクラスタ全体へ分散し、パフォーマンスの向上を図ることが目的 • ローリング再起動 (デコミッション) 時にリージョン数が増加する場合あり [3] [2] CDH5.0以前、5.1以降で算出式が変更されているので注意。詳しくはHBASE-10501 [3] 一時的にリージョン数が減ることが原因。詳しくはHBASE-12451
  • 18.
    18© 2014 Cloudera,Inc. All rights reserved. リージョンスプリットポリシー • ConstantSizeRegionSplitPolicy • CDH4.1 (0.92) までのスプリットポリシー • 一定のサイズに達したリージョンを分割 • IncreasingToUpperBoundRegionSplitPolicy • CDH4.2 (0.94) 以降でデフォルトのスプリットポリシー • 以下の条件を比較し、小さい方を上限として採用 1. リージョン数 (同一サーバ上、同一テーブル内) ^ 3 ([2]) * フラッシュサイズ * 2 2. hbase.hregion.max.filesizeの設定値 • リージョンをクラスタ全体へ分散し、パフォーマンスの向上を図ることが目的 • ローリング再起動 (デコミッション) 時にリージョン数が増加する場合あり [3] [2] CDH5.0以前、5.1以降で算出式が変更されているので注意。詳しくはHBASE-10501 [3] 一時的にリージョン数が減ることが原因。詳しくはHBASE-12451
  • 19.
    19© 2014 Clouderaand/or its affiliates. All rights reserved. HBaseクラスタのトラブルシューティング
  • 20.
    20© 2014 Cloudera,Inc. All rights reserved. トラブルシューティング • HBaseクラスタにおけるトラブルの種類 1. リージョン不整合 処理中に突然サーバの電源が落ち、メタ情報に食い違いが生じたなど 2. 高負荷時のGC 特に書き込み過多の場合はGCチューニングが必要となる 3. ホットスポット
  • 21.
    21© 2014 Cloudera,Inc. All rights reserved. トラブルシューティング • HBaseクラスタにおけるトラブルの種類 1. リージョン不整合 処理中に突然サーバの電源が落ち、メタ情報に食い違いが生じたなど 2. 高負荷時のGC 特に書き込み過多の場合はGCチューニングが必要となる 3. ホットスポット
  • 22.
    22© 2014 Cloudera,Inc. All rights reserved. トラブルシューティング(1) • リージョン不整合の検知 • hbckユーティリティ [1] • hbck -details > /tmp/hbase-`date`.txt • 主に以下の検査を行う 1. Region Consistency (一貫性) • META、HDFS内の.regioninfo、実際のリージョンアサイン状況がすべて合致しているか 2. Integrity (整合性) • 複数のリージョンでキーの範囲が重複していないか • キーの順序が後退していないか • リージョン間に穴が空いていないか • 最後に表示される不整合件数が0であればOK 0 inconsistencies detected [1] 詳細は http://hbase.apache.org/book.html#hbck.in.depth
  • 23.
    23© 2014 Cloudera,Inc. All rights reserved. トラブルシューティング(1) • まずはRegion Consistencyの確認、修復を行う • 不整合の例 1. Region X, key=Y, not on HDFS or in hbase:meta but deployed on Z キーYで始まるリージョンXがHDFS/META上に存在しないにも関わらず リージョンサーバZにアサインされている 2. Region X on HDFS, but not listed in hbase:meta or deployed on any region server リージョンXはHDFSに存在するが、METAになくどのリージョンサーバにも アサインされていない 3. Region X should not be deployed according to META, but is deployed on Z METAの情報によるとリージョンXはアサインされるべきではないが、リー ジョンサーバZにデプロイされている
  • 24.
    24© 2014 Cloudera,Inc. All rights reserved. トラブルシューティング(1) • 修復コマンド • hbck –fixAssignments -fixMeta • 実行前に直前の状況をファイルに出力しておくこと • 実行後は再度 hbck -details を実行してアサインの不整合が修復され ているか確認する 注意: 0.90時代の -fix オプションは -fixAssignments に置き換えられま した。後方互換性のためオプションとしては残っていますが、後者を 利用すること。
  • 25.
    25© 2014 Cloudera,Inc. All rights reserved. トラブルシューティング(1) • Integrityの確認、修復 • 不整合の例 ERROR ... Multiple regions have the same startkey 複数のリージョンが同じ開始キーを持っている • 修復コマンド • hbase hbck -repairHoles 注意: hbckには他にもオプションがありますが、HDFSの内容を操作 するオプションも含まれます。動作を把握しない状況で使用するのは 危険です
  • 26.
    26© 2014 Cloudera,Inc. All rights reserved. トラブルシューティング(2) • Garbage Collection • リージョンサーバは高負荷時にGCの影響を受けやすい • GCによる影響を疑うときのキーワード: slept • 詳細発生時刻付近に以下のメッセージが出力されていないか確認する 1. We slept 67160ms instead of 3000ms, this is likely due to a long garbage collecting pause and it's usually bad 2. Detected pause in JVM or host machine (eg GC): pause of approximately 62182ms GC pool 'ParNew' had collection(s): count=3 time=69ms GC pool 'ConcurrentMarkSweep' had collection(s): count=2 time=62425ms • old世代のGCに60秒以上かかっている • GCログから詳細を確認する
  • 27.
    27© 2014 Cloudera,Inc. All rights reserved. トラブルシューティング(2) • 下記オプションを追加することでより詳細なログを出力 -XX:+PrintPromotionFailure (promotion failedの詳細出力) -XX:PrintFLSStatistics=1 (連続領域の最大サイズなど詳細を出力) -XX:+PrintTenuringDistribution (new領域のオブジェクトの遷移を出力) • 典型的なFull GC発生のシナリオ • promotion failed old領域に十分な連続領域が確保できず、new領域からのオブジェクトの移動に 失敗した(断片化が原因) • concurrent mode failure old世代の回収が間に合わず、空き領域が不足していると判断された 参考資料: http://shop.oreilly.com/product/0636920028499.do http://blog.cloudera.com/blog/2011/02/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-1/
  • 28.
    28© 2014 Cloudera,Inc. All rights reserved. promotion failed new generation old generation
  • 29.
    29© 2014 Cloudera,Inc. All rights reserved. promotion failed new generation old generation new世代のGC (Stop-the-World)
  • 30.
    30© 2014 Cloudera,Inc. All rights reserved. promotion failed new generation old generation new世代のGC後
  • 31.
    31© 2014 Cloudera,Inc. All rights reserved. promotion failed new generation old generation new世代のGC (Stop-the-World)、old世代のGC (アプリケーションと並行)を繰り返す
  • 32.
    32© 2014 Cloudera,Inc. All rights reserved. promotion failed new generation old generation new世代のGC (Stop-the-World)、old世代のGC (アプリケーションと並行)を繰り返す
  • 33.
    33© 2014 Cloudera,Inc. All rights reserved. promotion failed 書き込み負荷が高まり、Memstoreのフラッシュが多発
  • 34.
    34© 2014 Cloudera,Inc. All rights reserved. promotion failed オブジェクトの移動 (promotion) に失敗 (failed)
  • 35.
    35© 2014 Cloudera,Inc. All rights reserved. promotion failed • CMSはオブジェクトのマージ(コンパクション) を行わないため、断片化が発生する • new世代からのオブジェクトを配置できる連続 領域がなくなる • 全アプリケーションスレッドを止めFull GCが 発生する
  • 36.
    36© 2014 Cloudera,Inc. All rights reserved. promotion failed対策 • グラフ化 • x軸: 時刻 • y軸: GB • 赤: 空き領域 (free space) • 青: 最大連続領域 (max chunk) • old世代の空き領域は6GB程度確保 • 連続領域(max chunk)は1GB強で推移
  • 37.
    37© 2014 Cloudera,Inc. All rights reserved. promotion failed対策 • グラフ化 • x軸: 時刻 • y軸: GB • 赤: 空き領域 (free space) • 青: 最大連続領域 (max chunk) • max chunkが急減したタイミングでpromotion failedが発生し、リージョンサーバが停止
  • 38.
    38© 2014 Cloudera,Inc. All rights reserved. promotion failed対策 1. GCログからmax chunkサイズの推移状況を確認 2. 障害発生時に残っていたchunk分では足りなかった • 今回のケースでは1GBほど 3. ヒープサイズを1GB-2GB増やし、再度経過観察を行う
  • 39.
    39© 2014 Cloudera,Inc. All rights reserved. Cloudera Managerのチャート機能
  • 40.
    40© 2014 Cloudera,Inc. All rights reserved. まとめ
  • 41.
    41© 2014 Cloudera,Inc. All rights reserved. まとめ 祝!
  • 42.
    42© 2014 Cloudera,Inc. All rights reserved. Thank you

Editor's Notes

  • #6 http://blog.cloudera.com/blog/2010/07/whats-new-in-cdh3-b2-hbase/ CDH3b2からサポート開始
  • #7 サポート購入顧客は、Cloudera Managerからシステムの診断データを任意で送ることができる。ログや設定情報、ホストの情報を取得する。社内のHBaseクラスタに格納され、整理された情報がCloudera Support Interfaceという形でこのように表示される。ホストは24台、CM/CDHの詳細なバージョンが確認できるようになっている
  • #8 Clouderaサポートでは診断データをもとに、設定情報やログの解析を行い、可能な限りクラスタの診断を行う。これは診断結果のうち、セキュリティに関するアラートを表示している
  • #12 THP:デフォルトのページサイズは4KBだが、JVMなどはメモリを大量に確保したいので効率が悪い。そこでHuge Page。THPはアプリから透過的に利用できるもの。つまりTHPをオフにするということはHPを使わないということ
  • #13 フラッシュとリージョンサイズ。フラッシュサイズを小さくするとコンパクションが多発する。コンパクションが多発すると書き込みが停止される。書き込みが停止されると、アプリケーションに影響がでる
  • #14 フラッシュとリージョンサイズ。フラッシュサイズを小さくするとコンパクションが多発する。コンパクションが多発すると書き込みが停止される。書き込みが停止されると、アプリケーションに影響がでる
  • #15 フラッシュとリージョンサイズ。フラッシュサイズを小さくするとコンパクションが多発する。コンパクションが多発すると書き込みが停止される。書き込みが停止されると、アプリケーションに影響がでる
  • #16 フラッシュとリージョンサイズ。フラッシュサイズを小さくするとコンパクションが多発する。コンパクションが多発すると書き込みが停止される。書き込みが停止されると、アプリケーションに影響がでる
  • #40 経過観察をする際にはCMがメトリクスをグラフ化してくれているので、時間帯、範囲を自由に変更しながら傾向を確認することができる
  • #41 THP:デフォルトのページサイズは4KBだが、JVMなどはメモリを大量に確保したいので効率が悪い。そこでHuge Page。THPはアプリから透過的に利用できるもの。つまりTHPをオフにするということはHPを使わないということ