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

負載均衡（SLB）使用最佳實踐.

負載均衡（Server Load Balancer，下文簡稱 SLB）的引入，可以降低單台雲服務器 ECS（下文簡稱 ECS）出現異常時對業務的衝擊，提升業務的可用性。同時，結合彈性伸縮服務，通過動態調整後端服務器，可以快速對業務進行彈性調整（擴容或縮容），以快速應對業務的發展。

本文，會先對 SLB 的使用限製和常見誤區進行說明，然後介紹 SLB 的使用最佳實踐。

SLB 基礎原理

在開始使用 SLB 之前，建議您務必閱讀如下文章，了解 SLB 的相關基礎原理：

• 負載均衡技術原理淺析
• 負載均衡健康檢查原理淺析
• 負載均衡網絡流量路徑說明
• 負載均衡高可用概要說明

SLB 使用限製

在使用 SLB 進行業務部署之前，請您務必了解 SLB 的相關使用限製，以免對後續使用造成困擾或對業務造成影響。

產品與業務規格限製

SLB 的相關資源或功能存在限製，部分可以通過提交工單申請調整。部分則沒有例外，無法調整。詳細說明，可以參閱 SLB 使用限製。

另外，後續阿裏雲會推出性能保障型實例，對實例性能提供保障，用戶可配置和查詢其具體的性能指標，並可查看其實時運行數據。相關說明可以參閱 產品文檔。

技術限製

SLB 在技術層麵還在逐步增強和完善，截止本文發稿，還存在如下技術限製：

• 在 4 層（TCP 協議）服務中，不支持添加進後端雲服務器池的 ECS 既作為 Real Server，又作為客戶端向所在的 SLB 實例發送請求。因為，返回的數據包隻在雲服務器內部轉發，不經過負載均衡，所以通過配置在 SLB 後端的 ECS 去訪問其 VIP 是不通的。
• 僅支持 TCP/UDP（4 層） 和 HTTP/HTTPS（7 層） 這 4 種協議。
• 後端服務器僅支持 ECS，不支持第三方雲服務器。
• 僅支持輪詢（RR）、加權輪詢（WRR）和最小加權連接數（WLC）這 3 中調度算法。
• 不支持 7 層 SSL Session 超時時間的調整。當前全局統一為 300s。
• 不支持 7 層 HTTP Keep-alive 超時時間的調整。當前配置為 15s。
  • 說明：如果客戶端訪問 SLB HTTP 監聽時使用長連接, 那麼這條連接最長的空閑時間為 15 秒, 即如果超過 15 秒沒有發送任何 HTTP 請求, 這條連接將會被 SLB 主動斷開。如果您的業務可能會出現超過 15 秒的空閑, 需要從業務層麵檢測連接的斷開並重新發起連接。
• 不支持轉發超時時間的調整：
  • 當前配置： TCP 900s，UDP 300s，HTTP 60s，HTTPS 60s
  • 上述配置是指 SLB 服務端從後端接收數據並進行轉發的超時時間，並非健康檢查超時時間間隔。如果超時，通常會向客戶端返回 504 錯誤碼。
• 金融雲 SLB 基於安全性考慮，僅允許開放特定的端口：80，443，2800-3300，6000-10000，13000-14000

SLB 常見誤區

從曆史案例看，用戶在 SLB 的規劃和使用過程中有很多常見誤區。接下來逐一說明。

誤區：SLB 後端隻需添加一台 ECS ，確保鏈路能跑通即可

用戶在 SLB 後端隻添加一台服務器時，雖然鏈路能跑通，客戶端也能正常訪問。但卻失去了 SLB 消除 ECS 單點的基本能力。如果這台僅有的 ECS 出現異常，那邊整個業務訪問也會出現異常。

建議：至少在 SLB 後端加入兩台以上 ECS。以便單一服務器出現異常時，業務還能持續正常訪問。

誤區：後端 ECS 能正常訪問，但 SLB 無法訪問，則說明 SLB 出現了異常

用戶通過 SLB 訪問業務出現異常。但 hosts 綁定後端 ECS 的公網 IP 能正常訪問。用戶據此推斷後端業務是正常的，是 SLB 服務端出現異常導致業務訪問異常。

