484      iPhone_iPad_Mac_apple

配置說明__產品簡介_負載均衡-阿裏雲

配置和管理一個負載均衡實例，主要涉及以下3部分的配置操作：

• 負載均衡實例屬性配置：定義負載均衡實例的類型。
• 負載均衡服務監聽配置：定義負載均衡實例的各項策略和轉發規則。
• 負載均衡後端 ECS 配置：定義負載均衡實例後端用來處理用戶請求的多個 ECS 實例。

負載均衡實例屬性配置

負載均衡實例名稱

用戶可以為其創建的負載均衡實例指定一個易於識別的名稱，如果用戶不指定，那麼係統將以該負載均衡實例的LoadBalancerId作為名稱進行展示，LoadBalancerId是識別用戶負載均衡實例的唯一標識，無法修改。

負載均衡實例類型

當前提供公網和私網2種類型的負載均衡供用戶選擇，用戶可根據其業務場景來選擇配置對外公開或對內私有的負載均衡服務，係統根據用戶的選擇分配公網或私網服務地址（IP）。

負載均衡服務地址

根據用戶選擇的負載均衡類型不同，係統會分配不同的服務地址給用戶。針對需要通過域名對外提供服務的應用，需要將域名解析到相應的公網服務地址上生效後即可通過域名訪問。

負載均衡服務監聽配置

前端協議/端口

• 協議：當前提供4層（TCP協議和UDP協議）和7層（HTTP和HTTPS協議）的負載均衡服務。
• 端口：用戶負載均衡實例對外或對內提供服務時用來接收請求並向後端服務器進行請求轉發的負載均衡係統前端端口，在同一個負載均衡實例內不可重複。

後端協議/端口

• 協議：當前提供4層（TCP協議和UDP協議）和7層（HTTP和HTTPS協議）的負載均衡服務。
• 端口：用戶負載均衡實例後端添加的一組用來處理外部或內部請求的ECS上開放的用來接收請求的後端端口，在同一個負載均衡實例內可重複。針對同一組後端ECS上部署多個應用服務的情況，當前負載均衡最多支持50個監聽配置規則。

調度算法

當前負載均衡支持加權輪詢，加權最小連接數，和輪詢3種模式的調度算法，對流量進行轉發。

• 加權輪詢模式會將訪問請求依序分發給分配了權重的後端ECS進行處理，後端ECS權重越高被分發的幾率也越大；
• 加權最小連接數模式會將訪問請求分發給當前連接數最小的一台後端ECS進行處理，後端ECS權重越高被分發的幾率也越大；
• 輪詢模式會將訪問請求依序分發給後端ECS進行處理。

使用虛擬服務器組

開啟配置後，用戶可在監聽維度上個性化定義服務器組，即實例下的不同監聽可使用不同的後端服務器組，可滿足按域名和URL轉發得個性化需求。

雙向認證

開啟配置支持在服務端和客戶端進行 HTTPS 雙向認證。

Gzip 數據壓縮

針對 7 層監聽，開啟配置支持對特定文件類型進行壓縮。

附加 HTTP 頭字段

針對 7 層監聽，自定義 HTTP/HTTPS 頭字段。

獲取來訪者真實IP

• 針對7層（HTTP協議）服務，由於采取替換HTTP頭文件IP地址的方式來進行請求轉發，所以後端雲服務器看到的訪問IP是負載均衡係統的本地IP而不是實際來訪者的真實IP。所以係統支持用戶采用X-Forwarded-For的方式獲取訪問者真實IP，係統默認開啟7層（HTTP協議）服務監聽的“獲取真實訪問IP”功能，不可關閉。針對常用的應用服務器的配置指引點擊這裏查看。
• 針對4層（TCP協議）服務，後端雲服務器將直接獲得來訪者的真實IP，所以無需采用其他手段獲取。

會話保持

用戶開啟會話保持功能後，負載均衡會把來自同一客戶端的訪問請求分發到同一台後端ECS上進行處理。針對7層（HTTP協議和HTTPS協議）服務，負載均衡係統是基於cookie的會話保持。負載均衡係統提供了兩種cookie處理方式：

• cookie植入，表示直接由負載均衡係統來分配和管理對客戶端進行的cookie植入操作，用戶在進行配置時需要指定會話保持的超時時間。

  說明：如果用戶配置了”植入 Cookie”方式的會話保持, 並且後端 RS 返回的 HTTP 狀態代碼為 4xx 時, SLB 不支持植入 Set-Cookie 頭部, 可能會導致會話保持失敗。後端 RS 返回的 HTTP 代碼在以下代碼中時, SLB 將植入會話保持所需頭部：200、201、204、206、301、302、303、304、307。

