Domino 集群跨数据中心互访故障

2019-11-26北京蓝鹏

网络安全和信息化 2019年10期

关键词：数据包端口防火墙

北京蓝鹏

月初OA 系统运维人员接到大量故障问题申报单，内容主要集中在部分兼职领导和大批整合子、分公司用户在使用系统审批公文时，响应速度缓慢甚至长时间无响应。

该问题不仅影响了领导的日常公文审批，还阻碍了系统在集团内部推广的速度和质量。OA 系统运维部门一直在平台和应用层面分析问题，但始终未果，遂求助网络运维团队，希望在网络和基础设施层面协助排查。

平台架构及业务逻辑说明

该OA 系统部署在Domino 集群平台上，通过与4A、Portal 系统的集成，实现了SSO（单点登录），其部署架构如图1 所示。

用户接入及访问流程如下：

（1）用户打开企业门户点击登录按钮。

（2）门户判断用户未登录，将用户重定向至4A 系统进行身份验证。

（3）用户输入用户名、密码通过身份验证并获取Token。

（4）用户携带Token 访问门户应用中心，点击OA 图标进行连接。

（5）OA 连接为Web 反向代理（缓存）服务器；其会将用户请求的URL 代理转发到OA 平台入口服务器前端的LB 虚拟IP。

图1 OA 系统部署架构图

（6）LB 根据会话保持、负载均衡算法，将请求分发到3 台入口服务器之一。

（7）入口服务器验证用户Token 有效性并根据从MDM 同步的组织机构信息，将用户重定向到为该用户所分配的固定后端服务器。同时，还会生成平台内部的用户标识符，供后续使用，后续用户对系统的访问均会携带该内部标识符。

根据背景所述，兼职领导及整合公司用户完成登录后会被分配到图1 下方的app21-36 的服务器之一。用户需要提交审批流程时会通过平台内部总线调用图1 上方的Common Workflow Server获取通用工作流信息。

而这2 组服务器分别部署在生产中心及灾备中心，其部署架构及数据包转发路径如图2 所示。

图2 部署架构及数据包转发路径

图3 数据采集点位置

故障分析流程

在与OA 系统运维同事交流后，得知图1 右上角所示的APP01-20 与Common Workflow Server 均部署在生产中心，未发生过类似的故障。遂将故障原因聚焦于APP21-36 服务器跨数据中心访问Common Server 上。

1.初步分析

通过网管软件查看月内数据中心间互访流量统计，峰值仅有500-600Mbps，远小于数据中心间互联的4*10 Gbps 链路的承载能力。

另外，使用灾备中心的服务器ping 生产中心服务器时延很小也没有丢包（包括故障发生时）。

2.数据采集

（1）应用基础信息收集

根据初步分析结果可判定链路质量、互联带宽无问题。后续将使用模拟访问，结合业务路径关键节点抓包方式进一步分析。在抓取数据前对Domino 集群的内部通信机制做了简单了解,Domino 应用程序及数据库均是以*.NSF( Notes Storage Format)格式存在的，集群成员之间通过基于TCP 协议端口号为1352 的Lotus Domino RPC进行通信。

当用户访问“/indishare/office.nsf/(frame)/normal?open&app=”URL 时，实际上就是访问domino 平台中分配给该用户服务器的某个应用程序或数据库，当访问的nsf 文件存放在集群中的其他服务器上，该服务器需要通过TCP 1352 端口对后端服务器进行访问。

（2）数据采集点选择

基于基础信息收集结果，选择数据源、宿服务器，灾备中心（生产中心）防火墙进出端口，数据中心间互联链路端口作为数据采集点。数据采集点如图3 箭头指示位置。由于访问路径上除三层交换设备外，灾备中心出口及生产中心服务器前端均部署了防火墙，从数据转发逻辑角度出发，穿越防火墙的TCP 1352 端口流量应是重点关注对象。

图4 查看灾备中心防火墙，存在的相应会话表项

（3）数据采集方法

在源（Linux）、宿（Windows）服务器上通过自带的TCPdump 及安装的Wireshark 工具抓取流量，其他采集点采用交换机端口镜像方式将采集点端口流量镜像到抓包端口。

为缩小数据抓取范围、减小镜像流量对抓包主机（图3中的设备镜像抓包点都是核心节点间互联的万兆或万兆聚合端口，而连接抓包主机的端口为千兆端口）冲击，在抓取数据时应配合正则表达式仅抓取源、宿主机TCP 1352 端口的通信流量。

例如，Linux 主机上的TCPdump 配置“tcpdump-i ens34 host x.x.184.128 and x.x.146.152 and tcp dst port 1352-vv-w./test.cap”，该过滤规则将相应原始数据包保存到test.cap 文件中；Wireshark 的抓包设置中也做类似过滤规则设置。

