Region是HBase的资源管理单位,在Region的生命周期内,一个Region迁移会发生在如下的情况下:
1)HMaster的Load Balance,造成部分Region在RS之间迁移。默认使用了
org.apache.hadoop.hbase.master.DefaultLoadBalancer,仅仅考虑RS上Region个数的分配的均衡性。
2)Region Split过程。这部分内容可以参考
http://blog.sina.com.cn/s/blog_4a1f59bf01018tu4.html
3) RS Offline过程-〉LOG Split过程-〉Region迁移。
在如上的过程中都会涉及到Region的迁移,那么Region的迁移又要经过哪些过程呢?
为了节省文章空间,我们以HMaster的Load Balancer为例来说明。
1)HMaster启动LoadBalancer线程。balancer的period由hbase.balancer.period控制,默认是300s。
int balancerPeriod = master.getConfiguration().getInt("hbase.balancer.period", 300000); |
2)关闭了BalancerSwitch、有Region处于In-Transition状态、或者RS下线的处理流程还没有走完,在这三种情况下,HMaster会停止执行Balancer过程。
3)由AssignmentManager获取每个Table的分布关系,由balancer为Region制定RegionPlan。对于DefaultLoadBalancer的实现,基本思想就是按照Region个数对于RS进行排列,首先按照Region个数多少进行排列,计算出Overload的RS需要回收的Region的个数,然后取出underload的RS中Region的个数。为了保证随机性,采取了再次打散underload RS,重组成RegionPlan(Region, RS-src,RS-dest)。
4) AssignmentManager 按照RegionPlan的要求,会执行unassign过程。在AssignmentManager的设计中,是一个由Zookeeper上hbase Node为仲裁者,RS与HMaster状态共享的过程状态机。
在AssignmentManager上提供了对于unassigned、splitlog等zk路径的Watcher,在HMaster、RS对于相应的Region状态的操作(Split)和迁移操作时,会在相应阶段时,修改对应zk路径的状态,这种节点下路径状态的改变,会被AM捕获,并启动下一个处理过程,从而最终完成处理操作。下面,我们已balancer过程来分析一下:
- HMaster 生成RegionPlan
- AM在ZK下unassigned路径下新建节点A,并标识A的状态为M_ZK_REGION_CLOSING
- AM通过RPC调用RS->CloseRegion
- RS完成Region关闭之后,修改节点A的状态为M_ZK_REGION_CLOSED
- AM的Zookeeper Watcher监听到Node A的变化,执行ClosedRegionHandler的处理
- AM修改节点A的状态从M_ZK_REGION_CLOSED到M_ZK_REGION_OFFLINE,根据RegionPlan,执行assignRegion操作
- AM通过RPC调用RS-〉openRegion操作
- RS转换节点A的状态为RS_ZK_REGION_OPENING
- RS执行openRegion操作
- RS执行完毕之后,修改节点A的状态从RS_ZK_REGION_OPENING到RS_ZK_REGION_OPENED
- AM执行OpenedRegionHandler处理,删除节点A。
- 到此,整个操作结束。
通过上面的过程,我们可以看到一个Region迁移过程,涉及到多次与ZK的操作,并且如果RegionPlan涉及到RS-src和RS-dest出现问题时,还有复杂的容错逻辑。因此,不得不说AM是HBase稳定性的关键。
问题:
在我们的大规模的应用测试中,发现了个别异常的Region。
首先,介绍发现这个问题的来由。在线上读写请求出现个别操作失败,并且失败的请求指向同一个Region A,因此,检查该Region A的位置,指向了host1,然而进入host1的onlineRegion列表中,却没有发现该Region,因此,此时出现Region不匹配的问题。更名为Region空洞。
在互联网应用中,有一个共性是,找问题比解决问题要难。只要定位到了问题,根据上面对于AM、RS、HMaster之间Region迁移的理解,很容易发现是Region迁移过程中出现了一次事故,造成了空洞现象。
我的解决方法就是增加一个定时触发的监控程序,去检查.META.表中记录的Region位置(RS)是否与RS对应上,如果RS上onlineRegion,不存在该Region,则就报警,并尝试进行unassign操作。核心代码如下:
HTable table = new HTable(HBaseConfiguration.create(), args[0]); HBaseAdmin admin = new HBaseAdmin(HBaseConfiguration.create()); ClusterStatus cs = admin.getClusterStatus(); Map regions = table.getRegionLocations(); if (regions != null && regions.size() > 0) { for (Map.Entry hriEntry : regions.entrySet()) { HRegionInfo regionInfo = hriEntry.getKey(); HServerLoad load = cs.getLoad(ServerName.parseServerName(hriEntry.getValue().getServerName())); if ( load != null && load.getRegionsLoad().get(regionInfo.getRegionName()) != null ) { System.err.println(Bytes.toStringBinary(regionInfo.getRegionName()) + " " + hriEntry.getValue().getServerName()); } else { System.out.println(Bytes.toStringBinary(regionInfo .getRegionName()) + " is Region Hole, and try to reassign again."); RegionAssigner.assign(regionInfo.getRegionName()); } } } |
将该程序放入crontab中,定时检查监控,并有Region重新部署功能。
From Binospace, post HBase监控之Region空洞
文章的脚注信息由WordPress的wp-posturl插件自动生成