駕馭千級節點——揭秘PUMA大規模集群能力（四） ---- 云上測試及結論

前面的博客說了一大堆，光說不干怎么行呢，下面就干起來，我最近一直在華為云上進行PUMA大規模集群能力驗證及測試，這里把測試過程及測試結果總結一下。

1.1 測試目地

1、? 測試puma集群的規模能否部署到1000節點 （PaaS需求）

2、? 測試單個puma集群的TPS能否達到1000w，消息大小為2k (消費者云需求)

3、? 隨著puma節點的增加，集群tps的變化曲線是如何的

4、? 海量topic ，平均單節點上有100個topic、每個topic配置為3副本、3分區、高可靠場景，集群的tps性能如何

1.2 測試環境

測試環境選擇為華為云，主要有以下兩點原因

1、需要測試的規格太大，當前的實驗室環境已經無法滿足上千萬TPS的測試規模，之前所有可用機器加起來組成的集群規模，也僅僅測試了上百萬TPS。

2、公有云的測試環境更符合下游產品用戶使用的真實場景，測試出來的數據比單純的實驗室數據更有說服力。

1.3 硬件環境

根據企業云上申請機器的規模及相應的配置信息如下：

機器屬性

硬件配置

部件

虛擬機

4C16G，需要單獨的數據盤

kafka

虛擬機

2C8G

zookeeper

虛擬機

千兆網卡

網卡

1.4 軟件環境

軟件列表

詳細版本說明

備注

Zookeeper

zookeeper-3.4.6.tar

PUMA

V1R1C003

選型為kafka 0.9.0.1

JDK

1.8.0_91

expect

系統自帶即可

編碼腳本使用

pdsh

分布式運維工具

nmon

服務器資源信息收集工具

1.5 公有云測試過程中的注意事項

1、公有云的特點

從使用情況看，公有云上申請的機器都是虛擬機，站在用戶角度，實在不清楚機器源是否來自同一臺物理機，這樣對于硬件資源的分析上，很難判斷機器資源是否處于飽和狀態，在一定程度上會影響測試結論的判斷，只能多次從測試角度不斷嘗試去證明測試結論，這樣在測試結果分析上，具有一定的不確定性。

公有云由于部署在外部網絡上，需要從跳板機跳轉，在機器之間的安全鑒權上耗時比較長，所以在機器之間的免密處理上，如果有超時時間，注意適當增加下，否則很容易超時而失敗。

公有云默認的機器配額是有限制的（包括IP和硬盤資源），只有20臺，所以在測試前需要預估清楚需要的測試規模，提前走工單申請好對應的機器資源，規劃好對應的子網，不然臨時申請和規劃，影響整個測試進度。

2、應對公有云，測試需要做的整改

公有云測試，由于各種不確定性，肯定需要調整測試模型的，所以測試環境自動部署是上云之前首先要滿足的必要條件，環境自動部署在上云前實驗室調試都是沒問題的，而且都已經上CI運行了，但是到了公有云后，自動部署不能完全跑起來，以下是整個應對公有云測試上，測試方面根據公有云做的整改，作為經驗總結下。

3、使用私有鏡像

剛開始確實不清楚公有云提供的公有鏡像為何不能用，直到使用后才知道，公有鏡像一般都做了防火墻策略，很多端口默認不開放，導致集群之間無法互通，不建議使用公有鏡像，不然出現一堆問題還得定位，建議使用平時測試對應的系統做的私有鏡像，可以聯系對應的客服操作。

4、需要獨立的機器做控制節點

當前公有云環境上的跳板機的系統是缺少不少組件的，導致免密是無法執行的，這樣什么后果呢，從該機器操作余下的機器幾乎就是不可能了，改造跳板機之前也嘗試過，失敗了，所以當時的處理方式就是多申請一個機器作為控制節點，以此節點作為控制機，與余下的機器做免密，來統一操作余下的機器。

這個控制節點的配置可以不需要太高，所有需要用的公共文件都保存在上面，需要長期保留，后續可以節省重新申請的時間。

5、一次申請的機器數量不要太多

公有云機器申請后是慢慢依次創建的，中間有個過程，不是一蹴而就。如果申請的機器數量太多，一來時間太長，影響部署配置文件的準備；二來不是每次申請所有機器都是成功的，可能總有那么幾個失敗的機器，原因我也不太清楚，最痛苦的就是從茫茫機器中找失敗機器的IP（公有云特點：IP都是依次創建下來的，所以我們在制作機器配置文件的時候可以直接刷下來，但是中間有幾個失敗的就不妙了，我們得找到然后刪除，不然自動部署會失敗，純粹浪費其他機器的部署時間），經驗值一次申請不要超過50個，申請頁面最大顯示的記錄是50條，有錯誤也容易看出來。

