PowerScale、Isilon OneFS：Isilon 上的 HBase 效能測試

不需要

不需要

簡介

使用 YCSB 基準測試套件和 CDH 5.10，在 Isilon X410 叢集上執行了一系列效能基準測試。

實驗室測試環境設定了五個執行 OneFS v8.0.0.4 和更新版本 v8.0.1.1 的 Isilon x410 節點。執行網路檔案系統 （NFS） 大型區塊串流效能指標。測試的預期理論聚合最大值為每個節點 ~700 MB/秒 （3.5 GB/秒） 的寫入和 ~1 GB/秒的讀取 （5 GB/秒）。

（9） 個運算節點是執行 CentOS v7.3.1611 的 Dell PowerEdge FC630 伺服器，每個節點配置 2x18C/36T-Intel Xeon® CPU E5-2697 v4 @ 2.30GHz，搭配 512GB RAM。本機儲存裝置為 2xSSD，採用 RAID 1 格式為 XFS，適用於作業系統和暫存空間或溢出檔案。

還有三個額外的邊緣伺服器用於驅動YCSB負載。

計算節點和 Isilon 之間的後端網路為 10 Gbps，並為 NIC 和交換器連接埠設定巨型訊框 （MTU=9162）。
CDH 5.10 設定為在 Isilon Cluster 的存取區域中執行。服務帳戶是在 Isilon 本機提供者和本機用戶端 /etc/passwd 檔案中建立的。所有測試都是使用沒有特殊許可權的基本測試客戶端運行的。

使用 IIQ 和 Grafana/Data Insights 套件監控 Isilon 統計資料。CDH統計數據由Cloudera Manager和Grafana監控。

初始測試

前一系列測試是確定HBASE側影響整體輸出的相關參數。YCSB 工具用於生成 HBASE 的荷載。此初始測試是使用單個用戶端（邊緣伺服器）運行的，使用 YCSB 和 4000 萬行的“載入”階段。此表在每次運行之前被刪除。
 

ycsb load hbase10 -P workloads/workloada1 -p table='ycsb_40Mtable_nr' -p columnfamily=family -threads 256 -p recordcount=40000000

• hbase.regionserver.maxlogs - 最大預先寫入日誌 （WAL） 檔數 - 此值乘以 HDFS 塊大小 （dfs.blocksize） 是伺服器崩潰時必須重播的 WAL 大小。此值與磁碟刷新的頻率成反比。
• hbase.wal.regiongrouping.numgroups - 使用多個 HDFS WAL 作為 WALProvider 時，這會設定每個 RegionServer 應執行的預先寫入記錄數量。結果顯示了 HDFS 管道的數量。給定區域的寫入僅轉到單個管道，從而分散總區域伺服器負載。

   
這裡的理念是並行化盡可能多的寫入。增加 WAL 的數量，然後增加每個 WAL 的線程數（管道）即可實現此目的。前兩個圖表顯示，對於“maxlogs”的給定數位 128 或 256，未顯示實際變化。這表示測試並沒有真正影響用戶端的結果。每個檔的「管道」數量各不相同，顯示出一個趨勢，指示對並行化敏感的參數。下一個問題是，和 Isilon 叢集會「妨礙」磁片 I/O、網路、CPU 或 OneFS 的哪些方面。若要回答此問題，請查看 Isilon 統計報告。
網路和 CPU 圖表顯示 Isilon 叢集未充分利用，並有更多工作空間。CPU 為 > 80%，網路頻寬將超過 3 GB/秒。
 
這些圖表顯示 HDFS 通訊協定的統計資料，以及 OneFS 如何轉換輸出。HDFS ops 是 dfs.blocksize 的倍數，這裡為 256MB。有趣的是，「熱度」圖表會顯示 OneFS 檔案作業，並顯示寫入和鎖定的相互關聯。在這種情況下，HBase 會執行附加至 WAL 的作業，因此 OneFS 會針對附加的每個寫入鎖定 WAL 檔案。這是集群文件系統上穩定寫入的預期。這些似乎有助於這組測試的限制因素。

HBase 更新

下一個測試是做更多的實驗，以發現大規模發生的事情。將創建一個 10 億行的表，該表需要一個小時才能生成。執行 YCSB 測試，使用「workloada」設定 （50/50 讀/寫） 更新 1,000 萬列。此測試在單個用戶端上運行。測試是依 YCSB 執行緒數的函數方式執行，以便產生最大的輸送量。此外，也套用了一些調整，並將 OneFS 升級至 v8.0.1.1，其中有針對資料節點服務的效能有所調整。下圖顯示了與前一組運行相比性能提升的情況。在這些執行中，hbase.regionserver.maxlogs 設定為 256，而 hbase.wal.regiongrouping.numgroups 設定為 20。    
檢閱這些測試執行顯示，在高執行緒計數時出現明顯下降，這可能是 Isilon 或用戶端問題。測試顯示，在 3 毫秒的 < 更新延遲下，每秒有 20 萬次操作，令人印象深刻。每次更新測試執行都很快，可以連續執行。下圖顯示每次測試執行時，Isilon 節點間的均衡狀況。
熱圖顯示檔操作是寫入和鎖定，對應於 WAL 進程的追加性質。

區域伺服器縮放

下一個測試是判斷 Isilon 節點 （五個節點） 在不同數量的區域伺服器上的表現。在上一次測試中運行的相同更新腳本涉及一個十億行表，並使用“workloada”進行了 1000 萬行更新。測試使用了 YCSB 線程設置為 51 的單個用戶端。對最大日誌和管道應用相同的設置（分別為 256 和 20）。  
結果內容豐富，儘管並不令人驚訝。HBase 的橫向擴充特性與 Isilon 的橫向擴充特性，代表越多越好。建議用戶端在其環境中運行此測試，作為其自己的大小調整練習的一部分。這裡有九部伺服器在推動五個 Isilon 節點，在達到收益遞減的點之前，看起來還有更多空間。

更多客戶

最後一系列測試用於測試硬體配置的限制。這樣做是為了確定正在測試的參數的上限。在這一系列測試中，另外兩個伺服器用於從中運行用戶端。此外，每個伺服器運行兩個 YCSB 用戶端，每個用戶端最多允許六個用戶端。每個用戶端驅動 512 個線程，總共產生 4096 個線程。創建了兩個不同的表。一個包含 40 億行的表拆分為 600 個區域，另一個包含 4 億行的表拆分為 90 個區域。  
下圖顯示，在此測試中，表的大小無關緊要。Isilon 熱度圖表再次顯示檔案作業的數量有幾個百分點的差異。大多數差異與 40 億行表與 4 億行表的差異一致。

結論

HBase 非常適合在 Isilon 上執行，主要是因為其橫向擴充到橫向擴充的架構。HBase 會執行大量自己的緩存，並且通過將表拆分到大量區域，HBase 可以隨數據橫向擴展。換句話說，它在滿足自己的需求方面做得很好，並且檔案系統用於應用程式彈性。測試無法將負載推到破壞事物的地步。如果 HBase 設計為 800,000 個操作且延遲小於 3 毫秒，則此體系結構支援它。HBase 支援用戶端和 HBase 本身的大量性能調整和調整。所有這些調整和調整的測試超出了本測試的範圍。