HBase怎么確保高可用

HBase怎么確保高可用，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡(jiǎn)單易行的方法。

HBase是一個(gè)基于Hadoop面向列的非關(guān)系型分布式數(shù)據(jù)庫(kù)(NoSQL)，設(shè)計(jì)概念來源于谷歌的BigTable模型，面向?qū)崟r(shí)讀寫、隨機(jī)訪問大規(guī)模數(shù)據(jù)集的場(chǎng)景，是一個(gè)高可靠性、高性能、高伸縮的分布式存儲(chǔ)系統(tǒng)，在大數(shù)據(jù)相關(guān)領(lǐng)域應(yīng)用廣泛。

HBase系統(tǒng)支持對(duì)所存儲(chǔ)的數(shù)據(jù)進(jìn)行透明切分，從而使得系統(tǒng)的存儲(chǔ)以及計(jì)算具有良好的水平擴(kuò)展性。

知乎從2017年起開始逐漸采用HBase系統(tǒng)存儲(chǔ)各類在線業(yè)務(wù)數(shù)據(jù)，并在HBase服務(wù)之上構(gòu)建各類應(yīng)用模型以及數(shù)據(jù)計(jì)算任務(wù)。

• 伴隨著知乎這兩年的發(fā)展，知乎核心架構(gòu)團(tuán)隊(duì)基于開源容器調(diào)度平臺(tái)Kubernetes打造了一整套HBase服務(wù)平臺(tái)管理系統(tǒng);

• 經(jīng)過近兩年的研發(fā)迭代，目前已經(jīng)形成了一套較為完整的HBase自動(dòng)化運(yùn)維服務(wù)體系，能夠完成HBase集群的快捷部署、平滑擴(kuò)縮容、HBase組件細(xì)粒度監(jiān)控、故障跟蹤等功能。

背景

知乎對(duì)HBase的使用經(jīng)驗(yàn)不算太長(zhǎng)，在2017年初的時(shí)候，HBase服務(wù)主要用于離線算法、推薦、反作弊，還有基礎(chǔ)數(shù)據(jù)倉(cāng)庫(kù)數(shù)據(jù)的存儲(chǔ)計(jì)算，通過MapReduce和Spark來進(jìn)行訪問。而在當(dāng)時(shí)知乎的在線存儲(chǔ)主要采用MySQL和Redis系統(tǒng)，其中：

• MySQL：支持大部分的業(yè)務(wù)數(shù)據(jù)存儲(chǔ)，當(dāng)數(shù)據(jù)規(guī)模增大后有一些需要進(jìn)行擴(kuò)容的表，分表會(huì)帶來一定的復(fù)雜性，有些業(yè)務(wù)希望能屏蔽這個(gè)事情，還有一些是因?yàn)闅v史原因在表設(shè)計(jì)的時(shí)候用rmsdb的形式存了一些本該由列存儲(chǔ)的數(shù)據(jù)，希望做一下遷移。此外MySQL基于SSD，雖然性能很好，花銷也比較大;

• Redis：可以提供大規(guī)模的緩存，也可以提供一定的存儲(chǔ)支持。Redis性能極好，主要的局限是做數(shù)據(jù)Resharding較為繁瑣，其次是內(nèi)存成本較高。

針對(duì)以上兩種在線存儲(chǔ)所存在的一些問題，我們希望建立一套在線存儲(chǔ)NoSQL服務(wù)，對(duì)以上兩種存儲(chǔ)作為一個(gè)補(bǔ)充。

選型期間我們也考慮過Cassandra，早期一些業(yè)務(wù)曾嘗試使用Cassandra作為存儲(chǔ)，隔壁團(tuán)隊(duì)在運(yùn)維了一段時(shí)間的Cassandra系統(tǒng)之后，遇到不少的問題，Cassandra系統(tǒng)可操作性沒有達(dá)到預(yù)期，目前除了Tracing相關(guān)的系統(tǒng)，其他業(yè)務(wù)已經(jīng)放棄使用Cassandra。

我們從已有的離線存儲(chǔ)系統(tǒng)出發(fā)，在衡量了穩(wěn)定性、性能、代碼成熟度、上下游系統(tǒng)承接、業(yè)界使用場(chǎng)景以及社區(qū)活躍度等方面之后，選擇了HBase，作為知乎在線存儲(chǔ)的支撐組件之一。

一、HBase On Kubernetes

