专栏首页工作专用1记一次线上DPDK-LVS的故障排查
原创

记一次线上DPDK-LVS的故障排查

背景

我们内部基于dpdk自研的高性能负载均衡器dpvs已经在多个机房部署上线,运行正常,但近期有多个金融相关的业务反馈,服务数据包在经过dpvs转发后,会出现hang住的情况。

问题

dpvs已经在多个机房上线,运行时间已超过半年,为何突然有业务反馈异常反馈问题的业务多与金融区相关(金融区由于其特殊性,会额外增加安全方面的加固策略)为什么问题表现均为服务hang住

问题排查

首先,我们怀疑与dpvs或与金融的某些安全策略相关,因此我们做了如下测试(后端上跑的均是相同的测试代码,并模拟了服务端逻辑): client < ----- > dpvs < ----- > rs(金融区) 不正常 client < ----- > dpvs < ----- > rs(非金融区) 正常 client < ----- > lvs < ----- > rs(金融区) 正常 client < ----- > lvs < ----- > rs(非金融区) 正常 通过1、2组测试能够得出结论:该问题与金融区相关且dpvs转发正常 通过3、4组测试能够得出结论:该问题与金融区无关且kernel版lvs转发正常 通过1、3组测试能够得出结论:该问题与dpvs有关,经过dpvs的请求不正常 通过2、4组测试能够得出结论:该问题与dpvs/lvs无关,经过dpvs/lvs的请求均正常 以上4组结论两两冲突,无法定位问题是与dpvs相关还是与金融区相关,排查一度进入僵局,无法定位故障点。 为了进一步排查,我们在client和后端rs上抓包排查,发现client的请求均能够正常到达rs,而rs的大部分数据也能够正常回复给client,但有固定的几个包总是会被重传且直至超时,以下是抓包截图:

其中10.128.x.x是rs的ip,10.115.x.0/24是dpvs的local ip,通过在rs上的抓包结果可以清楚的看出rs发给dpvs的length为184的包正确传输,但length为2的包一直在重传,且直至超时都没有成功,同时在client上的抓包显示,client收到了这个length为2的包,但是由于tcp checksum error被丢掉了,并没有交给上层应用去处理,这样就解释了为什么异常时的表现是hang住,因为某个数据包一直在重传,直至timeout。 通过上面的分析,我们又产生了疑问:现在的硬件网卡一般都具有csum offload的功能,能够通过网卡硬件帮我们做checksum,难道是网卡的checksum offload功能出现了问题?如果真是网卡硬件的offload功能出现问题,那影响的应该不是某一个特定的数据包,而是所有经过这块网卡的数据包才对,因此我们怀疑是网卡在针对某个特定数据包的计算checksum的时候产生了错误,为了验证这个问题,我们在dpvs上进行抓包分析,以下是抓包截图:

这个就是被不断重传的包,能够看到dpvs确实收到了这个包,并且处理逻辑也完全正常,剩下的步骤只有通过网卡做checksum并把这个数据包转发出去,问题似乎确实是出在了计算checksum这里,我们在分析这个包有什么特点,可以看到,这个包的初始大小=ethernet header length + ip header length + tcp header length + tcp data = 14 + 20 + 20 + 5 = 59,而我们知道,在网络中传输的数据帧最小长度为64字节,除去FCS的4字节(这部分也由网卡自行计算后添加在数据包末尾),最小长度应为60字节,也就是说,到达网卡的数据包如果不够60字节,那么网卡会在动在数据包末尾增加全0的padding来使数据包能够达到60字节,所以这个数据包也是需要网卡硬件来补充1字节的padding来达到最小传输长度。对此rfc894是这样规定的:

因此rs的网卡在数据包长度不足60字节时需要做两件事情:

  • 补充1字节的padding达到最小长度60字节
  • 补充的padding为全0

可以看到,在二层头中,确实有个补充的1字节的padding:ec,这个padding并没有按rfc894的规定填充成全0,而是填了非0值,这样就造成了dpvs的网卡在计算tcp checksum时把这个padding误当成了tcp data而计算了check sum,因此在client接收到这个数据包并根据ip伪头部和tcp头部计算出来的checksum与数据包tcp头部的checksum不一致,因此并没有把这个数据包交给上层应用处理而是直接drop。

