「從零單排HBase 10」HBase叢集多租戶實踐

lican123發表於2020-05-13

在HBase1.1.0釋出之前，HBase同一叢集上的使用者、表都是平等的，大家平等共用叢集資源。容易碰到兩個問題：

  • 一是某些業務較其他業務重要，需要在資源有限的情況下優先保證核心重要業務的正常執行
  • 二是有些業務QPS常常很高，佔用大量系統資源，導致其他業務無法正常運轉。

這是典型的多租戶問題。因此，我們需要通過資源隔離來解決多租戶問題，同時，需要考慮計算型業務與儲存型業務混合部署來提高叢集的資源利用率。

1.基本概念

1.1 namespace邏輯隔離

HBase名稱空間 namespace 與關聯式資料庫系統中的資料庫database類似，方便對錶在業務上進行劃分，實現邏輯隔離。

Apache HBase從0.98.0, 0.95.2兩個版本開始支援namespace級別的授權操作，HBase全域性管理員可以建立、修改和回收namespace的授權。

這種抽象為即將出現的多租戶相關功能奠定了基礎。

1.2. 配額管理(Quotas)

資源限制，主要針對使用者、namespace以及表的QPS和請求大小進行限制。

相關jira見：

https://issues.apache.org/jira/browse/HBASE-8410、https://issues.apache.org/jira/browse/HBASE-11598

一般可以對熱點表進行限制，或者在高峰期，對非核心業務表進行限制。

常用語句：

hbase> set_quota TYPE => THROTTLE, TABLE => 't1', LIMIT => '1000req/sec'
hbase> set_quota TYPE => THROTTLE, THROTTLE_TYPE => WRITE, USER => 'u1', LIMIT => '10M/sec'

注意事項:

1）set_quota 的限制都是針對單個region server來說的，並不是針對整個叢集，是一種分散式的限制

2）set_quota 預設執行後並不會立刻生效，需要等待一段時間才會生效，等待時間預設為5min。可以通過引數 hbase.quota.refresh.period 進行設定，比如可以通過設定

hbase.quota.refresh.period = 60000將生效時間縮短為1min

3）可以通過命令list_quotas檢視當前所有執行的set_quota命令

4）本質上是一種限流手段，無法充分隔離資源

1.3 RS隔離 （region group）

一般情況下，為了保證核心業務的隔離性，會為每個業務搭建一個叢集，但是這樣可能會導致資源使率過低，比如有些業務重計算輕儲存，有些業務重儲存輕計算，完全的物理隔離勢必帶來資源的不協調，有些叢集資源過剩，有些叢集資源不足。

對此，得益於HBase的共享儲存、計算分離的架構，Hbase提供了多租戶隔離技術region group。

相關jira見：

https://issues.apache.org/jira/browse/HBASE-6721

RegionServer Group 技術是通過對 RegionServer 進行分組，不同的 RegionServer 分到不同的組。每個組可以按需掛載不同的表，並且當組內的表發生異常後，Region 不會遷移到其他的組。這樣，每個組就相當於一個邏輯上的子叢集，通過這種方式達到儲存資源共享、計算資源隔離的效果，提高資源利用率，降低管理成本，不必為每個高 SLA 的業務線單獨搭叢集。

 

2.多租戶核心架構圖

下面，我們進一步深入多租戶的核心架構圖，通過架構圖能清晰的看到，資源的隔離和共享情況，某一個租戶的RS上哪些操作會對其他租戶的資源產生影響，具體影響在哪裡，影響大小如何量化。

從上圖可以看的，group對region server做了隔離，因此，在計算資源上是物理隔離的。

因此，多租戶場景下，相互直接的影響是在共享儲存層面的。

在共享儲存上，發生相互影響的根本原因在於HDFS的資料三副本寫入，如下圖所示

 

從以上可以看出多租戶間可能產生的影響主要來自於其他租戶引發的一些寫流量，主要包括：

  • HBase寫入產生的WAL同步
  • MemStore 刷盤導致的資料同步（flush）
  • StoreFile合併導致的資料同步（MinorCompaction & MajorCompaction）
  • 尤其是大資料量的寫入，會對其他group的load造成顯著影響

3.容量規劃

一個例項（叢集）的情況下，壓測的結果和效能表現就是該例項（叢集）的prod後實際執行的表現，但是針對一個叢集多個使用者的情況（主要是HBase的儲存節點共享），如何來評估容量，分配資源顯然更具挑戰。

重點解決業務訴求對HBase叢集資源的合理科學分配。例如下面這個參考：

 

為了方便我們識別某個業務是“儲存型”還是“計算型”，我們對當前業務需要的機器做個評估。

定義資源係數m（簡化計算，暫時不考慮記憶體）：

m = 核數 * cpu使用率/ （儲存容量*容量使用率）

由於我們一般採用8c64g 1788GB(三副本，實際儲存為0.6T)作為標準core，根據上文資源係數m的計算公式：

標準core的

m = 8 * 50%/（0.6*100%） = 6.67

 

其中，cpu安全水位為50%。

如果某個業務的預估m值低於6.67，則認為是儲存型，高於6.67則認為是計算型（當然，隨著業務的發展，這個偏向可能會發生變化）。

多租戶的核心在於提高資源利用率，因此，我們需要將便計算型業務和便儲存型業務進行混合部署。

4.告警監控

同叢集多租戶下的監控告警方案，區別不同叢集的監控方案，需要更細粒度的關係對映。

對於多租戶叢集，採用最小租戶單位為namespace，記錄namespace對應的group name、core-id

1）監控看版

在原本叢集監控的基礎上，手動記錄租戶與例項資源的對映關係，然後在目前的看板上進一步篩選core-id進行監控。

2）告警

監控針對core-id進行指標判斷，一旦指標到達閾值，根據instanceid、core-id請求hbase-ops獲取相關報警聯絡人

沒有按core區分的系統指標只需要instanceid，請求hbase-ops獲取該叢集所有相關聯絡人。

5.多租戶最佳實踐

  • 單個叢集不能太小，太小沒有意義。
  • 單個group內region server也不要太少，至少2個，region server越少，單個region server故障的影響面越大。
  • 如果做了group，那麼default的group最好空出來，只用來放meta表。
  • 最佳模式是按照namespace緯度進行group的劃分。
  • 叢集中，可以劃分一個buffer group，不承擔任何流量，如果出現線上的熱點，可以臨時把這個熱點表移動到buffer group上

 

看到這裡了，原創不易，點個關注、點個贊吧，你最好看了～

知識碎片重新梳理，構建Java知識圖譜：https://github.com/saigu/JavaKnowledgeGraph（歷史文章查閱非常方便）

相關文章