• 初期知乎只有一套進(jìn)行離線計(jì)算的集群，所有業(yè)務(wù)都跑在一個(gè)集群上，并且HBase集群和其他離線計(jì)算yarn以及Impala混合部署，HBase的日常離線計(jì)算和數(shù)據(jù)讀寫都嚴(yán)重受到其他系統(tǒng)影響;

• 并且HBase的監(jiān)控都只停留在主機(jī)層面的監(jiān)控，出現(xiàn)運(yùn)行問題時(shí)，進(jìn)行排查很困難，系統(tǒng)恢復(fù)服務(wù)時(shí)間較長(zhǎng)，這種狀態(tài)下，我們需要重新構(gòu)建一套適用于在線服務(wù)的系統(tǒng)。

在這樣的場(chǎng)景下，我們對(duì)在線HBase服務(wù)的需求是明確的：

隔離性

• 從業(yè)務(wù)方的視角來說，希望相關(guān)的服務(wù)做到環(huán)境隔離，權(quán)限收歸業(yè)務(wù)，避免誤操作和業(yè)務(wù)相互影響;

• 對(duì)于響應(yīng)時(shí)間，服務(wù)的可用性，都可以根據(jù)業(yè)務(wù)的需要指定SLA;

• 對(duì)于資源的分配和blockcache等參數(shù)的配置也能夠更加有適應(yīng)性，提供業(yè)務(wù)級(jí)別的監(jiān)控和報(bào)警，快速定位和響應(yīng)問題;

資源利用率：從運(yùn)維的角度，資源的分配要合理，盡可能的提升主機(jī)cpu，內(nèi)存包括磁盤的有效利用率;

成本控制：團(tuán)隊(duì)用最小的成本去得到相對(duì)較大的運(yùn)維收益，所以需要提供便捷的調(diào)用接口，能夠靈活的進(jìn)行HBase集群的申請(qǐng)、擴(kuò)容、管理、監(jiān)控。同時(shí)成本包括機(jī)器資源，還有工程師。當(dāng)時(shí)我們線上的這套系統(tǒng)是由一位工程師獨(dú)立去進(jìn)行維護(hù)。

綜合以上需求，參考我們團(tuán)隊(duì)之前對(duì)基礎(chǔ)設(shè)施平臺(tái)化的經(jīng)驗(yàn)，最終的目標(biāo)是把HBase服務(wù)做成基礎(chǔ)組件服務(wù)平臺(tái)向提供給上游業(yè)務(wù)，這個(gè)也是知乎技術(shù)平臺(tái)部門工作思路之一，盡可能的把所有的組件對(duì)業(yè)務(wù)都黑盒化，接口化，服務(wù)化。同時(shí)在使用和監(jiān)控的粒度上盡可能的準(zhǔn)確，細(xì)致，全面。這是我們構(gòu)建在線HBase管理運(yùn)維系統(tǒng)的一個(gè)初衷。

二、Why Kubernetes?

前文說到我們希望將整個(gè)HBase系統(tǒng)平臺(tái)服務(wù)化，那就涉及到如何管理和運(yùn)維HBase系統(tǒng)，知乎在微服務(wù)和容器方面的工作積累和經(jīng)驗(yàn)是相當(dāng)豐富的。

• 在當(dāng)時(shí)我們所有的在線業(yè)務(wù)都已經(jīng)完成了容器化的遷移工作，超萬級(jí)別的業(yè)務(wù)容器平穩(wěn)運(yùn)行在基于mesos的容器管理平臺(tái)Bay上(參見[1]);

• 與此同時(shí)，團(tuán)隊(duì)也在積極的做著Infrastructure容器化的嘗試，已經(jīng)成功將基礎(chǔ)消息隊(duì)列組件Kafka容器化運(yùn)行于Kubernetes系統(tǒng)之上(參見[2])，因此我們決定也將HBase通過Kubernetes來進(jìn)行資源的管理調(diào)度。

Kubernetes[3]是谷歌開源的容器集群管理系統(tǒng)，是Google多年大規(guī)模容器管理技術(shù)Borg的開源版本。Kubernetes提供各種維度組件的資源管理和調(diào)度方案，隔離容器的資源使用，各個(gè)組件的HA工作，同時(shí)還有較為完善的網(wǎng)絡(luò)方案。

Kubernetes被設(shè)計(jì)作為構(gòu)建組件和工具的生態(tài)系統(tǒng)平臺(tái)，可以輕松地部署、擴(kuò)展和管理應(yīng)用程序。有著Kubernetes大法的加持，我們很快有了最初的落地版本([4])。

三、初代

