• 快捷搜索
  • 全站搜索

服务器间歇性连接中断故障的排查

2017-12-28 16:27:38作者:中国人民银行南昌中心支行 谭罗生编辑:金融咨询网
“MQ”是一款主流的消息中间件产品,由于其为应用系统提供高效、灵活的消息同、异步处理、存储转发与可靠传输,如今MQ已广泛应用于人民银行联网核查、国库信息处理、中央银行会计核算、人民币跨境收付、财政支付电子化、反假货币等诸多系统。

MQ应用背景

  伴随大数据时代的到来,为解决系统及应用间大批量数据的可靠传输,普遍采用消息中间件。而IBM WebSphere MQ(以下简称“MQ”)是一款主流的消息中间件产品,由于其为应用系统提供高效、灵活的消息同、异步处理、存储转发与可靠传输,如今MQ已广泛应用于人民银行联网核查、国库信息处理、中央银行会计核算、人民币跨境收付、财政支付电子化、反假货币等诸多系统。目前人民银行与金融机构、财政、税务、国库系统间的联网已离不开消息中间件的支撑,对于人民银行省级节点来说,MQ的运维关系重大,一旦出现故障,将引发“多米诺”骨牌效应,直接影响全省范围内人民银行诸多业务系统的运行。

故障现象与影响范围

  财政支付电子化系统上线后,先后发现南昌中支数据中心DMZ区财政支付电子化服务器(9.*.*.70)及MQ队列管理程序服务器(9.*.*.7 1)与生产MQ前置机(9.*.*.8)之间出现间隙性无法连接的现象(经ping与telnet测试),导致了财政支付电子化系统异常及无法通过MQ队列管理程序服务器(Windows系统)对MQ队列进行维护管理的故障现象。在一般情况下(即MQ通道正常条件下),MQ对内(业务网)、对外(金融城域网)服务正常,除财政支付电子化系统化,其他应用系统不受该故障影响。但当某个应用(如联网核查等)需要重置MQ队列通道时,由于无法对MQ队列通道进行维护管理,从而以上故障也可能间接影响使用了MQ的其他应用系统的持续运行。

