项目实施｜Kafka集群升级方案，我们踩过的不少坑

项目背景

我们团队负责维护的 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，用于随时观察集群可用性。 

---

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

想了解更多关于大数据技术的内存扩容、缩容策略，详尽解析了故障诊断与问题排查的方法论的问题，可以加入我们
 

感谢你的阅读，如果喜欢我的文字，可以持续关注我，会陆续为你更新更多干货小知识。