（4）数据抓取过程

在源主机184.128 利用测试页面获取常用审批语信息，该过程就是通过与公共流程服务器146.152 在TCP 1352 端口上建立的连接，访问cyspy.nsf 数据库（文件），模拟OA 平台跨数据中心访问。

点击测试连接按钮后，在各采集点同步抓取数据，待故障复现时停止点击与数据抓取。故障发生时，OA 平台日志显示数据库打开超时错误。

查看源主机184.128 上抓取的同目的主机146.152 TCP 1352 端口通信且TCP 载荷中包含cyspy.nsf 关键字的原始数据包。

打开在采集点2、3 抓取的相应数据包，通过seq=2227669018（已在wireshark 中关闭了相对序列号选项）过滤出与源端一致的数据。

同时，查看灾备中心防火墙，存在如图4 所示的相应会话表项。

结合抓包结果及防火墙表项，可判断发生数据库打开错误时，184.128 访问146.152 的cyspy.nsf 文请求未得到响应，主机TCP 协议栈按照指数退避算法进行了重传，当到达最大重传次数后切断了TCP 连接。核心交换机、防火墙均正常转发了原始及后续重传数据。

另外，从数据样本的特点看，交互的TCP 流量PUSH 位均置位，数据往返时延很小。说明目的系统的响应速度很快，基本排除了由于大量PUSH 置位的数据需要快速从TCP 接收缓冲区提交至应用层处理，造成系统繁忙无法处理的情况。目的主机保存的原始抓包数据没有发现故障时的相应原始、重传数据包，生产中心防火墙上也没有相应的会话表项。

初步判断可能是生产中心防火墙将流量异常丢弃，导致了数据丢失，给用户造成了查询长时间无响应的感觉。后续又抓取了多个数据样本，在某次故障发生时4号采集点采集的数据，如图5所示。

图5 在4 号采集点采集的数据

图6 抓包结果

从图中的重传数据的源、目MAC 地址判断，交换机将源端184.28 的重传包发给了防火墙，源MAC 为交换机接口(04:00)，目的MAC 为防火墙VRRP 虚地址(01：f7)，数据走向与交换机的路由表一至。说明在故障发生时原始数据及重传数据交换机均交付给了防火墙。

另一次故障发生时在5 号抓包点抓取的数据，与源主机抓取数据比对，自开始测试至故障发生时，交换机侧仅有2 条TCP 流，分别为28:40700 →152:1352 与 28:58007 →152:1352。

而源主机抓取到的数据除了上面2 条流以外，还有2条引发故障的数据流，

由于5 号抓包点抓取的数据为交换机发给防火墙untrust 接口的流量，及从trust 接口接收到的流量，正常情况应该是一致的。

但从如图6 所示的抓包结果看交换机发送给防火墙的seq=245273368 的TCP数据包后续未抓取到，且从该包的payload 看刚好是“cyspy.csf”，说明防火墙丢弃了数据，并没有交付给目的主机。

综合上述抓包结果，引发故障的TCP 连接应为点击测试前，平台就已经建立且没有释放的历史连接。后续抓取的TCP keepalive 消息也证明了该点，客户端与服务器建立TCP 连接后，由于客户端长时间（操作系统相关，通常默认为2-3 个小时）空闲，服务端会启动keepalive探测机制，在客户端无响应后，切断了连接。

3.问题分析定位

根据上述的多次抓包结果可知，Domino 集群中前端服务器与公共流程服务器通过TCP 1352 端口建立连接后，将依据资源池调度算法，将对后端公共服务器数据库的访问，分配到不同公共服务器或不同的TCP 连接上。

这就意味着开始建立的端到端TCP 连接可能会长期处于空闲状态，并在后续的资源调度中复用。由于平台本身并没有保活机制，端到端的连接保活完全交给了TCP 协议层，该时间较长，超过了防火墙会话表超时时间（本例中防火墙预定义的TCP 协议会话表项超时时间为tcp protocol timeout:600(s)）。防火墙依据会话表项做转发决策，对于长时间没有流量转发，表项计时器得不到刷新，超时后将被被清除，后续接收的流量需重新建立会话表项。

但对状态检测防火墙而言，只有收到syn flag 置位的TCP 数据包才会依据安全策略放行、并创建相应会话表项，正常转发数据。就本例而言引发故障的TCP 数据段和重传数据段都仅包含ack flag，当防火墙收到该数据包时，因不存在相应会话表项，根据状态检测机制即使安全策略允许放行流量，防火墙也不会创建会话表项、转发数据包，而是按照丢弃处理。

最终，目的端收不到原始数据及重传数据，无法将数据交付给源端。对应用层而言，由于长时间无法从数据库中获取数据，就会出现无响应或卡死的现象。