故障排查过程

  由于MQ对内、对外提供正常服务,而从防火墙DMZ区分别ping以上三台服务器均显示正常,故开始未怀疑到网络原因,怀疑过是VMWare虚拟化导致的问题。但由于生产MQ与测试MQ(9.*.*.9)均由同一台物理机虚拟而来,而测试MQ没有出现过类似故障,故虚拟机原因解释不通。

  恰巧今年10月份等保测评时,对生产MQ服务器进行过安全策略加固,而测试MQ未加固,正好与生产MQ异常、而测试MQ又正常这一场景吻合。推测是否是等保安全加固策略导致以上故障现象,采取的临时性的解决办法是在9.*.*.70及9.*.*.8之间互相长ping,强制两服务器之间保持不问断连接。

  在11月份部署基于Zabbix的运维监控系统时,监测到从Zabbix ping其他被监控主机时周期性出现丢包,排查确认是IP地址冲突引起丢包,更换IP后故障排除。从这一故障现象推测M(=)故障中断是否也是地址冲突引起,但生产MQ所分配DMZ区ip、对内及对外映射ip使用多年,从未出现过IP地址冲突,经排查,排除IP地址冲突可能。

  考虑到年终决算将至,为定位故障、消除隐患,南昌中支于11月18日向总行申请MQ系统维护窗口。

  为定位故障点,对MQ停机,首先排除MQ服务器原因,将一台PC机(单网卡)模拟设成MQ系统(9.*.*.8),接入网络进行测试。从DMZ区财政支付电子化服务器用arp—ing命令测试记录如下:

  [root@ITFE_PROD]# arp i n g—l eno33557248 9.140.62.8

  ARPING 9.*.*.8 from 9.*.*.70 eno33557248

  Unicast reply from 9.*.*.8[02:6A:3E:4B:00:03]0.753ms

  Unicast repIy from 9.*.*.8[00:50:56:9C:1 6:CA]0.790ms

  Unicast repIy from 9.*.*.8[00:50:56:9C:16:CA]0.716ms

  通过arping命令发现生产MQ对应两个MAC地址,经过排查,确认[00:50:56:9C:16:CA]为VMWare虚拟机网卡MAC地址,查看天融信外联防火墙ARP表,与防火墙ARP表记录的MAC地址一致。

  由于测试MQ未出现过网络异常,为了对比,断开测试MQ,将测试PC机模拟成测试MQ(9.*.*.9),接入网络进行测试。从DMZ区测试记录如下:

  [root@ITFE—PROD]# arping—Ieno33557248 9.*.*.9

  ARPING 9.140.62.8 from 9.*.*.70eno33557248

  Unicast repIy from 9.*.*.9[00:50:56:9C:16:一CA]0.809ms

  Unicast reply from 9.*.*.9[00:50:56:9C:16:一CA]0.718ms

  通过以上排查分析,可以确认,生产MQ与DMZ区服务器通信异常问题是由于MAC地址冲突引起,而冲突源是[02:6A:3E:4B:00:03]。查询发现该冲突源为私有MAC地址,但该私有MAC从何而来,源头在哪?

  从测试MQ未现过异常这一信息入手,我们将对比排查生产MQ与测试MQ差异性作为查找思路。通过分析验证,抽丝剥茧,层层递进,先后排除了MQ服务器、接入层交换机、F5负载均衡设备等因素,最后将故障点定位于外联防火墙。

  还是从排查生产MQ与测试MQ在防火墙上的配置策略差异性入手,由于生产MQ与测试MQ在防火墙的地址转换规则大多数类同,通过将两者规则逐一对比,最终找到定位。

  由于FIC—M监控主机部署于内网,其ip(访问源)为内网地址11.*.*68,因此访问目的应是MQ前置机内网ip(11.*.*.8),目的转换为MQ前置机DMZ区ip,将规则改变后,通过arping测试恢复正常,故障消除。

故障原因探析

  由于外联防火墙的地址转换规则配置失误,造成防火墙代理了MQ服务器DMZ区真实IP(9.*.*.8),导致在DMZ区同网段服务器(以财政支付电子化ITFE为例进行说明)访问MQ的DMZ区真实IP时能分别收到来自防火墙(FW)和MQ服务器的不同arp应答报文,如图所示。

图片2.jpg
图 ARP访问请求示意图

  1.财政支付电子化(ITFE)发起arp请求,因为是二层网络环境,广播报文在同网段广播,此时FW和MQ都会收到来自同网段的arp请求报文。

  2.MQ收到是向自己的IP请求,于是以自己的MAC(00:50:56:9C:16:CA)进行回应;但同时FW也收到匹配地址转换规则9346的DNAT地址请求,于是FW也以自己转换的私有虚拟MAC(02:6A:3E:4B:00:03)进行了回应,造成ITFE短时间内先后收到分别来自FW和MQ对同一个arp请求,但却是不同MAC地址的回应。

  3.ITFE在刷新自己的arp表项时,可能出现以下两个操作。

  (1)只认最早收到的回应,但由于MQ和FW的回应报文到达ITFE的顺序是不确定的,就会导致arp表中9.*.*.8的IP对应的MAC有时是MQ的,有时是FW的,当出现这种情况时就造成了ITFE访问9.*.*.8时,对应MAC是MQ时,业务能通;对应MAC是FW时,业务不通(时断时续的故障现象)。

  (2)MQ和FW的arp应答报文到达的时间过于接近,导致ITFE的arp表项同时认可两个MAC,于是在发送数据包给9.*.*.8的时候同时采用广播方式分别向MQ和FW发送报文,这就是在MQ与ITFE之间挂了长ping后,业务为什么能不中断的原因。

(文章来源:金融电子化杂志)

扫码即可手机
阅读转发此文

本文评论

相关文章