买球平台





技术人生系列——追踪图数据库中“突然隐身”的通信连接

日期:2021-02-23

图数据库作为新兴的数据库技术热点,正在广泛的被各大银行客户采用。作为NoSQL数据库中最为突出的代表,图数据库对目前各种比较火热的精准营销业务场景、风控业务场景、客户图谱场景都能提供强大的底层支持。中亦大数据产品团队作为国内银行业接触图数据库较早的技术团队,为各大客户持续提供平台层面的技术支持能力。

 

最近,我们在客户现场的图数据库生产集群中遇到了一个罕见的通讯故障:数据库的导入组件和内部组件的通信通道会不定时丢失,且再也无法建立。经过现场反复协调排查和远程持续分析排查,并联合了中亦工程师和美国原厂的核心技术力量,终于分析出引发故障的系统原因并最终排除了故障,整个过程历经不少波折,真相大白水落石出时,大家都恍然大悟,原来是这样简单的原因——虽然答案和解决方案很简单,但是在分析过程中,由于大数据复杂的技术架构,需要抽丝剥茧,逐个分析可能因素,所以相对于最终的结果,这样的分析过程更值得记录,借本期技术人生系列文章,分享给大家。

 

 

 

一、故障描述

 

TG图数据库集群状态gadmin status均为正常工作状态,m1、m2、m3节点间连接状态均为正常,且TG所使用端口无被占用情况。在跑生产批量日更脚本中加载数据部分时,发现加载任务有一定几率卡住在读取文件步骤,且卡住后未产生报错日志和加载任务日志。经TG的Abort命令打断当前加载任务后重新运行多次该加载任务,故障依旧;gadmin start命令重启集群后,可成功运行该加载任务;重启后仍有一定几率重新发生此故障。

 

简单来说,在无人干预的情况下,原来正常的数据导入进程会hang死。重启后正常一段时间后,又会继续hang死,且图数据库层面通讯的两端组件都没有收到报错。

 

图片

 

通过上图,我们可以了解到,TigerGraph图数据库导入的基本原理:

 

1、每个节点admin组件会有一个线程定时轮询集群中每个节点的8500端口,尝试建立TCP连接。

 

2、当某个节点,如m1节点开启导入任务时,会开启restpp-loader进程,监听本地的8500端口,这时自然会和admin的线程建立连接。

 

3、通过建立好的tcp连接进行数据通信,由本地的restpp-loader读取文件,数据转换,传送至admin和其他组件,从而进行下游的导入任务。

 

 

二、排查过程

 

1.初步排查定位原因

我们首先针对TigerGraph版本,License,Schema脚本和loading脚本、数据源格式及生产机器内存硬盘资源进行了一一检查,均无发现异常。基本可以确定原有的流程是没有逻辑上的问题。

 

紧接着,我们对图数据库产品底层组件一一进行了故障排查。首先是对TigerGraph的Kafka、Nginx、GPE、GSE、GSQL、ZooKeeper、DICT、TS3、Restpp等组件的检查,经检查发现产品各组件均正常运行,日志文件均无报错情况。

 

经采用小批量数据进行测试并进行后台日志监控,我们发现一个特殊的现象:集群主节点m1不能接收到加载任务,而m2、m3可以接收到,那是否可以说明这其实是一个节点通讯的问题?但是我们紧接着分别对m1、m2、m3进行多次的测试,故障依然存在。这说明不光是 m1 主节点无法和其他节点通信,其他节点之间也会不定时无法建立连接。随着对数据流的逐个环节的分析,发现是RESTPP_LOADER所在的节点无法接收到本节点所发的请求,如下图所示,我们初步定位到了故障点:restpp-loader 尝试去与8500端口建立连接的线程出现了异常。

图片

 

 

2.尝试排除环境中其他软件的干扰

 

首先我们可以判断TigerGraph本身是没有问题的,因为在研发环境一直都是正常运行的。那么就需要判断是生产环境中安装的其他软件对TigerGraph造成了干扰,还是linux系统环境的不同导致了故障的发生。

 

遂在生产环境装有conductor、ctm等软件的其他节点,以及未安装上述软件但系统环境大致相同的两个节点,分别成功安装了TigerGraph单节点企业版。经测试,发现安装有conductor、ctm等软件的节点上的TigerGraph复现了生产环境三节点集群的数据加载故障,而未安装上述软件的节点可正常运行所有任务,无故障产生。经行内老师协调,临时关闭了生产节点的conductor和ctm服务,但故障依然存在,且故障依然为GSE与RESTPP组件通信受阻导致。

 

如下图显示,简单来说,在有其他软件的环境会出现故障,在“干净”的环境中正常运行,关掉其他软件依然有故障复现。那么真相直接指向唯一的一个方向:由于安装其他软件,修改了某项系统配置,引发了这个故障。

图片

 

3.设置监控脚本进行监控

 

问题分析到这里,我们再次回过头去分析哪些系统配置可能影响端口的情况。

 

首先是看系统资源限制,发现配置都比较正常:

