Movatterモバイル変換

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_

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/

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/

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) 128MBMemstoreサイズ (hbase.regionserver.global.memstore.upperLimit) 0.4  4GBMemstoreサイズ (4GB) / フラッシュサイズ (128MB)• Memstoreサイズと書き込み量から見積もる

13© 2014 Cloudera, Inc. All rights reserved.適切なリージョン数の見積もりリージョンサーバヒープサイズ 10GBフラッシュサイズ (hbase.hregion.memstore.flush.size) 128MBMemstoreサイズ (hbase.regionserver.global.memstore.upperLimit) 0.4  4GBMemstoreサイズ (4GB) / フラッシュサイズ (128MB)= サーバあたりのリージョン数 (32)• Memstoreサイズと書き込み量から見積もる

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]) * フラッシュサイズ * 22. hbase.hregion.max.filesizeの設定値• リージョンをクラスタ全体へ分散し、パフォーマンスの向上を図ることが目的• ローリング再起動 (デコミッション) 時にリージョン数が増加する場合あり [3][2] CDH5.0以前、5.1以降で算出式が変更されているので注意。詳しくはHBASE-10501[3] 一時的にリージョン数が減ることが原因。詳しくはHBASE-12451

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であればOK0 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 anyregion serverリージョンXはHDFSに存在するが、METAになくどのリージョンサーバにもアサインされていない3. Region X should not be deployed according to META, but is deployedon ZMETAの情報によるとリージョン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 pauseand it's usually bad2. Detected pause in JVM or host machine (eg GC): pause of approximately 62182msGC pool 'ParNew' had collection(s): count=3 time=69msGC 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 failedold領域に十分な連続領域が確保できず、new領域からのオブジェクトの移動に失敗した(断片化が原因)• concurrent mode failureold世代の回収が間に合わず、空き領域が不足していると判断された参考資料:http://shop.oreilly.com/product/0636920028499.dohttp://blog.cloudera.com/blog/2011/02/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-1/

Movatterモバイル変換

Change Language

HBaseサポート最前線 #hbase_ca

Embed presentation

Recommended

More Related Content

What's hot

Viewers also liked

Similar to HBaseサポート最前線 #hbase_ca

More from Cloudera Japan

HBaseサポート最前線 #hbase_ca

Editor's Notes