关于hbase:hbase运维故障案例分析

在理论运维 HBase 集群时，各位小伙伴总会遇到 RegionServer 异样宕机、业务写入提早增大甚至无奈写入等相似问题。本章联合笔者的教训、列举实在生产线环境常见的几个问题，并介绍这些地问题的根本排查思路。同时，重点对 HBase 零碎中的日志进行梳理介绍，最初对如何通过监控、日志等工具进行问题排查进行总结，造成问题排查套路，不便读者进行实际。

regionserver 宕机

案例一: 长时间 GC 导致 Regionserver 宕机

长时间 FullGC 是 RegionServer 宕机最常见的起因. 剖析这类问题, 能够遵循如下排错过程:

景象：收到 Regionserver 过程退出的报警。

1. 宕机起因定位

步骤 1: 通常在监控上看不出，须要到事发的 RegionServer 日志间接搜寻 2 类关键字 —a long garbage collecting pause 或 ABORTING region server。对于长时间 Full GC 的场景，搜寻第一个关键字会检索到:

     2019-06-14T17:22:02.054 WARN [JvmPauseMonitor] util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 20542ms
     GC pool 'ParNew' had collection(s): count=1 time=0ms
     GC pool 'ConcurrentMarkSweep' had collection(s): count=2 time=20898ms
     2019-06-14T WARN [regionserver60020.periodicFlusher] util.Sleeper: We slept 20936ms instead of 100ms, this is likely due to a long garbage collecting pause and it's usually bad, see http://hbase.apache.org/book.html#trouble.rs.runtime.zkexpired

步骤 2: 通常 CMS GC 策略会在 2 种场景下产生重大的 Full GC，1. Concurrent Mode Failure 2. Promotion Failure。

   2017-06-14T17:22:02.054+0800:21039.790[FulGC20172017-06-14T17:22:020544+0800:21039.790: [CMS2017-06-14T17:22:02.0544+0800:21041.477: [CMS-concurrent-mark:1767/1782 sec][Times: user=14.01 sys=0.00 real=1.79 secs](concurrent mode fallure): 25165780K->25165777K(25165824K), 18.4242160 secs] 26109489K->26056746K(26109568K), [CMS Perm: 48563K-48534K(262144K), 18.4244700s secs][Times: user=28.77 sys=0.00 real=18.42. secs]]
   2017-06-14T17:22:20:47340800:21058.215:Totalime for which appll cation threads were stopped:184270530 seconds

当初根本能够确认是因为 concurrent mode failure 模式的 CMS GC 导致长时间应用程序暂停。

2. 宕机起因剖析

故障因果剖析: JVM 触发的 concurrent mode failure 模式的 CMS GC 会产生长时间的 stop the world, 下层利用因而长时间暂停。进一步导致 RegionServer 与 Zookeeper 之间建设的 session 超时。session 一旦超时，Zookeeper 就会告诉 Master 将此宕机 RegionServer 踢出集群。

什么是 concurrent mode failure 模式的 GC？为什么会造成长时间暂停？假如 HBase 零碎正在执行 CMS 回收老年代空间，在回收的过程中恰好从年老代降职了一批对象进来，不巧的是，老年代此时曾经没有空间再包容这些对象了。这种场景下，CMS 收集器会进行工作，零碎进入 stop-the-world 模式，并且回收算法会进化为单线程复制算法，重新分配整个堆内存的存活对象到 SO 中，开释所有其余空间。很显然，整个过程会比拟漫长。

3. 解决方案

既然是老年代来不及 GC 导致的问题，那只须要让 CMS 收集器更早一点回收就能够大概率防止这种状况产生。
JVM 提供了参数
XX:CMSInitiatingOccupancyFraction= N 来设置 CMS 回收的机会, N 示意以后老年代已应用内存占年老代总内存的比例, 能够将值改得更小使回收更早进行，比方 60

另外倡议在解决时关注下零碎 BlockCache 是否开启了 offheap 模式，还有 JVM 启动参数是否正当，JVM 堆内存治理是否未正当应用堆外内存。

