健康檢查狀態

后端服務器的健康檢查狀態如下所示：

健康檢查工作原理

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）

• 健康檢查成功時間窗口= （健康檢查成功響應時間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，健康檢查狀態為健康。

從不健康狀態到健康的狀態檢查過程如下圖所示（假設服務器響應健康檢查請求需要耗時1s）：

HTTP健康檢查中域名的設置

當使用HTTP方式進行健康檢查時，可以設置健康檢查的域名，但這不是強制選項。因為有些后端服務器會對請求中的host字段做校驗，即要求請求頭中必須存在host字段。如果在健康檢查中配置了域名，則GWLB會將域名配置到host字段中，反之，如果沒有配置域名，勾選使用后端服務器內網IP，會用內網IP加端口作為host，因此健康檢查請求就會被后端服務器拒絕，可能導致健康檢查失敗。

綜上原因，如果您的后端服務器需要校驗請求的host字段，那么就需要配置相關的域名，確保健康檢查正常工作。

相關文檔

配置和管理健康檢查