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

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

• Zookeeper集群：自身设计保证了可用性;
• Master：通过多个Master注册在Zookeeper集群上来进行主节点的HA和更新;
• RegionServer：本身就是无状态的，节点失效下线以后会把上面的Region自动迁走，对服务可用性不会有太大影响;
• Thriftserver：当时业务大多数是Python和Golang，通过用Thrift对HBase的进行，Thriftserver本身是单点的，这里我们通过HAProxy来代理一组Thriftserver服务;
• HDFS：本身又由Namenode和DataNode节点组成，Namenode我们开启HA功能，保证了HDFS的集群可用性;

2、集群级别

• Pod容器失效：Pod是通过Replication Controller维护的，K8S的Controller Manager会在它的存储etcd去监听组件的失效情况，如果副本少于预设值会自动新的Pod容器来进行服务;
• Kubernetes集群崩溃：该场景曾经在生产环境中出现过，针对这种情况，我们对SLA要求较高的业务采用了少量物理机搭配容器的方式进行混合部署，极端场景出现时，可以保证重要业务收到的影响可控;

3、数据级别

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

五、实现细节

1、资源分配

初期物理节点统一采用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组。

2、参数配置

（编辑：西安站长网）

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