HBase集群中RegionServer崩潰快速恢復(fù)探索

責(zé)任編輯:editor004

2015-07-15 22:26:27

摘自:電子技術(shù)應(yīng)用

摘 要:本文 主要介紹了HBaseRegionServer與Zookeeper間的交互過程,闡述RegionServer崩潰后的恢復(fù)機(jī)制,并在此基礎(chǔ)上提出了幾點(diǎn)優(yōu)化的恢復(fù)措施。

摘 要:本文 主要介紹了HBaseRegionServer與Zookeeper間的交互過程,闡述RegionServer崩潰后的恢復(fù)機(jī)制,并在此基礎(chǔ)上提出了幾點(diǎn)優(yōu)化的恢復(fù)措施。優(yōu)化后的恢復(fù)措施大大縮短了RegionServer崩潰后的故障恢復(fù)時間和業(yè)務(wù)中斷時間,從而提高了HBase集群的穩(wěn)定性和可靠性。

0 引言

隨著互聯(lián)網(wǎng)和通信行業(yè)的迅猛發(fā)展,積聚的各種數(shù)據(jù)呈急劇增長態(tài)勢。這些海量數(shù)據(jù)既蘊(yùn)含著豐富的信息和資源,又面臨著信息有效管理和提取的難題。云計(jì)算是分布式處理、并行處理和網(wǎng)格計(jì)算的發(fā)展,可以提供近乎無限的廉價存儲和計(jì)算能力,特別適合于日益暴增的海量數(shù)據(jù)的存儲和處理。在云計(jì)算領(lǐng)域中,Hadoop體系獨(dú)樹一幟,其豐富的子系統(tǒng)可以滿足多種領(lǐng)域和行業(yè)的應(yīng)用需求,而其中的HBase作為一種非結(jié)構(gòu)化數(shù)據(jù)庫,特別適合于各種非結(jié)構(gòu)化和半結(jié)構(gòu)化的松散數(shù)據(jù)的存儲和管理。

HBase是一個高可靠性、高性能、面向列、可伸縮、實(shí)時讀寫的分布式存儲數(shù)據(jù)庫系統(tǒng)[1-3]。HBase建立在HDFS分布式文件系統(tǒng)基礎(chǔ)之上,其中的數(shù)據(jù)最終以HFile的格式存儲在HDFS之上;HBase可以通過內(nèi)嵌的MapReduce組件實(shí)現(xiàn)復(fù)雜任務(wù)的并行和分布處理,具有很高的性能。

1 HBase體系結(jié)構(gòu)

HBase主要由HMaster和RegionServer兩部分組成,輔以Zookeeper協(xié)調(diào)集群中各網(wǎng)元之間的數(shù)據(jù)共享和訪問,其組成框圖如圖1所示[4]。

(1)Client:訪問HBase的接口,維護(hù)著一些加快HBase訪問的緩存,比如Region的位置信息等。

(2)Master:負(fù)責(zé)Region到RegionServer的分配以及映射關(guān)系維護(hù);管理集群中的RegionServer及其負(fù)載均衡;維護(hù)數(shù)據(jù)表和其所在Region的元數(shù)據(jù)信息;處理表級的操作請求等。

(3)RegionServer:維護(hù)Master分配給它的Region,處理對這些Region的讀寫請求;負(fù)責(zé)運(yùn)行過程中過大的Region的Split和Compact操作。

(4)Zookeeper:保證任何時候集群中只有一個激活的Master;存儲RootRegion和Master的位置;存儲所有RegionServer的位置并實(shí)時監(jiān)控其狀態(tài);存儲HBase的其他運(yùn)行所需的信息[5]。

HBase中的數(shù)據(jù)單元通過主鍵、列簇、列名和版本號唯一確定,所有行按字典順序排列。HBase中的表在行的方向上分割為多個Region,每個Region只存儲表中某一范圍的數(shù)據(jù),并且每個Region只能被一個RegionServer管理。Region由一個或者多個Store組成,每個Store保存一個列簇;Store又由一個MemStore和0至多個storefile組成,storefile以HFile的格式存儲于HDFS上。

