linux配置vip自动漂移,由VIP漂移引发的算法异常问题调查和解决

最近工作中的一个问题，耗时一个月之久终于调查完毕且顺利解决，顿时感慨万千。耗时之久和预期解决时间和环境搭建以及日志不合理等等有关，当然这个并非此文的重点。

之所以在很久以后的今天又开始写文，主要是这个问题调查的过程值得铭记。具体情况如下文述。

一、问题发现过程

数据告警服务提示相关分析结果缺失，经初步调查，发现分析服务在调用对应的NLP算法服务时出现大量Failed，遂查看算法日志，确实存在错误信息。

二、问题调查和解决

1.定位问题

1) 反馈给算法相关开发同学：他们认为可能是该算法遇到了长文本数据(超过3000字)，由于分析时间超长，导致后续算法请求时出现阻塞而导致failed。

2) 根据开发的反馈，开始定位是否存在这样的长文本数据：通过分析日志和数据库查询确认后，并没有分析长文本数据，且出现异常时的文本数据均为短文本(小于200)。

3) 深入调查：该算法部署了多个节点，出现异常时，多个节点均出现了异常，因此可能是算法本身遇到了某个瓶颈问题。经确认，该算法使用了同一台GPU服务器上的tf-serveing服务。

4) 确认GPU服务器是否发生了异常情况：经确认，该服务器进行过VIP漂移操作。

5) 问题是否可以复现：测试环境中，对GPU服务器进行vip漂移操作，发现错误现象出现，问题可复现。

因此，问题的起因是GPU服务器进行了VIP漂移操作，导致算法出现异常。

2.调查问题

1) 了解vip原理，初步了解后，觉得可能是我们的算法缺少超时设置，因此算法中新增超时设置后，再次进行测试

备注：keepalived可以将多个无状态的单点通过虚拟IP(以下称为VIP)漂移的方式搭建成一个高可用服务，常用组合比如 keepalived+nginx，lvs，haproxy和memcached等。

它的实现基础是VRRP协议，包括核心的MASTER竞选机制都是在VRRP协议所约定的。

2)一轮测试发现：问题仍然存在，修复失败，且无新增日志。于是，我们要求增加日志信息，并以Debug方式启动算法，进行二轮测试。

3)二轮测试发现：问题仍然存在，出现新的错误日志，错误信息为：Connect error: No route to host(errno:113)。

百度一番，都说是server端的防火墙设置了过滤规则；但是，Server端并没有，怎么办？

Server端抓包：

经抓包发现，GPU服务器完成vip漂移需要耗时4s左右，然而，算法在漂移开始的2s内发送了近20次请求之后无请求。

问题的根源(可能)：Server端vip漂移未完成时，算法却发送了大量请求导致Server端的tcp连接池满，后续server端不再为其他请求分配资源。

3.解决问题

1)根据调查的原因，修复方法是：sever端在进行vip漂移完成前，尽量减少算法的请求次数，因此我们对该算法进行了超时重试次数的设置和请求间隔的设置(可配置)。

2)算法修复后经测试，问题解决。

三、总结

1)合理且重要的日志输出对于问题的定位和调查非常重要

2)涉及HTTP请求的问题调查时，服务端抓包有必要

3)Linux 的errno113问题并不一定是设置了防火墙导致的

备注：

(一)vip环境：用来给K8s做三节点高可用，被K8s的kubeproxy的ipvs方式转发到具体pod，四层转发，tcp协议(NAT模式)

(二)Linux errono命令