最初的落地版本架構(gòu)見下圖，平臺(tái)在共享的物理集群上通過Kubernetes(以下簡(jiǎn)稱K8S)API建立了多套邏輯上隔離的HBase集群，每套集群由一組Master和若干個(gè)Regionserver(以下簡(jiǎn)稱RS)構(gòu)成，集群共享一套HDFS存儲(chǔ)集群，各自依賴的Zookeeper集群獨(dú)立;集群通過一套管理系統(tǒng)Kubas服務(wù)來進(jìn)行管理([4])。

初代架構(gòu)

模塊定義

在K8S中如何去構(gòu)建HBase集群，首先需要用K8S本身的基礎(chǔ)組件去描述HBase的構(gòu)成;K8S的資源組件有以下幾種：

• Node：定義主機(jī)節(jié)點(diǎn)，可以是物理機(jī)，也可以是虛擬機(jī);

• Pod：一組緊密關(guān)聯(lián)的容器集合，是K8S調(diào)度的基本單位;

• ReplicationController：一組pod的控制器，通過其能夠確保pod的運(yùn)行數(shù)量和健康，并能夠彈性伸縮。

結(jié)合之前Kafka on  K8S的經(jīng)驗(yàn)，出于高可用和擴(kuò)展性的考慮，我們沒有采用一個(gè)Pod里帶多個(gè)容器的部署方式，統(tǒng)一用一個(gè)ReplicationController定義一類HBase組件，就是上圖中的Master，Regionserver還有按需創(chuàng)建的Thriftserver;通過以上概念，我們?cè)贙8S上就可以這樣定義一套最小HBase集群：

• 2*MasterReplicationController;

• 3*RegionserverReplicationController;

• 2*ThriftserverReplicationController(可選);

四、高可用以及故障恢復(fù)

作為面向在線業(yè)務(wù)服務(wù)的系統(tǒng)，高可用和故障轉(zhuǎn)移是必需在設(shè)計(jì)就要考慮的事情，在整體設(shè)計(jì)中，我們分別考慮組件級(jí)別、集群級(jí)別和數(shù)據(jù)存儲(chǔ)級(jí)別的可用性和故障恢復(fù)問題。

1、組件級(jí)別

HBase本身已經(jīng)考慮了很多故障切換和恢復(fù)的方案：

• Zookeeper集群：自身設(shè)計(jì)保證了可用性;

• Master：通過多個(gè)Master注冊(cè)在Zookeeper集群上來進(jìn)行主節(jié)點(diǎn)的HA和更新;

• RegionServer：本身就是無狀態(tài)的，節(jié)點(diǎn)失效下線以后會(huì)把上面的Region自動(dòng)遷走，對(duì)服務(wù)可用性不會(huì)有太大影響;

• Thriftserver：當(dāng)時(shí)業(yè)務(wù)大多數(shù)是Python和Golang，通過用Thrift對(duì)HBase的進(jìn)行，Thriftserver本身是單點(diǎn)的，這里我們通過HAProxy來代理一組Thriftserver服務(wù);

• HDFS：本身又由Namenode和DataNode節(jié)點(diǎn)組成，Namenode我們開啟HA功能，保證了HDFS的集群可用性;

2、集群級(jí)別

• Pod容器失效：Pod是通過Replication Controller維護(hù)的，K8S的Controller  Manager會(huì)在它的存儲(chǔ)etcd去監(jiān)聽組件的失效情況，如果副本少于預(yù)設(shè)值會(huì)自動(dòng)新的Pod容器來進(jìn)行服務(wù);

• Kubernetes集群崩潰：該場(chǎng)景曾經(jīng)在生產(chǎn)環(huán)境中出現(xiàn)過，針對(duì)這種情況，我們對(duì)SLA要求較高的業(yè)務(wù)采用了少量物理機(jī)搭配容器的方式進(jìn)行混合部署，極端場(chǎng)景出現(xiàn)時(shí)，可以保證重要業(yè)務(wù)收到的影響可控;

3、數(shù)據(jù)級(jí)別

所有在K8S上構(gòu)建的HBase集群都共享了一套HDFS集群，數(shù)據(jù)的可用性由HDFS集群的多副本來提供。

五、實(shí)現(xiàn)細(xì)節(jié)

1、資源分配

初期物理節(jié)點(diǎn)統(tǒng)一采用2*12核心的cpu，128G內(nèi)存和4T的磁盤，其中磁盤用于搭建服務(wù)的HDFS，CPU和內(nèi)存則在K8S環(huán)境中用于建立HBase相關(guān)服務(wù)的節(jié)點(diǎn)。

