LinkedIn開源Cruise Control：一個Kafka叢集自動化運維新利器

Kafka近年來日漸流行，LinkedIn的1800台Kafka伺服器每天處理2萬億個消息。雖說Kafka運作得十分穩定，但要大規模運作Kafka，在運維方面仍然面臨巨大的挑戰。每天都會有broker崩潰，導緻叢集工作負載不均衡。SRE團隊需要花費大量的時間和精力來重配置設定分區，以便讓叢集重新恢複均衡。

自動化是以變得十分重要，這也就是為什麼我們要開發Cruise Control：持續監控Kafka叢集，自動調整配置設定給伺服器的資源，達到預期的性能目标。使用者設定目标，Cruise Control對叢集的工作負載進行分析，并自動執行一些操作來達成目标。

Cruise Control即日起在GitHub上開源。在這篇文章裡，我們将介紹Cruise Control的使用場景、它的架構以及我們在開發Cruise Control過程中面臨的挑戰。

設計目标

可靠的自動化： Cruise Control要準确地分析叢集的工作負載，生成無需人工介入的執行計劃。資源有效性： Cruise Control要智能地執行操作，不會影響叢集處理正常的工作負載。可擴充性： Kafka使用者對可用性和性能會有不同的需求，還可能使用各種不同的部署工具、管理端點和度量名額收集機制。Cruise Control必須能夠滿足使用者定義的各種目标，并執行使用者定義的操作。通用性：盡管很多現有的産品可以用于均衡叢集的資源，但它們大部分都與應用程式毫無關聯，需要通過遷移整個應用程序來恢複均衡。這類産品對于無狀态的系統來說是沒有問題的，但對于有狀态的系統來說就會顯得有點力不從心，因為這類系統的很多狀态與應用程序相關聯。是以，我們希望Cruise

Control會是一個能夠了解應用程式的通用性架構，在恢複均衡時隻需要進行一小部分狀态遷移。

Cruise Control在LinkedIn的應用

Cruise Control在LinkedIn主要解決以下幾個問題。

保證Kafka叢集資源的均衡：磁盤、網絡和CPU。如果有broker崩潰，自動将副本重新配置設定給其他broker，并重置複制系數。識别出消耗資源最多的主題分區。在擴充叢集或broker退役時隻需要少量的人工介入。支援異構的Kafka叢集以及單台主機部署多個broker執行個體。

Cruise Control的工作原理

Cruise Control遵循的是“監控——分析——行動”這樣的工作流程。下圖是Cruise Control的架構圖。大部分元件都是可插拔的，如度量名額取樣器（metric sampler）、分析器（analyzer）等。

　　REST API

Cruise Control為使用者提供了一組REST API，可以用于查詢Kafka叢集的工作負載情況或觸發管理操作。

負載監控器

負載監控器從叢集收集Kafka的度量名額和每個分區的資源度量名額，并生成叢集工作負載模型，包括磁盤使用情況、CPU使用情況、流量流入速率、流量流出速率等，然後把模型發送給探測器和分析器。

分析器

分析器是Cruise

Control的“大腦”，它根據使用者提供的優化目标和來自負載監控器的工作負載模型來生成優化計劃。使用者可以配置優化計劃的優先級，還可以分别設定硬性目标和軟性目标。硬性目标是指必須達成的目标（例如必須根據機架來配置設定副本的位置），軟性目标是指在優先滿足硬性目标的前提下有可能得不到滿足的目标。

硬性目标

根據機架來安排副本的位置，即同一個分區的副本必須被放在不同的機架上，這樣可以減少硬體崩潰給Kafka叢集帶來不利的影響。broker的資源使用必須處在預定義的門檻值内。網絡使用不能超過預定義的容量。如果一個broker的所有副本都成為首領，那麼所有的消費者流量都會被重定向到這個broker上，導緻網絡流量膨脹。

軟性目标

讓叢集所有的broker使用相同的資源。讓所有broker的首領分區達到相同的流量流入速率。讓主題的分區均勻地分布在所有broker上。在所有broker上均勻地分布分區副本。

探測器

探測器主要用于探測兩種類型的異常。

broker失效：比如一個非空閑的broker離開叢集，導緻分區不同步。因為這種情況在叢集正常重置時也會發生，是以探測器在觸發告警之前會預留一段時間，如果不是正常重置，就會觸發告警并進行修複。偏離目标：如果啟用了自愈功能，Cruise Control會嘗試通過分析工作負載并執行優化計劃解決問題。

執行器

執行器負責執行由分析器生成的優化計劃。Kafka叢集的再均衡通常會涉及重新配置設定分區，執行器要對資源保持感覺，避免拖垮broker。分區重配置設定可能需要很長時間，一個大型的叢集可能需要幾天時間才能完成一次分區重配置設定。有時候，使用者希望能夠停止正在進行的分區重配置設定，是以執行器需要確定能夠安全地中斷執行計劃。

有趣的挑戰

在開發和使用Cruise Control時，我們遇到了很多有意思的挑戰。

為Kafka建構可靠的叢集工作負載模型

這個比看上去的要難得多，需要考慮到很多細節。例如，從broker上收集CPU度量名額是很容易的，但我們該如何量化每個分區的CPU使用情況？這個Wiki頁對這個問題進行了解釋。

你們願意花多少時間在一個優化計劃上？

分析器元件經曆了一個漫長的演化過程。我們最開始使用了一個具有複雜配置功能的通用優化器，它需要幾周的時間才能得到一個中型Kafka叢集的優化計劃。後來，我們改用現在的優化器，可以在幾分鐘之内得到一個較好的結果。

記憶體與速度的權衡

Cruise

Control是一個記憶體密集型的應用，因為它需要在記憶體裡儲存度量名額一段時間，以便分析流量模式。同時，它也是一個CPU密集型的應用，因為它需要大量的計算來生成優化計劃。這兩者之間存在沖突關系。為了加快生成優化計劃，我們需要緩存更多的資料，進行更多的并行計算，但這樣會使用更多的記憶體。我們需要在這兩者之間做出權衡。例如，我們會預計算優化計劃并緩存起來，當使用者發起查詢時就不需要等待那麼長時間。另外，我們會交錯執行記憶體密集型的任務，避免同時消耗大量記憶體。

未來的工作

更多的叢集優化目标

Cruise Control的優化元件是可插拔的，使用者有可能會根據實際需要提出各種複雜的優化目标。作為一個開源項目，我們鼓勵使用者建立自己的優化目标，并把它們貢獻給社群。

與雲管理系統內建

目前，Cruise Control通過移動失效broker的分區讓叢集保持正常運作。我們希望後續能夠與雲管理系統內建起來，實作自動叢集擴充，或者使用空閑執行個體替換失效的broker執行個體。

增強運維洞見

Cruise Control分析從Kafka收集而來的度量名額，幫助SRE團隊量化各種資源度量名額的影響程度，提升容量規劃和性能調優的能力。

通用性

我們在開發Cruise

Control時就意識到動态負載均衡器對于分布式系統來說是非常重要的。用于聚合度量名額、分析資源使用情況、生成優化計劃的Cruise

Control元件同樣适用于其他分布式系統。從長遠來看，我們想把這些核心元件抽象出來，用在其他的項目上。

本文轉自d1net（轉載）