其實，由於負載均衡的數據轉發和健康檢查都是通過內網進行的。所以，從後端 ECS 的公網 IP 進行對比訪問測試，並沒有可比性，並不能反應真實訪問情況。

建議：出現異常時，在後端 ECS 之間，通過內網 IP 做對比訪問測試。

誤區： SLB 的 VIP 能 ping 通就說明配置是正常的

用戶通過 ping SLB 的 VIP 地址來判斷 SLB 服務的有效性。

其實，這種測試非常不可靠。因為 ping 響應是由 SLB 服務端直接完成的，與後端 ECS 無關。所以，正常情況下：

• 隻要配置了任意監聽，即便相應監聽處於異常狀態，SLB VIP ping 也是正常的。
• 相反，如果 SLB 沒有配置任何監聽，其 VIP 是 ping 不通的。

建議：對於 4 層服務，通過 telnet 監聽端口進行業務可用性測試；對於 7 層服務，通過實際的業務訪問進行可用性測試。

誤區：已經調整了健康檢查間隔，結果還會出現訪問超時

用戶反饋已經調大了健康檢查的最大間隔時間，但客戶端訪還是由於訪問超時收到 504 錯誤。

其實，雖然健康檢查及業務轉發都是由 SLB 服務端相同的服務器承載，但卻是完全不同維度的處理邏輯。來自客戶端的請求，經由 SLB 轉發給後端 ECS 後，SLB 服務端會有接收數據的超時窗口。而另一方麵，SLB 服務端持續的對後端 ECS 根據檢查間隔配置進行健康檢查。這兩者之間沒有直接關係，唯一的影響是在後端 ECS 健康檢查失敗後，SLB 不會再對其進行數據轉發。

建議：客戶端訪問超時時，結合業務與 SLB 默認超時時間進行比對分析；健康檢查超時時，結合健康檢查與業務超時時間進行比對分析。

誤區：從後端日誌看，健康檢查間隔與監聽配置的間隔時間不一致

用戶反饋通過 SLB 後端 ECS 的業務日誌進行統計分析，發現健康檢查的間隔非常短，與之前在創建監聽時配置的健康檢查間隔時間不一致。

這個問題在文檔 負載均衡健康檢查原理淺析 有相關說明：LVS 集群內所有節點，都會獨立、並行的遵循該屬性去對後端 ECS 進行定期健康檢查。由於各 LVS 節點的檢查時間並不同步，所以，如果從後端某一 ECS 上進行單獨統計，會發現來自負載均衡的健康檢查請求在時間上並不會遵循上述時間間隔。

建議：如果健康檢查頻率過高對業務造成影響，可以參閱知識點 健康檢查導致大量日誌的處理 進行處理。

誤區：大量健康檢查形成 DDoS 攻擊，導致服務器性能下降

用戶認為 SLB 服務端使用上百台機器進行健康檢查，大量健康檢查請求會形成 DDoS 攻擊，造成後端 ECS 性能降低。

實際上，無論何種模式的健康檢查，其規模均不足以達到類似於 DDoS 攻擊的量級：SLB 集群會利用多台機器（假定為 M 個，個位數級別），對後端 ECS 的每個服務監聽端口 （假定為 N 個） ，按照配置的健康檢查間隔（假定為 O 秒，一般建議最少 2 秒）進行健康檢查。以 TCP 協議健康檢查為例，那麼每秒由健康檢查產生的 TCP 連接建立數為：M*N/O。

從該公式可以看出，M 和 N 都是固定的，而且值很小。所以，最終健康檢查帶來的每秒 TCP 並發請求數，主要取決於創建的監聽端口數量。所以，除非有巨量的監聽端口，否則由健康檢查產生的連接請求，根本無法達到 SYN Flood 的攻擊級別，實際對後端 ECS 的網絡壓力也極低。

建議： 如果健康檢查頻率過高對業務造成影響，可以參閱知識點 健康檢查導致大量日誌的處理 進行處理。

誤區：用戶為了降低健康檢查的影響，將健康檢查間隔設置得很長

