由VIP漂移引起的算法异常问题调查和解决

最近工做中的一个问题，耗时一个月之久终于调查完毕且顺利解决，顿时感慨万千。耗时之久和预期解决时间和环境搭建以及日志不合理等等有关，固然这个并不是此文的重点。
之因此在好久之后的今天又开始写文，主要是这个问题调查的过程值得铭记。具体状况以下文述。

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

2、问题调查和解决
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）算法修复后经测试，问题解决。

3、总结
1）合理且重要的日志输出对于问题的定位和调查很是重要
2）涉及HTTP请求的问题调查时，服务端抓包有必要
3）Linux 的errno113问题并不必定是设置了防火墙致使的

备注：
（一）vip环境：用来给K8s作三节点高可用，被K8s的kubeproxy的ipvs方式转发到具体pod，四层转发，tcp协议（NAT模式）
（二）Linux errono命令