負(fù)載均衡健康檢查使用的誤區(qū)和最佳實(shí)踐

1、精品文檔負(fù)載均衡健康檢查的使用誤區(qū)和最佳實(shí)踐本文章來自于阿里云云棲社區(qū)分析用戶提交的負(fù)載均衡（簡(jiǎn)稱SLB）工單，我們發(fā)現(xiàn)很多SLB異常問題與不合理的健康檢查策略相關(guān)。例如：健康檢查間隔設(shè)置過長，SLB無法及時(shí)準(zhǔn)確發(fā)現(xiàn)后端ECS出現(xiàn)服務(wù)不可用， 造成實(shí)際業(yè)務(wù)中斷。使用 HTTP模式健康檢查， 未合理配置后端日志記錄模塊，導(dǎo)致后端日志內(nèi)容記錄大量健康檢查HEAD日志，造成磁盤負(fù)載壓力。原理要點(diǎn)SLB服務(wù)通過健康檢查機(jī)制檢測(cè)后端云服務(wù)器池中ECS的健康狀態(tài)，自動(dòng)隔離異常狀態(tài)的 ECS，從而解決了單臺(tái) ECS的單點(diǎn)問題，同時(shí)提高了應(yīng)用的整體服務(wù)能力。關(guān)于健康檢查的原理，詳情請(qǐng)參考官網(wǎng)知識(shí)點(diǎn)，負(fù)載均衡健

2、康檢查原理淺析文章重點(diǎn)闡述了如下幾個(gè)方面：健康檢查處理過程健康檢查策略配置說明健康檢查機(jī)制說明健康檢查狀態(tài)切換時(shí)間窗總結(jié)要點(diǎn)如下：做最好的自己精品文檔1、 4 層 TCP協(xié)議的健康檢查通過TCP 3次握手檢查后端ECS 端口是否處于監(jiān)聽轉(zhuǎn)臺(tái)。與常規(guī) TCP連接使用 TCP FIN方式銷毀不同，健康檢查的TCP連接在 3 次握手建立成功后，發(fā)起方以TCP Reset方式主動(dòng)將連接斷開。2、7 層 HTTP協(xié)議的健康檢查通過HTTP HEAD 請(qǐng)求檢查指定URL 路徑的返回值，如果返回值與自定義的健康檢查成功返回值相匹配，則判定檢查成功。3、 SLB使用 4 層 TCP 協(xié)議監(jiān)聽時(shí)，健康檢查方式可

3、選TCP 協(xié)議 或 HTTP 協(xié)議。4、4 層 UDP 協(xié)議的健康檢查是通過ICMP Port Unreachable 消息來判斷， 可能存在服務(wù)真實(shí)狀態(tài)與健康檢查不一致的問題，我們后續(xù)會(huì)持續(xù)產(chǎn)品改進(jìn)解決該問題。5、健康檢查機(jī)制的引入，有效提高了承載于SLB的業(yè)務(wù)服務(wù)的可用性。但是，為了避免頻繁的健康檢查失敗引發(fā)的切換，對(duì)系統(tǒng)可用性帶來的沖擊，健康檢查只有在【連續(xù)】多次檢查成功或失敗后，才會(huì)進(jìn)行狀態(tài)切換（判定為健康檢查成功或失敗）。使用誤區(qū)如下是通過工單梳理總結(jié)的健康檢查常見的理解和使用誤區(qū)。誤區(qū) 1 : 懷疑 SLB健康檢查形成DDoS攻擊，導(dǎo)致服務(wù)器性能下降。例如，有用戶誤認(rèn)為SLB 使用

4、上百臺(tái)機(jī)器進(jìn)行健康檢查，大量高頻次的TCP 請(qǐng)求會(huì)形成 DDoS攻擊，造成后端ECS性能低下。但實(shí)際上，無論是4 層 TCP/UDP或 7 層 HTTP協(xié)議的健康檢查，都根本無法形成DDoS攻擊。做最好的自己精品文檔原理上， SLB集群會(huì)利用多臺(tái)機(jī)器(假定 M ，個(gè)位數(shù)級(jí)別 ) 對(duì)后端ECS 的每個(gè)服務(wù)監(jiān)聽端口 (假定 N) ，按照配置的檢查間隔(假定O 秒，一般建議最少2 秒) 進(jìn)行健康檢查。以 4 層 TCP 協(xié)議為例，每秒的 TCP連接建立數(shù)為： M*N/O 。因此，健康檢查帶來的每秒 TCP并發(fā)數(shù)，主要取決于創(chuàng)建的監(jiān)聽端口數(shù)量。除非監(jiān)聽端口達(dá)到巨量，否則健康檢查對(duì)后端ECS 的 TCP

