由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命令