鸡血藤,补偿MySQL和Redis短板:看HBase怎样保证高可用,去年夏天

HBase是一个根据Hadoop面向列的非联系型散布式数据库(NoSQL),规划概念来历于谷歌的BigTable模型,面向实时读写、随机拜访大规模数据集的场景,是一个高可靠性、高功用、高弹性的散布式存储体系,在大数据相关范畴运用广泛。

HBase体系支撑对所存储的数据进行通明切分,然后使得体系的存储以及核算具有杰出的水平扩展性。

知乎从2017年起开端逐步选用HBase体系存储各类在线事务数据,并在HBase效劳之上构建各类运用模型以及数据核算使命。

布景

知乎对HBase的运用经历不算太长,在2017年头的时分,HBase效劳首要用于离线算法、引荐、反作弊,还有根底数据仓库数据的存储核算,经过MapReduce和Spark来进行拜访。而在其时知乎的在线存储首要选用MySQL和Redis体系,其间:

针对以上两种在线存储所存在的一些问题,咱们期望树立一套在线存储NoSQL效劳,对以上两种存储作为一个弥补。

选型期间咱们也考虑过Cassandra,前期一些事务曾测验运用Cassandra作为存储,近邻团队在运维了一段时刻的Cassandra体系之后,遇到不少的问题,Cassandra体系可操作性没有到达预期,现在除了Tracing相关的体系,其他事务现已抛弃运用Cassandra。

咱们从已有的离线存储体系动身,在衡量了稳定性、功用、代码成熟度、上下游体系接受、业界运用场景以及社区活跃度等方面之后,挑选了HBase,作为知乎在线存储的支撑组件之一。

一、HBase On Kubernetes

在这样的场景下,咱们对在线HBase效劳的需求是清晰的:

阻隔性

资源运用率闻继霞:从运维的视点,资源的分配要合理,尽可能的提高主机cpu,内存包含磁盘的有用运用率;

本钱操控:团队用最小的本钱去得到最大的运维收益,所以需求供给快捷的调用接口,能够灵敏的进行HBase集群的恳求、扩容、办理、监控。一起本钱包含机器资源,还有工程师。其时咱们线上的这套体系是由一位工程师独立去进行保护。

归纳以上需求,参阅咱们团队之前对根底设施渠道化的经历,终究的方针是把HBase效劳做成根底组件效劳渠道向供给给上游事务,这个也是知乎技能渠道部分作业思路之一,尽可能的把一切的组件对事务都黑盒化,接口化,效劳化。一起在运用和监控的粒度上尽可能的精确,详尽,全面。这是咱们构建在线HBase办理运维鸡血藤,补偿MySQL和Redis短板:看HBase怎样确保高可用,上一年夏天体系的一个初衷。

二、Why Kubernetes?

前文提到咱们期望将整个HBase体系渠道效劳化,那就涉及到怎么办理和运维HBase体系,知乎在微效劳和容器方面的作业堆集和经历是适当丰厚的。

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的资源组件有以下几种:

结合之前Kafka on K8S的经历,出于高可用和扩展性的考虑,咱们没有选用一个Pod里带多个容器的布置方法,一致用一个ReplicationController界说一类HBase组件,便是上图中的Master,Regionserver还有按需创立的Thriftserver;经过以上概念,咱们在K8S上就能够这样界说一套最你走了我哭了小HBase集群:

四、高可用以及毛病康复

作为面向在线事务效劳的体系,高可用和毛病搬运是必需在规划就要考虑的工作,在全体规划中,咱们别离考虑组件等级、集群等级和数据存储等级的可用性和毛病康复问题。

1、组件等级

HBase自身现已考虑了许多毛病切换和康复的计划:

2、集群等级

3、数据等级

一切在K8S上构建的HBase集群都同享了一套HDFS集群,数亲吻妈妈据的可用性由HDFS集群的多副原本供给。

五、完结细汉汉节

1、资源分配