Master組件的功能主要是管理HBase集群，Thriftserver組件主要承擔(dān)代理的角色，所以這兩個(gè)組件資源都按照固定額度分配。

在對(duì)Regionserver組件進(jìn)行資源分配設(shè)計(jì)的時(shí)候，考慮兩種方式去定義資源：

資源分配方式

按照業(yè)務(wù)需求分配：

• 根據(jù)業(yè)務(wù)方對(duì)自身服務(wù)的描述，對(duì)相關(guān)的QPS以及SLA進(jìn)行評(píng)估，為業(yè)務(wù)專門配置參數(shù)，包含blockcache，region大小以及數(shù)量等;

• 優(yōu)點(diǎn)是針對(duì)業(yè)務(wù)優(yōu)化，能夠充分的利用資源，降低業(yè)務(wù)的資源占用成本;

• 管理成本增加，需要對(duì)每一個(gè)業(yè)務(wù)進(jìn)行評(píng)估，對(duì)平臺(tái)維護(hù)人員非常不友好，同時(shí)需要業(yè)務(wù)同學(xué)本身對(duì)HBase有理解;

統(tǒng)一規(guī)格的資源分配：

• CPU以及MEM都按照預(yù)先設(shè)定好的配額來分配，提供多檔的配置，將CPU和MEM的配置套餐化;

• 方便之處在于業(yè)務(wù)擴(kuò)容時(shí)直接增加Regionserver的個(gè)數(shù)，配置穩(wěn)定，運(yùn)維成本較低，遇到問題時(shí)排障方便;

• 針對(duì)某些有特有訪問方式的業(yè)務(wù)有局限性，如CPU計(jì)算型，大KV存儲(chǔ)，或者有MOB需求的業(yè)務(wù)，需要特殊的定制;

• 介于當(dāng)時(shí)考慮接入的在線業(yè)務(wù)并不多，所以采用了按業(yè)務(wù)定制的方式去配置Regionserver，正式環(huán)境同一業(yè)務(wù)采用統(tǒng)一配置的一組Regionserver，不存在混合配置的Regionserver組。

2、參數(shù)配置

基礎(chǔ)鏡像基于cdh6.5.0-hbase1.0.0構(gòu)建：

# Example for hbase dockerfile  # install cdh6.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/

• 固定的環(huán)境變量，如JDK_HOME，HBASE_HOME，都通過ENV注入到容器鏡像中;

• 與HDFS相關(guān)的環(huán)境變量，如hdfs-site.xml和core-site.xml預(yù)先加入Docker鏡像中，構(gòu)建的過程中就放入了HBase的相關(guān)目錄中，用以確保HBase服務(wù)能夠通過對(duì)應(yīng)配置訪問到HDFS;

• 與HBase相關(guān)的配置信息，如組件啟動(dòng)依賴的Zookeeper集群地址，HDFS數(shù)據(jù)目錄路徑，堆內(nèi)存以及GC參數(shù)等，這些配置都需要根據(jù)傳入KubasService的信息進(jìn)行對(duì)應(yīng)變量的修改，一個(gè)典型的傳入?yún)?shù)示例。

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", }

通過上面的參數(shù)KubasService啟動(dòng)Docker時(shí)，在啟動(dòng)命令中利用hadoop_xml_conf.sh和env-init.py修改hbase-site.xml和hbase-env.sh來完成配置注入，如下所示：

source /usr/lib/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/hbase/conf/hbase-site.xml --property 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 zookeeper01,zookeeper02,zookeeper03 && put_config --file /etc/hbase/conf/hbase-site.xml --property hbase.zookeeper.property.clientPort --value 2181 && service hbase-regionserver start && tail -f /var/log/hbase/hbase-hbase-regionserver.log

3、網(wǎng)絡(luò)通信

網(wǎng)絡(luò)方面，采用了Kubernetes上原生的網(wǎng)絡(luò)模式，每一個(gè)Pod都有自己的IP地址，容器之間可以直接通信，同時(shí)在Kubernetes集群中添加了DNS自動(dòng)注冊(cè)和反注冊(cè)功能，以Pod的標(biāo)識(shí)名字作為域名，在Pod創(chuàng)建和重啟和銷毀時(shí)將相關(guān)信息同步全局DNS。

在這個(gè)地方我們遇到過問題，當(dāng)時(shí)我們的DNS解析不能在Docker網(wǎng)絡(luò)環(huán)境中通過IP反解出對(duì)應(yīng)的容器域名，這就使得Regionserver在啟動(dòng)之后向Master注冊(cè)和向Zookeeper集群注冊(cè)的服務(wù)名字不一致，導(dǎo)致Master中對(duì)同一個(gè)Regionserver登記兩次，造成Master與Regionserver無法正常通信，整個(gè)集群無法正常提供服務(wù)。