5、 并發(fā)連接請(qǐng)求根本無法達(dá)到SYN Flood的攻擊級(jí)別，實(shí)際對(duì)后端ECS 的網(wǎng)絡(luò)壓力極低。誤區(qū) 2 : 用戶為了避免SLB 健康檢查的影響，將健康檢查間隔設(shè)置很長。該配置會(huì)導(dǎo)致當(dāng)后端ECS出現(xiàn)異常時(shí)， SLB需要較長時(shí)間才能偵測(cè)到后端ECS不可用。尤其當(dāng)后端ECS間斷不可用時(shí)，由于SLB需要【連續(xù)】檢測(cè)失敗時(shí)才會(huì)移除異常ECS，這會(huì)導(dǎo)致 SLB集群可能根本無法發(fā)現(xiàn)后端ECS不可用。舉一個(gè)實(shí)際案例：背景信息：用戶使用后端有2 臺(tái) ECS的 1 個(gè) 4 層 TCP協(xié)議的公網(wǎng)SLB,對(duì)外提供服務(wù)， TCP協(xié)議的健康檢查間隔設(shè)置為50 秒。某天用戶做了應(yīng)用代碼改進(jìn)后，發(fā)布到 1 臺(tái)測(cè)試 ECS，而后將

6、該 ECS加入 SLB。但是由于應(yīng)用問題以及不合理的健康檢查的設(shè)置，出現(xiàn)了連續(xù)2 次的業(yè)務(wù)不可用。下圖失敗連接數(shù)趨勢(shì)代表 SLB轉(zhuǎn)發(fā)到后端ECS但無法建立連接的TCP 3次握手失敗的連接數(shù)。在SLB 正常工作時(shí)其值應(yīng)該為0。做最好的自己精品文檔圖示 . 失敗連接數(shù)趨勢(shì)從圖中可以看到，出現(xiàn)了2 次 SLB轉(zhuǎn)發(fā)失敗，業(yè)務(wù)間斷不可用的情況。階段 1: 15:29 - 16:44: 該問題由于應(yīng)用代碼的原因?qū)е?。階段 2: 17:12 起 : 該問題由于 ECS內(nèi)核參數(shù)的配置錯(cuò)誤， 單臺(tái) ECS無法承擔(dān)業(yè)務(wù)量導(dǎo)致。如下是復(fù)盤的詳細(xì)過程：15:26】 用戶創(chuàng)建 ECS機(jī)器 (假定名稱 i-test),

7、部署最新的應(yīng)用代碼， 加入 SLB集群中。15:29】由于新應(yīng)用代碼的問題， SLB將請(qǐng)求轉(zhuǎn)發(fā)至該 ECS后，其 CPU飆升至 100%。圖示 . ECS CPU前圖 失敗連接數(shù)趨勢(shì)顯示 15:30 分 SLB的 TCP轉(zhuǎn)發(fā)失敗連接數(shù)開始飆升，原因就是新加入的 ECS i-test機(jī)器在 CPU 100%的情況下出現(xiàn)業(yè)務(wù)不可用。15:34 分開始，后端的ECS健康檢查日志中出現(xiàn)健康檢查失敗的信息。但由于健康檢查的間隔為50 秒，而后端 ECSi-test 也不是完全不響應(yīng)，偶爾的TCP 三次握手健康檢查還可以成功，因此未出現(xiàn)【連續(xù)】健康檢查失敗，所以該SLB的監(jiān)聽端口未報(bào)出異常狀態(tài)。做最好的自

8、己精品文檔用戶接到終端客戶反饋業(yè)務(wù)出現(xiàn)斷續(xù)不可用的情況后開始緊急自查。但由于 SLB狀態(tài)未報(bào)出異常，用戶將排查集中在應(yīng)用側(cè)。16:44】用戶將 ECS i-test從 SLB 中下線，業(yè)務(wù)恢復(fù)正常， 從前圖 失敗連接數(shù)趨勢(shì) 中，可以看到失敗的數(shù)量降到 0。16:56】用戶將裝有老版本應(yīng)用的 ECS i-test 加入 SLB集群，后端 3 臺(tái) ECS正常提供服務(wù)。【17:12】業(yè)務(wù)恢復(fù)后，用戶認(rèn)為之前問題是由于業(yè)務(wù)代碼的問題導(dǎo)致。此時(shí)用戶通過將 ECS權(quán)重設(shè)置為 0 的方式將 2 臺(tái) ECS下線，由新上線的那臺(tái)ECS i-test承擔(dān)所有業(yè)務(wù)。由于業(yè)務(wù)量陡增，ECS i-test機(jī)器未合理配置