初期物理节点一致选用2*12中心的cpu,128G内存和4T的磁盘,其间磁盘用于树立效劳的HDFS,CPU和内存则在K8S环境中用于树立HBase相关效劳的节点。

Master组件的功用首要是办理HBase集群,Thriftserver组件首要承当署理的人物,所以这两个组件资源都依照固定额度分配。

在对Regionserver组件进行资源分配规划的时分,考虑两种方法去界说资源:

资源分配方法

依照事务需求分配:

一致标准的资源分配:

2、参数装备

根底镜像根据cdh5.5.0-hbase1.0.0构建:

# Example for hbase dockerfile

# install cdh5.5.0-hbase1.0.0

ADD hdfs-site.xml /usr/lib/hbase/conf/

ADD core-site.xml /usr/lib/hbase/conf/

ADD env-init.py /usr/lib/hbase/bin/

ENV JAVA_HOME /usr/lib/jvm/java-8-oracle

ENV HBASE_HOME /usr/lib/hbase

ENV HADOOP_PREFIX /usr/lib/hadoop

ADD env-init.py /usr/lib/hbase/bin/

ADD hadoop_xml_conf.sh /usr/lib/hbase/bin/

REQUEST_DATA = {

"name": 'test-cluster',

"rootdir": "hdfs://namenode01:8020/tmp/hbase/test-cluster",

"zkparent": "/test-cluster",

"zkhost": "zookeeper01,zookeeper02,zookeeper03",

"zkport": 2181,

"regionserver_num": '3',

"codecs": "snappy",

"client_type": "java",

"cpu": '1',

"memory": '30',

"status": "running",

}

经过上面的参数KubasService发动Docker时,在发动指令中运用hadoop_xml_conf.sh和env-init.py修正hbase-site.xml和hbase-env.sh文件来完结最终的装备注入,如下所示:

source /usr/lib/hbase/鸡血藤,补偿MySQL和Redis短板:看HBase怎样确保高可用,上一年夏天bin/hadoop_xml_conf.sh

&& put_config --file /etc/hbase/conf/hbase-site.xml --property hbase.regionserver.codecs --value snappy

&& put_config --file /etc/hba姜宏波老公se/conf/hbase-site.xml --pr慕非池operty zookeeper.znode.parent --value /test-cluster

&& put_config --file /etc/hbase/conf/hbase-site.xml --property hbase.rootdir --value hdfs://namenode01:8020/tmp/hbase/test-cluster

&& put_config --file /etc/hbase/conf/hbase-site.xml --property hbase.zookeeper.quorum --value zookee究组词per01,zookeeper02,zookeeper03

&& put_config --file /etc/hbase/conf/hbase-site.xml --property hbase.zookeeper.property.clientPort --value 2181

&& service hbase-regio警花被nserver start && tail -f /var/log/hbase/hbase-hbase-regionserver.log

3、网络通讯

网络方面,选用了Kubernetes上原生的网络方法,每一个Pod都有自己的IP地址,容器之间能够直接通讯,一起在Kubernetes集群中添加了DNS主动注册和反注册功用,以Pod的标港怂萨沙识姓名作为域名,在Pod创立和重启和毁掉时将相关信息同步大局DNS。

在这个当地咱们遇到过问题,其时咱们的DNS解析不能在Docker网络环境中经过IP反解出对应的容器域名,这就使得Regionserver在发动之后向Master注册和向Zookeeper集群注册的效劳姓名不一致,导致Master中对同一个Regionserver挂号两次,形成Master与Regionserver无法正常通讯,整个集群无法正常供给效劳。

经过咱们对源码的研讨和试验之后,咱们在容器发动Regionserver效劳之前修正/etc/hosts文件,将Kubernetes对注入的hostname信息屏蔽。

这样的修正让容器发动的HBase鸡血藤,补偿MySQL和Redis短板:看HBase怎样确保高可用,上一年夏天集群能够顺畅发动并初始化成功,可是也给运维提高了复杂度,因为现在HBase供给的Master页现在看到的Regionserver都是IP方法的记载,给监控和毛病处理带来了诸多不便。