用戶為了降低健康檢查對業務的影響，將檢查間隔時間設置得很長。

這樣配置會導致當後端 ECS 出現異常時，負載均衡需要經過較長時間才能偵測到後端 ECS 出現不可用。尤其是當後端 ECS 間歇性不可用時，由於需要【連續多次】檢測失敗時才會移除異常 ECS。所以，檢查間隔過長，會導致負載均衡集群可能根本無法發現後端 ECS 不可用。

建議： 如果健康檢查頻率過高對業務造成影響，可以參閱知識點 健康檢查導致大量日誌的處理 進行處理。

誤區：移除服務器與權重置零的效果是一樣的

用戶在進行業務調整時，認為直接將服務器從 SLB 後端移除，或將其權重置零即可，兩者效果是一樣的。

其實，兩者有很大區別，相關操作對業務的影響也不一致：

• 移除服務器：已經建立的連接會一並中斷，新建連接也不會再轉發到該 ECS。
• 權重置零：已經建立的連接不會中斷，直至超時或主動斷開。新連接不會轉到該 ECS。

建議：在業務調整或服務器維護時，提前將相應服務器的權重置零，直至連接持續衰減至零。操作完成後，再恢複權重配置，以降低對業務的影響。

誤區：單個連接就能達到監聽配置的帶寬峰值

SLB 在創建監聽時可以指定帶寬峰值。但用戶通過單一客戶端進行測試時，發現始終無法達到該峰值。

由於 SLB 是基於集群方式部署和提供服務的。所以，所有前端請求會被均分到集群內不同的 SLB 服務器上進行轉發。相應的，在監聽上設定的帶寬峰值也會被平分後設定到各服務器。因此，單個連接下載的流量上限公式為：

單個連接下載峰值=設置的負載均衡總帶寬/(N-1) 
*注：N 為流量轉發分組個數，當前值一般為 4

示例：
假設在控製台上設置的帶寬峰值為 10Mb，那麼單個客戶端可下載的最大流量為： 10/(4-1)≈3.33Mb

建議：建議在配置單個監聽的帶寬峰值時，根據實際的業務情況並結合上述實現方式設定一個較為合理的值，從而確保業務的正常對外服務不會受到影響和限製。

SLB 使用最佳實踐

接下來，結合 SLB 的產品特性與曆史案例，從多個維度闡述使用 SLB 的最佳實踐。

設計業務架構

注：內網環境下，不支持多可用區，隻看圖例的單邊即可。

SLB 在公網環境下的典型業務架構如上圖所示。基於多可用區特性，當主可用區出現異常時，SLB 會自動將流量切換到備可用區。但在實際的業務架構設計過程中，建議關注如下要點：

• 實例類型與計費方式

  • 如果隻用於內部服務分發，則創建私網實例即可。
  • 按流量計費，適用於波峰波穀效應明顯的業務。
  • 按帶寬計費，適用於帶寬較為平穩的業務。

• 區域與多可用區

  • 為了降低延遲，建議選擇離您客戶最近的地域進行 SLB 部署。
  • 並非所有區域都支持多可用區特性（具體支持情況以您在控製台所見為準），請您結合業務情況選擇合適的可用區。
  • 在配合使用多可用區特性時，後端 ECS 也必須**同時**在相應的主備可用區部署，才能保障出現異常時，相應可用區有 ECS 能進行業務承載。

配置監聽

如上圖所示，SLB 支持創建多種協議監聽，然後按轉發策略，將前端業務請求轉發到後端多種邏輯服務器集。在 SLB 服務配置的各主要步驟中，請關注如下要點。

選擇監聽協議

SLB 支持創建 TCP/UCP/HTTP/HTTPS 這 4 種協議的監聽。您可參考以下表格，根據業務情況選擇適合的協議創建監聽：

補充說明

• 並非隻要 Web 網站就必須使用 HTTP 協議。大部分沒有特殊 HTTP 要求的 Web 網站，使用 TCP 監聽 80 端口就可以滿足業務需求。
• SLB 集群采用 LVS 和 Tengine 實現。其中 4 層監聽（TCP/UDP）經過 LVS 後直接到達後端服務器，而 7 層監聽（HTTP/HTTPS）經過 LVS 後，還需要再經過 Tengine 轉發，最後達到後端服務器，由於比 4 層多了一個處理環節。因此，7 層監聽的性能相對要差一些。

