Blog gzhBlog=Blog(ACM);

HBase Master 解析

分类:HBase

HBase的master server具体实现是HMaster。它提供了面向Client的HMasterInterface和面向region server的HMasterRegionInterface的实现。

下面是它的组件介绍:

InfoServer 展示信息的组件。这是一个web server,响应你访问:60010的http请求,它本质是一个Jetty web server。

ZooKeeperWatcher zookeeper的观察者。所有需要获知与处理ZNode状态变化的组件都需要在它上面注册ZooKeeperListener。同时它还提供了在zookeeper上操作节点的能力,通过获取其内部的RecoverableZooKeeper对象来进行操作。

ActiveMasterManager active master的管理对象。它主要做的事就是监听zookeeper上master znode的变化。一旦它发现当前的active master unavailable(也就是 master znode被删除了),那么它会竞争,使当前master成为新的active master。

在master启动的时候会调用其blockUntilBecomingActiveMaster方法,试图成为集群的active master。失败的话,master的启动会阻塞在这个方法上,直到集群停止或者是当前active master unavailable,那么它会被唤醒做新的竞争。

RegionServerTracker 跟踪online region server的状态通过zookeeper,,并做相应处理。如果某个RS znode被删除了,那么它会通过ServerManager去终止这个RS,并移出online servers列表。

特别的,在它准备expire这个RS的时候,会先通过ServerManager判断这个RS是否在线,如果不在线则不做exprire,也不移出列表,仅仅是打出一条warn log。我猜这样做的目的是:既然RS不在线,我也无法给它下达关闭命令,说不定过一会这个RS恢复正常又上线了,又重新在zookeeper里建立znode。但这样做我觉得有一个问题,万一这个RS永远也恢复不了呢,那online servers列表里不是会遗留一个offline RS。

DrainingServerTracker 跟踪draining region server状态,draining RS 就是不应该再获得更多region的RS。

RpcServer 提供RPC服务的组件。具体服务由RpcEngine来支持,而引擎的实现是WritableRpcEngine。在0.96版本之后HBase引入了protocol buffer,RPC引擎的实现也被替换了。

MasterFileSystem 抽象了Master对底层文件系统的操作。包括split log,检查文件系统状态等。

ServerManager 管理region server。维护在线和离线的server列表,同时处理RS的startup和shutdown等。RS启动之后会报告给它,它会检测时钟偏差在master和RS之间以及是否已经存在相同的HostPort的RS。同时还会检查这个RS是否在dead list里,防止这个RS因为快速恢复但是已经在expiration流程中的问题。

RS的负载信息也会report给它,关闭和打开region的也是通过它完成。

AssignmentManager 主要工作就是region assign。同时维护region state,比如它通过zookeeper知晓一个split已完成事件,那么它会更新相关region的状态。这是个重量级的组件,Master维护region的分裂,移动都和它有关。

CatalogTracker -ROOT- 和 .META. 的跟踪器。具体工作由RootRegionTracker和MetaNodeTracker完成。前者跟踪”root-region-server” 这个ZNode的状态 ,后者跟踪.META.对应的ZNode状态(具体这个ZNode是”unassign/HRegionInfo.FIRST_META_REGIONINFO.getEncodedName()”) 可以从这个组件上获取到目录表的location信息。

ClusterStatusTracker 跟踪“shutdown” 这个ZNode的状态,可以通过这个组件控制cluster的down or up。这个ZNode里面放了集群的启动时间。它的setClusterDown 方法就是通过删除”shutdown” ZNode来完成。

MemoryBoundedLogMessageBuffer 存放来自region server的fatal error信息,超过buffer大小后会自动清理。

ExecutorService 事件执行器,各种不同事件会被提交到里面不同的队列里等待执行。不同的事件默认的资源也不同,比如MASTER_OPEN_REGION事件的处理默认有5个线程。

这个不是java.util.concurrent.ExecutorService而是org.apache.hadoop.hbase.executor.ExecutorService

LoadBalancer 平衡region server上region的负载。当且仅当没有region in transition时候才会起作用。balanceCluster定期被调用生成RegionPlan。

它的默认实现是DefaultLoadBalancer,0.96之后默认是StochasticLoadBalancer(HBASE-5959)。后者的思想是随机做几次决策,每次比较cost function计算出的结果与当前最优的结果,保留较小者。最后如果当前最优cost小于原先的cost,那么就生成相应RegionPlan。

BalancerChore 定期执行 master.balance()。

CatalogJanitor 定期清理.meta.里split时候遗留的parent region信息。如果parent region的reference不再被它的daughter hold,那么parent region就会被清理。

还一个额外条件就是parent region的parent如果没被clean,那么这个parent也不该被clean。

LogCleaner 定期清理.oldlogs目录下的log。

它会从hbase.master.logcleaner.plugins配置里加载所有BaseLogCleanerDelegate。某个log可以被删除,只有所有delegate都同意。

HFileCleaner 定期清理.archive目录下的HFile。

它会从hbase.master.hfilecleaner.plugins配置里加载所有BaseHFileCleanerDelegate。 只有所有delegate都同意才能被删除。

MasterCoprocessorHost 提供Master端的coprocessor的执行环境与框架。

这些coprocessor被包装在MasterEnvironment里。当action发生的时候,会遍历MasterCoprocessorHost里所有MasterEnvironment,获取里面MasterObserver,并调用相关方法。

SnapshotManager 管理table快照的组件。

提供了监视快照执行状态的方法以及制作快照,快照恢复,删除快照等方法。

HealthCheckChore 这不是一个必要的组件,只有你配置了hbase.node.health.script.location才能启动它。它会定期执行location设置的Script来检测health,在失败窗口内失败次数达到阈值就会stop master。

然后我们看看HMaster整个启动过程主要都做了什么:

1.先是在HMaster的构造函数里设置各种参数以及启动RpcServer,链接zookeeper(即创建zookeeperWatcher),如果hbase.node.health.script.location配置存在,则构造一个HealthCheckChore。

2.然后HMaster的run方法会被执行,该方法做如下事情:

未经一番寒彻骨,焉得梅花扑鼻香