本文由簡體中文內容自動轉碼而成。阿里雲不保證此自動轉碼的準確性、完整性及時效性。本文内容請以簡體中文版本為準。

CLB健全狀態檢查

更新時間:2025-03-18 19:05

CLB通過健全狀態檢查判斷後端伺服器的可用性。開啟健全狀態檢查後,如果某台後端伺服器異常,CLB會將請求分發到其他正常的伺服器。當該伺服器恢複正常,CLB會重新將其流量轉寄。健全狀態檢查機制提高了業務整體可用性,避免了局部伺服器異常對服務的影響。

重要

如果您的業務對負載敏感,高頻率的健全狀態檢查可能影響正常業務訪問。您可以根據業務情況,通過降低健全狀態檢查頻率、增大檢查間隔、將七層檢查改為四層檢查等方式,來降低影響。但為了保障業務的持續可用,不建議關閉健全狀態檢查。

健全狀態檢查過程

健全狀態檢查是通過定期發送請求來確認伺服器的狀態。

CLB採用叢集部署,叢集內的節點伺服器同時負責資料轉寄和健全狀態檢查。如果某台伺服器健全狀態檢查失敗,則不會再將新的用戶端請求分發給該異常伺服器。

CLB健全狀態檢查使用的位址區段是100.64.0.0/10,後端伺服器務必不能屏蔽該位址區段。您無需在ECS安全性群組中額外配置允許存取策略,但如有配置iptables等安全性原則,請務必允許存取(100.64.0.0/10 是阿里雲保留地址,不會存在安全風險)。

HTTP/HTTPS監聽健全狀態檢查機制

七層監聽(HTTP/HTTPS)通過HEAD或GET請求進行健全狀態檢查。

HTTPS監聽的認證由CLB系統管理,資料互動使用HTTP以提高效能。

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

  1. 伺服器根據配置向後端伺服器發送HTTP HEAD請求。

  2. 後端伺服器返回HTTP狀態代碼。

  3. 若在響應逾時時間內未收到響應,則判定健全狀態檢查失敗。

  4. 若在響應逾時時間內收到響應,則比對狀態代碼,匹配則成功,否則失敗。

TCP監聽健全狀態檢查機制

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

TCP監聽的檢查機制如下:

  1. 四層叢集中的伺服器根據健全狀態檢查配置,向後端伺服器的內網IP和健全狀態檢查連接埠發送TCP SYN資料包。

  2. 後端伺服器收到請求後,如果相應連接埠正在正常監聽,則返回SYN+ACK資料包。

  3. 如果在響應逾時時間內,四層叢集中的伺服器沒有收到後端伺服器返回的資料包,則認為服務無響應,判定健全狀態檢查失敗,並發送RST資料包中斷TCP串連。

  4. 如果在響應逾時時間內,四層叢集中的伺服器成功收到後端伺服器返回的資料包,則認為服務正常運行,判定健全狀態檢查成功,並發送RST資料包中斷TCP串連。

說明

該機制可能會導致後端伺服器認為相關TCP串連異常,並在業務軟體日誌中拋出Connection reset by peer錯誤資訊。

解決方案:

  • TCP監聽採用HTTP方式進行健全狀態檢查。

  • 在後端伺服器配置擷取用戶端真實IP後,忽略來自CLB服務位址區段的串連錯誤。

UDP監聽健全狀態檢查

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

UDP監聽的檢查機制如下:

  1. 四層叢集中的伺服器根據監聽的健全狀態檢查配置,向後端伺服器的內網IP+【健全狀態檢查連接埠】發送UDP報文。

  2. 如果後端伺服器相應連接埠未正常監聽,則系統會返回類似port XX unreachable的ICMP報錯資訊,反之不做任何處理。

  3. 如果在【響應逾時時間】之內,四層叢集中的伺服器收到了後端伺服器返回的上述錯誤資訊,則認為服務異常,判定健全狀態檢查失敗。

  4. 如果在【響應逾時時間】之內,四層叢集中的伺服器沒有收到後端伺服器返回的任何資訊,則認為服務正常,判定健全狀態檢查成功。

