如何定位应用中断的根源

核心业务和支撑业务系统的发展相互促进、相互影响,系统在发展中变得更加庞大和复杂。尽管网络运维技术的不断进步,但能够影响业务运行的因素也越来越多,网络效率、应用状态甚至一些安全检测活动都会与业务的稳定运行息息相关,这使得解决问题变得困难和复杂。

本案例将详细讲解在突然发生应用中断的情况下,如何快速、精准定位问题的原因。

 

5.1 问题描述

 

据某单位运维人员描述,省金融单位与该单位业务交易突然中断,中断时间长达数分钟之久。现已知在故障发生时,省金融单位正授权某安全企业进行安全检察,故该单位网络运维人员初步判断中断原因与此有关,但故障原因不祥。该单位的网络拓扑图如下:

图 5-1

 

5.2 分析过程

 

5.2.1 对数据流向进行监测分析

在故障时间及故障现象都明确的情况下,通过科来网络回溯分析系统捕获的流量进行深入分析。

首先采用10秒级精度观察外联防火墙外侧到“XX单位”的应用流量趋势变化,发现在18点45分10秒至18点51分50秒时间段,该应用流量接近零;同时,该时间段存在两条由XX单位(X.X.129.161-162)向省金融单位DMZ区服务器发送的TCP交易会话,数据包分别为6和7个,DMZ区服务器发送的数据包为0。由此,判断外侧采集点到DMZ区服务器可能存在问题,如下图所示。

图 5-2

同理比对分析外联防火墙内侧到“XX单位”的应用流量趋势变化,发现出现了流量接近于零的相同状况。两条TCP交易会话与防火墙外侧相反(DMZ区服务器发送的数据包均是2个,而XX单位则发送数据包为0),其他会话通讯现象相同,由此判断内侧采集点到XX单位可能也存在问题。

图 5-3

小结:通过对比分析防火墙内、外侧的交易数据指标,发现防火墙外侧DMZ区服务器向XX单位发送数据包为0,而防火墙内侧则相反,XX单位向DMZ区服务器发送数据包为0,因此初步断定防火墙造成了会话中断。

5.2.2 对中断TCP会话进行分析

选取一条交易中断的TCP会话进行解码比对,分析防火墙内外两侧传输状况。通过观看下两图所示的TCP交易时序图,可以得知:

1、交易中断时间约为5分钟(相对时间减法),与通过回溯流量趋势变化分析所得一致;

2、交易中断时间里

  • 防火墙内侧DMZ区服务器从4458号包到4463号包持续重传,但一直未收到XX单位的ACK数据包(TCP协议规定接收方需ACK确认收到数据)或其他数据包,说明位于内侧采集点到XX单位之间的数据包丢失。
  • 防火墙外侧XX单位从4455号包到4465号数据包也一直重传,也并未收到来自DMZ区服务器的ACK包或其他数据包,说明位于外侧采集点到DMZ区服务器之间的数据包丢失。
  • 在防火墙内外两侧均未观察到DMZ服务器重传发送的数据包(Seq= 1603812174)和XX单位服务器发送的数据包(Seq= 1988827095)。

判定防火墙造成两端服务器通讯中断,引起的原因可能与防火墙的会话丢失或物理链路故障有关。

DMZ区服务器或XX单位在中断5分钟后,DMZ区服务器与XX单位服务器才发送FIN关闭会话(分别为4463、4465号包),推测应用程序层面设定交易失效时间约5分钟。

交易中断起始阶段:

图 5-4

交易中断结束阶段:

图 5-5

综上所述,判断防火墙由于会话丢失或物理线路故障导致交易会话中断。同时,当在安全检查过程中,漏扫流量经过防火墙时可能会影响防火墙运行状况,针对此现象怀疑防火墙可能发生了HA主备切换,因此需要查看防火墙日志。下图是原备防火墙日志:

图 5-6

日志解释见上图,XX单位交易通讯中断原因确实是防火墙发生了HA切换,因Session同步丢失造成了原备机无法学习到交易的Session。我们知道防火墙是有状态的,后续交易的数据包因未能匹配状态而被丢弃,证明上文分析判断准确。

