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

HBase是一个基于Hadoop面向列的非关系型分布式数据库（NoSQL），设计概念来源于谷歌的BigTable模型，面向实时读写、随机访问大规模数据集的场景，是一个高可靠性、高性能、高伸缩的分布式存储系统，在大数据相关领域应用广泛。

HBase系统支持对所存储的数据进行透明切分，从而使得系统的存储以及计算具有良好的水平扩展性。

知乎从2017年起开始逐渐采用HBase系统存储各类在线业务数据，并在HBase服务之上构建各类应用模型以及数据计算任务。

• 伴随着知乎这两年的发展，知乎核心架构团队基于开源容器调度平台Kubernetes打造了一整套HBase服务平台管理系统；

• 经过近两年的研发迭代，目前已经形成了一套较为完整的HBase自动化运维服务体系，能够完成HBase集群的快捷部署、平滑扩缩容、HBase组件细粒度监控、故障跟踪等功能。

背景

知乎对HBase的使用经验不算太长，在2017年初的时候，HBase服务主要用于离线算法、推荐、反作弊，还有基础数据仓库数据的存储计算，通过MapReduce和Spark来进行访问。而在当时知乎的在线存储主要采用MySQL和Redis系统，其中：

• MySQL ： 支持大部分的业务数据存储，当数据规模增大后有一些需要进行扩容的表，分表会带来一定的复杂性，有些业务希望能屏蔽这个事情，还有一些是因为历史原因在表设计的时候用rmsdb的形式存了一些本该由列存储的数据，希望做一下迁移。此外MySQL基于SSD，虽然性能很好，花销也比较大；

• Redis ： 可以提供大规模的缓存，也可以提供一定的存储支持。Redis性能极好，主要的局限是做数据Resharding较为繁琐，其次是内存成本较高。

针对以上两种在线存储所存在的一些问题，我们希望建立一套在线存储NoSQL服务，对以上两种存储作为一个补充。

选型期间我们也考虑过Cassandra，早期一些业务曾尝试使用Cassandra作为存储，隔壁团队在运维了一段时间的Cassandra系统之后，遇到不少的问题，Cassandra系统可操作性没有达到预期，目前除了Tracing相关的系统，其他业务已经放弃使用Cassandra。

我们从已有的离线存储系统出发，在衡量了稳定性、性能、代码成熟度、上下游系统承接、业界使用场景以及社区活跃度等方面之后，选择了HBase，作为知乎在线存储的支撑组件之一。

• 初期知乎只有一套进行离线计算的集群，所有业务都跑在一个集群上，并且HBase集群和其他离线计算yarn以及Impala混合部署，HBase的日常离线计算和数据读写都严重受到其他系统影响；

• 并且HBase的监控都只停留在主机层面的监控，出现运行问题时，进行排查很困难，系统恢复服务时间较长，这种状态下，我们需要重新构建一套适用于在线服务的系统。

在这样的场景下，我们对在线HBase服务的需求是明确的：

隔离性

• 从业务方的视角来说，希望相关的服务做到环境隔离，权限收归业务，避免误操作和业务相互影响；

• 对于响应时间，服务的可用性，都可以根据业务的需要指定SLA；

• 对于资源的分配和blockcache等参数的配置也能够更加有适应性，提供业务级别的监控和报警，快速定位和响应问题；

资源利用率： 从运维的角度，资源的分配要合理，尽可能的提升主机cpu，内存包括磁盘的有效利用率；

成本控制： 团队用最小的成本去得到最大的运维收益，所以需要提供便捷的调用接口，能够灵活的进行HBase集群的申请、扩容、管理、 监控。同时成本包括机器资源，还有工程师。当时我们线上的这套系统是由一位工程师独立去进行维护。

综合以上需求，参考我们团队之前对基础设施平台化的经验，最终的目标是把HBase服务做成基础组件服务平台向提供给上游业务，这个也是知乎技术平台部门工作思路之一，尽可能的把所有的组件对业务都黑盒化，接口化，服务化。同时在使用和监控的粒度上尽可能的准确，细致，全面。这是我们构建在线HBase管理运维系统的一个初衷。

前文说到我们希望将整个HBase系统平台服务化，那就涉及到如何管理和运维HBase系统，知乎在微服务和容器方面的工作积累和经验是相当丰富的。

• 在当时我们所有的在线业务都已经完成了容器化的迁移工作，超万级别的业务容器平稳运行在基于mesos的容器管理平台Bay上（参见[1]）；

• 与此同时，团队也在积极的做着Infrastructure容器化的尝试，已经成功将基础消息队列组件Kafka容器化运行于Kubernetes系统之上（参见[2]），因此我们决定也将HBase通过Kubernetes来进行资源的管理调度。

Kubernetes[3]是谷歌开源的容器集群管理系统，是Google多年大规模容器管理技术Borg的开源版本。Kubernetes提供各种维度组件的资源管理和调度方案，隔离容器的资源使用，各个组件的HA工作，同时还有较为完善的网络方案。

Kubernetes被设计作为构建组件和工具的生态系统平台，可以轻松地部署、扩展和管理应用程序。有着Kubernetes大法的加持，我们很快有了最初的落地版本（[4]）。

最初的落地版本架构见下图，平台在共享的物理集群上通过Kubernetes（以下简称K8S）API建立了多套逻辑上隔离的HBase集群，每套集群由一组Master和若干个Regionserver（以下简称RS）构成，集群共享一套HDFS存储集群，各自依赖的Zookeeper集群独立；集群通过一套管理系统Kubas服务来进行管理（[4]）。

第一代架构

模块定义

在K8S中如何去构建HBase集群，首先需要用K8S本身的基础组件去描述HBase的构成；K8S的资源组件有以下几种：

• Node： 定义主机节点，可以是物理机，也可以是虚拟机；

• Pod： 一组紧密关联的容器集合，是K8S调度的基本单位；

• ReplicationController： 一组pod的控制器，通过其能够确保pod的运行数量和健康，并能够弹性伸缩。

结合之前Kafka on K8S的经验，出于高可用和扩展性的考虑，我们没有采用一个Pod里带多个容器的部署方式，统一用一个ReplicationController定义一类HBase组件，就是上图中的Master，Regionserver还有按需创建的Thriftserver；通过以上概念，我们在K8S上就可以这样定义一套最小HBase集群：

• 2*MasterReplicationController；

• 3*RegionserverReplicationController；

• 2*ThriftserverReplicationController（可选）；

作为面向在线业务服务的系统，高可用和故障转移是必需在设计就要考虑的事情，在整体设计中，我们分别考虑组件级别、集群级别和数据存储级别的可用性和故障恢复问题。

HBase本身已经考虑了很多故障切换和恢复的方案：

• Zookeeper集群： 自身设计保证了可用性；

• Master： 通过多个Master注册在Zookeeper集群上来进行主节点的HA和更新；

• RegionServer： 本身就是无状态的，节点失效下线以后会把上面的Region自动迁走，对服务可用性不会有太大影响；

• Thriftserver： 当时业务大多数是Python和Golang，通过用Thrift对HBase的进行，Thriftserver本身是单点的，这里我们通过HAProxy来代理一组Thriftserver服务；

• HDFS： 本身又由Namenode和DataNode节点组成，Namenode我们开启HA功能，保证了HDFS的集群可用性；

• Pod容器失效： Pod是通过Replication Controller维护的，K8S的Controller Manager会在它的存储etcd去监听组件的失效情况，如果副本少于预设值会自动新的Pod容器来进行服务；

• Kubernetes集群崩溃： 该场景曾经在生产环境中出现过，针对这种情况，我们对SLA要求较高的业务采用了少量物理机搭配容器的方式进行混合部署，极端场景出现时，可以保证重要业务收到的影响可控；

所有在K8S上构建的HBase集群都共享了一套HDFS集群，数据的可用性由HDFS集群的多副本来提供。

初期物理节点统一采用2*12核心的cpu，128G内存和4T的磁盘，其中磁盘用于搭建服务的HDFS，CPU和内存则在K8S环境中用于建立HBase相关服务的节点。

Master组件的功能主要是管理HBase集群，Thriftserver组件主要承担代理的角色，所以这两个组件资源都按照固定额度分配。

在对Regionserver组件进行资源分配设计的时候，考虑两种方式去定义资源：

资源分配方式

按照业务需求分配：

• 根据业务方对自身服务的描述，对相关的QPS以及SLA进行评估，为业务专门配置参数，包含blockcache，region大小以及数量等；

• 优点是针对业务优化，能够充分的利用资源，降低业务的资源占用成本；

• 管理成本增加，需要对每一个业务进行评估，对平台维护人员非常不友好，同时需要业务同学本身对HBase有理解；

统一规格的资源分配：

