潍柴动力大数据平台集群扩容


项目背景

       潍柴动力股份有限公司为快速响应业务部门数据分析的需求，支撑整个集团业务快速发展,保障大数据平台稳定运行和项目的实际应用开发，快速响应解决大数据平台故障及性能问题与车辆管理数据增长过快问题,需要将部分业务数据从原有数据湖KAFKA集群中迁移至新搭建的车联网KAFKA集群中,在车联网集群中搭建了版本号为2.1.0的KAFKA集群,并将车辆管理数据从原有KAFKA集群成功迁移至新集群。

项目目标

      解决KAFKA文件描述符激增问题

解决方案

    发现问题后采取以下措施：

  1. 在CM界面查看问题Broker的“最大进程文件描述符数”，发现没有配置。

  2. 将问题Broker的“最大进程文件描述符数”由默认的1024修改为65535。

  3. 重启问题Broker。

  4. 重启后，文件描述符问题得到缓解。

                                                                                            图：文件描述符激增以及重启后缓解


      重启完成，集群在平静了2个小时后，pfkf01ht.weichai.comBroker文件描述符再次激增。在发现问题后，我们迅速定位问题。通过lsof 和 netstat命令查看文件句柄数，发现句柄数过多确实是由kafka进程导致的，且处于CLOSE_WAIT状态的socket在以每秒50个左右的速度在递增。



                                                                                                              图：close_wait状态递增




    由于CLOSE_WAIT状态的链接过多，怀疑是网络问题，于是优化网络如下。

1、修改/etc/sysctl.conf配置文件

2：net.ipv4.tcp_keepalive_time=30

3：net.ipv4.tcp_keepalive_probes=2

4：net.ipv4.tcp_keepalive_intvl=2

5：sysctl -p


     优化完成后，CLOSE_WAIT状态的链接不在开始增加，稳定了下来，但是句柄数依然在激增。

     此时pkfk01ht.weichai.com句柄数已经达到64184，Broker宕掉。只好重启。


                                                                                        pkfk01ht.weichai.com FD达到顶峰

      重启完成后，pkfk01ht.weichai.com文件描述符恢复正常水平，但pkfk03ht.weichai.com的文件描述符开始激增。

按照以上步骤开始排查pkfk03ht.weichai.com问题。

排查问题时发现，文件描述符最大数量只在CM界面配置了，操作系统层面并没有配置，于是给系统配置ulimit参数，配置大小为65535。

参数设置之后，FD依然激增。


     此时怀疑是外部因素导致的，因为zookeeper有canary无法删除znode的报错。排查zookeeper。


                                                                                                          图：zookeeper报错

       查看zookeeper-client能否登录，并查看kafka存储在zookeeper中的broker id。发现均正常使用。


                                                                                 图：zookeeper-client查看broker id

     继续测试zookeeper命令，均正常使用。


     于是在CM界面将“最大文件描述符数”调整到了655350,并继续排查问题

6月22日九点，通过运行命令，查看lsof以及netstat。发现sock过多，怀疑可能是由于kafka Server端和Client端不一致引发的一个BUG（后来发现不是这个BUG，而是另一个线程死锁 BUG）。


                                                                                          图：lsof命令运行结果


                                                                                           图：netstat运行结果

       在6月22日下午，我们详细排查了kafka的日志，以及堆栈信息还有kafka诊断包

6月23日上午，确定了kafka Broker文件描述符激增是由于一个已知的BUG：KAFKA-7697引起的。

附连接:

https://issues.apache.org/jira/browse/KAFKA-7697

         这个BUG的诱因和业务的多线程和高并发可能有一些关系。

从诊断包中的信息中可以看到, 很多Broker的线程在已持有 ReadLock 的情况下, 还在等待另一个锁, 导致死锁的现象发生。其他 Broker 连接上来之后, (socket 已经建立), 但是发生死锁的 Broker 无法去处理这个请求, 导致 socket 既没有实际发生数据传输, 最后也没有机会关闭, 所以会有持续 leak 的现象。

经过排查发现CDK4.1中已经修复了这个BUG，所以最后建议升级kafka版本为4.1.0。



项目成果

      通过升级KAFKA集群版本成功解决该BUG导致的KAFKA文件描述符激增问题