案例分享LVS技术中MTU问题.pdfVIP

案例分享 LVS技术中的MTU问题 问题现象 某日，项目反馈某文件存储系统异常：有一台北京电信 通服务器上传文件慢。如右图，红框中时间差值变是上传所 花费的时间，可以看到有将近8秒。 注：该系统是一套分布式文件存储系统，主要应用范围是小 文件存储。支持高可用、动态添加节点等功能。它的系统架 构图如下所示： 存储服务器 WEB、索引服务器 LVS 问题排查 收到反馈后，运维人员马上针对系统各结点进行检查。 LVS服务器：keepalived工作正常、日志无异常 WEB服务器：apache和索引程序工作正常、日志无异常 存储服务器：存储程序工作正常 sood存储服务器 sood索引服务器 LVS 问题排查 应用层面没有发现任何异常情况，初步怀疑是网络问题造成的 延时。分别在LVS、WEB及Client服务器上同时抓包。发现以下几 个现象： 现象一（lvs）： 数据长度2920超过MTU，lvs给client发了一个ICMP包要求分片。 问题排查 现象二（client）： client收到ICMP包后，过了3.8秒才进行重传。 问题排查 现象三（client与lvs）： 上图分别为client和lvs上，请求分片的ICMP包之前收到的数据包，可以看到，sequence number相同的两个包，长度却不同，下一个包的sequence number也不同。说明在接收端，将两个 数据包进行了合并操作。而合并后的数据包长度超过了MTU。 问题排查 再来看client服务器上的这个包，很明显这个sequence number后三位为110的包是上一页中 650包的后续，而到了lvs服务器上，这两个包被合并了。长度也刚好吻合（1460 + 1460 = 2920）。 client lvs 问题排查 注：需要在wireshark配置中，将relative sequence number的勾选去掉。这样才能在client和 lvs服务器上找出相对应的数据包。 问题排查 到了这里，上传慢的问题已经有了眉目，解决问题有两个方向： 1. 加快client收到后ICMP请求分片后的响应速度。 2. 禁止lvs服务器合并数据包的操作，以避免发送ICMP请求分片。 对于第一种方案，进行了大量测试，发现linux服务器对这类请求响应速度非 常快，windows服务器则参差不齐，有的快，有的慢。非常不可控，而且短时 间内也无法查明原因。 知识铺垫 对于第二种方案，合并操作是和网卡、内核的特性有关。 高速网卡设备不仅可以自动计算数据包的校验和，而且可以根据不同的 协议自动的对数据包进行分片。由于MTU的限制，原先只能通过IP协议对大的 数据包进行分片，现在网卡设备硬件本身就可以分片，并自动计算出校验和。 在较新的Linux内核中，也加入了类似的功能，通过内核来分片而不是协议栈。 同时，在接收处理方面，也有一些对应的功能，可以合并数据包，接收大的数 据包。 这四个参数就是合并操作最主要的参数了。从上到下缩写依次为TSO、 UFO、GSO、GRO。 知识铺垫 UFO是专门针对UDP协议的，使用了这个特性，用户层就可以发送大的数据包（最大长度是64K ）， 而不需要由IP协议来分片。UFO与TSO，GSO没有任何的联系，但是却需要tx-checksumming，scatter- gather这两个特性的支持。遗憾的是，现在还没有看到有网卡支持UFO。所以，默认情况下，改功能的状 态是off 。当前UFO被应用在虚拟设备(