• cookie重寫，表示負載均衡係統會根據用戶自定義cookie名稱來分配和管理對客戶端進行的cookie植入操作，便於用戶識別和區分自定義的cookie名稱，從而有選擇的針對後端應用服務器上的不同應用設定會話保持規則，用戶在進行配置時需要指定相應的cookie名稱。針對多個域名配置不同會話保持規則的實現方法點擊這裏查看。

針對4層（TCP協議和UDP協議）服務，負載均衡係統是基於IP地址的會話保持。負載均衡會將來自同一IP地址的訪問請求轉發到同一台後端雲服務器進行處理。

健康檢查

• 用戶開啟健康檢查功能後，當後端某個ECS健康檢查出現問題時會將請求轉發到其他健康檢查正常的ECS上，而當該ECS恢複正常運行時，負載均衡會將其自動恢複到對外或對內的服務中。
• 針對7層（HTTP協議和HTTPS協議）服務，負載均衡係統的健康檢查機製為：默認由負載均衡係統通過後端ECS內網IP地址來向該服務器應用服務器配置的缺省首頁發起http head請求（缺省通過在服務監聽配置中指定的後端ECS端口進行訪問），返回200 OK後將視為後端ECS運行正常，否則視為後端ECS運行異常。如果用戶用來進行健康檢查的頁麵並不是應用服務器的缺省首頁，那麼需要用戶指定相應的URI。如果用戶對http head請求限定了host字段的參數，那麼需要用戶指定相應的URL。用戶也可以通過設定健康檢查的頻率、健康閾值和不健康閾值來更好的控製健康檢查功能。
• 針對4層（TCP協議和UDP協議）服務，負載均衡係統的健康檢查機製為：默認由負載均衡係統通過在服務監聽配置中指定的後端ECS端口發起訪問請求，如果端口訪問正常則視為後端ECS運行正常，否則視為後端ECS運行異常。
• 針對可能引起健康檢查異常的排查思路點擊這裏查看。
• 如果配置了虛擬服務器組，建議不要設置健康檢查的檢查端口。

關於TCP/HTTP/HTTPS健康檢查的參數配置，提供如下參考建議：

• 響應超時時間：5秒
• 健康檢查間隔：2秒
• 不健康閾值：3
• 健康閾值：3

在此配置下有利於用戶服務及應用狀態的盡快收斂：ECS健康檢查失敗響應時間（網絡有問題）：(2+5)×3=21秒如果用戶有更高要求，可以適當地降低響應超時時間值，但必須先保證自己服務在正常狀態下的處理時間小於這個值。ECS健康檢查成功響應時間：2×3=6秒

關於UDP健康檢查的參數配置，提供如下參考建議：

• 響應超時時間：10秒
• 健康檢查間隔：5秒
• 不健康閾值：6
• 健康閾值：6

在此配置下有利於用戶服務及應用狀態的盡快收斂：ECS健康檢查失敗響應時間（網絡有問題）：(5+10)×6=90秒如果用戶有更高要求，可以適當地降低響應超時時間值，但必須先保證自己服務在正常狀態下的處理時間小於這個值。ECS健康檢查成功響應時間：5×6=30秒

帶寬峰值

用戶可以針對監聽設定不同的帶寬峰值來限定後端ECS上的不同應用所能對外提供的服務能力。

帶寬峰值的設定規則：

• 一個負載均衡實例最多對應50個監聽，每個監聽可獨立設定限定規則；
• 單個監聽可限定5-1000Mbps範圍的帶寬峰值；
• 當單個監聽上限無法滿足用戶業務需求時，可以選擇不限帶寬峰值。

負載均衡後端ECS配置

對於添加到負載均衡實例後端的ECS，原則上不需要進行特別的配置。如果針對關聯到負載均衡 4層（TCP協議和UDP協議）服務的Linux係統的ECS，如果發現無法正常訪問，需要確保係統配置文件/etc/sysctl.conf的以下三項為0：

net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0

如果部署在同一內網網段下的ECS之間有通信需求，且發現有無法通信的情況存在，按照以下步驟檢查配置是否正確：

1. 檢查如下參數的配置是否正確：

   net.ipv4.conf.default.arp_announce =2
   net.ipv4.conf.all.arp_announce =2

2. 使用以下命令更新配置：

   sysctl –p

後端ECS權重

用戶可以指定後端服務器池內各ECS的轉發權重，權重越高的ECS將被分配到更多的訪問請求，用戶可以根據後端ECS的對外服務能力和情況來區別設定。

最後更新：2016-12-20 13:18:52

  上一篇： 為什麼雲數據庫 HybridDB 版的 OLAP 性能比 RDS 好？__使用管理常見問題_產品相關問題_雲數據庫 HybridDB-阿裏雲

  下一篇： 變更記錄__產品簡介_負載均衡-阿裏雲