發生在阿里雲 SLB 4 層的一次故障記錄

阿里雲 SLB 與 ECS 之間發生故事。環境如下：

SLB api-node: 該 SLB 后端接着 10 台節點服務器

SLB sql-node: 該 SLB 后端接着 2 台節點服務器

問題描述：

訪問 web 站點發現，連續點擊幾次頁面就會有一次請求時間很長 30s 。

這個 30s 是超過了 php.ini 中 max_execution_time = 30 該參數的設置最大值，最終請求失敗，返回 400 。

分析故障現象應該是有一台 api-node 有問題，當請求被輪詢到該節點時，請求失敗。

通過監控服務器觀看，各個 api-node 負載都均衡，無法直觀的發現是哪台服務器故障。

(如果有每台 api-node 的訪問日志，做了日志分析，可以通過統計圖直觀的反應出來)

最終寫腳本拿問題URL去循環請求每台 api-node ，發現了這台問題服務器。

通過開發人員調試代碼，發現問題為該節點連接數據庫故障。具體情況如下：

1、該 ECS 請求三四次數據庫的SLB就會出現連接超時。( 直接使用 mysql 命令連接 )

2、該 ECS 單獨去請求數據庫SLB后端的服務器，沒有任何問題。

通過上面的測試，排除服務器環境、代碼、數據庫服務器的問題。最終問題定位在數據庫的SLB上。

由於是做 mysql 的負載均衡，使用的是 TCP 協議的 4 層負載均衡。

向阿里雲發起工單，提交問題，經過一系列排查，最終阿里雲給出故障原因及解決方法如下：

"這是由於您使用的slb 4層tcp 協議,由於slb 的一些底層架構原因引起的,這個問題我們也已經向后端反饋過了;
只要客戶端ecs 的內網ip 和 slb 后端的ecs 內網ip 有在一個路由段的，就會出現這個問題;
建議您可以手工刪除slb 后端ecs 重復的路由條目,或者將您的slb 配置修改成7層http 協議"

解決方法：

1、登錄問題 ECS 查看路由表

shell > route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
159.110.44.0     0.0.0.0         255.255.252.0   U     0      0        0 eth1
110.27.240.0     0.0.0.0         255.255.252.0   U     0      0        0 eth0
169.254.0.0      0.0.0.0         255.255.0.0     U     1002   0        0 eth0
169.254.0.0      0.0.0.0         255.255.0.0     U     1003   0        0 eth1
172.16.0.0      110.27.243.247   255.240.0.0     UG    0      0        0 eth0
100.64.0.0      110.27.243.247   255.192.0.0     UG    0      0        0 eth0
10.0.0.0        110.27.243.247   255.0.0.0       UG    0      0        0 eth0
0.0.0.0         159.110.47.247   0.0.0.0         UG    0      0        0 eth1

2、登錄數據庫 SLB 后端 ECS 查看路由表 ( 與問題 ECS 內網同一網段的服務器 )

shell > route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
59.110.20.0     0.0.0.0         255.255.252.0   U     0      0        0 eth1
110.27.240.0    0.0.0.0         255.255.252.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0        0 eth1
172.16.0.0      110.27.243.247  255.240.0.0     UG    0      0        0 eth0
100.64.0.0      110.27.243.247  255.192.0.0     UG    0      0        0 eth0
10.0.0.0        110.27.243.247  255.0.0.0       UG    0      0        0 eth0
0.0.0.0         159.110.23.247  0.0.0.0         UG    0      0        0 eth1

3、刪除這台數據庫服務器內網地址與問題 ECS 重復的路由 (只刪數據庫服務器這台就可以)

shell > route del -net 110.27.240.0 netmask 255.255.252.0 dev eth0

shell > route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
159.110.20.0     0.0.0.0         255.255.252.0   U     0      0        0 eth1
169.254.0.0      0.0.0.0         255.255.0.0     U     1002   0        0 eth0
169.254.0.0      0.0.0.0         255.255.0.0     U     1003   0        0 eth1
172.16.0.0      110.27.243.247   255.240.0.0     UG    0      0        0 eth0
100.64.0.0      110.27.243.247   255.192.0.0     UG    0      0        0 eth0
10.0.0.0        110.27.243.247   255.0.0.0       UG    0      0        0 eth0
0.0.0.0         159.110.23.247   0.0.0.0         UG    0      0        0 eth1

# 經測試，問題解決。最終關閉工單提示，實際處理時長：6小時2分鍾

# 記錄：確保以后新買的需要訪問數據庫 SLB 的 ECS 不與數據庫 SLB 后端的 ECS 在同一內網段，如果在，刪除數據庫 SLB 后端 ECS 重復路由。