某省移动公司网络业务回溯全过程(二)

中国移动通信集团作为全国乃至世界最大的运营商,业务量不断增大,各类业务系统的持续加入,网络规模也随之升级与发展,网络及业务故障、异常日益突出。

问题描述

为了能对网络中业务数据进行可视化的监控、分析、诊断,帮助管理员排除网络事故,规避安全风险,提高网络可用性,某省移动公司业务支撑部部署了科来网络回溯分析系统对门户网站,针对其BOSS系统,数据库等关键节点进行监控,并在日常运维中利用该系统协助分析并解决了大量问题。

分析价值

通过数据流进行解码快速分析与定位网络故障位置、分析应用流量确定故障原因,为排障以及优化网络资源提供可靠数据依据;通过长期监测网络带宽用量、能够建立网络基准,一旦出现异常流量能够迅速发现,减少故障恢复时间,甚至能在故障发生前消除故障隐患。

分析过程

本次案例讲解为第二次推送,按照网络分析逻辑,深入浅出讲解回溯分析全过程。请在“延伸阅读”阅读上篇。

缴话费业务故障分析

背景

月初缴话费业务大量交易超时情况。20台缴费服务器通过*.*.*.32访问BOSS系统*.*.*.249。*.*.*.32通过边界防火墙是会被NAT为*.*.*.1。

分析过程

出现超时告警时,在科来回溯上查看发现*.*.*.32访问*.*.*.249有部分连接显示状态为同步包已发送,即TCP连接没有建立成功。

提取会话可以看到这些TCP会话均为10个数据包,并且连接都没有建立成功。

正常建立连接时,*.*.*.249收到SYN包后应该回复SYN ACK包才能正常建立连接,并且SYN ACK包的Ack应该等于SYN包的Seq+1,如下左图。连接建立失败时,*.*.*.249收到SYN包后回复的是ACK包,并且该包的Ack字段与SYN包的Seq完全没有关系,因此TCP连接不能建立,SYN包重传5次后连接失败,如下右图。

通过移动省公司网状网端科来回溯上提取的对应会话对比,如下图。*.*.*.249回复的异常ACK包的Ack字段与上一个会话的FIN包Ack字段相等。说明在上一个会话还没有结束连接之前,客户端就重复使用了源端口建立连接,导致连接建立失败。

总结

经过上文分析,服务器在上一个会话还没有结束连接之前,就重复使用了源端口向省公司BOSS系统建立连接,导致连接建立失败。TCP连接建立客户端随机使用源端口与服务器建立连接,对于一个客户端IP源端口数量是有限的。当业务量增大,建立连接速度大于连接结束速度,并且持续一段时间导致可用源端口数耗尽。客户端就会使用到连接中的源端口,导致新连接无法建立。增加客户端的IP数量能够有效缓解业务量增大时,源端口达到上限而产生的新连接建立失败的现象。

数据库延时问题

月初缴费高峰缴费业务数据库出现大量延时告警,延时为1.302秒。

部署点一为应用服务器集群出口,该点发现1.3秒的延时是有重传导致的。

部署点二为数据服务器出口,该部署点没有发现重传包的原始包,说明数据在传输中被丢弃了。

为了找到抓包位置我们增加了部署点三,核心交换机入口,防火墙入口和防火墙出口。由于该交换机只能做一个镜像,因此三点只能镜像到一个口出,也就是说任何正常的包会被抓三次。如下图右,只有重传包的原始包只被抓到2次,其余包均被抓到三次。可以判断丢包只能是防火墙。

总结

月初缴费高峰移动电商缴费业务数据库出现大量延时告警,通过多段抓包对比发现延时是由于丢包造成的,丢包点位应用服务器区的防火墙。

-END-

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20171211A0I8KC00?refer=cp_1026

扫码关注云+社区