9、內(nèi)核TCP參數(shù)， IP Conntrack 表耗盡，前圖 失敗連接數(shù)趨勢(shì) 顯示大量新建TCP連接失敗。 但由于健康檢查間隔高，SLB無法及時(shí)判斷后端 ECS實(shí)際狀態(tài)， SLB日志顯示該ECS的狀態(tài)在很長一段時(shí)間內(nèi)保持正常，當(dāng)前端用戶反饋后，才發(fā)現(xiàn)實(shí)際業(yè)務(wù)影響，導(dǎo)致業(yè)務(wù)中斷時(shí)間較長。后續(xù)通過修改ECS 內(nèi)核TCP配置參數(shù)解決。從該示例可以看出，合理的配置健康檢查間隔對(duì)于及時(shí)發(fā)現(xiàn)業(yè)務(wù)不可用非常重要。誤區(qū) 3 : 使用 HTTP模式健康檢查，未合理配置后端，導(dǎo)致后端日志內(nèi)容記錄大量健康檢查 HEAD日志，造成磁盤負(fù)載壓力。我們確實(shí)遇到過一例健康檢查配置導(dǎo)致后端ECS的性能低下的案例。 用戶購買低配

10、(1 核1G) ECS，使用 7 層 HTTP健康檢查，健康檢查間隔低，同時(shí)配置多個(gè)監(jiān)聽，后端ECS的Web 服務(wù)記錄大量的HEAD請(qǐng)求日志，導(dǎo)致IO 占用高，引起性能低下。解決方案請(qǐng)參考知識(shí)點(diǎn)健康檢查導(dǎo)致大量日志的處理 。做最好的自己精品文檔最佳實(shí)踐結(jié)合 SLB健康檢查的技術(shù)要點(diǎn)和實(shí)際使用誤區(qū)，我們提供如下最佳實(shí)踐。1、根據(jù)業(yè)務(wù)需要合理選擇4 層 TCP 或 7 層 HTTP的健康檢查模式。如果使用 HTTP 健康檢查模式，請(qǐng)合理配置后端日志配置，避免健康檢查HEAD請(qǐng)求過多對(duì) IO 的影響。HTTP健康檢查請(qǐng)不要對(duì)根目錄進(jìn)行檢查，可以配置為對(duì)某個(gè)HTML文件檢查以確認(rèn)Web服務(wù)正常。2、合

11、理配置健康檢查間隔根據(jù)實(shí)際業(yè)務(wù)需求配置健康檢查間隔，避免因?yàn)榻】禉z查間隔過長導(dǎo)致無法及時(shí)發(fā)現(xiàn)后端 ECS出現(xiàn)問題。具體請(qǐng)參考：健康檢查的相關(guān)配置，是否有相對(duì)合理的推薦值？3、合理配置SLB架構(gòu)，監(jiān)聽、虛擬服務(wù)器組合轉(zhuǎn)發(fā)策略為滿足用戶的復(fù)雜場(chǎng)景需求，目前SLB可以配置虛擬服務(wù)器組和轉(zhuǎn)發(fā)策略。詳情請(qǐng)參考文檔：如何實(shí)現(xiàn)域名 / URL 轉(zhuǎn)發(fā)功能對(duì)于虛擬服務(wù)器組、轉(zhuǎn)發(fā)策略，其與監(jiān)聽對(duì)健康檢查并發(fā)的影響相同，如下圖：維度健康檢查配置健康檢查目標(biāo)服務(wù)器后端服務(wù)器使用配置監(jiān)聽時(shí)的健康檢查配置所有后端ECS做最好的自己精品文檔虛擬服務(wù)器組使用配置監(jiān)聽時(shí)的健康檢查配置相應(yīng)虛擬服務(wù)器組包含的服務(wù)器轉(zhuǎn)發(fā)策略使用配置監(jiān)聽時(shí)的健康檢查配置相應(yīng)虛擬服務(wù)器組包含的服務(wù)器建議用戶根據(jù)實(shí)際業(yè)務(wù)需求，合理配置監(jiān)聽、虛擬服務(wù)器組和轉(zhuǎn)發(fā)策略。a、對(duì)于 4 層 TCP協(xié)議，由于虛擬服務(wù)器組可以是有后端ECS不同的端口承載業(yè)務(wù)，因此