项目背景

我们团队负责维护的 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 操作完成)，根据操作复杂度决定是否需要进行手动后台操作。

测试验证选择方案的过程，实际上是不断解决上述方案中的各项“如果”“尝试”的过程。随着这些项的全部解决和确定，最终的执行方案也就确定了。

测试过程及用例记录

快速搭建测试集群

• 安装包：为了搭建多个版本的集群，提前下载所有需要的安装包（包括 Kafka、Zookeeper、相关插件及依赖的 Jar 包），并以 FTP 形式提供，方便测试时随时使用。

• 安装流程自动化：手工部署集群的流程相对固定，通过自动化脚本处理，节省大量时间，降低人为误操作的风险。

相关脚本包括：

• __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. 集群日常增减机器的操作较为繁琐。

测试环境：   

两台机器分别为：

1. 10.120.187.33

2. 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. 序号 1-8 的工作，可以提前操作完成，待正式操作线上前再校验一次；

2. 升级 broker 间通信协议前一定要完全确认集群运行正常！

Cloudera 部署集群升级方案  

Cloudera 部署集群的升级方案，与手工部署集群的升级方案流程大体相同，不同点如下：

1. 旧版本服务的启停，是通过 Cloudera manager 进行操作的；

2. 在停止旧版本服务后，必须对数据目录权限进行调整以增加 worker 账号的读写权限，原因是 Cloudera 部署的服务是通过 kafka 账号进行读写的；

3. “更新新版本的配置项”步骤中，新增内容“根据 brokerId 调整预留 brokerId 范围”，原因是 Cloudera 自动生成的 brokerId 是在预留范围以外的

说明：

1. 序号 1-8 的工作，可以提前操作完成，待正式操作线上前再校验一次；

2. 升级 broker 间通信协议前一定要完全确认集群运行正常！

注意事项

1. 升级操作应避开集群流量高峰时段；

2. 开始操作前，需在用户群中提前通知预计操作时长和潜在影响；

3. 先在线上创建测试 topic，并启动 Producer 和 Consumer，用于随时观察集群可用性。

          

升级方案演练

目标          

在测试环境对即将进行升级的集群操作进行全流程演练，主要目的有两点：

1. 以文档的形式固化操作步骤 (包括每一步的执行人、执行的具体命令/操作、执行耗时 (作为线上操作预计耗时)、检查点，以及可能的回滚方案)，供线上操作使用；

2. 演练执行并确认回滚步骤的有效性。

其它问题

1.Cloudera manager 操作   

• Cloudera manager 的部署和操作细节，可能需要多请教佳哥和玉才    

• 如果在 Cloudera manager UI 上操作，需要关注每一步操作对应的后台变更 (可以随手记录积累经验)

2.集群与 Cloudera 环境剥离         

在本期升级完成后，对 Cloudera 环境的依赖将仅剩 zookeeper，可考虑在后续进行迁移，以完全脱离 Cloudera 环境副本数为 1 / ISR 中只有一个 的 topic 的处理这种情况下是否可能有数据丢失，取决于写入的数据是否含 key：

• 如果不含 key，则某个 broker 重启过程中，数据会写到其它 broker 分区中，理论上不会丢失数据；

• 如果含有 key，则某些 key 对应的数据必须写到某个 broker，这样，该 broker 重启过程中，这些数据丢失的可能性就较大，需要提前和用户沟通。

3.数据路径下 meta.properties 文件中 brokerId 与集群配置文件中不一致   

影响：如果上述两种文件中记录的 brokerId 不一致，服务会启动失败          

原因：之前 brokerId 有变更          

解决：启动服务前修改 meta.properties 文件中的 brokerId，以匹配集群配置文件 server.properties 中的 brokerId；或者全部删除数据路径下的 meta.properties 文件    

4.低版本 (0.8.x) 集群中的 topic __consumer_offsets 不健康   

影响：集群升级到高版本后，高版本 consumer API 依然不可用          

原因：之前 brokerId 有变更          

解决：最好在升级之前删除该 topic (执行相关命令进行删除 + 删除 zookeeper 元数据 + 删除数据文件)，滚动重启集群，然后再进行升级操作。

5.机器 IP 和机器名的双向映射不一致

影响：如果 broker 配置中绑定机器名，则会导致服务无法启动          

原因：机器 IP 变更          

解决：修改 broker 配置项"listeners"，绑定机器 IP 来替换机器名

思考：1 个大集群 VS 多个小集群

考虑因素：稳定性 (如:集群之间相互隔离)、运维 (如:便捷程度、重启对客户端的影响) 等大集群重启 broker 会慢，在加载数据过程中 broker 是不可用的。    

执行计划  

    

---

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