HBase入門5(集羣) -壓力分載與失效轉發

在上一篇關於HBase的文章中曾經講述過HBase在分佈式中的架構，這篇文章將會講述HBase在分佈式環境中是如何排除單點故障的(SPFO)，作一個小實驗講述HBase在分佈式環境中的高可用性，親眼看到一些現象，延伸一些思考的話題。 先來回顧一下HBase主要部件：    1.HBaseMaster      2.HRegionServer     3.HBase Client    4.HBase Thrift Server    5.HBase REST Server HBaseMaster     HMaster 負責給HRegionServer分配區域,而且負責對集羣環境中的HReginServer進行負載均衡，HMaster還負責監控集羣環境中的HReginServer的運行情況，若是某一臺HReginServer down機，HBaseMaster將會把不可用的HReginServer來提供服務的HLog和表進行從新分配轉交給其餘HReginServer來提供，HBaseMaster還負責對數據和表進行管理，處理表結構和表中數據的變動，由於在 META 系統表中存儲了全部的相關表信息。而且HMaster實現了ZooKeeper的Watcher接口能夠和zookeeper集羣交互。 HRegionServer     HReginServer負責處理用戶的讀和寫的操做。HReginServer經過與HBaseMaster通訊獲取本身須要服務的數據表，並向HMaster反饋本身的運行情況。當一個寫的請求到來的時候，它首先會寫到一個叫作HLog的write-ahead log中。HLog被緩存在內存中，稱爲Memcache，每個HStore只能有一個Memcache。當Memcache到達配置的大小之後，將會建立一個MapFile，將其寫到磁盤中去。這將減小HReginServer的內存壓力。當一塊兒讀取的請求到來的時候，HReginServer會先在Memcache中尋找該數據，當找不到的時候，纔會去在MapFiles 中尋找。 HBase Client     HBase Client負責尋找提供需求數據的HReginServer。在這個過程當中，HBase Client將首先與HMaster通訊，找到ROOT區域。這個操做是Client和Master之間僅有的通訊操做。一旦ROOT區域被找到之後，Client就能夠經過掃描ROOT區域找到相應的META區域去定位實際提供數據的HReginServer。當定位到提供數據的HReginServer之後，Client就能夠經過這個HReginServer找到須要的數據了。這些信息將會被Client緩存起來，當下次請求的時候，就不須要走上面的這個流程了。 HBase服務接口     HBase Thrift Server和HBase REST Server是經過非Java程序對HBase進行訪問的一種途徑。 進入正題 先來看一個HBase集羣的模擬環境，此環境中一共有4臺機器，分別包含zookeeper、HBaseMaster、HReginServer、HDSF 4個服務，爲了展現失效轉發的效果HBaseMaster、HReginServer各有2臺，只是在一臺機器上即運行了HBaseMaster，也運行了HReginServer。 注意，HBase的集羣環境中HBaseMaster只有失效轉發沒有壓力分載的功能，而HReginServer即提供失效轉發也提供壓力分載。 服務器清單以下：     一、zookeeper              192.168.20.214     二、HBaseMaster        192.168.20.213/192.168.20.215     三、HReginServer        192.168.20.213/192.168.20.215     四、HDSF                       192.168.20.212 整個模擬環境的架構如圖所示： 注意，這裏只是作了一個模擬環境，由於這個環境的重點是HBase，因此zookeeper和HDFS服務都是單臺。 雖說在整個HBase的集羣環境中只能有一個HMaster，但是在集羣環境中HMaster能夠啓動多個，但真正使用到的HMaster Server只有一個，他不down掉的時候，其餘啓動的HMasterServer並不會工做，直到與ZooKeeper服務器判斷與當前運行的HMaster通信超時，認爲這個正在運行的HMaster服務器down掉了，Zookeeper纔會去鏈接下一臺HMaster Server。 簡單來講,若是運行中HMaster服務器down掉了，那麼zookeeper會從列表中選擇下一個HMaster 服務器進行訪問，讓他接管down掉的HMaster任務，換而言之，用Java客戶端對HBase進行操做是經過ZooKeeper的，也就是說若是zookeeper集羣中的節點全掛了那麼HBase的集羣也掛了。自己HBase並不存儲中的任何數據 真正的數據是保存在HDFS上，因此HBase的數據是一致的，可是HDFS文件系統掛了，HBase的集羣也掛。 在一臺HMaster失敗後，客戶端對HBase集羣環境訪問時，客戶端先會經過zookeeper識別到HMaster運行異常，直到確認屢次後，才鏈接到下一個HMaster，此時，備份的HMaster服務才生效，在IDE環境中的效果，如圖所示： 上圖中能看見拋出的一些異常和name:javahttp://www.javabloger.com和name:javahttp://www.javabloger.com1的結果集，由於我在serv215機器上用killall java命令把 HMaster和HReginServer都關掉，而且馬上用Java客戶端對HBase的集羣環境進行訪問有異常拋出，可是retry到必定次數後查詢出結果，前面已經說了訪問HBase是經過zookeeper再和真正的數據打交道，也就是說zookeeper接管了一個standby 的 HMaster，讓原先Standby的HMaster接替了失效的HMaster任務，而被接管的HBaseMaster再對HReginServer的任務進行分配，當 HReginServer失敗後zookeeper會通知 HMaster對HReginServer的任務進行分配。這樣充分的說明了HBase作到了實效轉發的功能。 如圖所示：   口水： 一、HBase的失效轉發的效率比較慢了，不期望能在1-2秒切換和恢復完畢，也許是我暫時沒有發現有什麼參數能夠提升失效轉發和恢復過程的速度，未來會繼續關注這個問題。 二、在官方網站上看見HBase0.89.20100924的版本有篇講述關於數據同步的文章，我嘗試了一下在一臺機器上能夠運行所謂的HBase虛擬集羣環境，可是切換到多臺機器的分佈式環境中，單點失效轉發的速度很慢比HBase0.20.6還要慢，我又檢查了是否存在網絡的問題，目前還沒有找到正確的答案，對與HBase0.89.20100924 新版中的數據同步的原理，如圖所示：(更多信息)

更多精彩內容請關注：http://bbs.superwu.cn

關注超人學院微信二維碼：