1. 健全狀態檢查的原理是什嗎?

負載平衡通過健全狀態檢查來探測後端ECS執行個體的可用性。開啟健全狀態檢查功能後,當後端某個ECS執行個體健全狀態檢查出現異常時,來自用戶端的新請求將不會再被轉寄到該ECS執行個體,直到該ECS執行個體恢複正常。

如下圖所示,負載平衡健全狀態檢查使用的位址區段是100.64.0.0/10,後端伺服器務必不能屏蔽該位址區段。您無需在ECS安全性群組中額外針對該位址區段配置允許存取策略,但如有配置iptables等安全性原則,請務必允許存取(100.64.0.0/10 是阿里雲保留地址,其他使用者無法分配到該網段內,不會存在安全風險)。

更多詳細資料,參考健康檢查介紹

2. 推薦的健全狀態檢查配置是什嗎?

為了避免頻繁的健全狀態檢查失敗引起的切換對系統可用性的衝擊,健全狀態檢查只有在健全狀態檢查時間窗內連續多次檢查成功或失敗後,才會進行狀態切換。更多詳細資料參見配置健康檢查

以下是TCP/HTTP/HTTPS監聽建議使用的健全狀態檢查配置。

配置 推薦值
響應逾時時間 5秒
健全狀態檢查間隔 2秒
不健康閾值 3

以下是UDP監聽建議使用的健全狀態檢查配置。

配置 推薦值
響應逾時時間 10秒
健全狀態檢查間隔 5秒
不健康閾值 3
健康閾值 3
说明 此配置有利於使用者服務及應用狀態的儘快收斂。如果您有更高要求,可以適當地降低響應逾時時間值,但必須先保證服務在正常狀態下的處理時間小於這個值。

3. 是否可以關閉健全狀態檢查?

您只可能關閉HTTP/HTTPS監聽的健全狀態檢查,不能關閉TCP/UDP監聽的健全狀態檢查。具體操作,參考關閉健全狀態檢查

说明 如果關閉健全狀態檢查,當後端某個ECS執行個體健全狀態檢查出現異常時,負載平衡還是會把請求轉寄到該異常的ECS執行個體上,造成部分業務不可訪問。建議您不要關閉健全狀態檢查。

4. TCP監聽如何選擇健全狀態檢查方式?

TCP監聽支援HTTP和TCP兩種健全狀態檢查方式:

  • TCP協議健全狀態檢查通過發送SYN握手報文,檢測伺服器連接埠是否存活。
  • HTTP協議健全狀態檢查通過發送HEAD/GET請求,類比瀏覽器的訪問行為來檢查伺服器應用是否健康。

TCP健全狀態檢查方式對伺服器的效能資源消耗相對要少一些。如果您對後端伺服器的負載高度敏感,則選擇TCP健全狀態檢查;如果負載不是很高,則選擇HTTP健全狀態檢查。

5. ECS執行個體權重設定為零對健全狀態檢查有什麼影響?

該狀態下,負載平衡不會再將流量轉寄給該ECS執行個體,且四層監聽的後端伺服器健全狀態檢查會顯示異常(七層監聽不會顯示異常)。

將負載平衡後端ECS執行個體的權重設為零,相當於將該ECS執行個體移出負載平衡。一般是在ECS執行個體進行重啟、配置調整等主動營運時將其權重設定為零。

6. HTTP監聽向後端ECS執行個體執行健全狀態檢查使用的方法是什嗎?

HEAD方法。

如果後端ECS執行個體的服務關閉HEAD方法,會導致健全狀態檢查失敗。建議在ECS執行個體上用HEAD方法訪問自已IP地址進行測試:
curl -v -0 -I -H "Host:" -X HEAD http://IP:port

7. HTTP監聽向後端ECS執行個體執行健全狀態檢查的IP地址是什嗎?

負載平衡健全狀態檢查使用的位址區段是。如果後端ECS執行個體啟用了iptables等存取控制,需要在內網網卡對做訪問允許存取。