接下来我们讲解下可能存在的疑问:

疑问1:为何防火墙发生HA切换?

“2017-9-21 18:47:20  peer device 10424192 disappeared”该日志说明原主防火墙的邻居丢失。能够造成HA邻居丢失的因素较多,如HA心跳线中断、防火墙配置不当、防火墙BUG或防火墙资源不足,从而造成无法发送HA保持报文,超时后被对端认为邻居丢失,主动抢占为master。

再此案例中,是省金融单位正授权某安全企业进行安全检查的漏扫时刻,漏扫必然引起防火墙资源开销加剧,而HA线路是一直是好的、又并没有调整配置,所以可认为是防火墙资源不足的原因引起了HA切换。

疑问2:多少扫描量会造成防火墙资源不足?

如何快速定位扫描IP?漏扫往往会对主机的端口开放情况进行扫描,因此只需在被分析链路的“IP地址”分析界面上排序“发送TCP同步包”,观察与“接受TCP同步确认包”比例。主机开放端口往往不多,所以扫描时两者比例相差较大。

图 5-7

如上图所示,TOP 5的IP都具有扫描嫌疑,对其单独分析发现只有X.X.1.119是漏扫IP。对X.X.1.119进行回溯分析发现,该IP主要是向主机X.X.200.245发动扫描,特征为扫描端口随机发送SYN包,并未接收到SYN同步确认包或RST包,如下图所示。

图 5-8

再通过1秒精度的流量趋势展示(1秒精度的指标变化趋势展示,对日常运维分析非常关键,尤其是定位极短暂的业务中断的故障),了解到本次扫描时间为18点44分01秒到18点45分25秒,期间会话数达6182条。扫描数及流量不大,但确实严重造成了防火墙HA丢失。

疑问3:业务恢复慢于网络恢复?

从备防火墙日志上可以看到18点49分49秒左右,HA重新切换到原主防火墙上,之后不再有日志信息,同时漏扫活动早已停止,网络已稳定,但直到在18点51分50秒之后,业务才重新恢复正常交易。造成这一现象的原因,其实和应用交易计时有关。

通过上文我们判断应用层交易失效时间为5分钟,所以当交易失效时,DMZ区服务器在18点52分09秒才重新向XX单位发起新的交易连接(如下图中全新三次握手)。此时会话连接成功建立,可推测经过防火墙后其重新建立该笔TCP会话并放行,至此业务又重新恢复交易。

图 5-9

倘若省金融单位的应用能缩短失效的计时时间,或是在未收到对方ACK包时,拥有直接发送keep-alive探测网络运行状况的机制,服务器便能快速判断感知网络中断(网络中断故障可能发生在内部网络、或是专线、或是外联单位网络),提前重新建立交易进程,业务必然能更快速恢复。

 

5.3 分析总结及建议

 

通过对流量精细分析,发现交易中断是由于TCP会话传输中断造成。漏扫导致主防火墙资源不足,造成了备防火墙未收到主墙的peer保持报文,因此HA邻居丢失,发生了主-备切换。同时因为Session未成功同步,Session丢失造成了TCP传输中断,从而导致交易失败。

省金融单位的应用交易失效时间约5分钟,建议通过优化缩短失效时间或是增加keep-alive来判断网络中断(如5次keep-alive未收到对端ACK设定判断网络故障,拆连并重新发起新链接)。倘若再次碰到同类故障后,省A金融单位服务器便能快速新建会话,促使业务更快恢复。

 

5.4 价值

 

业务系统的稳定、高效运行依赖于诸多环节协同合作,如本案例所示:虽然由于防火墙的原因导致应用中断,但长时间应用中断现象,也是因为缺乏应用探测机制,无法快速重新建立会话导致。而通过网络回溯分析系统,我们可以从流量角度对问题现象进行深层次分析,不仅能从众多可能性因素中精确定位故障产生的根本原因,还能够提出相关优化建议,实现更有针对性的解决方案。

免费测试申请及购买咨询

您的名字 :

您的手机 :

您的邮箱 :

公司名称 :

您的职位 :

公司地址 :

网络规模 :

购买用途 :

补充留言:

验证: