阿里雲MySQL及Redis靈異斷連現象:安全組靜默丟包解決方法

資料和雲發表於2019-02-26

導讀:雲端計算時代的服務端網路環境越來越複雜。不但要考慮實際的物理網路,也要考慮到SDN/安全等技術的影響。理論上說,網路對應用開發無感知,然而有時候也並非如此。本文作者記錄了一種阿里雲上Redis/MySQL的靈異現象,並且記錄了問題原因,給出瞭解決方案。

引子:Redis client library 連線 Redis server 超時

差不多一兩年前,在阿里雲上遇到一個奇怪的 Redis 連線問題,每隔十來分鐘,服務裡的 Redis client 庫就報告連線 Redis server 超時,當時花了很大功夫,發現是阿里雲會斷開長時間閒置的 TCP 連線,不給兩頭髮 FIN or RST 包,而當時我們的 Redis server 沒有開啟 tcp_keepalive 選項,於是 Redis server 側那個連線還存在於 Linux conntrack table 裡,而 Redis client 側由於連線池重用連線進行 get、set 發現連線壞掉就關閉了,所以 client 側的對應 local port 回收了,當接下來 Redis 重用這個 local port 向 Redis server 發起連線時,由於 Redis server 側的 conntrack table 裡 <client_ip, client_port, redis-server, 6379> 四元組對應狀態是 ESTABLISHED,所以自然客戶端發來的 TCP SYN packet 被丟棄,Redis client 看到的現象就是連線超時。


解決這個問題很簡單,開啟 Redis server 的 tcp_keepalive 選項就行。 然而當時沒想到,這個問題深層次的原因影響很重大,後果很嚴重!

孽債:"SELECT 1" 觸發的 jdbc4.CommunicationsException

最近生產環境的 Java 服務幾乎每分鐘都報告類似下面這種錯誤:

阿里雲MySQL及Redis靈異斷連現象:安全組靜默丟包解決方法


由於有之前調查 Redis 連線被阿里雲異常中斷的先例,所以懷疑是類似問題,花了大量時間比對客戶端和服務端的 conntrack table,然而並沒有引子中描述的問題,然後又去比對多個 MySQL 伺服器的 sysctl 設定,研究 iptables TRACE,研究 tcpdump 抓到的報文,試驗 tw_reuse, tw_recyle 等引數,調整 Aliyun 負載均衡器後面掛載的 MySQL 伺服器個數,都沒效果, 反而意外發現一個**新問題**,在用如下命令不經過阿里雲 SLB 直接連線資料庫時,有的資料庫可以在 600s 時返回,有的則客戶端一直掛著,半個多小時了都退不出來,按 ctrl-c 中斷都不行。

阿里雲MySQL及Redis靈異斷連現象:安全組靜默丟包解決方法

當時檢查了一個正常的資料庫和一個不正常的資料庫,發現兩者的 wait_timeout 和 interactive_timeout 都是 600s,思索良苦,沒明白怎麼回事,然後偶然發現另外一個資料庫的 wait_timeout=60s,卻一下子明白了原始的 "select 1" 問題怎麼回事。

我們的服務使用了 Hikari JDBC 連線池[1],它的 idleTimeout 預設是 600s, maxLifetime 預設是 1800s,前者表示 idle JDBC connection 數量超過 minimumIdle 數目並且閒置時間超過 idleTimeout 則關閉此 idle connection,後者表示連線池裡的 connection 其生存時間不能超過 maxLifetime,到點了會被關掉。

在發現 "select 1" 問題後,我們以為是這倆引數比資料庫的 wait_timeout=600s 大的緣故,所以把這兩個引數縮小了,idleTimeout=570s, maxLifetime=585s,並且設定了 minimumIdle=5。但這兩個時間設定依然大於其中一個資料庫失誤設定的 wait_timeout=60s,所以閒置連線在 60s 後被 MySQL server 主動關閉,而 JDBC 並沒有什麼事件觸發回撥機制去關閉 JDBC connection,時間上也不夠 Hikari 觸發 idleTimeout 和 maxLifetime 清理邏輯,所以 Hikari 拿著這個“已經關閉”的連線,發了 "select 1" SQL 給伺服器檢查連線有效性,於是觸發了上面的異常。

解決辦法很簡單,把那個錯誤配置的資料庫裡 wait_timeout 從 60s 修正成 600s 就行了。 下面繼續講述 "SELECT sleep(1000)" 會掛住退不出來的問題。

緣起:阿里雲安全組與 TCP KeepAlive

最近看了一點佛教常識,對”諸法由因緣而起“的緣起論很是感慨,在調查 "SELECT sleep(1000)" 問題中,真實感受到了“由因緣而起” 的意思 

首先解釋下,為什麼有的資料庫伺服器對 "SELECT sleep(1000)" 可以返回,有的卻掛著退不出來。 其實 wait_timeout 和 interactive_timeout 兩個引數只對 “閒置” 的資料庫連線,也即沒有 SQL 正在執行的連線生效,對於 "SELECT sleep(1000)",這是有一個正在執行的 SQL,其最大執行時間受 MySQL Server 的 max_execution_time 限制,這個引數在我司一般設定為 600s,這就是 “正常的資料庫" 在 600s 時 "SELECT sleep(1000)" 中斷執行而退出了。

但不走運的是(可以說又是個失誤配置 ),我們有的資料庫 max_execution_time 是 6000s,所以 "SELECT sleep(1000)" 在 MySQL server 服務端會在 1000s 時正常執行結束——但問題是,通過二分查詢以及 tcpdump、iptables TRACE,發現阿里雲會”靜默“丟棄 >=910s idle TCP connection,不給客戶端、服務端傳送 FIN or RST 以強行斷掉連線,於是 MySQL server 在 1000s 結束時發給客戶端的 ACK+PSH TCP packet 到達不了客戶端,然後再過 wait_timeout=600s,MySQL server 就斷開了這個閒置連線——可憐的是,mysql client 這個命令列程式還一無所知,它很執著的等待 MySQL server 返回,Linux 核心的 conntrack table 顯示這個連線一直是 ESTABLISHED,哪怕 MySQL server 端已經關閉對應的連線了,只是這個關閉動作的 FIN TCP packet 到不了客戶端!

下面是 iptables TRACE 日誌對這個問題的實錘證明。

mysql 命令列所在機器的 iptables TRACE 日誌表明,mysql client 在 23:58:25 連線上了 mysql server,開始執行 SELECT sleep(1000),然後一直收不到伺服器訊息,最後在 00:41:20 的時候我手動 kill 了 mysql 客戶端命令列程式,mysql 客戶端給 mysql server 發 FIN 包但收不到響應(此時 mysql server 端早關閉連線了)。

阿里雲MySQL及Redis靈異斷連現象:安全組靜默丟包解決方法

阿里雲MySQL及Redis靈異斷連現象:安全組靜默丟包解決方法

MySQL server 在 00:15:05 時執行 SELECT sleep(1000) 結束,給 mysql 客戶端回送結果,但 mysql 客戶端無響應(被阿里雲丟包了,mysql 客戶端壓根收不到),在 00:25:05 時,由於 wait_timeout=600s,所以 MySQL server 給 mysql 客戶端發 FIN 包以斷開連線,自然,mysql 客戶端收不到,所以也沒有回應,結局是 MySQL server 一側的 Linux 核心反正自行關閉 TCP 連線了,mysql client 一側的 Linux 核心還在傻乎乎的在 conntrack table 維持著 ESTABLISHED 狀態的 TCP 連線,mysql client 命令列還在傻乎乎的 recv() 等著服務端返回或者關閉連結。

阿里雲MySQL及Redis靈異斷連現象:安全組靜默丟包解決方法

Ok,現在知道是阿里雲對 >= 910s 沒有發生 TCP packet 傳輸的虛擬機器之間直連閒置 TCP 連線會“靜默”丟包,那麼是任意虛擬機器之間嗎?是任意埠嗎?要求伺服器掛到負載均衡器後面嗎?要求對應埠的併發連線到一定數目嗎?

在阿里雲提交工單詢問後,沒得到什麼有價值資訊,在經過艱苦卓絕的試驗後——每一次試驗要等近二十分鐘啊——終於功夫不負有心人,我發現一個穩定復現問題的規律了:

  1. 兩臺虛擬機器分別處於不同安全組,沒有共同安全組;

  2. 服務端的安全組開放埠 P 允許客戶端的安全組連線,客戶端不開放埠給服務端(按照一般有狀態防火牆的配置規則,都是隻開服務端埠,不用開客戶端埠);

  3. 客戶端和服務端連線上後,閒置 >= 910s,不傳輸任何資料,也不傳輸有 keep alive 用途的 ack 包;

  4. 然後服務端在此長連線上發給客戶端的 TCP 包會在網路上丟棄,到不了客戶端;

  5. 但如果客戶端此時給服務端發點資料,那麼會重新“啟用”這條長連結,但此時還是單工狀態,客戶端能給服務端發包,服務端的包還到不了客戶端(大概是在服務端 OS 核心裡重試中);

  6. 啟用後,服務端再給客戶端發資料時,之前傳送不出去的資料(如果還在核心裡的 TCP/IP 協議棧重試中),加上新發的資料,會一起到達客戶端,此後這條長連線進入正常的雙工工作狀態;

