Server Load Balancer：ALB健全狀態檢查異常排查方法

問題描述

ALB執行個體的監聽對應的健全狀態檢查狀態顯示異常。

問題原因

解決方案

首次配置健全狀態檢查出現異常

原因一：健全狀態檢查參數設定錯誤

1. 登入應用型負載平衡ALB控制台。

2. 在頂部功能表列，選擇ALB執行個體所屬的地區。

3. 在左側導覽列，選擇應用型負載均衡 ALB > 伺服器組。

4. 在伺服器組頁面，找到目標ALB執行個體掛載的伺服器組，然後單擊伺服器組ID。

5. 在服務組詳情頁面，在健全狀態檢查地區單擊編輯健全狀態檢查。

6. 在編輯健全狀態檢查對話方塊，檢查健全狀態檢查參數設定是否正常，建議按照預設提供的健全狀態檢查參數進行設定。

   更多資訊，請參見配置和管理健全狀態檢查。

原因二：監聽連接埠問題

1. 登入應用型負載平衡ALB控制台。

2. 在頂部功能表列，選擇ALB執行個體所屬的地區。

3. 在左側導覽列，選擇應用型負載均衡 ALB > 伺服器組。

4. 在伺服器組頁面，找到目標ALB執行個體掛載的伺服器組，然後單擊伺服器組ID。

5. 在伺服器組詳情頁，單擊後端伺服器頁簽，查看並記錄後端伺服器連接埠。

6. 在服務組詳情頁面，單擊詳細資料頁簽，在健全狀態檢查地區單擊編輯健全狀態檢查。在編輯健全狀態檢查對話方塊，查看並記錄健全狀態檢查參數。

7. 登入後端伺服器，使用nc或curl命令對後端伺服器進行探測。

   關於如何登入ECS，請參見ECS遠端連線操作指南。

   # nc命令：
   echo -e "[$Method] [$PATH] [$VERSION]\r\nHost: [$Domain]\r\n\r\n" | nc -t [$IP] [$Port] #格式
   echo -e "HEAD /index.html HTTP/1.0\r\nHost: www.example.org\r\n\r\n" | nc -t 127.0.0.1 80 #樣本
   # curl命令：
   curl -X [$Method] -H "Host: [$Domain]" -I http://[$IP]:[$Port][$PATH]  #格式
   curl -X HEAD --http1.0 -H "Host: www.example.org" -I http://127.0.0.1:80/index.html #樣本

   說明

   • [$Method]為該伺服器組設定的健全狀態檢查方法。

   • [$PATH]為該伺服器組設定的健全狀態檢查路徑。

   • [$VERSION]為該伺服器組設定的健全狀態檢查中HTTP協議的版本，例如HTTP/1.0。

   • [$Domain]為該伺服器組設定的健全狀態檢查網域名稱，如果該值為“-----”，說明預設使用各後端ECS執行個體的內網IP為網域名稱，可以使用[$IP]代替。

   • [$IP]為後端ECS執行個體內網IP地址。

   • [$Port]為該伺服器組設定的健全狀態檢查的探測連接埠，如果沒有手動設定過健全狀態檢查連接埠，預設使用的是後端ECS執行個體連接埠，如果配置了健全狀態檢查連接埠，則使用配置的健全狀態檢查連接埠。