選擇後端服務器集模式

SLB 後端服務器支持按 3 種邏輯創建服務器集。要點如下：

建議

• 按業務邏輯創建不同的虛擬服務器組，然後創建相應的監聽與之對應。
• 無論創建何種服務器集合，均結合 SLB 多可用區特性，同時加入位於不同可用區的服務器，以實現跨可用區容災。
• 設置過多轉發規則會增加業務維護的複雜度，建議盡量精簡策略條目。

選擇轉發策略

權重代表相應服務器所承載的業務的相對占比，而非絕對值。當前 SLB 支持 3 種轉發策略，其使用場景及要點如下：

示例：假設有 100 個新增連接，則在不同的調度算法下，不同服務器的分配連接數示意如下：

配置健康檢查

健康檢查用於實時探測後端 ECS 上的業務可用性，以避免新增連接被分發到異常服務器對業務造成影響。由於是 SLB 依賴的核心服務，所以 4 層協議（TCP/UCP）的健康檢查無法關閉。

在配置健康檢查時，注意如下要點：

• 根據業務情況合理選擇 TCP 或 HTTP 模式健康檢查
  • TCP 模式健康檢查隻能檢查端口的可用性，對 7 層 HTTP 狀態無法感知。所以，Web 類 7 層業務建議配置 HTTP 模式健康檢查。
  • TCP 模式健康檢查由於在連接建立後即主動發送 RST 斷開連接，所以可能會導致業務層麵認為是非正常中斷，導致產生大量相關聯的錯誤日誌。該問題可以參閱 健康檢查導致大量日誌的處理 進行處理。
  • 如果使用 HTTP 健康檢查模式，建議合理調整後端日誌配置，避免健康檢查 HEAD 請求過多對 IO 性能造成影響。
• 合理配置健康檢查間隔 根據實際業務需求配置健康檢查間隔，避免因為健康檢查間隔過長導致無法及時發現後端 ECS 出現問題。具體請參考：健康檢查的相關配置，是否有相對合理的推薦值？
• 合理配置檢查端口與檢查 URL
  • 對於 4 層 TCP 協議，由於虛擬服務器組可以由後端 ECS 不同的端口承載業務，因此在配置健康檢查時不要設置檢查端口，而應該"默認使用後端服務器的端口進行健康檢查"。否則可能導致後端 ECS 健康檢查失敗。
  • 對於 7 層 HTTP 協議，使用虛擬服務器組合轉發策略時，確保健康檢查配置策略中的 URL 在後端每台機器上都可以訪問成功。
  • 使用 HTTP 模式健康檢查時，不要對根目錄進行檢查。建議配置為對某個靜態頁麵或文件進行檢查以降低對主頁的衝擊。但是，相應的，這可能會導致誤判：健康檢查 URL 雖然訪問是正常的，但主頁實際上已經出現異常。
• UDP 健康檢查 當前 UDP 協議健康檢查可能存在服務真實狀態與健康檢查不一致的問題：
  • 如果後端 ECS 服務器是 Linux 服務器，在大並發場景下，由於 Linux 的防 ICMP 攻擊保護機製，會限製服務器發送 ICMP 的速度。此時，即便服務已經出現異常，但由於無法向前端返回 “port XX unreachable” 報錯信息，會導致負載均衡由於沒收到 ICMP 應答進而判定健康檢查成功，最終導致服務真實狀態與健康檢查不一致。
  • 如果相應服務器非正常關機，由於也不會返回 “port XX unreachable” 報錯信息。所以也會導致健康檢查處於"正常"狀態的誤報。

選擇與配置後端 ECS

在後端 ECS 的選擇與配置時，注意如下要點：