图片

 

接下来分成两个方向进行排查:

 

◆ 通过gdb在产品层面打断点去分析

这个方向的考虑是希望在美国原厂的支持下,对TigerGraph图数据库进行调试,在导入组件内部通过打断点的方式,发现组件层面的报错。之前已经分析过了,在产品提供的通用日志中并没有提供报错信息,那么我们本质上是去提取debug级别的日志。

 

令我们困惑的一点是,在debug日志中只能看到某一次程序从线程池中取得线程,并去建立连接,并且建立了连接!但是这个连接从此就消失了,并且从系统的nestat无法找到?!这是让我们百思不得其解的一点。

 

程序认为连接已经建立,系统中却找不到建立的连接,那么这个连接去哪里了?

 

 

◆ 通过shell脚本在系统层去监控进程和网络情况

既然从产品层面无法获得更多信息,我们把思路转向系统层面,通过监控系统的进程情况和网络情况,来定位到故障发生的瞬间,到底发生了什么。

图片

图片

 

4.分析监控日志最终发现原因 

 

如果您能有耐心看到这里,想必也能或多或少体会到这个问题的诡异程度。已经可以确认就是端口之间通讯的问题,但是又找不到这个“隐身”的连接到底去哪了?

 

在系统运行一晚后,我们分析了监控日志,我们发现在某一个时刻连接自己8500端口的线程突然消失了。

图片

 

我突然联想到之前查到的一个资料:因为TigerGraph底层用了zmq进行通信,我在社区中看到一个人在2013年提交了一个issue,说他发现在大并发的情况下,他写的单机程序会时不时的hang住,建议zmq修复这个bug。他遇到的问题和我们很像,但是这个issue没有被fix,而是被关闭了,说明zmq的社区管理判断他提的并不是一个真实的bug。

图片

 

但是在他的描述中出现了self connection ,这个词就像一道闪电,照亮了整个黑暗。我再次联系美国开发,他也立马反应过来,去查看关键的系统配置项,果然真相大白,我们苦苦追寻的配置项就是下图中的:

正常的配置应该是如下:

图片

 

该配置项是linux为了区分服务端程序可用端口和客户端可用随机端口而设置的,就是为了防止端口冲突。在这个故障中,TigerGraph所在集群的默认系统配置中

/proc/sys/net/ipv4/ip_local_port_range

的32768  60999被修改为1025  65535。在这个配置修改后,客户端在申请随机端口连接服务端的时候,有一定概率申请到8500端口,从8500端口去与8500端口建立自连接,从而导致TigerGraph组件认为连接建立,而系统却认为服务未建立,进而导致整个导入功能的异常。而重启过后能正常一段时间的原因就是在图数据库进程关闭后,在8500端口隐身的线程连接也会被系统回收。

 

为了保险起见,根据这个原因,我们在多个安装且正常运行TigerGraph的环境中修改了系统配置,并都复现了生产环境的故障。

 

到此为止,我们完全确定了故障的发生原因。

 

 

三、故障修复方案制定与执行

1.修复方案

故障由/proc/sys/net/ipv4/ip_local_port_range的默认配置被修改导致,行内老师协调,将该设置还原系统默认设置,以解决TigerGraph加载故障。

具体步骤如下:

图片

 

2.修复故障

经由行内老师内部自检及评估后,暂未发现该系统设置被修改原因,遂将该设置修改回系统默认设置,TigerGraph再也没有出现该加载故障。

 

 

四、故障总结

1.控制变量快速定位故障根源

在本次故障排除的过程中,我们面对的是一个复杂的分布式系统环境,系统环境本身与其他环境不同,而且在这个环境中还有多个软件的潜在干扰。这个时候需要我们冷静的采用枚举法列出所有可能的故障原因,再通过控制变量法和排除法逐一去除干扰因素。排除一切不可能的因素后,剩下的肯定是正确的答案。

 

2.关键系统配置检查

在定位到系统级别的问题时,应该第一时间检查相关关键配置项。首先,我们需要定时监控维护这些配置项。在这次排除后,我们也无从得知到底是什么原因这个配置项被修改了。这警示我们可能在平时的工作需要关注这个方面。第二是需要了解这些系统参数的含义和配置方法,这就需要我们不断对自己的技术进行提高。

 

3.广泛积累夯实技术基础、深入钻研挖掘技术深度

这次排查问题,我们从图数据库产品本身技术架构,组件功能原理,到linux系统运行机制,考虑了很多技术问题和可能原因,这对我们提出了很大的挑战。所幸这次有美国原厂技术力量并肩作战,最终取得胜利,但是这次问题也鞭策我们平时需要广泛的去学习技术知识,并在自己的技术领域持续深耕,正所谓博观而约取,厚积而薄发。只有这样,在考验来临时,我们才能举重若轻的解决,为客户创造价值。

 

 


锻造凝炼IT服务 助推用户事业发展
地址:北京市西城区百万庄大街11号粮科大厦3层
电话:(010)58523737
传真:(010)58523739