經(jīng)過我們對(duì)源碼的研究和實(shí)驗(yàn)之后，我們?cè)谌萜鲉?dòng)Regionserver服務(wù)之前修改/etc/hosts文件，將Kubernetes對(duì)注入的hostname信息屏蔽。

這樣的修改讓容器啟動(dòng)的HBase集群能夠順利啟動(dòng)并初始化成功，但是也給運(yùn)維提升了復(fù)雜度，因?yàn)楝F(xiàn)在HBase提供的Master頁(yè)現(xiàn)在看到的Regionserver都是IP形式的記錄，給監(jiān)控和故障處理帶來了諸多不便。

六、存在問題

初代架構(gòu)順利落地，在成功接入了近十個(gè)集群業(yè)務(wù)之后，這套架構(gòu)面臨了以下幾個(gè)問題：

管理操作業(yè)務(wù)HBase集群較為繁瑣

• 需要手動(dòng)提前確定HDFS集群的存儲(chǔ)，以及申請(qǐng)獨(dú)立Zookeeper集群，早期為了省事直接多套HBase共享了一套Zookeeper集群，這和我們?cè)O(shè)計(jì)的初衷不符合;

• 容器標(biāo)識(shí)符和HBaseMaster里注冊(cè)的regionserver地址不一致，影響故障定位;

• 單Regionserver運(yùn)行在一個(gè)單獨(dú)的ReplicationController(以下簡(jiǎn)稱RC)，但是擴(kuò)容縮容為充分利用RC的特性，粗暴的采用增加或減少RC的方式進(jìn)行擴(kuò)容縮容。

HBase配置

• 最初的設(shè)計(jì)缺乏靈活性，與HBase服務(wù)配置有關(guān)的hbase-site.xml以及hbase-env.sh固化在DockerImage里，這種情況下，如果需要更新大量配置，則需要重新build鏡像;

• 由于最初設(shè)計(jì)是共享一套HDFS集群作為多HBase集群的存儲(chǔ)，所以與HDFS有關(guān)的hdfs-site.xml和core-site.xml配置文件也被直接配置進(jìn)了鏡像。如果需要在Kubasservice中上線依賴其他HDFS集群的HBase，也需要重新構(gòu)建鏡像。

HDFS隔離

• 隨著接入HBase集群的增多，不同的HBase集群業(yè)務(wù)對(duì)HDFS的IO消耗有不同的要求，因此有了分離HBase依賴的HDFS集群的需求;

• 主要問題源自Docker鏡像對(duì)相關(guān)配置文件的固化，與HDFS有關(guān)的hdfs-site.xml和core-site.xml配置文件與相關(guān)Docker鏡像對(duì)應(yīng)，而不同Docker鏡像的版本完全由研發(fā)人員自己管理，最初版本的實(shí)現(xiàn)并未考慮到這些問題。

監(jiān)控運(yùn)維

• 指標(biāo)數(shù)據(jù)不充分，堆內(nèi)堆外內(nèi)存變化，region以及table的訪問信息都未有提取或聚合;

• Region熱點(diǎn)定位較慢，無法在短時(shí)間內(nèi)定位到熱點(diǎn)Region;

• 新增或者下線組件只能通過掃KubasService的數(shù)據(jù)庫(kù)來發(fā)現(xiàn)相關(guān)變更，組件的異常如RegionServer掉線或重啟，Master切換等不能及時(shí)反饋;

七、重構(gòu)

為了進(jìn)一步解決初版架構(gòu)存在的問題，優(yōu)化HBase的管控流程，我們重新審視了已有的架構(gòu)，并結(jié)合Kubernetes的新特性，對(duì)原有的架構(gòu)進(jìn)行升級(jí)改造，重新用Golang重寫了整個(gè)Kubas管理系統(tǒng)的服務(wù)(初版使用了Python進(jìn)行開發(fā))。

并在Kubas管理系統(tǒng)的基礎(chǔ)上，開發(fā)了多個(gè)用于監(jiān)控和運(yùn)維的基礎(chǔ)微服務(wù)，提高了在Kubernetes上進(jìn)行HBase集群部署的靈活性，架構(gòu)如下圖所示：

二代架構(gòu)圖

1、Deployment&ConfigMap

Deployment

