功能验证 - 愚蠢的重命名修复
建议更改
PDF
对于功能验证，我们表明，使用 NFSv3 挂载存储的 Kafka 集群无法执行分区重新分配等 Kafka 操作，而使用修复程序挂载在 NFSv4 上的另一个集群可以执行相同的操作而不会出现任何中断。
验证设置
该设置在 AWS 上运行。下表显示了用于验证的不同平台组件和环境配置。
| 平台组件 | 环境配置 |
|---|---|
Confluent 平台版本 7.2.1 |
|
所有节点上的操作系统 |
RHEL8.7或更高版本 |
NetApp Cloud Volumes ONTAP实例 |
单节点实例 – M5.2xLarge |
下图显示了该解决方案的架构配置。
建筑流程
-
*计算。*我们使用了四节点 Kafka 集群，并在专用服务器上运行三节点 zookeeper 集合。
-
*监控*我们使用两个节点来实现 Prometheus-Grafana 组合。
-
*工作量*为了生成工作负载，我们使用了一个单独的三节点集群，该集群可以从该 Kafka 集群中生产和消费。
-
*贮存。*我们使用了单节点NetApp Cloud Volumes ONTAP实例，该实例连接了两个 500GB GP2 AWS-EBS 卷。然后，这些卷通过 LIF 作为单个 NFSv4.1 卷公开给 Kafka 集群。
所有服务器都选择了 Kafka 的默认属性。对动物园管理员群也做了同样的事情。
测试方法
-
更新 `-is-preserve-unlink-enabled true`到kafka卷，如下：
aws-shantanclastrecall-aws::*> volume create -vserver kafka_svm -volume kafka_fg_vol01 -aggregate kafka_aggr -size 3500GB -state online -policy kafka_policy -security-style unix -unix-permissions 0777 -junction-path /kafka_fg_vol01 -type RW -is-preserve-unlink-enabled true [Job 32] Job succeeded: Successful
-
创建了两个类似的 Kafka 集群，但有以下区别：
-
*集群 1.*运行生产就绪ONTAP版本 9.12.1 的后端 NFS v4.1 服务器由NetApp CVO 实例托管。代理上安装了 RHEL 8.7/RHEL 9.1。
-
*集群 2.*后端 NFS 服务器是手动创建的通用 Linux NFSv3 服务器。
-
-
在两个 Kafka 集群上都创建了一个演示主题。
集群 1：
集群 2：
-
数据被加载到这两个集群新创建的主题中。这是使用默认 Kafka 包中的生产者性能测试工具包完成的：
./kafka-producer-perf-test.sh --topic __a_demo_topic --throughput -1 --num-records 3000000 --record-size 1024 --producer-props acks=all bootstrap.servers=172.30.0.160:9092,172.30.0.172:9092,172.30.0.188:9092,172.30.0.123:9092
-
使用 telnet 对每个集群的 broker-1 执行健康检查：
-
远程登录
172.30.0.160 9092 -
远程登录
172.30.0.198 9092下图显示了两个集群上的代理的成功健康检查：
-
-
为了触发导致使用 NFSv3 存储卷的 Kafka 集群崩溃的故障条件，我们在两个集群上启动了分区重新分配过程。分区重新分配是使用
kafka-reassign-partitions.sh。具体过程如下：-
为了重新分配 Kafka 集群中主题的分区，我们生成了建议的重新分配配置 JSON（对两个集群都执行了此操作）。
kafka-reassign-partitions --bootstrap-server=172.30.0.160:9092,172.30.0.172:9092,172.30.0.188:9092,172.30.0.123:9092 --broker-list "1,2,3,4" --topics-to-move-json-file /tmp/topics.json --generate
-
生成的重新分配 JSON 随后保存在
/tmp/reassignment- file.json。 -
实际的分区重新分配过程由以下命令触发：
kafka-reassign-partitions --bootstrap-server=172.30.0.198:9092,172.30.0.163:9092,172.30.0.221:9092,172.30.0.204:9092 --reassignment-json-file /tmp/reassignment-file.json –execute
-
-
重新分配完成后几分钟，对代理进行的另一次健康检查显示，使用 NFSv3 存储卷的集群遇到了一个愚蠢的重命名问题并崩溃了，而使用已修复的NetApp ONTAP NFSv4.1 存储卷的集群 1 继续运行而没有任何中断。
-
Cluster1-Broker-1 处于活动状态。
-
Cluster2-broker-1 已死亡。
-
-
检查 Kafka 日志目录后，很明显，使用已修复的NetApp ONTAP NFSv4.1 存储卷的集群 1 具有干净的分区分配，而使用通用 NFSv3 存储的集群 2 由于愚蠢的重命名问题而没有，从而导致崩溃。下图显示了集群 2 的分区重新平衡，这导致了 NFSv3 存储上出现了一个愚蠢的重命名问题。
下图显示了使用NetApp NFSv4.1 存储对集群 1 进行干净的分区重新平衡。
