全部產品
Search
文件中心

Server Load Balancer:健全狀態檢查概述

更新時間:Oct 30, 2024

GWLB通過健全狀態檢查來判斷後端伺服器的業務可用性。開啟健全狀態檢查功能後,當某台後端伺服器健全狀態檢查出現異常時,GWLB會自動將新的請求分發到其他健全狀態檢查正常的後端伺服器上;而當該後端伺服器恢複正常運行時,GWLB會將其自動回復到GWLB服務中進行流量轉寄。

健全狀態檢查狀態

後端伺服器的健全狀態檢查狀態如下所示:

狀態

說明

初始化中

GWLB執行個體配置了健全狀態檢查,健全狀態檢查後端伺服器列表初始化中。

正常

後端伺服器運行狀態正常。

異常

後端伺服器未響應健全狀態檢查或未通過健全狀態檢查,表示存在異常狀態的後端伺服器。

未使用

後端伺服器沒有被使用。

未開啟

關閉健全狀態檢查。

健全狀態檢查工作原理

說明

在GWLB的健全狀態檢查過程中,請求報文不會通過Geneve協議進行封裝。

TCP健全狀態檢查

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

TCP健全狀態檢查的檢查機制如下:

  1. GWLB叢集中的伺服器根據監聽的健全狀態檢查配置,向後端伺服器的私網IP+【健全狀態檢查連接埠】發送TCP SYN資料包。

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

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

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

HTTP健全狀態檢查

HTTP健全狀態檢查通過GET探測來擷取狀態資訊,如下圖所示。

HTTP健全狀態檢查機制如下:

  1. GWLB叢集中的伺服器根據監聽的健全狀態檢查配置,向後端伺服器的私網IP+【健全狀態檢查連接埠】+【檢查路徑】發送HTTP GET請求(包含設定的【網域名稱】)。

  2. 後端伺服器收到請求後,根據相應服務的運行情況,返回HTTP狀態代碼。

  3. 如果在【響應逾時時間】之內,GWLB叢集中的伺服器沒有收到後端伺服器返回的資訊,則認為服務無響應,判定健全狀態檢查失敗。

  4. 如果在【響應逾時時間】之內,GWLB叢集中的伺服器成功接收到後端伺服器返回的資訊,則將該返回資訊與配置的狀態代碼進行比對。如果匹配則判定健全狀態檢查成功,反之則判定健全狀態檢查失敗。

健全狀態檢查時間窗

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

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

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

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

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

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

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

    說明

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

    image.png

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

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

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

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

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

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

  • 響應逾時時間:5秒

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

  • 健康閾值:3次

  • 不健康閾值:3次

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

從健康狀態到不健康狀態的檢查過程如下圖所示:

image.png

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

說明

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

從不健康狀態到健康的狀態檢查過程如下圖所示(假設伺服器響應健全狀態檢查請求需要耗時1s):

image.png

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

當使用HTTP方式進行健全狀態檢查時,可以設定健全狀態檢查的網域名稱,但這不是強制選項。因為有些後端伺服器會對請求中的host欄位做校正,即要求要求標頭中必須存在host欄位。如果在健全狀態檢查中配置了網域名稱,則GWLB會將網域名稱配置到host欄位中,反之,如果沒有佈建網域名,勾選使用後端伺服器內網IP,會用內網IP加連接埠作為host,因此健全狀態檢查請求就會被後端伺服器拒絕,可能導致健全狀態檢查失敗。

綜上原因,如果您的後端伺服器需要校正請求的host欄位,那麼就需要配置相關的網域名稱,確保健全狀態檢查正常工作。

相關文檔

配置和管理健全狀態檢查