• 在同一個服務器集中，同時加入不同可用區的服務器，以實現同城容災
• 根據服務器規格的差異，配置與之成正比的權重
• SLB 後端最少配置兩台以上 ECS，以避免單台 ECS 出現異常導致整個業務也出現異常
• 後端 ECS 建議無狀態部署：即隻用於計算，而數據調用與存儲後連至後端的 OSS、RDS 等公共服務。這樣可以無需為 ECS 之間的數據同步問題而困擾。
• 建議基於相同的鏡像或自定義鏡像創建後端 ECS 服務器，以保障配置的一致性。
• 後端 ECS 歸屬安全組及係統內部防火牆必須對 SLB 服務端地址段進行訪問放行。

調整後端 ECS 的操作建議

新增後端服務器

在往 SLB 內新增服務器時，注意如下要點：

• 建議新增服務器時，將權重置零，在確保業務正常運行後，再調整權重使其上線。
• 如果業務是長連接，在新增服務器時，建議先將相應監聽的調度算法修改為輪詢模式，然後逐步調高新增服務器的權重，以降低對該新增服務器的過高衝擊。

調整、維護業務和後端服務器

在後端 ECS 服務器的日常調整、維護過程中，注意如下要點：

• 選擇合適的業務窗口，定期對後端 ECS 進行重啟操作（操作前先創建快照進行備份），以便應用係統補丁，並主動觸發、感知係統內部錯誤導致的服務器無法正常啟動等問題。
• 業務更新或係統維護時建議的操作步驟： 1.將相應 ECS 的權重置零。此時，已建立的連接不受影響，新增連接不會再分發到該服務器。 2.周期性的在係統內通過 netstat/ss 等指令，確保已建立連接逐步自動斷開，衰減置零。如果客戶端有自動重連機製，則根據業務情況也可以忽略本步驟。 3.對服務器進行快照備份。 4.進行業務調整、服務器配置、重啟等操作。 5.操作完畢後，確認業務重新正常上線。然後逐步調高服務器權重，使其重新上線。 6.逐一對服務器集內所有服務器按上述步驟進行維護。

移除服務器

如果確認服務器不再使用，不建議直接移除服務器。而是參閱前述步驟，將相應服務器權重置零。待已建立連接全部正常斷開後，再移除該服務器。

常見問題的排查思路

SLB 在使用過程中的常見問題與排查思路可以參閱下列文檔，本文不再詳述：

• 健康檢查異常的排查思路
• 負載均衡返回 HTTP 500/502/504 錯誤的處理
• 後端 ECS 負載不均衡問題的處理

典型案例

後端 ECS 負載不均

問題場景：
後端 ECS 規格均一致，但其中幾台服務器的 PPS 一直非常高。而新加入的服務器，相對負載非常低。
業務高峰期，相關服務器健康檢查異常，導致服務器下線，並進一步導致其它服務器負載升高，引發整個 SLB 後端出現雪崩式異常，業務受到嚴重影響。

排查思路：
1. 業務監聽使用 WRR 調度算法，在 SLB 服務端統計，在單位時間內分發到各服務器的連接數是均衡的。
2. 異常服務器上的連接數持續居高不下，嚐試調高 OS 層麵的 TCP 連接數限製等配置，無明顯效果。
3. 和客戶交流，結合業務分析，相關連接來源正常，都是正常的業務連接。但業務場景是物聯網的監控數據上報，使用的是長連接。所以除非主動斷開相關連接，否則相關連接會持續堆積。

應對措施：

1. 將負載較低的服務器的權重值調低。
2. 將監聽的調度算法修改為 WLC。
3. 將異常服務器的權重值置零。
4. 將負責較低的服務器的權重值逐步調高。

以上步驟用於將負載逐步轉移到新加入的服務器，並避免對新增服務器及異常服務器的衝擊。

1. 待異常服務器的連接數下降到合理水平後，將其重新上線（重新配置權重）。
2. 由於後端服務器負載總體偏高，導致業務高峰期多台服務器無法滿足業務需求，出現雪崩式異常。所以，同步建議客戶對 SLB 後端服務器進行擴容。

最後更新：2017-05-11 12:01:53

  上一篇：  基於Ansible+Docker快速實現DCOS雲平台部署

  下一篇：  八年數據庫轉型之路：技術易改，匠心永存