由此可見,HBase中的表通常被劃分為多個Region,而各個Region可能被不同的RegionServer所管理??蛻舳送ㄟ^Master和相關(guān)操作獲取目標(biāo)Region的位置后,最終通過RegionServer完成對用戶表的讀寫請求。因此,如果某個RegionServer異常,客戶端對其所管理的Region的訪問就會失敗,造成了業(yè)務(wù)中斷,這在在線系統(tǒng)中是不可接受的。雖然HBase中實(shí)現(xiàn)了RegionServer異常后的自動恢復(fù)機(jī)制,但是這種機(jī)制的時延很大,不能滿足實(shí)際應(yīng)用需求。因此,本文針對這部分進(jìn)行了研究,并提出了一種可以快速、高效恢復(fù)業(yè)務(wù)的方法。

2 HBase集群與Zookeeper交互機(jī)制分析

在HBase的使用過程中,Zookeeper起著至關(guān)重要的作用。正是Zookeeper的存在,使得HBase的運(yùn)行更加穩(wěn)定和高效。

在配置環(huán)境中,Zookeeper集群中的HBase的目錄如圖2所示。

HBase集群的相關(guān)信息存儲在Zookeeper集群中的hbase目錄(這個目錄是可以配置的)下,其中master目錄存儲HMaster的位置等相關(guān)信息,rs目錄存儲所有的RegionServer的位置等相關(guān)信息。

在HMaster啟動時,會在Zookeeper集群中創(chuàng)建自己的ZNode臨時節(jié)點(diǎn)并獲得該節(jié)點(diǎn)的獨(dú)占鎖,該節(jié)點(diǎn)位于Zookeeper集群中的/hbase/master目錄下。同時會在所有的其他目錄上創(chuàng)建監(jiān)聽,這樣當(dāng)其他節(jié)點(diǎn)的狀態(tài)發(fā)生變化時,HMaster就可以立即感知從而進(jìn)行相應(yīng)的處理。

在RegionServer啟動時,會在Zookeeper集群中創(chuàng)建自己的ZNode臨時節(jié)點(diǎn)并獲得該節(jié)點(diǎn)的獨(dú)占鎖,這個節(jié)點(diǎn)位于Zookeeper集群中的/hbase/rs目錄下。

RegionServer會通過Socket連接向Zookeeper集群發(fā)起Session會話,會話建立后在Zookeeper集群中創(chuàng)建屬于自己的臨時節(jié)點(diǎn)ZNode。這個節(jié)點(diǎn)的狀態(tài)是由Zookeeper集群依據(jù)Session的狀態(tài)來維護(hù)的。

RegionServer作為客戶端,向Zookeeper集群的Server端發(fā)起Session會話請求。Session建立后,會以唯一的SessionID作為標(biāo)示。Client會定期向Server端發(fā)送Ping消息來表達(dá)該Session的存活狀態(tài);而Server端收到Ping消息時會更新當(dāng)前Session的超時時間。如此,對于Client而言,只要Ping信息可達(dá)則表明該Session激活;對于Server而言,只要Session未超時則表明該Session激活。

在Server端,Zookeeper會啟動專門的SessionTrackerImpl線程來處理Session的相關(guān)狀態(tài)遷移問題,該線程每隔tickTime(Zookeeper配置文件中指定,默認(rèn)為2 s)時間遍歷一次Session列表,如果超時則立即關(guān)閉此Session,同時刪除與該Session關(guān)聯(lián)的臨時節(jié)點(diǎn),并將該事件通知給注冊了該節(jié)點(diǎn)事件的組件。在HBase集群中,這就意味著如果RegionServer崩潰,則Zookeeper需要在Session超時后才能通知Master,后者才能啟動故障恢復(fù)。

而Session的超時時間是這樣確定的:HBase默認(rèn)的Timeout為180 s,在創(chuàng)建Session時會將該參數(shù)傳遞給Server端。最終協(xié)商確定的Session的超時時間由Zookeeper的配置參數(shù)決定,處于Zookeeper集群minSessionTimeout和maxSessionTimeout之間。默認(rèn)的minSessionTimeout=2×tickTime(默認(rèn)2 s)=4 s,maxSessionTimeout=20×tickTime=40 s。不管Client傳遞的Timeout多大,最終協(xié)商確定的Session的Timeout時間都在4~40 s之間,實(shí)現(xiàn)代碼如下。如果一切按照默認(rèn)配置,則Session的Timeout為40 s。

int sessionTimeout=connReq.getTimeOut;

int minSessionTimeout=getMinSessionTimeout;

if(sessionTimeout

sessionTimeout=minSessionTimeout;

}

int maxSessionTimeout=getMaxSessionTimeout;

if(sessionTimeout>maxSessionTimeout){

sessionTimeout=maxSessionTimeout;

}

cnxn.setSessionTimeout(sessionTimeout);