說明

當前UDP協議服務健全狀態檢查可能存在服務真實狀態與健全狀態檢查不一致的問題:

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

解決方案:

負載平衡通過發送指定字串到後端伺服器,並在收到指定應答後判定檢查成功。此機制需要用戶端程式配合。

健全狀態檢查時間窗

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

  • 健全狀態檢查間隔(每隔多久進行一次健全狀態檢查)

  • 響應逾時時間 (等待伺服器返回健全狀態檢查的時間)

  • 檢查閾值(健全狀態檢查連續成功或失敗的次數)

健全狀態檢查時間視窗的計算方法如下:

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

  • 健全狀態檢查成功時間視窗= (健全狀態檢查成功回應時間x健康閾值)+檢查間隔x(健康閾值-1)

    說明

    健全狀態檢查成功回應時間是一次健全狀態檢查請求從發出到響應的時間。TCP方式健全狀態檢查時間非常短,幾乎可以忽略不計;HTTP方式健全狀態檢查時間取決於伺服器效能和負載,通常在秒級以內。

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

  • 如果目標後端伺服器的健全狀態檢查失敗,新的請求不會再分發到相應後端伺服器上,所以對前端訪問沒有影響。

  • 如果目標後端伺服器的健全狀態檢查成功,新的請求會分發到該後端伺服器上,前端訪問正常。

  • 如果目標後端伺服器存在異常,正處於健全狀態檢查失敗時間窗,而健全狀態檢查還未達到檢查失敗判定次數(預設為三次),則相應請求還是會被分發到該後端伺服器,進而導致前端訪問請求失敗。

健全狀態檢查響應逾時和健全狀態檢查間隔樣本

以如下健全狀態檢查配置為例:

  • 響應逾時時間:5秒

  • 健全狀態檢查間隔:2秒

  • 健康閾值:3次

  • 不健康閾值:3次

健全狀態檢查失敗時間視窗=響應逾時時間×不健康閾值+檢查間隔×(不健康閾值-1),5×3+2×(3-1)=19s,即以19s為一個時間窗,健全狀態檢查回應時間超過19s,健全狀態檢查狀態為不健康。

健全狀態檢查成功時間視窗= (健全狀態檢查成功回應時間×健康閾值)+檢查間隔×(健康閾值-1),(1×3)+2×(3-1)=7s,即以7s為一個時間窗,健全狀態檢查成功回應時間低於7s,健全狀態檢查狀態為健康。

說明

健全狀態檢查成功回應時間是一次健全狀態檢查請求從發出到響應的時間。當採用TCP方式健全狀態檢查時,由於僅探測連接埠是否存活,因此該時間非常短,幾乎可以忽略不計。當採用HTTP方式健全狀態檢查時,該時間取決於應用伺服器的效能和負載,但通常都在秒級以內。

HTTP健全狀態檢查中網域名稱的設定

使用HTTP方式進行健全狀態檢查時,可以設定網域名稱,但這不是強制的。有些應用伺服器會校正請求中的host欄位,要求要求標頭中必須存在host欄位。如果配置了網域名稱,CLB會將其添加到host欄位中。如果沒有佈建網域名,健全狀態檢查請求可能會被伺服器拒絕,導致檢查失敗。

因此,如果您的應用伺服器需要校正host欄位,請配置相關網域名稱以確保健全狀態檢查正常工作。

相關文檔

  • 本頁導讀 (1, M)
  • 健全狀態檢查過程
  • HTTP/HTTPS監聽健全狀態檢查機制
  • TCP監聽健全狀態檢查機制
  • UDP監聽健全狀態檢查
  • 健全狀態檢查時間窗
  • 健全狀態檢查響應逾時和健全狀態檢查間隔樣本
  • HTTP健全狀態檢查中網域名稱的設定
  • 相關文檔
文檔反饋
phone 聯絡我們

立即和Alibaba Cloud在線服務人員進行交談,獲取您想了解的產品信息以及最新折扣。

alicare alicarealicarealicare