負載平衡通過健康檢查來判斷後端伺服器(ECS執行個體)的業務可用性。健康檢查機制提高了前端業務整體可用性,避免了後端ECS異常對總體服務的影響。

開啟健康檢查功能後,當後端某台ECS健康檢查出現異常時,負載平衡會自動將新的請求分發到其它健康檢查正常的ECS上;而當該ECS恢複正常運行時,負載平衡會將其自動回復到負載平衡服務中。

如果您的業務對負載敏感性高,高頻率的健康檢查探測可能會對正常業務訪問造成影響。您可以結合業務情況,通過降低健康檢查頻率、增大健康檢查間隔、七層檢查修改為四層檢查等方式,來降低對業務的影響。但為了保障業務的持續可用,不建議關閉健康檢查。

健康檢查過程

負載平衡採用叢集部署。LVS叢集或Tengine叢集內的相關節點伺服器同時承載了資料轉寄和健康檢查職責。

LVS叢集內不同伺服器分別獨立、並行地根據負載平衡策略進行資料轉寄和健康檢查操作。如果某一台LVS節點伺服器對後端某一台ECS健康檢查失敗,則該LVS節點伺服器將不會再將新的用戶端請求分發給相應的異常ECS。LVS叢集內所有伺服器同步進行該操作。

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



HTTP/HTTPS監聽健康檢查機制

針對七層(HTTP或HTTPS協議)監聽,健康檢查通過HTTP HEAD探測來獲取狀態資訊,如下圖所示。

對於HTTPS監聽,證書在負載平衡系統中進行管理。負載平衡與後端ECS之間的資料互動(包括健康檢查資料和業務互動資料),不再通過HTTPS進行傳輸,以提高系統效能。



七層監聽的檢查機制如下:

  1. Tengine節點伺服器根據監聽的健康檢查配置,向後端ECS的內網IP+【健康檢查通信埠】+【檢查路徑】發送HTTP HEAD請求(包含設定的【網域名稱】)。
  2. 後端ECS收到請求後,根據相應服務的運行情況,返回HTTP狀態碼。
  3. 如果在【響應逾時時間】之內,Tengine節點伺服器沒有收到後端ECS返回的資訊,則認為服務無響應,判定健康檢查失敗。
  4. 如果在【響應逾時時間】之內,Tengine節點伺服器成功接收到後端ECS返回的資訊,則將該返回資訊與配置的狀態碼進行比對。如果匹配則判定健康檢查成功,反之則判定健康檢查失敗。

TCP監聽健康檢查機制

針對四層TCP監聽,為了提高健康檢查效率,健康檢查通過定製的TCP探測來獲取狀態資訊,如下圖所示。



TCP監聽的檢查機制如下:

  1. LVS節點伺服器根據監聽的健康檢查配置,向後端ECS的內網IP+【健康檢查通信埠】發送TCP SYN資料包。
  2. 後端ECS收到請求後,如果相應通信埠正在正常監聽,則會返回SYN+ACK資料包。
  3. 如果在【響應逾時時間】之內,LVS節點伺服器沒有收到後端ECS返回的資料包,則認為服務無響應,判定健康檢查失敗;並向後端ECS發送RST資料包中斷TCP串連。
  4. 如果在【響應逾時時間】之內,LVS節點伺服器成功收到後端ECS返回的資料包,則認為服務正常運行,判定健康檢查成功,而後向後端ECS發送RST資料包中斷TCP串連。
说明 正常的TCP三向交握,LVS節點伺服器在收到後端ECS返回的SYN+ACK資料包後,會進一步發送ACK資料包,隨後立即發送RST資料包中斷TCP串連。

該實現機制可能會導致後端ECS認為相關TCP串連出現異常(非正常退出),並在業務軟體如Java串連池等日誌中拋出相應的錯誤資訊,如Connection reset by peer

解決方案:

  • TCP監聽採用HTTP方式進行健康檢查。
  • 在後端ECS配置了獲取用戶端真實IP後,忽略來自前述負載平衡服務地址段相關訪問導致的串連錯誤。

UDP監聽健康檢查

針對四層UDP監聽,健康檢查通過UDP報文探測來獲取狀態資訊,如下圖所示。



UDP監聽的檢查機制如下:

  1. LVS節點伺服器根據監聽的健康檢查配置,向後端ECS的內網IP+【健康檢查通信埠】發送UDP報文。
  2. 如果後端ECS相應通信埠未正常監聽,則系統會返回類似返回 port XX unreachable的ICMP報錯資訊;反之不做任何處理。
  3. 如果在【響應逾時時間】之內,LVS節點伺服器收到了後端ECS返回的上述錯誤資訊,則認為服務異常,判定健康檢查失敗。
  4. 如果在【響應逾時時間】之內,LVS節點伺服器沒有收到後端ECS返回的任何資訊,則認為服務正常,判定健康檢查成功。
说明 當前UDP協議服務健康檢查可能存在服務真實狀態與健康檢查不一致的問題:

如果後端ECS是Linux伺服器,在大並發場景下,由於Linux的防ICMP攻擊保護機制,會限制伺服器發送ICMP的速度。此時,即便服務已經出現異常,但由於無法向前端返回port XX unreachable報錯資訊,會導致負載平衡由於沒收到ICMP應答進而判定健康檢查成功,最終導致服務真實狀態與健康檢查不一致。

解決方案:

負載平衡通過發送您指定的字元串到後端伺服器,必須得到指定應答後才認為檢查成功。但該實現機制需要用戶端程式配合應答。

健康檢查時間窗

健康檢查機制的引入,有效提高了商務服務的可用性。但是,為了避免頻繁的健康檢查失敗引起的切換對系統可用性的衝擊,健康檢查只有在健康檢查時間窗內連續多次檢查成功或失敗後,才會進行狀態切換。健康檢查時間窗由以下三個因素決定:

  • 健康檢查間隔 (每隔多久進行一次健康檢查)
  • 響應逾時時間 (等待伺服器返回健康檢查的時間)
  • 檢查閾值 (健康檢查連續成功或失敗的次數)

健康檢查時間窗的計算方法如下:

  • 健康檢查失敗時間窗=響應逾時時間×不健康閾值+檢查間隔×(不健康閾值-1)


  • 健康檢查成功時間窗= (健康檢查成功回應時間x健康閾值)+檢查間隔x(健康閾值-1)
    说明 健康檢查成功回應時間是一次健康檢查請求從發出到響應的時間。當採用TCP方式健康檢查時,由於僅探測通信埠是否存活,因此該時間非常短,幾乎可以忽略不計。當採用HTTP方式健康檢查時,該時間取決於應用伺服器的效能和負載,但通常都在秒級以內。


健康檢查狀態對請求轉寄的影響如下:

  • 如果目標ECS的健康檢查失敗,新的請求不會再分發到相應ECS上,所以對前端訪問沒有影響。
  • 如果目標ECS的健康檢查成功,新的請求會分發到該ECS上,前端訪問正常。
  • 如果目標ECS存在異常,正處於健康檢查失敗時間窗,而健康檢查還未達到檢查失敗判定次數(預設為三次),則相應請求還是會被分發到該ECS,進而導致前端訪問請求失敗。