本帖最后由 Hacking 于 2022-5-20 13:15 编辑
本来这个是不想写的,理应当是一个运维的问题,结果发现近期又出现了这样的问题,服务通过AD负载均衡器使用LB的方式对外提供服务,client连接某LB_VIP的时候,发现client发送了syn,server直接回了rst断了连接。业务侧也是一遍又一遍的投诉,登陆服务器查看资源使用top,vmstat等命令查看了一番发现服务器各项指标都没有异常。于是将问题转向了网络层,业务反映只有在访问系统后台的时候才会出现卡顿,访问其他网站正常,本地使用ping服务器外网ip正常返回,无丢包,延迟也正常。最后检查了一遍业务系统,发现了问题,还是服务端机器配置了net.ipv4.tcp_tw_recycle=1 ,这个 表示开启TCP连接中TIME-WAIT sockets的快速回收。这种配置会导致一个问题,当服务是一个网关类的应用的时候且访问量很大的时候容易出现很多的连接拒绝的情况。
一, 现象:
资源池几台danted代理通过公网地址访问次级管理中心的负载均衡器业务8803端口偶尔会出现连接不上的问题,反映系统后台存在卡顿问题
二, 原因:
之前业务同事为改善time_wait连接数过多问题曾改过该内核参数,次级管理中心开启了net.ipv4.tcp_tw_recycle, 内核会记录TIME_WAIT连接的对端信息,包括IP地址、时间戳。当内核收到同一个IP的数据包时,就会去比较时间戳,检查包的时间戳是否滞后,如果滞后,就将其丢掉(认为是旧连接的数据)。当多台设备通过nat访问次级管理中心,使用同一个ip,设备之间如果时间不同步或者时间波动,某台设备的sync包时间戳可能会小于内核记录的TIME_WAIT连接的时间戳而被丢弃,导致不能正常建立连接。
通过netstat可以证实:
- <font size="3"> [root@VM-OS01-CSCENTER-28 ~]$ netstat -s |grep reject
- 74671837 passive connections rejected because of time stamp
- 92342 packets rejects in established connections because of timestamp
- </font>
复制代码
三,解决方法:
次级管理中心关闭tcp_tw_recycle, 确认无影响
四,操作步骤(在所有次级管理中心)
1,sudo sysctl -w net.ipv4.tcp_tw_recycle=0 系统实时生效
2,修改/etc/sysctl.conf, 把net.ipv4.tcp_tw_recycle = 1 改成 net.ipv4.tcp_tw_recycle = 0 ,以便下次机器重启时依然生效
总结一下:
网上的帖子,大多都写开启net.ipv4.tcp_tw_recycle这个开关,可以快速回收处于TIME_WAIT状态的socket(针对Server端而言)。而实际上,这个开关,需要net.ipv4.tcp_timestamps(默认开启的)这个开关开启才有效果。更不为提到却很重要的一个信息是:当tcp_tw_recycle开启时(tcp_timestamps同时开启,快速回收socket的效果达到),对于位于NAT设备后面的Client来说,是一场灾难——会导到NAT设备后面的Client连接Server不稳定(有的Client能连接server,有的Client不能连接server)。也就是说,tcp_tw_recycle这个功能,是为“内部网络”(网络环境自己可控——不存在NAT的情况)设计的,对于公网,不宜使用。通常,“回收”TIME_WAIT状态的socket是因为“无法主动连接远端”,因为无可用的端口,而不应该是要回收内存(没有必要)。即,需求是“Client”的需求,Server会有“端口不够用”的问题吗?除非是前端机,需要大量的连接后端服务——即充当着Client的角色。
经过此次故障,告诫我们在处理线上问题时,不能盲目修改参数,一定要经过测试,确认无误后,再应用于生产环境。同时,也要加深对相关内核参数的认识和理解。
世间万物,无一及你,希望本文能帮助您了解AD并熟悉其使用。喜欢的来个一键三连(关注+收藏+点赞),怕下次有好东西分享不到你。 |