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

簡介

我們使用 YCSB 效能指標套件和 CDH 5.10，對 Isilon X410 叢集進行了一系列效能基準測試測試。

CAE POC 實驗室環境已設定為 5 個 Isilon x410 節點正在執行 OneFS 8.0.0.4 和更新版本 8.0.1.1 NFS 大型區塊串流基準 在任一項測試中，理論匯總最大值應為 5x ~700 MB/秒寫入 （3.5 GB/秒） 和 5x ~1 GB/秒讀取 （5 GB/秒）。

（9） 運算節點是執行 CentOS 7.3.1611 的 Dell PowerEdge FC630 伺服器，每個伺服器都設定為 2 個 18C/36T-Intel Xeon® CPU E5-2697 v4 （2.30GHz，含 512GB RAM）。在 RAID 1 中，本機儲存是 2 個 SSD，格式化為 XFS，適用于作業系統和刮傷空間/潑灑檔案。

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

運算節點和 Isilon 之間的後端網路為 10Gbps，並具有 NIC 和交換器埠的巨型訊框設定 （MTU=9162）。

初始測試

第一個測試系列是用來判斷 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 - Write-Ahead Log （WAL） 檔案數量上限。此值乘以 HDFS 區塊大小 （dfs.blockize） 的大小，是在伺服器當機時必須重新顯示的 WAL 大小。此值與排清磁片的頻率成反比。

hbase.wa.regiongrouping.numgroups - 使用多個 HDFS WAL 作為 WALProvider 時，會設定每個 RegionServer 應執行多少預先寫入記錄。產生此數量的 HDFS 管道。特定區域的寫入只會移至單一管道，分散整體的 RegionServer 負載。

此處的理念是盡可能地平行處理大量的寫入，因此，增加 WAL 的數量，然後每個 WAL 的執行緒 （管道） 數目就能達成此目標。前兩張圖表顯示，針對「maxlogs」128 或 256 的指定編號，我們並未看到任何實際變更，這表示我們並沒有從用戶端真正推入這個數位。儘管我們看到趨勢指出對平行處理敏感的參數，但每個檔案的「管道」數量會有所不同。下一個問題是 Isilon 使用磁片 I/O、網路、CPU 或 OneFS「妨礙」的位置，我們可以查看 Isilon 的統計資料包告。



網路和 CPU 圖表告訴我們，Isilon 叢集未充分利用，有空間可以進行更多工作。CPU 為 > 80%，且網路頻寬大於 3 GB/秒。



這些節點會顯示 HDFS 通訊協定統計資料，以及 OneFS 的翻譯方式。HDFS 操作是 dfs.blocksize 的倍數，此處為 256 MB。這裡有趣的是，「熱」圖顯示 OneFS 檔案作業，您可以看到寫入和鎖定的相互關聯。在此案例中，HBase 會附加到 WAL，因此 OneFS 會針對附加的每一個寫入鎖定皆鎖定 WAL 檔案。這是我們預期在叢集檔案系統上穩定寫入的原因。這些似乎造成這組測試的限制因素。

HBase 更新

下一個測試是進行更多的實驗，找出大規模運作的情況，因此我建立了一個十億清單格，它需要好好一個小時才能產生，然後執行 YCSB，以「workloada」設定更新 1,000 萬列 （50/50 讀/寫）。這是在單一用戶端上執行，我也在尋找最多可產生的輸送量，因此我執行此作業是作為 YCSB 執行緒數的函數。另一個注意，我們調整了 Isilon，並前往 OneFS 8.0.1.1，對資料節點服務進行效能調整。相較于前一組的執行，您可以看到效能大幅提升。在執行這些作業時，我們設定 hbase.regionerver.maxlogs = 256 和 hbase.wa.regiongrouping.numgroups = 20

查看這些畫面時，首先會明顯看出高執行緒數的落差。我當時很想，這是 Isilon 問題還是用戶端的問題。在即將推出的段落中，我們將看到一些相關的進一步測試。但我可以說，以 3ms 的更新延遲 < 時間推動 200K+ Ops 是令人目不擋的。這些更新執行的速度都很快，我可以逐一執行，下圖顯示這些執行的 Isilon 節點間的平衡。



同樣地，您可以從熱度圖表中看到檔作業會寫入，並鎖定與核准程式的附加性質相對應。

區域伺服器擴充

下一個測試是決定 Isilon 節點 （其中五個） 如何因使用不同數量的區域伺服器。在先前的測試中執行相同的更新指令檔是在這裡執行。使用「workloada」的單一用戶端和 YCSB 執行緒更新的 10 億清單格和 1,000 萬列的執行緒為 51，我們也會在 maxlogs 和管道上保留相同的設定 （分別為 256 和 20）。

 
這些結果十分有用，雖然並不讓人感到意外。HBase 的水準擴充性質結合了 Isilon 的水準擴充性質，而 more===更好。這是一項測試，建議客戶在自己的規模調整練習中，于其環境中執行。回饋金可能逐漸減少，但我們有九台伺服器在推送五個 Isilon 節點，而且看起來還有更多空間。

更多用戶端

最後一系列的測試來自深暗的地方，讓您想要破壞您正在測試的系統。畢竟，在事物中斷與通話之前，對測試進行測試是一種完美有效的科學方法，因此，您必須知道測試參數的上限為何。在這一系列的測試中，我有兩個額外的伺服器可以用來執行用戶端，此外，我在每一個測試中執行兩個 YCSB 用戶端，讓我最多可擴充 6 個用戶端，每個伺服器有 512 個執行緒，整體執行緒為 4096 個。我回到過去，建立了兩個不同的表格，其中一個 40 億列分為 600 個地區，一個擁有 4 億排，分為 90 個地區。  

 



 

如您所見，本測試中的表格大小並不重要。再次查看 Isilon 熱圖表，您會發現檔案作業的數量有幾個百分比差異，最多隻能是內嵌在 40 億清單格到 4 億列的差異。

結論

HBase 適合在 Isilon 上執行，這主要是因為水準擴充至水準擴充架構。HBase 有很多自己的快取，並且會將表格分割到數量相當多的地區，您可以利用您的資料進行 HBase 水準擴充。換言之，它能善用自己的需求，而且檔案系統存在持續性。我們無法將負載測試推送至實際發生錯誤的程度，但若您在 HBase 設計中查看 40 億列，且預期可執行 80 萬次作業，且延遲時間少於 3 毫秒，此架構便可支援。如果您注意到我未進一步提及您可能適用于 HBase 本身的無數其他用戶端調整，則我預期所有這些調整仍然有效，並且超出此測試的範圍。