• Deployment(部署)是Kubernetes中的一個(gè)概念，是Pod或者ReplicaSet的一組更新對(duì)象描述，用于取代之前的ReplicationController。Deployment繼承了ReplicationController的所有功能，并擁有更多的管理新特性;

• 在新的Kubas管理系統(tǒng)中，新設(shè)計(jì)用Deployment代替Replication  Controller做Pod的管理，使用一個(gè)Deployment部署一組Region  Servers的方式來代替單Regionserver對(duì)應(yīng)一個(gè)Replication Controller的設(shè)計(jì)，提升集群部署擴(kuò)縮容管理的靈活性;

• 每一組Deployment都會(huì)注入各類信息維度的標(biāo)簽，如相關(guān)集群的信息就，服務(wù)類型，所屬應(yīng)用等。

Deployment部署

ConfigMap

• ConfigMap是Kubernetes用來存儲(chǔ)配置文件的資源對(duì)象，通過ConfigMap可以將外部配置在啟動(dòng)容器之前掛載到容器中的指定位置，并以此為容器中運(yùn)行的程序提供配置信息;

• 重構(gòu)之后管理系統(tǒng)中，所有HBase的組件配置都存放至ConfigMap之中，系統(tǒng)管理人員會(huì)根據(jù)需-要預(yù)先生成若干HBase的配置模板存放到K8S系統(tǒng)的ConfigMap中;

• 在業(yè)務(wù)方提供出HBase服務(wù)申請(qǐng)時(shí)，管理人員通過業(yè)務(wù)資源的需求結(jié)合配置模板，為申請(qǐng)的HBase集群組件渲染具體的hbase-site。xml以及hbase-env。sh等HBase配置相關(guān)的文件再存放到ConfigMap中;

• 在容器啟動(dòng)時(shí)，k8s會(huì)根據(jù)deployment將ConfigMap中的配置文件Mount到配置中指定的路徑中;

• 和Deployment的操作類似，每一份ConfigMap也都會(huì)標(biāo)記上標(biāo)簽，將相關(guān)的ConfigMap和對(duì)應(yīng)的集群和應(yīng)用關(guān)聯(lián)上。

ConfigMap存檔

2、組件參數(shù)配置

在引入了ConfigMap功能之后，之前創(chuàng)建集群的請(qǐng)求信息也隨之改變。

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集群有關(guān)的組件配置都由該配置模板渲染出具體配置。

config_template中還預(yù)先約定了HBase組件的基礎(chǔ)運(yùn)行配置信息，如組件類型，使用的啟動(dòng)命令，采用的鏡像文件，初始的副本數(shù)等。

servers: {   "master": {     "servertype": "master",     "command": "service hbase-master start && tail -f /var/log/hbase/hbase-hbase-master.log",     "replicas": 1,     "image": "dockerimage.zhihu.example/apps/example-master:v1.1",     "requests": {       "cpu": "500m",       "memory": "5Gi"     },     "limits": {       "cpu": "4000m"     }   }, }

Docker鏡像文件配合ConfigMap功能，在預(yù)先約定的路徑方式存放配置文件信息，同時(shí)在真正的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、構(gòu)建流程

結(jié)合之前對(duì)Deployment以及ConfigMap的引入，以及對(duì)Dockerfile的修改，整個(gè)HBase構(gòu)建流程也有了改進(jìn)：

HBaseonKubernetes構(gòu)建流程

• 編制相關(guān)的Dockerfile并構(gòu)建基礎(chǔ)的HBase組件鏡像;

• 為將要?jiǎng)?chuàng)建的HBase構(gòu)建基礎(chǔ)屬性配置模板，訂制基礎(chǔ)資源，這部分可以通過KubasAPI在Kubernetes集群中創(chuàng)建ConfigMap;

• 具體創(chuàng)建部署集群時(shí)，通過調(diào)用KubasAPI，結(jié)合之前構(gòu)建的ConfigMap模板，渲染出HBase集群中各類組件的詳細(xì)ConfigMap，然后在Kubernetes集群中構(gòu)建Deployment;

• 最終通過之前構(gòu)建好的鏡像加載組件ConfigMap中的配置，完成在KubernetesNode中運(yùn)行的一個(gè)HBase組件容器。

通過結(jié)合K8S的ConfigMap功能的配置模板，以及KubasAPI調(diào)用，我們就可以在短時(shí)間部署出一套可用的HBase最小集群(2Master +  3Region Server +  2Thriftserver)，在所有宿主機(jī)Host都已經(jīng)緩存Docker鏡像文件的場(chǎng)景下，部署并啟動(dòng)一整套HBase集群的時(shí)間不超過15秒。