案例二: 零碎重大 Bug 导致 Regionserver 宕机

大字段 scan 导致 RegionServer 宕机

景象：RegionServer 过程退出

1. 宕机起因定位

步骤 1: 日志。先查看 GC 相干，如果没有再持续搜寻关键字“abort”，查到可疑日志“java.lang.OutOfMemoryError: Requested array exceeds VM limit”

步骤 2: 源码确认。看到带堆栈的 FALTAL 级别日志，定位到源码或者依据在关键字在网上搜寻，确认该异样产生在 scan 后果数据在回传给客户端时，因为数据量太大导致申请的 array 大小超过 JVM 规定的最大值(Interge.Max_Value-2)

2. 故障因果剖析

因为 HBase 零碎本身的 bug，在某些场景下 scan 后果数据太大导致 JVM 在申请 array 时抛出 OutOfMemoryError，造成 RegionServer 宕机

3. 实质起因剖析

造成这个问题能够认为是 HBase 的 bug，不应该申请超过 JVM 规定阈值的 array。另一方面，也能够认为是业务方用法不当。

• 表列太宽，并且对 scan 后果没有做列数据限度，导致一行数据就可能因为蕴含大量列而超过 array 阈值
• KeyValue 太大，并且没有对 scan 的返回做限度，导致返回数据后果大小超过 array 阈值。

4. 解决方案

能够在服务端做限度 hbase.server.scanner.max.result.size 大小
也能够在客户端拜访的时候对返回后果大小做限度(scan.setMaxResultSize)

hbase 写入异样

案例：HDFS 缩容导致局部写入异样

景象：业务反馈局部写入申请超时异样。此时 HBase 在执行 HDFS 集群多台 DataNode 服役操作。

1. 写入异样起因定位

步骤 1: 实践上平滑服役不会造成下层业务感知

步骤 2: 排查 HBase 节点集群监控，发现服役操作期间节点 IO 负载较高

初步判断写入异样和退服期间 IO 负载较高有肯定关系。

步骤 3:在相干工夫点查看 RegionServer 日志，搜寻“Exception”，失去要害的 2 行:

 2020-04-24 13:03:16,685 WARN [ResponseProcessor for block BP-1655660372-10.x.x.x-1505892014043:blk_1093094354_19353580] hdfs.DFSClient: DFSOutputStream ResponseProcessor exception for block BP-1655660374-10.x.x.x-1505892014043:blk_1093094354_19353580 java.io.IOException: Bad response ERROR for block BP-1655660372-10.x.x.x-1505892014043:blk_1093094354_19353580 from datanode 10.x.x.x:50010 at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer$ResponseProcessor.run(DFSOutputStream.java:828)
 2020-04-24 13:03:16,700 INFO [sync.0] wal.FSHLog: Slow sync cost: 13924 ms, current pipelin: [10.x.x.x:50010, 10.x.x.x:50010]

HLog 执行 sync 破费工夫太长(13924ms), 写入响应阻塞。

步骤 4: 进一步查看了 DataNode 日志发现刷盘很慢，有异样信息

2020-04-24 13:03:16,686 ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: newsrec-hbase10.dg.163.org:50010:DataXceiver error processing WRITE_BLOCK operation src: /10.x.x.x:55637 dst:10.x.x.x:50010

2. 写入异样起因剖析

• 多台 DataNode 同时服役，过程中 copy 大量数据块会导致集群所有节点的带宽和 IO 压力陡增。
• 节点 IO 负载很高导致 DataNode 执行数据块落盘很慢，进而导致 HBase 中 HLog 刷盘超时异样，在集群写入压力较大的场景下会引起写入沉积超时

3. 解决方案

• 运维应在业务低峰期执行 DataNode 服役操作
• 不能同时服役多台 DataNode，免得造成短时间 IO 压力急剧增大，改成顺次服役。

hbase 运维时问题剖析思路

