146      阿裏雲  技術社區[雲棲]

負載均衡健康檢查的使用誤區和最佳實踐

針對客戶反饋的問題，不但要解決，還要總結分析，本文針對SLB問題進行了分析總結，發現大家遇到的很多負載均衡（簡稱 SLB）異常問題都與健康檢查配置相關。不合理的健康檢查策略可能會導致很多問題出現：

例如：

・ 健康檢查間隔設置過長，無法準確發現後端 ECS 出現服務不可用，造成業務中斷。

・ 使用 HTTP 模式健康檢查，未合理配置後端，導致後端日誌內容記錄大量健康檢查 HEAD 日誌，造成磁盤負載壓力。

如何解決這些問題，為了讓大家走出常見的誤區，今天帶大家來了解下健康檢查的原理、常見的誤區以及最佳實踐。從此 SLB 健康檢查用起來得心應手，再也不用踩坑了。

原理要點

對於健康檢查的原理，詳情請參考官網知識點：負載均衡健康檢查原理淺析

文章重點闡述了如下幾個方麵：

・?健康檢查處理過程

・?健康檢查策略配置說明

・?健康檢查機製說明

・?健康檢查狀態切換時間窗

?

總結要點如下：

1、4層TCP健康檢查通過TCP 3次握手檢查後端 ECS 端口是否監聽。與普通的TCP連接使用TCP FIN方式銷毀過程不同，健康檢查的連接在3次握手建立成功後，以TCP Reset方式主動將連接斷開。

2、7層健康檢查通過HTTP HEAD 請求檢查指定URL路徑的返回值，如果返回值與自定義的健康檢查成功返回值相匹配，則判定檢查成功。

3、負載均衡使用 TCP 協議監聽時，健康檢查方式可選 TCP協議 或 HTTP協議。

4、UDP協議的健康檢查是通過ICMP Port Unreachable消息來判斷，可能存在服務真實狀態與健康檢查不一致的問題，我們後續會持續產品改進解決該問題。

5、健康檢查機製的引入，有效提高了承載於負載均衡的業務服務的可用性。但是，為了避免頻繁的健康檢查失敗引發的切換，對係統可用性帶來的衝擊，健康檢查隻有在【連續】多次檢查成功或失敗後，才會進行狀態切換（判定為健康檢查成功或失敗）。

?

以下是通過客戶問題反饋進行的梳理，我們總結的常見健康檢查的理解和使用配置誤區：

?

誤區1?

例如，某用戶誤認為SLB服務端使用上百台機器進行健康檢查，大量的TCP請求會形成DDoS攻擊，造成後端機器性能低下。但實際上，無論是TCP/UDP/HTTP協議的健康檢查，其根本無法形成DDoS攻擊。

原理上，SLB集群會利用多台機器(假定M個，個位數級別)對後端 ECS 的每個服務監聽端口 (假定N個) ，按照配置的健康檢查間隔(假定O秒，一般建議最少2秒)進行健康檢查。以TCP協議為例，每秒的TCP連接建立數為：M*N/O。

因此，健康檢查帶來的每秒TCP並發數，主要取決於創建的監聽端口數量。除非監聽端口達到巨量，否則健康檢查對後端ECS的TCP並發連接請求，根本無法達到SYN Flood的攻擊級別，實際對後端ECS的網絡壓力極低。

?

: 用戶為了避免SLB健康檢查的影響，將健康檢查間隔設置很長。

該配置會導致當後端ECS出現異常時，負載均衡需要較長時間才能偵測到後端ECS不可用。尤其當後端ECS間斷不可用時，由於SLB需要【連續】檢測失敗時才會移除異常ECS，較長的檢查間隔會導致負載均衡集群可能根本無法發現後端ECS不可用。

?

舉一個實際案例：

背景信息：

某用戶1個公網負載均衡, 後端有2台ECS對外提供服務，TCP協議的健康檢查間隔設置為50秒。某天用戶做了應用代碼改進後，發布到1台測試ECS，而後將該ECS加入負載均衡。但是由於應用問題以及不合理的健康檢查的設置，出現了連續2次業務不可用。

圖示.?失敗連接數趨勢

上圖"連接數趨勢"代表負載均衡失敗連接數的變化趨勢。從圖中可以看到，出現了2次負載均衡業務間斷不可用的情況。

階段1: 15:29 - 16:44: 該問題由於應用代碼的原因導致。

