HBase 高可用集群運維實踐

隨著越來越多的業務選擇HBase作為存儲引擎，對HBase的可用性要求也越來越高，對于HBase的運維也提出了新的挑戰。目前運維集群超過30+，而且接入的業務類型繁多，對于性能要求也不完全一樣，這是今年面臨的問題。從15年開始，結合京東的業務情況，基于大數據平臺，實現用戶接入使用全流程自動化。而今年，我們主要從集群層面上提升集群可用性。

1.控制隔離——rsgroup

在94版本中，經常困擾我們的一個問題就是集群上的某些機器會因為某些用戶的不恰當操作，例如熱點問題，大量的scan操作等導致機器上的其他表正常讀寫受到影響。之前的運維經驗，一般的做法就是stop balance，然后通過move region的方式把有影響的表移到某些機器上。由于存在這個原因和業務的壓力，往往只能采用拆分集群的方式，在一個HDFS 上往往運行幾個HBase集群，但是帶來的是運維成本的增加。  

今年618之前，在我們決定采用新版本之后，我們將HBase 2.0 尚未發布的rsgroup功能遷移到我們的自己維護的1.1.X版本中，從而實現在HBase集群上隔離和控制。整個架構如下：

最后我們把分組功能接入了BDP運維平臺。DBA在配置實例的時候，根據業務選擇不同的分組。通過rsgroup 解決拆分集群問題，可運維性也得到了提升。另外，不同于之前的平滑滾動重起，動不動就需要幾天，我們也通過移動分組的方式進行集群滾動從而縮短維護時間。考慮到不同分組的replication可能會產生影響，我們也開發不同分組的replication功能，主集群的日志只能發送到備份集群的同一個分組的regionserver中。在集群頁面上，我們也添加不同分組統計，效果如下：

2.異地容災——replication

HDFS提供了三個備份的功能，但是對于重要的業務還遠遠不夠。HBase本身的replication功能可以實現集群間秒級的數據同步，而且整個replication的過程是異步化，對于主集群幾乎沒有影響。考慮業務的重要性，在新版本的集群配置了集群間的主主同步。如果機房出現問題或者主集群異常短時間無法恢復，那么用戶可以切換到備份集群。

由于采用實例來管理集群，所以DBA配置的時候可以選擇實例是否進行主備以及集群：增加備份集群之后，我們把所有需要抽取的表從主集群改成為備份集群，這樣對于大量的抽取可以減少對主集群的影響。

目前集群的數據，除了用戶普通的寫入之外，還有采用bulkload的方式入庫，不同用戶在不同的集市生成HFile導入到HBase中。針對這種情況，我們把2.0 版本的HBASE-13153（Bulk Loaded HFile Replication）打進到我們的版本中，實現了HFile的replication。

最終通過replication實現數據的備份和聚合，這樣在用戶申請實例的時候，可以選擇不同的套餐組合。例如只需要實時數據存儲，可以選擇主主備份，需要離線分析的可以選擇主備同步到離線分析集群。

3.資源限制——配置quotas

雖然rsgroup 起到了隔離功能，HBase本身讀寫隊列分離，但是同個分組的表還會互相影響，而且京東這么多業務部門，不可能都獨立分組。HBase1.0 發布了一個針對讀寫進行限制的功能——配額管理。使用配額管理做到對namespace和table 的rpc請求的限制，目前是限制讀寫次數和流量。這個功能很適合我們，作為底層提供者，很大程度上我們沒有辦法預估用戶的所有情況，在運維過程中，經常有用戶出現熱點問題導致單臺服務的請求量過高從而影響到了其他表的讀寫。我們針對實例，也就是表空間的請求進行限制，這就需要用戶在申請的時候衡量資源了。

通過配額，我們可以做到對集群的資源整體把控。唯一的遺憾是當前HBase的quotas 只能限制單臺的ReginServe。目前配額管理功能在開發集成自動化配置流程當中，預計年后上線。

總結

目前我們準備這 三把利劍保障了集群的穩定性，但是隨著業務規模的增大， 我們也越來越重視客戶端， 目前也在對客戶端進行改造。希望通過 SDK 實現集群主備切換，接入 UMP 采集更多性能指標，做到提前發現問題 ，從而保障集群穩定。

來自：http://mp.weixin.qq.com/s/Acgeh_UIzfBX-da1epQ0zw