俗話說,”人無遠慮,必有近憂”,容量規劃就是”遠慮”。所謂容量規劃,是一個產品滿足使用者標的需求而決定生產能力的過程。當產品發展到一個較為穩定成熟的階段,產品的整體處理能力的把控自然是不可或缺,儘管我們線上下做效能測試能夠獲得一些資料,其參考價值終究有限。但是我們常常被問到以下一些問題而無以應對。
1.單臺節點到底最大處理能力是多少?
2.目前線上有多少容量正在被使用?
3.在一次大促前當前的機器數是否能夠支撐?
4.什麼時候需要增加機器?加多少?
這時候,容量規劃就顯得格外必要了。透過對容量規劃學習,談談自己對容量規劃的認識和理解。
什麼樣的叢集適合做容量規劃?只有線性可水平擴充套件的叢集,我們才能透過獲取一個節點的處理能力,計算出叢集的處理能力,否則將會費很大物力和人力。
怎麼做容量規劃?一句話概括:線上壓測到單節點的某一指標達到臨界值,從而計算出叢集的最大處理能力,再根據線上歷史監控獲得當前叢集實際執行負荷,透過計算即可求出理論機器。
容量規劃能指導我們做什麼?如果計算出叢集當前的負荷快達到極限處理能力時,我們可以垂直擴充套件(加CPU/記憶體/磁碟)和水平擴充套件(加機器)兩種方式來增加叢集容量。
容量規劃6步走
Step1:明確標的
容量規劃和計算,我們可以用運籌學中的最佳化命題來定義,最佳化命題的標的是叢集實際負荷 <=叢集理想負荷,求解這樣一個不等式最佳化命題,同時系統需要滿足一定的不等式約束條件。
(1) 標的:
備註:
(2) 約束條件:
當然滿足標的的同時,叢集的狀態是受到約束的,資源是不可能無限供應,終會有一項資源會達到臨界值。
Step2:瞭解叢集特點
不同的叢集在選取容量指標和約束條件時是完全不同的,容量指標在後面會介紹,主要用於衡量叢集的處理能力,而約束條件是壓測停止的訊號。舉例說明,對於CPU密集型的叢集,我們常常會選擇TPS(每秒處理請求書)作為叢集的容量指標來衡量叢集的處理能力,而約束條件中則會重點關註CPU的使用率是否率先成為瓶頸;對於儲存型的叢集,選擇流量(MB/S)作為容量指標,儲存型的叢集TPS依賴於業務資料大小,所有流量更適合作為表徵叢集的處理能力,而約束條件最先成為瓶頸的是網路流量或者IO。
而判斷叢集式何種型別則可以透過線下的效能測試結果來判斷,線下的效能測試可以作為線上壓測的參考依據。
Step3:選取容量指標
容量指標主要用作衡量伺服器的處理能力。容量指標的選取原則:1)線上資料可採集2)能夠客觀反映伺服器處理能力。
作為容量指標,需要透過線上監控獲取統計資料,其歷史資料用於計算叢集的實際負荷,而透過壓測獲得叢集的最大處理能力。如上所說,CPU密集型叢集常選TPS作為容量指標,而儲存型叢集常選流量作為容量指標。
Step4:明確約束條件
約束條件的存在主要是作為線上壓測停止的訊號,常常會包括業務指標和資源指標。其中只要有一項指標達到臨界值,則停止壓測將當前容量指標的值作為叢集的最大處理能力,例如某項服務質量要求響應時間不超過100ms,那當響應時間達到臨界值時,儘管其它指標並沒有達到極限但是也把此時作為叢集最大處理能力。因此服務指標的選取原則:1)業務需求 2)資源使用瓶頸。一則保證產品的服務質量,二來保證系統的安全。
Step5:線上壓測
線上壓測的主要目的主要用於獲取叢集的最大處理能力,而對於線上壓測的手段主要介紹三種,針對不同的集群系統架構特點和業務型別選取不同的壓測手段。
模擬請求
模擬請求,即是模擬客戶端的呼叫方式向壓測伺服器發起請求,簡單易操作。
測試資料:可以透過分析線上日誌分析,根線上業務配比建立壓測模型,對於HTTP請求業務還有一種簡單的方式,透過提取線上日誌資料URL直接用於壓測請求資料。
實施步驟
(1) 將線上一臺節點offline,測試客戶端直連被測伺服器
(2) 客戶端梯度增加併發(50),不斷增加併發直至超過設定的服務指標
優缺點
測試效果不受服務實際流量的限制,壓測時間靈活,適用於GET請求不會產生臟資料。業務指標可以透過測試客戶端直接獲取。
風險評估
風險低,首先機器offline不會影響到線上的正常請求;其次緩慢增加併發,不會造成服務崩潰的情況。
線上引流
線上引流,即將線上其它節點的請求複製到被測伺服器上,推薦使用Tcpcopy工具。
測試資料:線上請求直接複製引流,無需準備資料
實施步驟
(1) 將線上一臺節點Off-line,按照Tcpcopy部署的方法部署client和server,為了便於指標的統計,通常將Tcpcopy部署在nginx所在伺服器,被壓測伺服器前需要增加一層nginx伺服器。
(2) 將叢集的其它節點流量複製到off-line節點上,可以透過tcpcopy –r引數逐步增加複製繫數,不斷增加-r引數直至超過設定的服務指標
(3) 如果100%全部線上流量都不能壓測到off-line節點的瓶頸,再逐步放大引流繫數
優缺點
請求真實,能夠放大流量,測試效果不受服務實際流量的限制,壓測時間靈活,但環境部署稍微麻煩,對於PUT請求需要做一些業務處理,避免產生臟資料。
風險評估
風險低,首先機器offline不會影響到線上的正常請求,緩慢增加流量複製,不會造成服務崩潰的情況。
修改負載權重
對於一個叢集,前面往往會有負載均衡伺服器,以Nginx為例,透過修改Upstream模組的負載均衡weight可以不斷增加叢集某一節點的請求數,增加其訪問壓力。
測試資料:無需準備
實施步驟
(1) 緩慢增加nginx的負載均衡繫數,使被測節點壓力不斷增加
(2) 直至超過設定的服務指標停止增加壓力
優缺點
完全真實的場景,壓測資料準確,但是依賴自身的流量,壓測時間不靈活,需在高峰期,對使用者體驗有一定影響,隨著一臺機器的負載增加響應時間會受到一定影響,會直接反饋給線上使用者。
風險評估
風險低,雖然在高峰期進行,但是隻需要修改nginx配置再reload,對服務基本無影響,且每次都逐步增加weight,不會造成伺服器崩潰的情況。
Step6:線上監控
線上監控不僅用於叢集歷史資料的收集,計算叢集的實際負荷的監控,還用於壓測過程中監控約束條件中的各種指標是否超限並停止壓測。根據叢集的特點和之前效能測試經驗關註容量指標和約束條件的業務和資源指標。而這裡的歷史資料,是需要長期的採集和整理。
小結
綜上所述,容量規劃主要圍繞著這麼一個等式展開工作,紙上談來終覺淺,實踐出真知。希望能夠在接下來的實踐中成長和收穫。
朋友會在“發現-看一看”看到你“在看”的內容