階段2: 17:12起 : 該問題由於單台ECS無法承擔業務量導致。

?

如下是複盤的詳細過程：

【15:26】 用戶創建ECS機器(假定名稱i-test), 部署最新的應用代碼，加入負載均衡集群中。

【15:29】由於新應用代碼的問題，該ECS i-test上線後，負載均衡將業務轉發至該ECS後，其CPU飆升至100%。

圖示.?ECS CPU

從前圖"失敗連接數趨勢"可以看出，15:30分，負載均衡報出4層TCP轉發失敗的連接數開始飆升，原因就是新加入的ECS i-test機器在CPU 100%的情況下，出現業務不可用。而且從15:34分開始，後端的ECS健康檢查日誌中開始出現健康檢查失敗的信息，但是由於用戶設置的間隔為50秒，而後端ECS i-test也不是完全不響應，偶爾的TCP 三次握手健康檢查還可以成功，因此未出現【連續】健康檢查失敗，所以該負載均衡的監聽端口未報出異常狀態。

?

用戶接到終端客戶反饋，業務出現斷續不可用的情況，用戶開始緊急自查。但由於負載均衡狀態未報出異常，用戶將排查集中在應用側。

?

【16:44】用戶緊急將ECS i-test從負載均衡中下線，更換為老版本的應用。

【16:56】用戶將裝有老版本應用的ECS i-test上線到負載均衡集群。此時，負載均衡集群有3個ECS在提供服務，業務恢複正常。從前圖"失敗連接數趨勢"中，可以看到失敗的數量降到0。

【17:12】業務恢複後，用戶認為之前問題是由於業務代碼的問題導致。此時用戶通過將權重設置為0將2台原先的ECS下線，由新上線的那台ECS i-test承擔所有業務。此時，ECS i-test由於業務量陡增，IP Conntrack表耗盡，大量新建TCP連接失敗。所以看到從17:12分起，負載均衡大量的連接建立失敗。由於健康檢查間隔高，我們從負載均衡的日誌中看到，該ECS的健康檢查狀態在很長一段時間內保持正常，負載均衡集群無法及時判斷後端ECS實際狀態，當前端用戶反饋後，才發現實際業務影響，導致業務中斷時間較長。

?

從該示例可以看出，合理的配置健康檢查間隔對於及時發現業務不可用問題非常重要。

?

我們確實遇到過一例健康檢查配置，導致後端ECS的性能低下的案例。用戶購買低配(1核1G) ECS，使用7層HTTP健康檢查，健康檢查間隔低，同時配置多個監聽，後端ECS的Web服務記錄大量的HEAD請求日誌，導致IO占用高，引起性能低下。

解決方案請參考知識點"健康檢查導致大量日誌的處理"。

?

結合負載均衡健康檢查的技術要點和實際中所遇到的使用誤區，我們提供如下最佳實踐：

如果使用HTTP 健康檢查模式，請合理配置後端日誌配置，避免健康檢查HEAD請求過多對IO的影響。

HTTP健康檢查請不要對根目錄進行檢查，可以配置為對某個HTML文件檢查以確認Web服務正常。

?

根據實際業務需求配置健康檢查間隔，避免因為健康檢查間隔過長導致無法及時發現後端ECS出現問題。具體請參考：

健康檢查的相關配置，是否有相對合理的推薦值？

?

為滿足用戶的複雜場景需求，目前負載均衡可以配置虛擬服務器組和轉發策略。詳情請參考文檔：

如何實現域名 / URL 轉發功能

?

對於虛擬服務器組、轉發策略，其與監聽對健康檢查並發的影響相同，如下圖：

建議用戶根據實際業務需求，合理配置監聽、虛擬服務器組和轉發策略。

a、對於4層TCP協議，由於虛擬服務器組可以是有後端ECS不同的端口承載業務，因此在配置4層TCP的健康檢查時不要設置檢查端口，而"默認使用後端服務器的端口進行健康檢查", 否則可能導致後端ECS健康檢查失敗。?

b、對於7層HTTP協議，使用虛擬服務器組合轉發策略時，確保健康檢查配置策略中的URL在後端每台機器上都可以訪問成功。

C、避免過多的配置監聽、虛擬服務器組和轉發策略，以免對後端ECS形成一定的健康檢查壓力。

最後更新：2017-05-10 15:02:41

  上一篇： H5 誘導分享如何界定與規避方式，飛沐告訴你

  下一篇： 直播|硬盤式研發管理實踐