天天看點

WAF+SLB負載不均衡案例分享

作者:楓凡

問題演變過程

時間點1:高防+WAF+SLB+2台ECS

時間點2:高防+WAF+SLB+4台ECS

問題描述

在時間點1時,沒有發現明顯的負載不均衡的情況。在時間點2時,出現大部分請求都打到了其中一台ECS上。需要定位問題原因

問題梳理

  • 問題鍊路

    是SLB後端的ECS出現負載不均衡的請求,那麼直接影響這個轉發算法的,是WAF以及SLB。那麼和高防沒有關系了。

WAF+SLB負載不均衡案例分享
  • 配置情況
  1. SLB:TCP監聽,WRR轉發算法,開啟會話保持
  2. WAF:無特殊配置,域名直接回源負載均衡IP

問題點1:輪詢算法+會話保持

措施:嘗試修改輪詢算法為WLC,會話保持時間調短。

然而這個優化措施效果并不明顯,由于開啟了會話保持,那原有負載不均衡的情況下,調整WRR算法到WLC的算法,沒有實作預期的WLC。

但是從另外一個角度來說,如果源IP非常分散的場景下,即使有會話保持,理論上還是應該在經過一個較長的時間段之後,依然能夠到達均衡。

這裡由于是使用WAF的回源位址進行通路,是以對負載均衡來說,用戶端的公網IP位址是固定的,一直是固定的幾個;進而調整WLC+會話保持的調整收效甚微。

問題點2:會話保持模闆重新整理問題

措施:嘗試關閉會話保持。

稍有成效:關閉會話保持後,經過一段時間的通信,4台ECS初步的開始均衡,但是到了一個固定值之後;沒有繼續均衡,一直保持着1:2的狀态。

這裡有2個知識點:

1、WLC算法的計數開始是從調整為這個算法的時間點開始的;那麼如果曆史開始就出現不均衡,那麼開啟後還是會不均衡的。

2、由于WAF的回源位址與SLB的通信一直在,沒有斷過是以曆史的會話保持的效果依然存在,已經會話保持的IP,依然會發給對應負載均衡的RS,導緻不均衡。

推薦的解法為:使用負載均衡的權重功能,将連接配接數多的機器的權重調低,待4台機器的連接配接數基本均衡後,将RS的權重都調整為一緻。

繼續閱讀