作者簡介
姜澤 百度高級運維工程師
負責百度智能運維產品（Noah）的運維工作，在可用性建設，容量管理方面有着豐富的實踐經驗。
乾貨概覽
容量管理是系統可用性運維的重要環節之一。通常來說，容量管理包含容量度量、容量規劃和過載保護三個過程。容量度量首先要確定系統容量的衡量標準，通過一定方法得到各模塊的流量承載能力（包括額定負載、極限負載和冗餘度），從而得到系統整體容量。容量規劃是基於SLA可用性要求，確定資源在時間上的需求規劃。過載保護是根據容量衡量和規劃結果進行的外圍系統設計，以保障業務在滿足SLA的前提下，穩定處理高於額定負載的請求。
百度Noah平臺的時序數據存儲系統（TSDB），承載了百度諸多核心業務的監控數據存儲與查詢需求，日均寫入點數以萬億記，查詢請求高達數十億次。在如此大的請求場景下，建設一套完善的容量管理機制，有效的度量TSDB系統的容量能力，合理規劃系統容量發展，及時發現系統的容量風險，有效應對容量過載場景，是非常困難又非常重要的。本文主要介紹TSDB系統容量度量、容量規劃方面的內容。在接下來的後續文章中會詳細介紹過載保護方面的一些實踐。
容量度量--容量管理的基礎
1設定容量指標容量是系統對業務承載能力的量化，一般我們使用可量化的性能指標來衡量系統的容量。通常來說有下面三種：
吞吐量（Throughput）：指系統單位時間內處理的請求總數。請求可以是讀寫請求，也可以是數據處理請求，對應着QPS（Query Per Second）和RPS（Request Per Second）兩類；
併發數（Concurrency）：同一時間內能夠處理的請求數目；
系統延遲（Latency）：指系統完成一個請求所花費的時間。
在多併發系統中，可以把這三者的關係簡化爲：吞吐量＝併發數／系統延遲。對於單併發系統，吞吐量就是系統延遲的倒數。
至於具體使用哪一個性能指標來衡量系統容量能力，需要根據不同的業務場景來判斷。在多數場景下，我們考量的都是吞吐量（QPS或RPS），當然對於實際的業務場景，QPS、RPS的定義會略有區別。在Noah監控場景下，主要是監控數據（時序數據）的寫入和查詢，每個請求會對應多個itemCollection，而一個itemCollection中帶有多個監控數據點。因此，我們使用PPS（Point Per Second）作爲TSDB系統的QPS指標來衡量系統的容量能力。
2獲取容量數據獲取容量數據的方法有容量估算和壓測兩種。容量估算指通過各子模塊的運行指標，使用資源建模計算的方式匯聚計算出全系統的容量數據。例如下圖，模塊A爲整個系統的入口模塊，入流量爲x，他有兩個下游B和C，分別承載y和z的流量。首先，通過資源消耗（瓶頸資源）與流量的折算關係估算出每個模塊的容量分爲X，Y，Z，例如在資源消耗50％的時候，流量是1KQPS，可以預測系統達到極限負載的情況下容量爲2KQPS（只考慮系統爲線性系統）。接着通過假設流量在各個模塊的等比例放大/縮減，計算出整個系統的容量爲min（X，xY/y，xZ/z），即整個系統的容量由子模塊的最小容量決定。這種計算方式存在兩個誤差來源，一是資源消耗與流量增長並非完全線性，二是各模塊間未必完全解耦導致模塊之間的流量增長並非等比例。
實際應用上更廣泛的做法是通過壓測來獲取相對準確的容量數據。壓測方法一般分爲線上壓測和線下壓測。線上壓測是直接對線上服務進行真實流量的壓力測試以獲得整個系統的容量，精度較高，但成本較大，且可能會對線上服務的穩定性造成影響。線下壓測首先需要部署與線上環境完全一致或等比例縮放的系統，再通過壓測得到線下系統的容量，最後通過等比例折算的方式獲得線上實際生產環境的全系統容量。搭建一套與線上完全一致的線下系統用於壓測，投入的成本過大。如果僅僅是線上集羣的等比例小規模集羣，壓測的數據準確性又無法保證。
我們在對監控的計算-存儲(Astream-TSDB)系統實施壓測時採取了折中的方案，雖然是線上壓測，但壓測的對象是線上規模相近的熱備集羣。監控系統計算存儲集羣的示意圖如下所示。Agent將同樣的兩份數據發往跨地域的兩個計算集羣，由計算集羣計算後分別發往同地域的TSDB集羣，查詢端通過流量切換可選擇在兩個集羣進行數據查詢。兩個集羣在物理上隔離，所以對備集羣的壓測帶來線上系統可用性風險的概率大大降低。
具體的壓測方案，我們還需要考慮以下三個方面：發壓端，壓測預案，數據污染。
發壓端主要考慮的是如何構造流量壓力的問題。一方面，我們希望發壓端有足夠大的併發，能模擬系統在超高壓力下的性能表現；另一方面，我們希望壓測的壓力能真實模擬線上實際的流量。爲了完美解決這兩個問題，我們的壓測平臺LTP使用流量回放來構造發壓數據。其基本原理是對服務的流量進行拷貝，並以實時或離線的方式將流量的副本分發到發壓機上。同時流量回放也支持比例加壓，或者流量成分的過濾和修改操作。
在壓測方案的設計中，應儘量保證壓測子系統與線上系統的隔離，以減少對線上的影響。壓測預案考慮的是當壓測造成系統故障時，我們需要具備有效的止損預案，比如中斷髮壓預案、流量切換預案和集羣恢復預案等等。
對於存儲系統來說，不得不面對的一個問題是寫入的髒數據問題。這部分壓測的髒數據是不希望被用戶獲取的。解決的辦法還是儘量從業務上隔離壓測系統，具體採用的方法可以是給發壓的數據單獨打上壓測的標籤，壓測結束後單獨刪除；也可以在查詢端做壓測數據的區分。
上述我們所說的系統容量值其實指的是系統所能承受住的極限負載，是不帶任何冗餘的。這個值無法保證系統的高可用性，因爲線上稍有退化，甚至是計算的誤差，都會導致基於這個值做的一切預警無效。爲了避免各種因素的影響，我們可以給容量加上冗餘，這部分冗餘容量用來抵禦系統的流量突增、性能退化、容量計算誤差等等場景。所以我們可以認爲極限容量*（1-Buffer）纔是系統的容量，也叫額定容量。我們建立的容量報表，也是基於該值。建立系統及子模塊的容量水位報表，可以定期巡檢線上服務容量狀態，及時發現容量瓶頸。並且，我們還對核心服務的容量水位設置閾值報警，一旦系統容量到達容量水位預警值將自動執行服務彈性擴容，保障系統穩定運行。
容量規劃
隨着業務量的快速增長，我們不得不考慮的問題是未來整個集羣的容量需求爲多少，當前集羣距離目標容量還需擴容多少。有了容量數據後，我們就可以通過下面的計算回答這個問題。
假設線上服務流量歷史上月增幅X，冗餘度要求爲R，當前極限容量爲C，線上有M個實例，則N個月後容量需求爲
總 結
容量管理是系統運維不可或缺的部分，而建立容量數據是容量管理中最爲基礎、重要的一環。基於準確的容量數據有利於更有效的做容量規劃和優化分析。以上是Noah在容量管理方面落地的一些粗淺經驗，如有不當之處，歡迎指正。
閱讀推薦
運維實踐
智能運維架構 | 架構集成 | 網絡判障 | 監控數據採集 | 監控報警 | 網絡異常 | 分佈式監控系統 | 數據可視化 | 單機房故障自愈 | TSDB數據存儲 | 異常檢測 | 流量異常檢測 | 複雜異常檢測 | 報警風暴 | 實時計算 | 故障診斷 | 日誌監控 | 網絡監控可視化 | HBase實踐 | 多維度數據
運維產品
百度雲BCM | 企業級運維平臺 | 基礎設施管理引擎 | 運維知識庫 | 通告平臺 | 百度名字服務 | 業務部署 | 數據配送 | 集羣控制系統 | 外網監控 | 內網監控 | 部署變更 | 配置管理 | 站點監控
精品推薦
AIOps全解析 | AIOps中的四大金剛 | 智能運維 | AIOps時代 | 運維演進
↓↓ 點擊"閱讀原文" 【瞭解更多精彩內容】