下圖是用 nc 試驗的結果。

阿里雲MySQL及Redis靈異斷連現象:安全組靜默丟包解決方法


阿里雲MySQL及Redis靈異斷連現象:安全組靜默丟包解決方法

在跟網友討論後,認識到這應該是阿里雲安全組基於“集中式防火牆”實現導致的,因為集中式防火牆處於網路中心樞紐,它要應付海量連線,因此其記憶體裡的 conntrack table 需要比較短的 idle timeout(目前是 910s),以把長時間沒活躍的 conntrack record 清理掉節約記憶體,所以上面問題的根源就清晰了:

  1. client 連線 server,安全組(其實是防火牆)發現規則允許,於是加入一個記錄到 conntrack table;

  2. client 和 server 到了 910s 還沒資料往來,所以安全組把 conntrack 裡那條記錄去掉了;

  3. server 在 910s 之後給 client 發資料,資料包到了安全組那裡,它一看 conntrack table 裡沒記錄,而 client 側安全組又不允許這個埠的包通過,所以丟包了,於是 server -> client 不通;

  4. client 在同一個長連線上給 server 發點資料,安全組一看規則允許,於是加入 conntrack table 裡;

  5. server 重試的資料包,或者新資料包,通過安全組時,由於已經有 conntrack record 了,所以放行,於是能到達客戶端了。

原因知道了,怎麼繞過這個問題呢?阿里雲給了我兩個無法接受的 workaround:

  1. 把 server、client 放進同一個安全組;

  2. 修改 client 所在安全組,開放所有埠給 server 所在安全組;

再琢磨下,通過 netstat -o 發現我們的 Java 服務使用的 Jedis 庫和 mysql JDBC 庫都對 socket 檔案控制程式碼開啟了 SO_KEEPALIVE 選項[2]:

阿里雲MySQL及Redis靈異斷連現象:安全組靜默丟包解決方法

而 MySQL server 也對其開啟的 socket 檔案控制程式碼開啟了 SO_KEEPALIVE 選項,所以我只用修改下服務端和客戶端至少其中一側的對應 sysctl 選項即可,下面是我司服務端的預設配置,表示 TCP 連線閒置 1800s 後,每隔 30s 給對方發一個 ACK 包,最多發 3 次,如果在此期間對方回覆了,則計時器重置,再等 1800s 閒置條件,如果發了 3 次後對方沒反應,那麼會給對端發 RST 包同時關閉本地的 socket 檔案控制程式碼,也即關閉這條長連線。

阿里雲MySQL及Redis靈異斷連現象:安全組靜默丟包解決方法

由於阿里雲跨安全組的 910s idle timeout 限制,所以需要把 net.ipv4.tcp_keepalive_time 設定成小於 910s,比如 300s。

預設的 tcp_keepalive_time 特別大,這也解釋了為什麼當初 Redis client 設定了 SO_KEEPALIVE 選項後還是被阿里雲靜默斷開。

如果某些網路庫封裝之後沒有提供 setsockopt() 呼叫的機會,那麼需要用 LD_PRELOAD 之類的黑科技強行設定了,只有開啟了 socket 檔案控制程式碼的 SO_KEEPALIVE 選項,上面三個 sysctl 才對這個 socket 檔案控制程式碼生效,當然,程式碼裡可以用 setsockopt() 函式進一步設定 keep_alive_intvl 和 keepalive_probes,不用 Linux 核心的全域性預設設定。

最後,除了 Java 家對 SO_KEEPALIVE 處理的很好,利用 netstat -o 檢查得知,對門的 NodeJS 家,其著名 Redis client library 開了 SO_KEEPALIVE 但其著名 mysql client library 並沒有開,而 Golang 家則嚴謹多了,兩個庫都開了 SO_KEEPALIVE。 為什麼引子裡說這個問題很嚴重呢?因為但凡服務端處理的慢點,比如 OLAP 場景,不經過阿里雲 SLB 直連服務端在 910s 之內沒返回資料的話,就有可能沒機會返回資料給客戶端了啊,這個問題查死人有沒有! 你可能問我為啥不通過阿里雲 SLB 中轉,SLB 不會靜默丟包啊——但它的 idle timeout 上限是 900s 啊!!!

頭圖 Photo credit: “No Bugs” Hare

文中連結:

[1] https://github.com/brettwooldridge/HikariCP

[2] http://www.tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html

轉載自:高可用架構

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31556440/viewspace-2637027/,如需轉載,請註明出處,否則將追究法律責任。

相關文章