----- 网卡手册针对 TCP/UDP checksum部分的说明 至此,问题的原因已经很明显了:部分机器的网卡在做padding时未按照rfc894的规定补充全0而是补充了其他值,导致dpvs的网卡在做checksum offload时padding的数据也参与了checksum的计算。 分析正常的rs和不正常的rs在网卡硬件上的差别,发现:网卡的硬件型号相同,驱动型号也相同,但不正常的网卡fireware与正常的网卡不相同,而fireware我们没有办法自行升级或降级。 整个故障的过程可以大概表示为: client dpvs rs ---1--- &gt; &lt; ---2--- &lt; ---3--- 步骤1:数据包正常,请求数据 步骤2:部分数据包初始长度小于60字节,需要网卡补充padding,网卡先计算checksum填入tcp包头后补充padding至数据包末尾,此时checksum正常,但padding不为全0 步骤3:dpvs收到步骤2的包进行正常转发逻辑处理后转发至网卡,由网卡计算checksum并转发,但在计算新的checksum时由于padding非全0导致checksum计算错误,client收到后丢弃了这个包 ps:以上是rs的网卡在添加padding时补充的不是全0,另一种场景是client的网卡在添加padding时补充的不是全0,这两种情况都会导致上述问题的出现。

问题解决

至此,我们已经能够解释最开始提出的三个问题: dpvs已经在多个机房上线,运行时间已超过半年,为何突然有业务反馈异常 a:该业务是在某个核心机房上线了dpvs后出现了问题,其他机房很早上线了dpvs但由于其他机房是改业务的备份机房实际并未启用,因此半年多来一直没有发现问题 反馈问题的业务多与金融区相关(金融区由于其特殊性,会额外增加安全方面的加固策略) a:排查发现是金融区的某一批次机器的fireware存在bug导致,与金融区本身的安全策略无关 为什么问题表现均为服务hang住 a:问题的实质是出现丢包,服务在等待响应,因此表现为hang住 接下来我们将解决该问题: 只要让dpvs在处理数据包时,忽略数据包以前的padding部分,而由dpvs的网卡重新去处理padding(由于网卡计算checksum是在补充padding之前,因此可以保证此时的checksum一定是正确的)。由于dpvs是基于dpdk开发的,数据包在dpvs中是以mbuf的结构保存和处理的,以下是mbuf的结构: 数据帧被存储在headroom和tailroom之间(与skb类似),pkt_len=data_len=整个数据帧的长度,我们要做的就是将padding从data中去除(放到tailroom中去),因此可以在数据包入口处添加以下代码:

int padding_length = mbuf->data_len - (mbuf->l2_len +rte_be_to_cpu_16(ipv4_hdr->total_length));

mbuf->data_len = mbuf->data_len - padding_length;

mbuf->pkt_len = mbuf->data_len;

添加以上代码后测试通过,本次故障解决。

参考资料

https://tools.ietf.org/html/rfc894

http://doc.dpdk.org/guides/prog_guide/mbuf_lib.html

https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/82599-10-gbe-controller-datasheet.pdf

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • CVE-2019-12592:印象笔记Chrome扩展漏洞分析

    Guardio研究人员发现了Evernote Web Clipper(印象笔记·剪藏)Chrome扩展存在逻辑编码错误漏洞,攻击者利用这些漏洞可以打破隔离机制并...

    迅达集团
  • 关于jHispster框架在构建中的出现的error修复

    jhipster The JDL object and the database type are both mandatory.这个错误应该是在构建基于jHi...

    迅达集团
  • 关于jHispster框架在构建中的出现的error修复

    jhipster The JDL object and the database type are both mandatory.这个错误应该是在构建基于jHi...

    迅达集团
  • 关于mysql操作的详细介绍以及实例

    前言:在后台开发中绝对避免不了要关系型数据库管理系统。常见的数据库管理系统有MySql、SQLServer、Oracle等。

    叫我可儿呀
  • Http Referer 的盗链与反盗链

    happy123.me
  • Red Hat安全公告—2016年7月

    在2016年6月份至2016年7月份 Red hat CVE漏洞库发布了7个“重要”等级的安全漏洞,针对出现的安全漏洞,发布了对应的Bugzilla。安全公告每...

    嘉为科技
  • RabbitMQ集群和高可用方案

    Cluster多机多节点部署:多机多节点是指在每台机器中部署一个RabbitMQ服务节点,进而由多个机器组成一个RabbitMQ集群

    CodingDiray
  • 语义分割--DeconvNet--Learning Deconvolution Network for Semantic Segmentation

    版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/zhangjunhit/article/de...

    用户1148525
  • 科学瞎想系列之八十三 说说短路

    本期瞎想我们说说短路,和以前瞎想不同的是,本期的“说说”是真的说说,不像以前那样写文字了,而是以音频和PPT的形式来呈现这期瞎想,这也是瞎想系列的...

    标准答案
  • FFmpeg 播放器实现音视频同步的三种方式

    前文中,我们基于 FFmpeg 利用 OpenGL ES 和 OpenSL ES 分别实现了对解码后视频和音频的渲染,本文将实现播放器的最后一个重要功能:音视频...

    字节流动

扫码关注云+社区

领取腾讯云代金券