項目背景

我們團隊負責維護的 Kafka 集羣承載了公司大部分實時數據的收集與傳輸任務。然而，目前存在一些問題，嚴重影響了集羣的穩定性、用户體驗以及管理員的運維效率：

• 當前集羣版本較低，且低版本的 bug 頻繁出現，導致集羣穩定性受到威脅。例如，violet 集羣最近因觸發 bug 而出現不可用的情況。
• 多個集羣版本不一致，用户在使用時受到版本限制，管理員需要關注不同版本之間的差異，增加了問題排查的時間和複雜度。

因此，我們決定啓動集羣升級項目，將所有集羣統一升級至較高的 2.2 版本，以提升集羣的穩定性，改善用户體驗，並降低運維成本。我們參考了 Kafka 官網、主流企業服務提供商（如：Confluent、Cloudera）以及國內其他公司的升級方案，結合公司現有集羣的實際情況，制定了本方案。   

項目目標

根據“儘量減少對用户的影響，確保操作高效、安全”的原則，細化為“分批次、分階段、不停服”的目標：

1. 不停服：採取 滾動升級 的方式，避免出現整個集羣不可用的情況，儘可能降低用户感知；
2. 分批次：將當前所有集羣按優先級劃分為多個批次，當前批次執行升級且持續運行一週無異常後，再升級下一批次；
3. 分階段：將升級操作流程拆解為多個階段，每個階段的 checklist 確認無誤後，再執行下一階段操作，同時，提前準備好相應的預案 (回滾和線上服務恢復步驟) 以應對異常情況。

方案描述

作為 C/S 架構，Kafka 集羣的完整升級過程涵蓋了 broker 側和 client 側。按照執行次序，完整的升級過程可劃分為 5 個階段，如下：

1. [broker 側] 代碼升級；
2. [broker 側] broker 間通信協議版本 (配置項) 升級；
3. [client 側] Consumer 升級；
4. [broker 側] 消息格式版本 (配置項) 升級；    
5. [client 側] Producer 升級。

執行流程

集羣升級的整體執行流程可分為 7 個環節，如下：

組內集羣現狀

主要關注點包括：

• 當前版本
• 部署方式：不同方式部署的集羣，升級操作過程可能不同 (取決於測試驗證的結果，如果可以通過同一種方案對所有部署方式下的集羣執行同等高效安全的操作，最好不過)；
• 監控：考慮到後續的監控會全部對接 Mon/AXE，藉助此次梳理機會，對 AXE 節點和主機基礎監控信息進行規整和完善。

目前，我們的 Kafka 集羣共有 14 個，按照部署方式分為兩類：

1. Cloudera 部署的集羣（8 個）：版本 0.8.2（4 個）、0.10.2（3 個）、0.10.0（1 個）；
2. 手工部署的集羣（6 個）：版本 0.8.2.2（2 個）、0.10.2（1 個）、1.0.0（1 個）、2.1.0（1 個）、2.2.1（1 個）。

各集羣詳細信息如下：

• 測試  
• 測試目標  
• 從可行性、安全性和操作便利性三個方面對所有備選方案進行測試，選出綜合最優的方案作為最終執行方案。 
     
  測試方案
  手工部署的集羣測試方案：
  

Cloudera 部署的集羣測試方案，流程與上述方案大體一致，不同點如下：

• 複用當前的 Cloudera manager 服務進行操作；
• 測試環境 zookeeper 和 kafka 的搭建，以及配置項的修改，都是在 Cloudera Manager UI 上操作完成的；
• 官方推薦採用 parcel 方式進行升級 (即，新版本代碼的下載和部署由 Cloudera Manager UI 上的 parcel 操作完成)，根據操作複雜度決定是否需要進行手動後台操作。

測試驗證選擇方案的過程，實際上是不斷解決上述方案中的各項“如果”“嘗試”的過程。隨着這些項的全部解決和確定，最終的執行方案也就確定了。

測試過程及用例記錄
快速搭建測試集羣

1. 安裝包：為了搭建多個版本的集羣，提前下載所有需要的安裝包（包括 Kafka、Zookeeper、相關插件及依賴的 Jar 包），並以 FTP 形式提供，方便測試時隨時使用。
2. 安裝流程自動化：手工部署集羣的流程相對固定，通過自動化腳本處理，節省大量時間，降低人為誤操作的風險。

相關腳本包括：
__download_scrpits.sh: 下載所有腳本
download_kafka.sh: 特定版本 kafka 安裝包的下載與前置處理    
download_zookeeper.sh: zookeeper 安裝包的下載與前置處理init_before_download.sh: 安裝環境的初始化 (包括服務和數據路徑的創建、權限更改等操作，需要在下載安裝包之前且以有 root 權限的賬號運行)

測試環境
三台機器分別為：

• 10.103.17.55
• 10.103.17.56
• 10.103.17.57
  kafka manager 上“test-inner”集羣

測試驗證執行流程（測試用例）
結論：經過測試，方案 1 滿足目標，因此選定為最終升級方案。

