买球平台





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

日期:2021-02-23

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

 

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

 

 

 

一、故障描述

 

TG图(tu)数(shu)据库集(ji)群(qun)状(zhuang)态gadmin status均为(wei)正(zheng)常(chang)工(gong)作(zuo)状(zhuang)态,m1、m2、m3节点间连接状(zhuang)态均为(wei)正(zheng)常(chang),且(qie)TG所(suo)使(shi)用端口无被占用情况(kuang)。在跑(pao)生(sheng)产(chan)批量(liang)日(ri)更脚本中(zhong)加(jia)(jia)(jia)(jia)载(zai)(zai)数(shu)据部分(fen)时,发现(xian)加(jia)(jia)(jia)(jia)载(zai)(zai)任(ren)务(wu)(wu)有一(yi)定(ding)几(ji)率(lv)卡住(zhu)在读(du)取文件步(bu)骤,且(qie)卡住(zhu)后(hou)未产(chan)生(sheng)报(bao)错日(ri)志和加(jia)(jia)(jia)(jia)载(zai)(zai)任(ren)务(wu)(wu)日(ri)志。经TG的Abort命令(ling)打断当前加(jia)(jia)(jia)(jia)载(zai)(zai)任(ren)务(wu)(wu)后(hou)重新(xin)(xin)运行多(duo)次该加(jia)(jia)(jia)(jia)载(zai)(zai)任(ren)务(wu)(wu),故(gu)障(zhang)依旧;gadmin start命令(ling)重启(qi)(qi)集(ji)群(qun)后(hou),可成功运行该加(jia)(jia)(jia)(jia)载(zai)(zai)任(ren)务(wu)(wu);重启(qi)(qi)后(hou)仍有一(yi)定(ding)几(ji)率(lv)重新(xin)(xin)发生(sheng)此故(gu)障(zhang)。

 

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

 

图片

 

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

 

1、每个(ge)节点admin组件会(hui)有(you)一个(ge)线(xian)程(cheng)定(ding)时轮(lun)询集群中每个(ge)节点的(de)8500端口,尝(chang)试建立(li)TCP连接(jie)。

 

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

 

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

 

 

二、排查过程

 

1.初步排查定位原因

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

 

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

 

经采用(yong)小批量(liang)数据进行测试并进行后台日志监控,我(wo)们(men)发(fa)现(xian)一个特(te)殊的现(xian)象(xiang):集群(qun)主节(jie)(jie)(jie)点(dian)m1不能接(jie)(jie)(jie)收(shou)到(dao)(dao)加载(zai)任务,而m2、m3可(ke)以接(jie)(jie)(jie)收(shou)到(dao)(dao),那是(shi)否可(ke)以说明(ming)(ming)这(zhei)其实是(shi)一个节(jie)(jie)(jie)点(dian)通讯(xun)的问题?但是(shi)我(wo)们(men)紧接(jie)(jie)(jie)着(zhe)分别对m1、m2、m3进行多次的测试,故(gu)(gu)障依然存在。这(zhei)说明(ming)(ming)不光是(shi) m1 主节(jie)(jie)(jie)点(dian)无(wu)法和其他节(jie)(jie)(jie)点(dian)通信,其他节(jie)(jie)(jie)点(dian)之间也会不定(ding)时无(wu)法建立连接(jie)(jie)(jie)。随着(zhe)对数据流的逐个环节(jie)(jie)(jie)的分析,发(fa)现(xian)是(shi)RESTPP_LOADER所(suo)在的节(jie)(jie)(jie)点(dian)无(wu)法接(jie)(jie)(jie)收(shou)到(dao)(dao)本(ben)节(jie)(jie)(jie)点(dian)所(suo)发(fa)的请(qing)求,如(ru)下(xia)图所(suo)示(shi),我(wo)们(men)初步定(ding)位到(dao)(dao)了故(gu)(gu)障点(dian):restpp-loader 尝试去(qu)与8500端口(kou)建立连接(jie)(jie)(jie)的线程出现(xian)了异(yi)常。

图片

 

 

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

 

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

 

遂在(zai)生(sheng)产环境装有conductor、ctm等软(ruan)(ruan)件(jian)的其他(ta)节点(dian)(dian)(dian)(dian),以及未安装上述软(ruan)(ruan)件(jian)但(dan)系统(tong)环境大致相(xiang)同的两个节点(dian)(dian)(dian)(dian),分(fen)别成(cheng)功安装了TigerGraph单节点(dian)(dian)(dian)(dian)企业(ye)版(ban)。经(jing)测试,发现(xian)安装有conductor、ctm等软(ruan)(ruan)件(jian)的节点(dian)(dian)(dian)(dian)上的TigerGraph复现(xian)了生(sheng)产环境三(san)节点(dian)(dian)(dian)(dian)集群的数(shu)据(ju)加(jia)载故(gu)障(zhang),而未安装上述软(ruan)(ruan)件(jian)的节点(dian)(dian)(dian)(dian)可正常运行(xing)所(suo)有任务,无故(gu)障(zhang)产生(sheng)。经(jing)行(xing)内老师协调,临时(shi)关闭了生(sheng)产节点(dian)(dian)(dian)(dian)的conductor和(he)ctm服务,但(dan)故(gu)障(zhang)依然存在(zai),且故(gu)障(zhang)依然为GSE与RESTPP组件(jian)通信受阻导(dao)致。

 