同時(shí)在缺少專屬前端控制臺(tái)的情況下，可以完全依托Kubernetesdashboard完成HBase集群組件的擴(kuò)容縮容，以及組件配置的查詢修改更新以及重新部署。

八、資源控制

在完成重構(gòu)之后，HBase服務(wù)面向知乎內(nèi)部業(yè)務(wù)進(jìn)行開放，短期內(nèi)知乎HBase集群上升超過30+集群，伴隨著HBase集群數(shù)量的增多，有兩個(gè)問題逐漸顯現(xiàn)：

• 運(yùn)維成本增高：需要運(yùn)維的集群逐漸增高;

• 資源浪費(fèi)：這是因?yàn)楹芏鄻I(yè)務(wù)的業(yè)務(wù)量并不高，但是為了保證HBase的高可用，我們至少需要提供2個(gè)Master+3個(gè)RegionServer，而往往Master的負(fù)載都非常低，這就造成了資源浪費(fèi)。

為了解決如上的兩個(gè)問題，同時(shí)又不能打破資源隔離的需求，我們將HBaseRSGroup功能加入到了HBase平臺(tái)的管理系統(tǒng)中。

優(yōu)化后的架構(gòu)如下：

RSGroup的使用

由于平臺(tái)方對(duì)業(yè)務(wù)HBase集群的管理本身就具有隔離性，所以在進(jìn)行更進(jìn)一步資源管理的時(shí)候，平臺(tái)方采用的是降級(jí)的方式來管理HBase集群。

通過監(jiān)聽每個(gè)單獨(dú)集群的指標(biāo)，如果業(yè)務(wù)集群的負(fù)載在上線一段時(shí)間后低于閾值，平臺(tái)方就會(huì)配合業(yè)務(wù)方，將該HBase集群遷移到一套MixedHBase集群上。

同時(shí)如果在MixedHBase集群中運(yùn)行的某個(gè)HBase業(yè)務(wù)負(fù)載增加，并持續(xù)一段時(shí)間超過閾值后，平臺(tái)方就會(huì)考慮將相關(guān)業(yè)務(wù)提升至單獨(dú)的集群。

九、多IDC優(yōu)化

隨著知乎業(yè)務(wù)的發(fā)展和擴(kuò)大，知乎的基礎(chǔ)架構(gòu)逐漸升級(jí)至多機(jī)房架構(gòu)，知乎HBase平臺(tái)管理方式也在這個(gè)過程中進(jìn)行了進(jìn)一步升級(jí)，開始構(gòu)建多機(jī)房管理的管理方式;基本架構(gòu)如下圖所示：

多IDC訪問方式

• 業(yè)務(wù)HBase集群分別在多個(gè)IDC上運(yùn)行，由業(yè)務(wù)確定IDC機(jī)房的主從方式，業(yè)務(wù)的從IDC集群數(shù)據(jù)通過平臺(tái)方的數(shù)據(jù)同步組件進(jìn)行數(shù)據(jù)同步;

• 各IDC的Kubas服務(wù)主要負(fù)責(zé)對(duì)本地Kubernetes集群的具體操作，包括HBase集群的創(chuàng)建刪除管理，regionserver的擴(kuò)容等HBase組件的管理操作，Kubas服務(wù)部署與機(jī)房相關(guān)，僅對(duì)接部署所在機(jī)房的K8S集群;

• 各IDC的Kubas服務(wù)向集群發(fā)現(xiàn)服務(wù)上報(bào)本機(jī)房集群信息，同時(shí)更新相關(guān)集群主從相關(guān)信息;

• 業(yè)務(wù)方通過平臺(tái)方封裝的ClientSDK對(duì)多機(jī)房的HBase集群進(jìn)行訪問，客戶端通過集群發(fā)現(xiàn)服務(wù)可以確定HBase集群的主從關(guān)系，從而將相關(guān)的讀寫操作分離，寫入修改訪問可以通過客戶端指向主IDC的集群;

• 跨機(jī)房間的數(shù)據(jù)同步采用了自研的HBaseReplicationWALTransfer來提供增量數(shù)據(jù)的同步。

十、數(shù)據(jù)同步

在各類業(yè)務(wù)場(chǎng)景中，都存在跨HBase集群的數(shù)據(jù)同步的需求，比如數(shù)據(jù)在離線HBase集群和在線集群同步、多IDC集群數(shù)據(jù)同步等，對(duì)于HBase的數(shù)據(jù)同步來說，分為全量復(fù)制和增量復(fù)制兩種方式。

