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

問題演變過程

時間點1：高防+WAF+SLB+2臺ECS
時間點2：高防+WAF+SLB+4臺ECS

問題描述

在時間點1時，沒有發現明顯的負載不均衡的狀況。在時間點2時，出現大部分請求都打到了其中一臺ECS上。須要定位問題緣由

問題梳理

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

• 配置狀況

  1. SLB：TCP監聽，WRR轉發算法，開啓會話保持
  2. WAF：無特殊配置，域名直接回源負載均衡IP

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

措施：嘗試修改輪詢算法爲WLC，會話保持時間調短。
然而這個優化措施效果並不明顯，因爲開啓了會話保持，那原有負載不均衡的狀況下，調整WRR算法到WLC的算法，沒有實現預期的WLC。

可是從另一個角度來講，若是源IP很是分散的場景下，即便有會話保持，理論上仍是應該在通過一個較長的時間段以後，依然可以到達均衡。
這裏因爲是使用WAF的回源地址進行訪問，因此對負載均衡來講，客戶端的公網IP地址是固定的，一直是固定的幾個；從而調整WLC+會話保持的調整收效甚微。

問題點2：會話保持模板刷新問題

措施：嘗試關閉會話保持。
稍有成效：關閉會話保持後，通過一段時間的通訊，4臺ECS初步的開始均衡，可是到了一個固定值以後；沒有繼續均衡，一直保持着1:2的狀態。
這裏有2個知識點：
一、WLC算法的計數開始是從調整爲這個算法的時間點開始的；那麼若是歷史開始就出現不均衡，那麼開啓後仍是會不均衡的。
二、因爲WAF的回源地址與SLB的通訊一直在，沒有斷過因此歷史的會話保持的效果依然存在，已經會話保持的IP，依然會發給對應負載均衡的RS，致使不均衡。

推薦的解法爲：使用負載均衡的權重功能，將鏈接數多的機器的權重調低，待4臺機器的鏈接數基本均衡後，將RS的權重都調整爲一致。

原文連接
本文爲雲棲社區原創內容，未經容許不得轉載。