8. 查看命令執行結果的狀態代碼，結合業務判斷返回的狀態代碼是否屬於正常情況下的返回。

   • 如果判斷返回的狀態代碼是屬於正常情況下的返回，且該狀態代碼未在健全狀態檢查中配置，請修改健全狀態檢查的健康狀態返回碼。

   • 如果判斷返回的狀態代碼異常，請參見下表進行排查。下表列出了可能返回的HTTP狀態代碼及排查方法。

     狀態代碼	描述	排查方法
     400	請求無效，通常由HTTP請求格式錯誤、健全狀態檢查協議與後端服務不匹配或後端商務邏輯固定返回400狀態代碼導致	請參考以下方法逐一排查： HTTP頭部格式錯誤，如content length為空白；請檢查HTTP請求的格式。 健全狀態檢查協議和後端服務不匹配，如對HTTPS連接埠使用HTTP健全狀態檢查協議；請使用正確的健全狀態檢查協議。 若商務邏輯本身固定返回400等4xx狀態代碼，可在健全狀態檢查配置的健康狀態返回碼中勾選http_4xx，將4xx狀態代碼視為正常返回，避免因特定業務返回碼導致後端節點被健全狀態檢查剔除。 警告 將4XX或5XX納入健康狀態代碼可能導致故障執行個體無法被及時剔除。建議優先確保後端服務返回正確的2XX或3XX狀態代碼。
     403	禁止訪問，通常由後端Web服務的配置引起	檢查後端服務（如Nginx、Tomcat）是否配置了針對特定來源IP或請求特徵的攔截規則。若後端服務對健全狀態檢查請求的來源設定了攔截，會導致健全狀態檢查持續返回403，請調整後端服務的存取控制配置以放通健全狀態檢查請求。
     404	未找到目標資源，通常由健全狀態檢查路徑與後端實際可用路徑不匹配導致	請參考以下方法排查： 檢查後端網關程式（如Nginx）實際對外暴露的介面路徑首碼（例如/api/v1），確保健全狀態檢查配置的檢查路徑與後端實際可訪問的資源路徑一致。 如果通過IP直接存取後端服務返回正常，但通過網域名稱訪問返回404，通常是後端服務按網域名稱（Host頭）進行虛擬機器主機匹配所致，請核實健全狀態檢查配置的檢查網域名稱與後端服務的網域名稱配置一致。
     405	健全狀態檢查要求方法不支援	請檢查後端服務是否支援健全狀態檢查的要求方法。
     500	伺服器內部錯誤，無法完成請求	請檢查後端服務的商務邏輯。
     503	伺服器暫時不可用	請檢查後端服務的商務邏輯或負載是否過高。

配置成功後健全狀態檢查出現異常

原因一：安全類防護軟體問題

因為ALB通過內部保留位址區段中的IP地址與後端ECS執行個體通訊，ALB的該位址區段被屏蔽會導致健全狀態檢查異常，ALB將無法正常工作。本文以Iptables檢查100.64.0.0/10為例介紹。

1. 登入問題後端ECS執行個體，執行以下命令，查看filter表的所有規則。

   iptables -nL

   如果返回類似以下資訊，說明後端ECS執行個體禁止ALB內網位址區段請求。

   [root@xxx Z ~]# iptables -nL
   Chain INPUT (policy ACCEPT)
   target     prot opt source               destination
   DROP       all  --  100.64.0.0/10        0.0.0.0/0
   Chain FORWARD (policy ACCEPT)
   target     prot opt source               destination
   Chain OUTPUT (policy ACCEPT)
   target     prot opt source               destination
   Chain L (0 references)
   target     prot opt source               destination

2. 執行以下命令，刪除此規則即可。

   iptables -t filter -D INPUT -s 100.64.0.0/10 -j DROP

3. 執行以下命令，確認沒有禁止ALB內網位址區段請求。

   iptables -nL

除iptables規則外，還需檢查以下安全配置，確保ALB健全狀態檢查流量能夠正常到達後端服務：

1. 檢查後端伺服器的連接埠監聽狀態：確認後端伺服器正在監聽伺服器組中配置的後端連接埠（例如80連接埠）。可執行以下命令查看連接埠監聽情況：

   netstat -tlnp | grep <連接埠號碼>
   # 或使用ss命令：
   ss -tlnp | grep <連接埠號碼>

   若連接埠未處於監聽狀態（LISTEN），請檢查後端服務是否已正常啟動。

   說明

   如果後端服務部署在Docker或其他容器中，宿主機連接埠連通並不代表容器內服務已在健全狀態檢查連接埠上正確監聽。出現“宿主機連接埠可達但健全狀態檢查失敗”時，請進入容器內部確認服務已在健全狀態檢查連接埠（例如80連接埠）上監聽，且監聽地址為0.0.0.0（而非僅 127.0.0.1），並檢查容器內是否存在限制ALB健全狀態檢查IP的安全性原則。

