弥补MySQL和Redis短板：看HBase怎么确保高可用

结合之前对Deployment以及ConfigMap的引入，以及对Dockerfile的修改，整个HBase构建流程也有了改进：

HBaseonKubernetes构建流程

• 编制相关的Dockerfile并构建基础的HBase组件镜像;
• 为将要创建的HBase构建基础属性配置模板，订制基础资源，这部分可以通过KubasAPI在Kubernetes集群中创建ConfigMap;
• 具体创建部署集群时，通过调用KubasAPI，结合之前构建的ConfigMap模板，渲染出HBase集群中各类组件的详细ConfigMap，然后在Kubernetes集群中构建Deployment;
• 最终通过之前构建好的镜像加载组件ConfigMap中的配置，完成在KubernetesNode中运行的一个HBase组件容器。

通过结合K8S的ConfigMap功能的配置模板，以及KubasAPI调用，，我们就可以在短时间部署出一套可用的HBase最小集群(2Master + 3Region Server + 2Thriftserver)，在所有宿主机Host都已经缓存Docker镜像文件的场景下，部署并启动一整套HBase集群的时间不超过15秒。

同时在缺少专属前端控制台的情况下，可以完全依托Kubernetesdashboard完成HBase集群组件的扩容缩容，以及组件配置的查询修改更新以及重新部署。

八、资源控制

在完成重构之后，HBase服务面向知乎内部业务进行开放，短期内知乎HBase集群上升超过30+集群，伴随着HBase集群数量的增多，有两个问题逐渐显现：

• 运维成本增高：需要运维的集群逐渐增高;
• 资源浪费：这是因为很多业务的业务量并不高，但是为了保证HBase的高可用，我们至少需要提供2个Master+3个RegionServer，而往往Master的负载都非常低，这就造成了资源浪费。

为了解决如上的两个问题，同时又不能打破资源隔离的需求，我们将HBaseRSGroup功能加入到了HBase平台的管理系统中。

优化后的架构如下：

RSGroup的使用

由于平台方对业务HBase集群的管理本身就具有隔离性，所以在进行更进一步资源管理的时候，平台方采用的是降级的方式来管理HBase集群。

通过监听每个单独集群的指标，如果业务集群的负载在上线一段时间后低于阈值，平台方就会配合业务方，将该HBase集群迁移到一套MixedHBase集群上。

同时如果在MixedHBase集群中运行的某个HBase业务负载增加，并持续一段时间超过阈值后，平台方就会考虑将相关业务提升至单独的集群。

九、多IDC优化

随着知乎业务的发展和扩大，知乎的基础架构逐渐升级至多机房架构，知乎HBase平台管理方式也在这个过程中进行了进一步升级，开始构建多机房管理的管理方式;基本架构如下图所示：

多IDC访问方式

• 业务HBase集群分别在多个IDC上运行，由业务确定IDC机房的主从方式，业务的从IDC集群数据通过平台方的数据同步组件进行数据同步;
• 各IDC的Kubas服务主要负责对本地Kubernetes集群的具体操作，包括HBase集群的创建删除管理，regionserver的扩容等HBase组件的管理操作，Kubas服务部署与机房相关，仅对接部署所在机房的K8S集群;
• 各IDC的Kubas服务向集群发现服务上报本机房集群信息，同时更新相关集群主从相关信息;
• 业务方通过平台方封装的ClientSDK对多机房的HBase集群进行访问，客户端通过集群发现服务可以确定HBase集群的主从关系，从而将相关的读写操作分离，写入修改访问可以通过客户端指向主IDC的集群;
• 跨机房间的数据同步采用了自研的HBaseReplicationWALTransfer来提供增量数据的同步。

十、数据同步

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!