負載平衡通過健全狀態檢查來判斷後端伺服器的業務可用性。開啟健全狀態檢查功能後，當某台後端伺服器健全狀態檢查出現異常時，負載平衡會自動將新的請求分發到其他健全狀態檢查正常的後端伺服器上；而當該後端伺服器恢複正常運行時，負載平衡會將其自動回復到負載平衡服務中進行流量轉寄。健全狀態檢查機制提高了使用者業務整體可用性，避免了局部後端伺服器異常對總體服務的影響，是保證業務高可用的重點要素。
如果您的業務對負載敏感性高，高頻率的健全狀態檢查探測可能會對正常業務訪問造成影響。您可以結合業務情況，通過降低健全狀態檢查頻率、增大健全狀態檢查間隔、七層檢查修改為四層檢查等方式，來降低對業務的影響。但為了保障業務的持續可用，不建議關閉健全狀態檢查。
健全狀態檢查過程
負載平衡採用叢集部署。四層叢集或七層叢集內的相關節點伺服器同時承載了資料轉寄和健全狀態檢查職責。
四層叢集內不同伺服器分別獨立、並行地根據負載平衡策略進行資料轉寄和健全狀態檢查操作。如果某一台四層叢集中的伺服器對某一台後端伺服器健全狀態檢查失敗，則該四層叢集中的伺服器將不會再將新的用戶端請求分發給相應的異常的後端伺服器。四層叢集內所有伺服器同步進行該操作。
如下圖所示，傳統型負載平衡CLB健全狀態檢查使用的位址區段是100.64.0.0/10，後端伺服器務必不能屏蔽該位址區段。您無需在ECS安全性群組中額外針對該位址區段配置允許存取策略，但如有配置iptables等安全性原則，請務必允許存取（100.64.0.0/10 是阿里雲保留地址，其他使用者無法分配到該網段內，不會存在安全風險）。
HTTP/HTTPS監聽健全狀態檢查機制
針對七層（HTTP或HTTPS協議）監聽，健全狀態檢查通過HEAD或GET探測來擷取狀態資訊，如下圖所示。
對於HTTPS監聽，認證在負載平衡系統中進行管理。負載平衡與後端伺服器之間的資料互動（包括健全狀態檢查資料和業務互動資料）使用HTTP，不再通過HTTPS進行傳輸，以提高系統效能。
七層監聽的檢查機制如下：
七層叢集中的伺服器根據監聽的健全狀態檢查配置，向後端伺服器的內網IP+【健全狀態檢查連接埠】+【檢查路徑】發送HTTP HEAD請求（包含設定的【網域名稱】）。
後端伺服器收到請求後，根據相應服務的運行情況，返回HTTP狀態代碼。
如果在【響應逾時時間】之內，七層叢集中的伺服器沒有收到後端伺服器返回的資訊，則認為服務無響應，判定健全狀態檢查失敗。
如果在【響應逾時時間】之內，七層叢集中的伺服器成功接收到後端伺服器返回的資訊，則將該返回資訊與配置的狀態代碼進行比對。如果匹配則判定健全狀態檢查成功，反之則判定健全狀態檢查失敗。
TCP監聽健全狀態檢查機制
針對四層TCP監聽，為了提高健全狀態檢查效率，健全狀態檢查通過定製的TCP探測來擷取狀態資訊，如下圖所示。
TCP監聽的檢查機制如下：
四層叢集中的伺服器根據監聽的健全狀態檢查配置，向後端伺服器的內網IP+【健全狀態檢查連接埠】發送TCP SYN資料包。
後端伺服器收到請求後，如果相應連接埠正在正常監聽，則會返回SYN+ACK資料包。
如果在【響應逾時時間】之內，四層叢集中的伺服器沒有收到後端伺服器返回的資料包，則認為服務無響應，判定健全狀態檢查失敗，並向後端伺服器發送RST資料包中斷TCP串連。
如果在【響應逾時時間】之內，四層叢集中的伺服器成功收到後端伺服器返回的資料包，則認為服務正常運行，判定健全狀態檢查成功，而後向後端伺服器發送RST資料包中斷TCP串連。
正常的TCP三向交握，四層叢集中的伺服器在收到後端伺服器返回的SYN+ACK資料包後，會進一步發送ACK資料包，隨後立即發送RST資料包中斷TCP串連。
該實現機制可能會導致後端伺服器認為相關TCP串連出現異常（非正常退出），並在業務軟體如Java串連池等日誌中拋出相應的錯誤資訊，如Connection reset by peer。
解決方案：
TCP監聽採用HTTP方式進行健全狀態檢查。
在後端伺服器配置了擷取用戶端真實IP後，忽略來自前述負載平衡服務位址區段相關訪問導致的串連錯誤。
UDP監聽健全狀態檢查
針對四層UDP監聽，健全狀態檢查通過UDP報文探測來擷取狀態資訊，如下圖所示。
UDP監聽的檢查機制如下：
四層叢集中的伺服器根據監聽的健全狀態檢查配置，向後端伺服器的內網IP+【健全狀態檢查連接埠】發送UDP報文。
如果後端伺服器相應連接埠未正常監聽，則系統會返回類似
port XX unreachable的ICMP報錯資訊，反之不做任何處理。如果在【響應逾時時間】之內，四層叢集中的伺服器收到了後端伺服器返回的上述錯誤資訊，則認為服務異常，判定健全狀態檢查失敗。
如果在【響應逾時時間】之內，四層叢集中的伺服器沒有收到後端伺服器返回的任何資訊，則認為服務正常，判定健全狀態檢查成功。
當前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方式健全狀態檢查時，該時間取決於應用伺服器的效能和負載，但通常都在秒級以內。
從不健康狀態到健康的狀態檢查過程如下圖所示（假設伺服器響應健全狀態檢查請求需要耗時1s）：
HTTP健全狀態檢查中網域名稱的設定
當使用HTTP方式進行健全狀態檢查時，可以設定健全狀態檢查的網域名稱，但並非強制選項。因為有些應用伺服器會對請求中的host欄位做校正，即要求要求標頭中必須存在host欄位。如果在健全狀態檢查中配置了網域名稱，則SLB會將網域名稱配置到host欄位中去，反之，如果沒有佈建網域名，CLB則不會在請求中附帶host欄位，因此健全狀態檢查請求就會被伺服器拒絕，可能導致健全狀態檢查失敗。
綜上原因，如果您的應用伺服器需要校正請求的host欄位，那麼則需要配置相關的網域名稱，確保健全狀態檢查正常工作。
相關文檔
健全狀態檢查需要在添加監聽時配置，具體操作可參考配置和管理CLB健全狀態檢查。
健全狀態檢查常見問題可參考CLB健全狀態檢查FAQ。