2. 檢查後端ECS安全性群組入方向規則：確保安全性群組入方向規則已放通以下來源的訪問，否則ALB健全狀態檢查探測包可能被安全性群組攔截：

   • 授權對象（源地址）：升級後的ALB執行個體為其Local IP所在的交換器網段；升級前的ALB執行個體為100.64.0.0/10網段

   • 協議：TCP

   • 連接埠範圍：伺服器組中配置的後端服務連接埠和實際使用的健全狀態檢查連接埠

原因二：路由配置錯誤問題

當ALB執行個體使用的內網位址區段100.64.0.0/10在後端ECS上的路由配置錯誤時，也會導致ALB執行個體收不到健全狀態檢查探測的資料包，造成健全狀態檢查異常。本文以Linux下的route命令為例，檢查路由配置情況。

1. 登入問題後端ECS執行個體，執行以下命令，檢查當前系統的路由配置情況。

   route -n

   若您發現存在路由條目的Destination為100.64.0.0，Genmask為255.192.0.0，且Gateway沒有指向對應網卡的預設閘道（當Destination為0.0.0.0時，Gateway顯示的資訊就是預設閘道），則該路由配置錯誤。

   [root@test-server2 ~]# route -n
   Kernel IP routing table
   Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
   0.0.0.0         <eth0的預設閘道>  0.0.0.0         UG    100    0        0 eth0
   xxx             xxx             xxx             xxx   xxx    xxx      xxx xxx
   100.64.0.0      0.0.0.0         255.192.0.0     U     0      0        0 eth0

2. 執行以下命令，刪除配置錯誤的100.64.0.0/10路由。

   route del -net 100.64.0.0/10

原因三：後端ECS執行個體負載過高

當後端ECS執行個體資源不足時，伺服器可能無法在健全狀態檢查逾時時間內響應探測請求，從而導致健全狀態檢查異常。資源不足既可能是系統整體過載，也可能是串連泄漏等具體問題逐漸耗盡系統資源所致，可參考以下兩個子情境進行排查。

子情境一：系統資源過載

當CPU、記憶體或磁碟I/O等系統資源被佔滿時，伺服器來不及響應健全狀態檢查探測。參見Linux執行個體負載高問題排查和異常處理，查看是否是伺服器負載過高導致的問題。

子情境二：串連泄漏導致資源耗盡（CLOSE_WAIT堆積）

如果後端ECS上存在大量處於TCP CLOSE_WAIT狀態的串連，通常是由於後端應用程式（例如使用jsvc.exec託管的Java服務）在處理完請求後，未主動調用close()方法釋放串連，導致串連長期處於CLOSE_WAIT狀態並持續堆積。CLOSE_WAIT串連過多會佔用系統資源，可能影響健全狀態檢查的正常響應。

排查步驟：

1. 登入後端ECS，執行以下命令查看當前CLOSE_WAIT串連數量：

   netstat -an | grep CLOSE_WAIT | wc -l

2. 如果CLOSE_WAIT串連數量持續增長或異常偏高，請檢查後端應用代碼或服務配置，確保應用在請求處理完成後正確執行串連關閉操作（如調用close()或shutdown()方法）。對於使用串連池的架構，請檢查串連池的空閑逾時和回收配置。

常見問題

為什麼後端伺服器收到的健全狀態檢查請求頻率很高？

ALB採用多可用性區域分布式叢集架構，叢集內所有轉寄節點均會獨立向後端伺服器發送健全狀態檢查探測請求。因此，後端實際接收到的健全狀態檢查請求頻率為：單節點檢查頻率 × 節點數量。例如，若健全狀態檢查間隔設定為5秒，叢集中存在10個轉寄節點，則後端每5秒約收到10次健全狀態檢查請求，即近2次/秒。這是ALB的正常設計行為，並非異常。

如需降低健全狀態檢查的探測頻率或其對後端伺服器的影響，可參考以下方法：

1. 適當增大健全狀態檢查間隔，減少單位時間內的探測次數。但請注意，間隔越長，異常節點被檢測和剔除所需的時間越長，可能影響故障檢測的時效性，需結合業務對可用性的要求進行權衡。

2. 將健全狀態檢查協議改為TCP四層健全狀態檢查：ALB僅執行TCP握手，不發送HTTP請求，對後端應用資源消耗更低，可減少伺服器處理健全狀態檢查請求的開銷。