經(jīng)以上分析,可以得出以下結(jié)論:Session存活意味著RegionServer存活;Session超時意味著RegionServer啟動時創(chuàng)建的ZNode節(jié)點(diǎn)被刪除,也就表明該RegionServer異常。

[page]

3 HBase中RegionServer異常后的恢復(fù)機(jī)制分析

通過以上的分析可以看出,當(dāng)HBase集群中的一個RegionServer崩潰(如RegionServer進(jìn)程掛掉)后,此時該RegionServer和Zookeeper集群的Server間的Socket連接會斷開,但是二者之間的Session由于有超時時間的存在而不會立即被刪除,需要等到Session超時之后才會被Zookeeper集群刪除,只有Session超時了Zookeeper集群才會刪除該RegionServer啟動時創(chuàng)建的臨時節(jié)點(diǎn)。只有Zookeeper集群中代表此RegionServer的節(jié)點(diǎn)刪除后,HMaster才可以得知該RegionServer發(fā)生故障,才能啟動故障恢復(fù)流程。HMaster恢復(fù)故障時,將故障RegionServer所管理的Region一個一個重新分配到集群中。

由此可得出以下結(jié)論:Session Timeout的存在使得HMaster無法立即發(fā)現(xiàn)故障RegionServer,從而延遲了故障的恢復(fù)時間,間接增加了業(yè)務(wù)中斷的時間。同時,HMaster重新分配Region的處理過程效率太低,尤其是Region數(shù)目很大時。

4 改進(jìn)的RegionServer異常后的恢復(fù)措施

針對以上場景,本文進(jìn)行了如下改進(jìn):

(1)在RegionServer的啟動腳本中加入特殊處理的代碼,在該RegionServer的進(jìn)程結(jié)束前自動刪除其在Zookeeper集群中創(chuàng)建的ZNode節(jié)點(diǎn),這樣HMaster就能立即感知到RegionServer的狀態(tài)異常事件,盡早地啟動異常恢復(fù),代碼如下。

cleanZNode

{

if[-f $HBASE_ZNODE_FILE];then

#call ZK to delete the node

ZNODE=`cat $HBASE_ZNODE_FILE`

$bin/hbase zkcli delete $ZNODE>/dev/null 2>&1

rm $HBASE_ZNODE_FILE

fi

}

(2)在HMaster的恢復(fù)過程中加入特殊處理的代碼,通過批量處理,將故障RegionServer所管理的Region一次性地分配到集群中,如同HBase集群啟動時批量分配Region的過程,提高Region分配的速度。所謂批量分配,就是先獲取故障RegionServer所管理的Region數(shù)目rn和存活的RegionServer的數(shù)目rs,按照平均負(fù)載的原則,在每個存活的RegionServer上分配rn/rs個Region。這樣就可以將多個Region一次分配給一個RegionServer;而原來的分配過程則是一次分配一個Region到一個RegionServer上,顯然改進(jìn)后的處理效率更高,尤其是Region數(shù)目較多時尤為明顯。

采用以上的處理方式后,HBase集群中當(dāng)一個或幾個RegionServer發(fā)生故障后,業(yè)務(wù)的恢復(fù)速度提升了幾十倍,從最初的故障恢復(fù)時間40 s左右到現(xiàn)在的幾秒,實(shí)測數(shù)據(jù)如表1所示。

5 結(jié)論

本文在論述HBase集群與Zookeeper集群的交互機(jī)制以及RegionServer發(fā)生故障后的異常處理恢復(fù)機(jī)制的基礎(chǔ)上,提出了提高恢復(fù)效率、降低業(yè)務(wù)中斷時間的改進(jìn)方案。該方案對于RegionServer進(jìn)程的異常終止和崩潰有很好的處理效果,但是對于RegionServer斷電等物理事件導(dǎo)致的異常則無效,這種情況只能依靠Session Timeout后的處理流程。批量恢復(fù)的處理對所有的恢復(fù)過程都是有效的,雖然其提供的改進(jìn)空間較小。總體說來,本文提出的RegionServer崩潰后的改進(jìn)措施在通常情況下能夠較好地改進(jìn)現(xiàn)有HBase集群的性能,縮短故障恢復(fù)時間,提高故障恢復(fù)效率,從而能有效縮短業(yè)務(wù)中斷時間。

鏈接已復(fù)制,快去分享吧

企業(yè)網(wǎng)版權(quán)所有?2010-2024 京ICP備09108050號-6京公網(wǎng)安備 11010502049343號