• CPU以及MEM都按照预先设定好的配额来分配，提供多档的配置，将CPU和MEM的配置套餐化；

• 方便之处在于业务扩容时直接增加Regionserver的个数，配置稳定，运维成本较低，遇到问题时排障方便；

• 针对某些有特有访问方式的业务有局限性，如CPU计算型，大KV存储，或者有MOB需求的业务，需要特殊的定制；

• 介于当时考虑接入的在线业务并不多，所以采用了按业务定制的方式去配置Regionserver，正式环境同一业务采用统一配置的一组Regionserver，不存在混合配置的Regionserver组。

基础镜像基于cdh5.5.0-hbase1.0.0构建：

• 固定的环境变量，如JDK_HOME，HBASE_HOME，都通过ENV注入到容器镜像中；

• 与HDFS相关的环境变量，如hdfs-site.xml和core-site.xml预先加入Docker镜像中，构建的过程中就放入了HBase的相关目录中，用以确保HBase服务能够通过对应配置访问到HDFS；

• 与HBase相关的配置信息，如组件启动依赖的Zookeeper集群地址，HDFS数据目录路径，堆内存以及GC参数等，这些配置都需要根据传入KubasService的信息进行对应变量的修改，一个典型的传入参数示例。

通过上面的参数KubasService启动Docker时，在启动命令中利用hadoop_xml_conf.sh和env-init.py修改hbase-site.xml和hbase-env.sh文件来完成最后的配置注入，如下所示：

网络方面，采用了Kubernetes上原生的网络模式，每一个Pod都有自己的IP地址，容器之间可以直接通信，同时在Kubernetes集群中添加了DNS自动注册和反注册功能，以Pod的标识名字作为域名，在Pod创建和重启和销毁时将相关信息同步全局DNS。

在这个地方我们遇到过问题，当时我们的DNS解析不能在Docker网络环境中通过IP反解出对应的容器域名，这就使得Regionserver在启动之后向Master注册和向Zookeeper集群注册的服务名字不一致，导致Master中对同一个Regionserver登记两次，造成Master与Regionserver无法正常通信，整个集群无法正常提供服务。

经过我们对源码的研究和实验之后，我们在容器启动Regionserver服务之前修改/etc/hosts文件，将Kubernetes对注入的hostname信息屏蔽。

这样的修改让容器启动的HBase集群能够顺利启动并初始化成功，但是也给运维提升了复杂度，因为现在HBase提供的Master页现在看到的Regionserver都是IP形式的记录，给监控和故障处理带来了诸多不便。

初代架构顺利落地，在成功接入了近十个集群业务之后，这套架构面临了以下几个问题：

管理操作业务HBase集群较为繁琐

• 需要手动提前确定HDFS集群的存储，以及申请独立Zookeeper集群，早期为了省事直接多套HBase共享了一套Zookeeper集群，这和我们设计的初衷不符合；

• 容器标识符和HBaseMaster里注册的regionserver地址不一致，影响故障定位；

• 单Regionserver运行在一个单独的ReplicationController（以下简称RC），但是扩容缩容为充分利用RC的特性，粗暴的采用增加或减少RC的方式进行扩容缩容。

HBase配置

• 最初的设计缺乏灵活性，与HBase服务配置有关的hbase-site.xml以及hbase-env.sh固化在DockerImage里，这种情况下，如果需要更新大量配置，则需要重新build镜像；

• 由于最初设计是共享一套HDFS集群作为多HBase集群的存储，所以与HDFS有关的hdfs-site.xml和core-site.xml配置文件也被直接配置进了镜像。如果需要在Kubasservice中上线依赖其他HDFS集群的HBase，也需要重新构建镜像。

HDFS隔离

• 随着接入HBase集群的增多，不同的HBase集群业务对HDFS的IO消耗有不同的要求，因此有了分离HBase依赖的HDFS集群的需求；

• 主要问题源自Docker镜像对相关配置文件的固化，与HDFS有关的hdfs-site.xml和core-site.xml配置文件与相关Docker镜像对应，而不同Docker镜像的版本完全由研发人员自己管理，最初版本的实现并未考虑到这些问题。

监控运维

• 指标数据不充分，堆内堆外内存变化，region以及table的访问信息都未有提取或聚合；

• Region热点定位较慢，无法在短时间内定位到热点Region；

• 新增或者下线组件只能通过扫KubasService的数据库来发现相关变更，组件的异常如RegionServer掉线或重启，Master切换等不能及时反馈；