HBase數(shù)據(jù)同步

在知乎HBase平臺(tái)中，我們采用兩種方式進(jìn)行HBase集群間的數(shù)據(jù)同步：

HBase Snapshot

全量數(shù)據(jù)復(fù)制我們采用了HBaseSnapshot的方式進(jìn)行;主要應(yīng)用在離線數(shù)據(jù)同步在線數(shù)據(jù)的場(chǎng)景;

WALTransfer

主要用于HBase集群之間的的增量數(shù)據(jù)同步;增量復(fù)制我們沒有采用HBaseReplication，相關(guān)同步方式我們通過自研的WALTransfer組件來對(duì)HBase數(shù)據(jù)進(jìn)行增量同步;

WALTransfer通過讀取源數(shù)據(jù)HBase集群提供WAL文件列表，于HDFS集群中定位對(duì)應(yīng)的WAL文件，將HBase的增量數(shù)據(jù)按序?qū)懭氲侥康募海嚓P(guān)的細(xì)節(jié)我們會(huì)在以后的文章中詳細(xì)解析。

十一、監(jiān)控

從之前重構(gòu)后的架構(gòu)圖上我們可以看到，在Kubas服務(wù)中我們添加了很多模塊，這些模塊基本屬于HBase平臺(tái)的監(jiān)控管理模塊。

1、Kubas-Monitor組件

基本的監(jiān)控模塊，采用輪詢的方式發(fā)現(xiàn)新增HBase集群，通過訂閱Zookeeper集群發(fā)現(xiàn)HBase集群Master以及Regionserver組。

采集Regionserver Metric中的數(shù)據(jù)，主要采集數(shù)據(jù)包括：

• Region的信息，上線region數(shù)量，store的數(shù)量、storefile的大小、storefileindex的大小，讀取時(shí)memstore缺失次數(shù);

• blockcache的信息，例如blockcache中使用多少、空閑多少、累計(jì)的缺失率等;

• 讀寫請(qǐng)求的統(tǒng)計(jì)信息，例如讀寫響應(yīng)時(shí)間，讀寫的表分布、讀寫數(shù)據(jù)量、讀寫失敗次數(shù)等;

• compact與split的操作信息，例如隊(duì)列的長(zhǎng)度、操作次數(shù)和時(shí)間等;

• handler的信息，例如隊(duì)列長(zhǎng)度、處于活躍handler的數(shù)量以及活躍的reader數(shù)量。

其他維度的指標(biāo)如容器CPU以及Mem占用來自Kubernetes平臺(tái)監(jiān)控，磁盤IO，磁盤占用等來自主機(jī)監(jiān)控：

HBase部分監(jiān)控

2、Kubas-Region-Inspector組件

• 采集HBase表Region信息，通過HBaseAPI接口，獲取每個(gè)HBaseRegion的數(shù)據(jù)統(tǒng)計(jì)信息，并將Region數(shù)據(jù)聚合成數(shù)據(jù)表信息;

• 通過調(diào)用開源組件形成HBase集群Region分布的圖表，對(duì)Region熱點(diǎn)進(jìn)行定位;

HBaseRegion分布監(jiān)控

通過以上模塊采集的監(jiān)控信息，基本可以描述在Kubernetes上運(yùn)行的HBase集群的狀態(tài)信息，并能夠輔助運(yùn)維管理人員對(duì)故障進(jìn)行定位排除。

十二、Future Work

隨著公司業(yè)務(wù)的快速發(fā)展，知乎的HBase平臺(tái)業(yè)務(wù)同時(shí)也在不斷的迭代優(yōu)化，短期內(nèi)我們會(huì)從以下幾個(gè)方向進(jìn)一步提升知乎HBase平臺(tái)的管理服務(wù)能力：

• 提升集群安全穩(wěn)定性。加入HBase權(quán)限支持，進(jìn)一步提升多租戶訪問下的安全隔離性;

• 用戶集群構(gòu)建定制化。通過提供用戶數(shù)據(jù)管理系統(tǒng)，向業(yè)務(wù)用戶開放HBase構(gòu)建接口，這樣業(yè)務(wù)用戶可以自行構(gòu)建HBase集群，添加Phoniex等插件的支持;

• 運(yùn)維檢測(cè)自動(dòng)化。自動(dòng)對(duì)集群擴(kuò)容，自動(dòng)熱點(diǎn)檢測(cè)以及轉(zhuǎn)移等;

關(guān)于HBase怎么確保高可用問題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。