六、存在问题

初代架构顺畅落地,在成功接入了近十个集群事务之后,这套架构面临了以下几个问题:

办理操作事务HBase集群较为繁琐

HBase装备

HDFS阻隔

监控运维

七、重构

为了进一步处理初版架构存在的问题,优化HBase的管控流程,咱们从头审视了已有的架构,并结合Kubernetes的新特性,对原有的架构进行晋级改造,从头用Golang重写了整个Kubas办理体系的效劳(初版运用了Python进行开发)。

并在Kubas办理体系的根底上,开发了多个用于监控和运维的根底微效劳,提高了在Kubernedocsifytes上进行HBase集群布置的灵nixgix活性,架构如下图所示:

二代架构图

1、Deployment&ConfigMap

Deployment

Deployment布置

ConfigMap

ConfigMap存档

2、组件参数装备

在引进了ConfigMap功用之后,之前创立集群的恳求信息也随之改动。

RequestData

{

"name": "performance-test-rmwl",

"namespace": "online",

"app": "kubas",

"config_template": "online-example-base.v1",

"status": "Ready",

"properties": {

"hbase.regionserver.codecs": "snappy",

"hbase.rootdir": "hdfs://zhihu-example-online:8020/user/online-tsn/performance-test-rmwl",

"hbase.zookeeper.property.clientPort": "2181",

"hbase.zookeeper.quorum": "zookeeper01,zookeeper02,zookeeper03",

"zookeeper.znode.parent": "/performance-test-rmwl"

},

"client_type": "java",

"cluster_uid": "k8s-example-hbase---performance-test-rmwl---example"

}

其间config_template指定了该集群运用的装备信息模板,之后一切和该HBase集群有关的组件萝莉爱装备都由该装备模板烘托出具体装备。

c鸡血藤,补偿MySQL和Redis短板:看HBase怎样确保高可用,上一年夏天onfig_template中还预先约好了HBase组件的根底运转装备信息,如组件类型,运用的发动指令,选用的镜像文件,初始的副本数等。

servers:

{

"master": {

"servertype": "master",

"command": "service hbase-master start && tail -f /var/log/hbase/hbase-hbase-master.log",

"r藁城毛庄杀人eplicas": 1,

"image": "dockerimage.zhihu.example/apps/example-master:v1.1",

"requests": {

"cpu": "5逍遥军神00m",

"memory": "5Gi"

},

"limits": {

"cpu": "4000m"

}

},

}

Docker镜像文件合作ConfigMap功用,在预先约好的途径方法寄存装备文件信息,一起在真实的HBase装备途径中参加软链文件。

RUN mkdir -p /data/hbase/hbase-site

RUN mv /etc/hbase/conf/hbase-site.xml /data/hbase/hbase-site/hbase-site.xml

RUN ln -s /data/hbase/hbase-site/hbase-site.xml /etc/hbase/conf/hbase-site.xml

RUN mkdir -p /data/hbase/hbase-env

RUN mv /etc/hbase/conf/hbase-env.sh /data/hbase/hbase-env/hbase-env.sh

RUN ln -s /data/hbase/hbase-env/hbase-env.sh /etc/hbase/conf/hbase-env.sh

3、构建流程

结合之前对Deployment以及ConfigMap的引进,以及对Dockerfile的修正,整个HBase构建流程也有了改善:

HBaseonKubernetes构建流程

经过结合K8S的ConfigMap功用的陈二珂装备模板,以及KubasAPI调用,咱们就能够在短时刻布置出一套可用的HBase最小集群(2Master + 3Region Server + 2Thriftserver),在一切宿主机Host都现已缓存Docker镜像文件的场景下,布置并发动一整套HBase集群的时刻不超越15秒。

一起在短少专属前端操控台的情况下,能够彻底依托Kubernetesdashboard完结HBase集群组件的扩容缩容,以及组件装备的查询修正更新以及从头布置。