Cloudera 部署集羣的搭建與測試

以當前生產環境下 Cloudera 部署集羣的最低版本 0.8.2.0 進行測試。
方案的選型與驗證策略：優先驗證手工升級方式，同時解耦 Cloudera 環境，因 Cloudera 部署和日常運維操作中存在以下問題：

1. 通過 yum 部署帶來的不便，各機器的 yum 緩存差異引入不確定性；
2. 部署過程中需在 Cloudera Manager 頁面和目標機器之間頻繁切換處理異常；
3. Cloudera 對服務目錄和數據目錄有特定權限設置；
4. 集羣日常增減機器的操作較為繁瑣。

測試環境

兩台機器分別為：

• 10.120.187.33
• 10.120.187.34

kafka manager 上“test-inner-cloudera”集羣    
測試過程：在 Cloudera 部署的測試集羣下驗證方案 1，未發現新問題。
結論：經測試，可以手工通過方案 1 對 Cloudera 部署的集羣進行升級，升級後 Cloudera Manager 上的 broker 將全部被替換。

極端異常場景測試

MirrorMaker 相關場景測試

由於線上環境的 MirrorMaker 僅涉及從 blue 集羣（0.8.2）到 violet 集羣（0.8.2）的複製，測試過程基於該版本的集羣進行，MirrorMaker 部署在源集羣上。和線上環境保持一致，MirrorMaker 部署在源集羣上。         

名詞解釋：

• 低版本：本節特指 0.8.2 版本
• 高版本：本節特指目標版本 2.2.1

測試結果顯示：

• 源集羣維持低版本，目標集羣升級，MirrorMaker 正常工作；
• 目標集羣為高版本，源集羣升級，MirrorMaker 保持不變，正常工作；
• 目標集羣維持低版本，源集羣升級，且 MirrorMaker 升級，MirrorMaker 工作異常。

MirrorMaker 實質上是一組與其所在 broker 版本相同的 Producer 和 Consumer。測試結果表明，高版本集羣能夠兼容低版本客户端，反之則不行。

升級過程需要注意事項：

1. 在升級 blue/violet 集羣過程中，需隨時關注 MirrorMaker 的工作狀態；
2. 本次集羣 broker 側升級過程中，MirrorMaker 保持現狀（包括版本和運行路徑），由於 MirrorMaker 使用 Cloudera 工作路徑和代碼，因此 blue 集羣的 Cloudera 工作路徑和代碼需保留，直至後續 MirrorMaker 版本升級完成。

其它關注點：          
新舊版本的元信息記錄文件（如：checkpoint）內容和格式是否有變更？升級前後是否存在差異？

• 0.8 版本的元信息記錄文件僅包含 recovery-point-offset-checkpoint 和 replication-offset-checkpoint；
• 2.2 版本的元信息記錄文件在保持上述兩個文件內容格式不變的情況下，新增 meta.properties、log-start-offset-checkpoint 和 cleaner-offset-checkpoint 三個文件。

線上集羣升級方案

配置項          
1.基本配置項，需要根據實際集羣進行修改：
broker.id：配置文件 server.properties 及數據路徑下的 meta.properties 文件；
listeners：對於使用機器名（非 IP）配置的 broker，需驗證機器 IP 和機器名映射的 IP 是否一致，如不一致，則需使用 IP 進行配置。

2.broker 配置項中值得關注的變更：    

3.其餘配置項，直接追加到新版本配置文件中，並加以註釋分割和説明。

手工部署集羣升級方案

説明： 

• 序號 1-8 的工作，可以提前操作完成，待正式操作線上前再校驗一次；
• 升級 broker 間通信協議前一定要完全確認集羣運行正常！

Cloudera 部署集羣升級方案

Cloudera 部署集羣的升級方案，與手工部署集羣的升級方案流程大體相同，不同點如下：

• 舊版本服務的啓停，是通過 Cloudera manager 進行操作的；
• 在停止舊版本服務後，必須對數據目錄權限進行調整以增加 worker 賬號的讀寫權限，原因是 Cloudera 部署的服務是通過 kafka 賬號進行讀寫的；
• “更新新版本的配置項”步驟中，新增內容“根據 brokerId 調整預留 brokerId 範圍”，原因是 Cloudera 自動生成的 brokerId 是在預留範圍以外的

説明：

• 序號 1-8 的工作，可以提前操作完成，待正式操作線上前再校驗一次；
• 升級 broker 間通信協議前一定要完全確認集羣運行正常！

注意事項

• 升級操作應避開集羣流量高峯時段；
• 開始操作前，需在用户羣中提前通知預計操作時長和潛在影響；
• 先在線上創建測試 topic，並啓動 Producer 和 Consumer，用於隨時觀察集羣可用性。 

以上就是今天分享的全部內容。

想了解更多關於大數據技術的內存擴容、縮容策略，詳盡解析了故障診斷與問題排查的方法論的問題，可以加入我們
 

感謝你的閲讀，如果喜歡我的文字，可以持續關注我，會陸續為你更新更多幹貨小知識。