生产线问题是零碎运维工程师的导师。之所以这样说，是因为对问题的剖析能够让咱们积攒更多的问题定位伎俩，并且让咱们对系统的工作原理有更加深刻的了解，甚至接触到很多之前不可能接触到的常识畛域。就像去一个 未知的世界摸索一个未知的问题，越往里面走，就越能看到他人看不到的世界。所以生产线上的问题产生了，肯定要抓住机会，追根溯源。毫不夸大地说，技术人员的外围能力很大部分体现在定位并解决问题的能力上。

实际上，解决问题只是一个后果。从收到报警看到问题的那一刻到最终解决问题，必然会经验三个阶段：问题定位，问题剖析，问题修复。问题定位是从问题登程通过肯定的技术手段找到触发问题的实质，问题剖析是从原理上对整个流程脉络梳理分明，问题解决依赖于问题剖析，依据问题剖析的后果对问题进行针对性修复或全局修复。

1. 问题定位

定位问题的触发起因是解决问题的要害。问题定位的根本流程如图：

• 指标监控剖析。很多问题都能够间接在监控界面上直观地找到答案。比方业务反馈在某一时刻后读提早变得十分高。第一反馈是去查看零碎 IO、CPU 或者带宽是不是有任何异样，如果看到 IO 利用率在对应工夫点变得异样高，就根本能够确认读性能降落就是由此导致。虽说 IO 利用率不是实质起因，但这是问题链上的 重要一环，接下来探索为什么 IO 利用率在对应工夫点异样。

对问题定位有用的监控指标十分多，宏观上看能够分为零碎根底指标和业务相干指标两大类。零碎根底指标包含零碎 IO 利用率、CPU 负载、带宽等；业务相干指标包含 RegionServer 级别读写 TPS、读写均匀提早、申请队列长度 /Compaction 队列长度、MemStore 内存变动、BlockCache 命中率等。

• 日志剖析。对于零碎性能问题，监控指标或者能够帮忙，但对于零碎异样类型的问题，监控指标可能看不到端倪。这个时候 HBase 零碎相干日志最外围的有 RegionServer 日志和 Master 日志，另外 GC 日志、HDFS 相干日志 (NameNode 日志和 DataNode 日志) 以及 Zookeeper 日志在特定场景下对剖析问题都有帮忙。

对于日志剖析并不需要将日志从头到尾读一遍，能够间接搜寻相似于“Exception”，“ERROR”，甚至“WARN”关键字，再联合时间段对日志进行剖析。

• 网络求助。通过监控指标剖析和日志剖析后，运维人员通常都会有播种。也有局部状况下，咱们能看到了 ”Exception”，但不明确具体含意。此时须要去网络上求助。首先在搜索引擎上依据相干日志查找，大多数状况下都能找到相干的文章阐明，因为你遇到的问题很大概率他人也会遇到。如果没有线索，接着去各个业余论坛查找求教，比方 stackoverflow、hbase-help.com 以及各种 HBase 相干交换群组。最初，还能够发邮件到社区求教社区技术人员。
• 源码剖析。在问题解决之后，倡议通过源码对问题进行再次确认

2. 问题剖析

解决未知问题就像一次摸索未知世界的旅程。定位问题的过程就是向未知世界走去，走得越远，看到的货色越多，见识到的世面越大。然而目迷五色的风景如果不认真捋一捊，一旦他人问起那个中央怎么样，必然会无言以对。

问题剖析是问题定位的一个逆过程。从问题的最实质起因登程，联合零碎的工作原理，一直推演，最终推演出零碎的异样行为。要把这个过程剖析的清清楚楚，不仅仅须要监控信息、异样日志，更须要联合零碎工作原理进行剖析。所以回过头来看，只有把零碎的原理了解分明，能力把问题剖析分明。

3. 问题修复

如果可能把问题的前因后果解释分明，置信就可能轻而易举地给出针对性解决方案。这应该是整个问题摸索中最轻松的一个环节。没有解决不了的问题，如果有，那就是没有把问题剖析分明。

参考:《HBase 原理与实际》

作者：许佳宾|Growing 运维施行工程师
专一于平台施行、sla 治理 / 工具建设、Devops 开发