八、资源操控

在完结重构之后,HBase效劳面向知乎内部事务进行敞开,短期内知乎HBase集群上升超越30+集群,伴跟着HBase集群数量的增多,有两个问题逐步闪现:

为了处理如上的两个问题,一起又不能打破资源阻隔的需求,咱们将HBaseRSGroup功用参加到了HBase渠道的办理体系中。

优化后的架构如下:

RSGroup的运用

因为渠道方对事务HBase集群的办理自身就具有阻隔性,所以在进行更进一步资源办理的时分,渠道方选用的是降级的方法来办理HBase集群。

经过监听每个独自集群的目标,假如事务集群的负载在上线一段时刻后低于阈值,渠道方就会合作事务方,将该HBase集群迁移到一套MixedHBase集群上。

一起假如在MixedHBase集群中运转的某个HBase事务负载添加,并继续一段时刻超越阈值后,渠道方就会考虑将相关事务提高至独自的集群。

九、多I鸡血藤,补偿MySQL和Redis短板:看HBase怎样确保高可用,上一年夏天DC优化

跟着知乎事务的开展和扩展,知乎的根底架构逐步晋级至多机房架构,知乎HBase渠道办理方法也在这个过程中进行了进一步晋级,开端构建多机房办理的办理方法;根本架构如下图所示:

多IDC拜访方法

十、数据同步

在各类事务场景中,都存在跨HBase集群的数据同步的需求,比方数据在离线HBase集群和在线集群同步、多IDC集群数据同步等,关于HBase的数据同步来说,分为全量仿制和增量仿制两种方法。

HBase数据同步

在知乎HBase渠道中,咱们选用两种方法进行HBase集群间的数据同步:

HBase Snapshot

全量数据仿制咱们选用了HBaseSnapshot的方法进行;首要运用在离线数据同步在线数据的场景;

WALTransfer

首要用于HBase集群之间的的增量数据同步;增量仿制咱们没有选用HBaseReplication,相关同步方法咱们经过自研的WALTransfer组件来对HBase数据进行增量同步;

WALTransfer经过读取源数据HBase集群供给WAL文件列表,于HDFS集群中定位对应的WAL文件,将HBase张锐轩的增量数据按序写入到意图集群,相关的细节咱们会在今后的文章中具体解析。

十一、监控

从之前重构后的架构图上咱们能够看到,在Kubas效劳中咱们添加了许多模块,这些模块根本归于HBase渠道的监控办理模块。

1、Kubas-Monitor组件

根本的监控模块,选用轮询的方法发现新增HBase集群,经过订阅Zookeeper集群发现HBase集群Master以及Regionserver组。

收集Regionserver Metric中的数据,首要收集数据包含:

其他维度的目标如容器CPU以及Mem占用来自Kubernetes渠道监控,磁盘IO,磁盘占用等来自主机监控:

HBase部分监控

2、Kubas-Region-Inspector组件

HBaseRegion散布监控

经过以上模块收集的监鸡血藤,补偿MySQL和Redis短板:看HBase怎样确保高可用,上一年夏天控信息,根本能够描绘在Kubernet鸡血藤,补偿MySQL和Redis短板:看HBase怎样确保高可用,上一年夏天es上运转的HBase集群的状况信息,并能够辅佐运维办理人员对毛病进行定位扫除。

十二、Future Work

跟着公司事务的快速开展,知乎的HBase渠道事务一起也在不断的迭代优化,短期内咱们会从以下几个方向进一步提高知乎HBase渠道的办理效劳才能:

参阅

作者:张小渔

来历:https://zhuanlan.zhihu.com/p/57739371

dbaplus社群欢迎广阔技能人员投稿,投稿邮箱:editor@dbaplus.cn

索菲麦希拉
知乎 开发 Master
声明:该文观念仅代表作者自己,搜狐号系信息发布渠道,搜狐仅供给信息存储空间效劳。
点击展开全文

上一篇:

下一篇:

相关推荐