6、免密腳本失敗能自動重試

前面有提到公有云部署在外部網絡上，需要從跳板機跳轉，在機器之間的安全鑒權上耗時比較長，從環境部署情況來看，不出意外，單臺機器免密需要耗時1分鐘，如果由于網絡原因導致的免密失敗，則需要重復執行，還得重復耗時1分鐘，時間還是挺長的，所以這里為了應對這種概率性的免密失敗，腳本需要支持自動重試，否則機器數量太多，手工不好再次操作。

7、修改系統文件減少登陸時間

這里選用的系統為suse11 SP3，需要修改兩個系統文件屏蔽掉域名解析部分，以減少登陸時間，不然即使做了免密，使用SSH登陸還是會比較耗時，具體方法如下：

vim /etc/hosts

注釋多余的127.0.0.1信息

127.0.0.1 kafka-0004

#127.0.0.1 host-192-168-1-189

#127.0.0.1 host-192-168-1-183

#127.0.0.1 host-192-168-1-42

#127.0.0.1 host-192-168-101-87

#127.0.0.1 host-192-168-101-69

vim /etc/resolv.conf

全部注釋

8、依賴的三方軟件在測試前需要安裝好

公有云系統上面是沒有多余軟件存在的，測試程序所依賴的所有三方軟件需要自己安裝，否則測試過程出現問題還需要耗時定位，影響測試效率。

9、申請的數據盤需要自己手工進行掛接

性能測試對于磁盤讀寫是有要求的，一般情況下，存儲和系統最好分離，以免頻繁讀寫磁盤會對系統造成沖擊，所以主測環境一般會申請額外的數據盤進行數據存儲，注意：公有云上單獨申請的硬盤需要自己手工掛接，否則無法使用。

公有云系統如果申請時候使用同一系統，則數據盤掛接方式基本一致，可以采用同樣的腳本實現自動化掛接，提升測試效率。

10、測試結果自動化處理

由于公有云測試規模比較大，所以需要收集的測試結果比較多，這里對于需要收集的測試數據一定想辦法自動化處理，否則數據處理巨大，影響測試效率。

1.6 性能測試結果分析

公有云之前也有提過申請的機器都是虛擬機，實在不清楚機器源是否來自同一臺物理機，這樣對于硬件資源的分析上，很難判斷機器資源是否處于飽和狀態，對于收集到的硬件資源文件，一些資源的占用率往往與在實驗室測試有一定差距，那如何分析呢，可以多抽取幾個系統資源文件查看和對比，如果各個文件的數據均不一致，說明服務器端系統資源還有冗余，可以考慮增加一些客戶端，看是否可以提升TPS，盡量往實驗室已有的測試數據靠近；而實際測試出來的數據有差距是正常的，我們得先排除系統資源是否飽和，再來找測試系統本身的問題。

1.7 現網組網

在華為云上直接創建虛擬私有云，然后在虛擬私有云中創建多個虛擬子網，具體的過程就不介紹了，有興趣的童鞋可以自己去華為云上玩一玩

1.8 測試組網

1.9 消息配置

在測試過程中，如果不做特別說明，消息的大小均為2K，場景分為高吞吐和高可靠，其中高吞吐的配置一般為1副本，1分區，ack=1，異步落盤；高可靠配置一般為3副本，3分區，ack=all，min.insync.replicas=2，異步落盤。

另外，在測試過程中，統計tps的模式和kafka自帶的kafka-producer-perf-test.sh腳本有所不同，自帶的腳本是消息發送了就立馬統計tps，而我們的測試腳本是消息收發后，等收到了消息發送成功的回調再來統計tps，這樣的話，相同條件下統計的tps可能比kafka自帶的腳本統計出來的tps略低，但是統計的結果會更準確。

1.10 千節點集群

1.10.1 搭建千級的kafka集群

在華為云上搭建1000個kafka節點的集群，整個部署時間5小時左右，集群能正常搭建，消息能正常收發。

1.10.2 千級節點集群的性能

受限與華為云配額的限制，如果搭建了千節點的集群，那么可供使用的客戶端只有200多臺了，這種情況下是無法測試出集群的tps性能的，通過后面其他的測試，這里可以給一個預估值：

在kafka節點和客戶端節點的比例為1:1的情況下，1000節點集群能提供的tps約為1100w（消息大小2K，高吞吐場景）

如果客戶端節點數量足夠，在和合理的比例下，集群中單節點的性能能達到4.8w的tps，則千節點集群的tps可以達到4800w（消息大小2K，高吞吐場景）。

1.10.3 小結

1、? 千節點的集群可以正常工作，消息收發正常

2、? 千節點集群中，zk不是瓶頸，3節點的zk即可滿足，但是節點的內存不能太低4G即夠用

