负载均衡会话时间导致故障案例

案例分析

         本案例介绍了某电商交易系统内部突发故障，网络运维人员利用科来回溯分析系统抓取链路上数据包，完整还原业务交互过程，明确故障原因，解决开发人员和运维人员的困恼。

背景描述：

电商交易系统时刻有业务，某一天发生了交易异常，运行人员协调客户端、服务器开发人员和网络人员进行故障排查，整个拓扑图如下，客户端将交易请求发给负载均衡，负载均衡转发给后台服务器：

客户端开发人员在客户端查询到在28分的时候发出交易请求，迟迟等不到服务器响应，但是到43分才收到服务器的响应，客户端认为服务器处理时间过长。服务器开发人员比较委屈，他说在43分才收到交易请求。网络人员通过在负载均衡前后部署科来回溯分析系统进行抓包，回溯网络传输过程中的报文传输路径，还原传输过程，明确故障原因，给客户端和服务器都有交代。

分析过程：

根据客户端开发人员提供的关键词：6939776880582542，对客户端报文进行筛选：

发现客户端开发人员所说，交易在28分就发出，并进行重传。

对负载均衡后端服务器进行抓包，发现如服务器开发人员所说，43分才收到相关报文。

客户端和服务器开发人员均说的有道理。仔细看，负载均衡前，传输交易的时候，距离上一次发包有20分钟，而且是数据包重传，负载均衡后，是新建会话。

现在看来，因为负载均衡没有对重传包进行转发。仔细查看负载均衡前报文，发现客户端在发该交易前，有20分钟的空闲，猜测是不是负载均衡因空闲太久，将会话清除。

经过负载均衡运维人员咨询，负载均衡默认会话超时时间是2分钟，两分钟内无新数据包过来，则将会话清除，不再对原有会话数据包进行抓发。经过对负载均衡进行日志查询，果然，在负载均衡上同时间段看到“First packet isn't SYN”的日志，表明负载均衡已经将会话清除，同时因为数据包再次发过来，负载均衡识别到该数据包不是新建会话的SYN包，将该包丢弃，同时日志显示该包不是SYN包。

分析结论与解决方案：

         由于负载均衡会话超时时间过短（2分钟），导致客户端在超过2分钟后的包被认为异常，负载均衡不再进行包转发而直接丢弃。由于客户端和服务器会话超时时间均为30分钟，修改负载均衡会话超时时间为30分钟后，故障不再出现。