8. 為什麼健全狀態檢查監控頻率與web日誌記錄不一致?

負載平衡健全狀態檢查服務也是叢集方式的,這樣可以避免單點故障。負載平衡的代理分布到很多節點上,因此看到的健全狀態檢查日誌訪問頻率和控制台設定的頻率不一致,這是正常現象。

9. 健全狀態檢查是否會消耗系統資源?

HTTP模式的健全狀態檢查對後端ECS執行個體的資源消耗不大。

10. 負載平衡因後端資料庫故障導致健全狀態檢查失敗,如何處理?

問題現象:

ECS執行個體內配置了兩個網站,www.test.com是靜態網站,app.test.com是動態網站,都配置了負載平衡。後端資料庫服務異常,導致訪問www.test.com靜態網站出現502錯誤。

問題原因:

負載平衡健全狀態檢查配置的檢查網域名稱是app.test.com,RDS或者自建資料庫故障導致app.test.com訪問異常,所以健全狀態檢查失敗。

解決方案:

將負載平衡健全狀態檢查網域名稱配置為www.test.com即可。

11. 負載平衡服務TCP連接埠健全狀態檢查成功,為什麼在後端業務日誌中出現網路連接異常資訊?

問題現象:

負載平衡後端配置TCP服務連接埠後,後端業務日誌中頻繁出現類似如下網路連接異常錯誤資訊。經進抓包分析,發現相關請求來自負載平衡伺服器,同時負載平衡主動向伺服器發送了RST資料包。

問題原因:

該問題和負載平衡的健全狀態檢查機制有關。

由於TCP對上層業務狀態無感知,同時,為了降低負載平衡健全狀態檢查成本和對後端業務的衝擊,當前負載平衡針對TCP協議服務連接埠的健全狀態檢查只會做簡單的TCP三向交握,而後直接發送RST包斷開TCP串連。資料互動流程如下:

  1. 負載平衡伺服器向後端負載平衡服務連接埠發送SYN請求包;
  2. 後端伺服器收到請求後,如果連接埠狀態正常,則按照正常的TCP機制返回相應的SYN+ACK應答包;
  3. 負載平衡伺服器成功收到後端服務連接埠應答後,則認為連接埠監聽是正常的,判定健全狀態檢查成功;
  4. 負載平衡伺服器向相應TCP服務連接埠直接發送RST包主動關閉串連,結束本次健全狀態檢查操作,且沒有繼續發送業務資料。

如上所述,由於健全狀態檢查成功後,負載平衡伺服器直接發送TCP RST包中斷了串連,並沒有做進一步的業務資料互動,導致上層業務(比如Java串連池等)認為相應的串連是異常的,所以會出現Connection reset by peer等錯誤資訊。

解決方案:

  • 更換TCP協議為HTTP協議。
  • 在業務層面,對來自SLB伺服器IP位址區段的相關請求做日誌過濾,忽略相關錯誤資訊。

12. 為什麼業務本身沒有異常但是健全狀態檢查顯示異常?

問題現象:

負載平衡HTTP方式的健全狀態檢查始終失敗,但測試curl -I得到的狀態代碼是正常的。
echo -e ‘HEAD /test.html HTTP/1.0\r\n\r\n’ | nc -t 192.168.0.1 80

問題原因:

如果返回的狀態與控制台配置的正常狀態代碼不一致,則判定健全狀態檢查異常。如果您配置的正常狀態代碼為http_2xx,則所有返回的非HTTP 2xx狀態代碼均被認為是健全狀態檢查失敗。

Tengine/Nginx配置會發現curl沒有問題,但是echo測試會匹配到預設網站,導致測試檔案test.html返回404錯誤,如下圖所示。

解決方案:

  • 修改主設定檔,將預設網站注釋掉。
  • 在健全狀態檢查配置中添加檢查網域名稱。