如下图显示,简(jian)单来说(shuo),在有其(qi)他(ta)软(ruan)件(jian)(jian)的环境(jing)会出现故障,在“干(gan)净”的环境(jing)中正常运行,关掉其(qi)他(ta)软(ruan)件(jian)(jian)依然有故障复(fu)现。那(nei)么真相(xiang)直(zhi)接指向唯(wei)一的一个(ge)方(fang)向:由于(yu)安(an)装其(qi)他(ta)软(ruan)件(jian)(jian),修改了某项系统配置,引(yin)发了这个(ge)故障。

图片

 

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

 

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

 

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

图片

 

接下来分成两个(ge)方(fang)向进行排查:

 

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

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

 

令我们(men)(men)困惑的一(yi)(yi)点(dian)是(shi)(shi),在debug日(ri)志中只能看到某一(yi)(yi)次程(cheng)序从(cong)线程(cheng)池中取得(de)线程(cheng),并去建(jian)立连接(jie),并且建(jian)立了(le)连接(jie)!但是(shi)(shi)这个连接(jie)从(cong)此就消(xiao)失了(le),并且从(cong)系(xi)统(tong)的nestat无(wu)法找到?!这是(shi)(shi)让我们(men)(men)百思(si)不得(de)其(qi)解的一(yi)(yi)点(dian)。

 

程(cheng)序认(ren)为(wei)连接(jie)已经(jing)建立,系统中(zhong)却找不到建立的连接(jie),那么这个连接(jie)去(qu)哪里了?

 

 

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

既然从(cong)产品(pin)层(ceng)面无法(fa)获(huo)得更多信息,我们把思(si)路(lu)转(zhuan)向系(xi)统层(ceng)面,通过(guo)监控(kong)系(xi)统的(de)进程情况和(he)网络情况,来定位(wei)到(dao)故障(zhang)发(fa)生(sheng)的(de)瞬间(jian),到(dao)底发(fa)生(sheng)了什么。

图片

图片

 

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

 

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

 

在(zai)系(xi)统运行一晚后,我(wo)们(men)分析(xi)了(le)监(jian)控(kong)日志,我(wo)们(men)发(fa)现在(zai)某(mou)一个时(shi)刻连(lian)接自(zi)己8500端(duan)口的线程突然消失了(le)。

图片

 

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

图片

 

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

正常的配(pei)置应该是如下:

图片

 

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

/proc/sys/net/ipv4/ip_local_port_range

的(de)32768  60999被(bei)修(xiu)改为(wei)1025  65535。在(zai)这(zhei)个配置修(xiu)改后,客(ke)户端在(zai)申请随(sui)机端口(kou)(kou)连(lian)接服务端的(de)时候,有(you)一(yi)定概率申请到8500端口(kou)(kou),从(cong)8500端口(kou)(kou)去与8500端口(kou)(kou)建(jian)立自连(lian)接,从(cong)而(er)导(dao)致(zhi)TigerGraph组件认为(wei)连(lian)接建(jian)立,而(er)系(xi)统(tong)却(que)认为(wei)服务未(wei)建(jian)立,进而(er)导(dao)致(zhi)整(zheng)个导(dao)入(ru)功(gong)能(neng)的(de)异常。而(er)重启(qi)过后能(neng)正常一(yi)段时间的(de)原因就(jiu)是在(zai)图(tu)数据库进程关闭后,在(zai)8500端口(kou)(kou)隐身的(de)线程连(lian)接也(ye)会被(bei)系(xi)统(tong)回(hui)收。

 

为了保险起见(jian),根据这个原因,我(wo)们在(zai)多个安装(zhuang)且正常运行TigerGraph的(de)环境中修改(gai)了系统配(pei)置(zhi),并(bing)都(dou)复现了生产(chan)环境的(de)故障。

 

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

 

 

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

1.修复方案

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

具体步(bu)骤如(ru)下:

图片

 

2.修复故障

经由(you)行内(nei)老师(shi)内(nei)部自(zi)检及评估后,暂未发现该(gai)(gai)系(xi)统(tong)设置被修(xiu)改原因,遂将该(gai)(gai)设置修(xiu)改回系(xi)统(tong)默认设置,TigerGraph再也没(mei)有(you)出现该(gai)(gai)加(jia)载(zai)故障。

 

 

四、故障总结

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

在本(ben)次(ci)故障排除(chu)的(de)过程中,我们面对的(de)是(shi)一(yi)个复杂的(de)分(fen)布式系统环(huan)境(jing),系统环(huan)境(jing)本(ben)身与(yu)其他环(huan)境(jing)不(bu)同,而且在这个环(huan)境(jing)中还有多个软件(jian)的(de)潜在干(gan)扰(rao)。这个时候需要我们冷静的(de)采(cai)用枚举法列(lie)出所有可(ke)能的(de)故障原因,再通过控制变量法和排除(chu)法逐一(yi)去除(chu)干(gan)扰(rao)因素(su)。排除(chu)一(yi)切不(bu)可(ke)能的(de)因素(su)后,剩(sheng)下的(de)肯(ken)定(ding)是(shi)正确的(de)答案。

 

2.关键系统配置检查

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

 

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

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

 

 


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