3、? 千節點集群的tps受限于測試機器的數量，無法準確給出，這里可以給一個大的范圍：1100w --- 4800w之間

4、? 千節點集群運行過程中，創建和刪除topic不會影響其他topic的性能，但是加入節點或者移除節點會稍微影響集群的tps性能。

1.11 千萬tps

1.11.1 理論分析

按照一般的規律，整個集群的tps會隨著集群節點數量的擴大而增長，有可能是線性增長，也有可能不是，或者節點數量達到一定規模后，再增加節點，集群的tps反而下降，因此，我這邊的測試就是通過不斷增加kafka的節點數來測試其tps，找出最少需要多少節點就能達到千萬tps的規模。

1.11.2 測試

在測試過程中，受限于配額，最初使用的是1:1的模型，就是kafka節點數和客戶端節點數的數量一致，測試的數據如下：

從圖中可以看到，當機器節點規模達到500時，整個集群的tps能達1249w。

后面調整了kafka節點和客戶端節點的比例，增加了客戶端的數量，測試的數據如下：

從圖中可以看到，通過修改kafka節點和客戶端節點的數量，200個kafka節點的集群就能達到987w的tps，而300個節點的集群在未壓滿的情況下能達到1203wtps。

1.11.3 小結

1、? kafka集群通過增加節點數量和客戶端數量，可以達到千萬tps的規模

2、? 達到千萬tps規模所需要的最少節點數量為205臺左右

1.12 集群tps隨節點數量的變化

1.12.1 理論分析

這個在測試前，想到了兩種可能性

1、? 在一定的集群規模下，集群tps隨節點數量線性變化，就是增加一個節點會帶來固定的tps的增長

2、? 集群tps隨節點數量的增加而增加，但不是線性增長，同時，集群擴大到一定的規模后，再增加節點，集群tps不會增加，反而有可能下降

1.12.2 測試

部分測試數據入下：

上圖表明，在kafka節點數和客戶端數為1:1的情況下，集群單個節點的平均tps是逐步減小的，而且，在1000個節點以內，隨著集群內節點的增加，集群總的tps是成上升趨勢，最大tps為1100w。

另一種測試的數據如下：

在客戶端數量充足且和kafka節點保持特定比例的情況下，集群內單節點的性能基本維持在4.9w左右，隨著節點數量的增加，集群總的tps線性增長；但是不同規模集群達到最大tps所需要的客戶端數量不一樣。下面給出一個曲線，如下：

注：最后一組數據300節點的tps未壓滿

1.12.3 小結

1、? 在puma節點和客戶端節點數量為1:1的情況下，隨著集群節點的增加，集群內單個節點的平均tps逐步下降，集群總的tps緩慢上升，當集群規模達到千節點時，集群內單個節點的平均tps為1.1w，總的tps為1100w。

2、? 不管多大規模的集群，在千兆網卡環境下，其單節點的平均tps上限均為5w，嚴格來說是4.9w左右

3、? 不同規模集群的tps達到上限所需要的client數比例也不同，但是，只要有合適的topic比例和足夠的客戶端數量，另外，增加topic數量，測試過程中使用的比例為broker : topic為1:6；集群內單個節點的平均tps可以達到4.9w，使得集群tps隨著節點的增加實現線性增長

1.13 海量topic場景

1.13.1 場景背景

該場景主要是paas的多topic場景，集群內平均每個節點上的topic比較多，topic配置為3副本，3分區，高可靠配置，min.insync.replicas=2 ，flush.messages=1

主要測試節點上平均不同topic數情況下，集群的tps變化

1.13.2 測試

測試集群的規模為100節點，客戶端數量為1200個，測試的數據如下：

從上圖可以看出，在海量topic且高可靠的場景下，100節點集群的tps基本在100w左右，同時，在50 100 200topic這三個場景下，topic數越多，集群的tps越低，這說明增加topic會降低集群的tps。

1.14 測試總結

1、? 單個puma集群最大支持的節點數受限于測試環境，無法準確給出；但是測試過程中成功搭建過1000節點的集群，可以正常工作，收發消息、添加刪除topic都OK。

2、? 不同數量節點的PUMA集群，可以通過調整topic數和連接的client數來使集群的tps達到上限，同時使集群tps隨著節點數量的增加而呈線性增長；在公有云的千兆網卡、消息大小2K、高吞吐的配置下，單個節點的tps上限為4.9w，就是說集群每增加一個節點，其總的tps會增加4.9w左右，下圖是一個變化趨勢：

在這中配置下根據變化趨勢，1000節點集群的tps將達到4800w左右

3、? 單個集群達到千萬tps很容易，最少200個節點+1700個客戶端就可以達到千萬tps的要求。

1.15 部分測試截圖

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。