LVS –負載均衡基礎

一 負載均衡的五種解決方案

1 http重定向

HTTP重定向就是應用層的請求轉發。用戶的請求其實已經到了http重定向負載均衡服務器，服務器根據算法要求用戶重定向，用戶收到重定向請求后，再次請求真正的集群。

優點：簡單

缺點：性能較差

2 DNS域名解析負載均衡

DNS域名解析負載均衡就是在用戶請求DNS服務器，獲取域名對應的IP地址時，DNS根據服務器直接給出負載均衡后的服務器IP。

優點：交給DNS，不用我們去維護負載均衡服務器

缺點：當一個服務器掛了，不能及時通知DNS，而且DNS負載均衡的控制權在域名服務商那里，網站無法做出更多的改善和更強大的管理

3 方向代理服務器

在用戶的請求到達反向代理服務器時（已經到達網站機房），有反向代理服務器根據算法轉發到具體的服務器。常用的有Apache、Nginx都可以充當方向代理服務器。

優點：部署簡單

缺點：代理服務器可能成為性能瓶頸，特別是一次上傳大文件

4 IP層負載均衡

在請求到達負載均衡器后，負載均衡器通過修改請求的IP地址，從而實現請求的轉發，做的負載均衡。

優點：性能更好

缺點：負載均衡器的帶寬成為瓶頸

5 數據鏈路層負載均衡

在請求到達負載均衡器后，負載均衡器通過修改請求的Mac地址，從而做到負載均衡，與IP負載均衡不一樣的是，當請求訪問完服務器后，直接返回給用戶。而無需再經過負載均衡器。

二 集群調度算法

1.靜態算法

只根據算法進行調度 而不考慮后端服務器的實際連接情況和負載情況

（1）rr 輪詢調度算法

顧名思義，就是輪詢分發請求

優點：實現簡單

缺點：不考慮每臺服務器的處理能力

（2） wrr 加權輪詢調度算法

我們給每個服務器設置權值（weight），負載均衡調度器根據權值調度服務器，服務器被調用的次數跟權值成正比。

優點：考慮了服務器處理能力不同

缺點：

（3）sh 原地址散列

提取用戶IP，根據散列函數得出一個key，再根據靜態映射表，查處對應的value，既目標服務器IP。過目標機器負荷，則返回空。

（4） dh 目標地址散列（Destination Hash）

根據請求的目標IP地址，作為散列鍵(HashKey)從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。

2 動態算法

前端的調度器會根據后端真實服務器的實際連接情況來分配請求

（1）LC：最少鏈接（Least Connections）

優先把請求轉發給連接數最少的服務器。

優點：使得集群中各個服務器負載更加均勻

（2）WLC：加權最少連接(默認采用的就是這種)（Weighted Least Connections）

在LC的基礎上，為每臺服務器加上權值，算法為：（活動連接數 * 256 + 非活動連接數）/ 權值。計算出來值小的服務器優先被選擇。

優點：可根據服務器 的能力分配請求

（3）SED：最短延遲調度（Shortest Expected Delay ）

在WLC基礎上改進，Overhead = （ACTIVE+1）*256/加權，卻別是不再考慮非活動狀態，把當前處于活動狀態的數目+1來實現，數目最小的，接受下次請求，+1的目的是為了考慮加權的時候，非活動連接過多缺陷：當權限過大的時候，會倒置空閑服務器一直處于無連接狀態。算法為：（活動連接數 + 1 ）* 256 / 權值，同樣計算出來的值小的服務器優先被選擇。

（4）NQ永不排隊/最少隊列調度（Never Queue Scheduling NQ）

改進的SED算法，就是某個服務器連接數為零時，均衡器直接把請求轉發給它，無需經過SED的計算。

（5）LBLC：基于局部性的最少鏈接（locality-Based Least Connections）

基于局部性的最少鏈接調度算法是針對目標IP地址的負載均衡，目前主要用于Cache集群系統?該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器，若服務器不存在，或者該服務器超載且有服務器處于一半的工作負載，則用最少鏈接的原則選出一個可用的服務器，將請求發送到該服務器?

（6）LBLCR：帶復制的基于局部性最少連接（Locality-Based Least Connections with Replication）

均衡器根據請求的目的IP地址，找出該IP 地址最近使用的”服務器組”，注意，并不是某個服務器，然后采用最少連接數從給組中挑出具體的某臺服務器出來，把請求轉發之。若服務器超載，那么根據最少連接數算法，在集群的非本”服務器組”的服務器中，找出一臺服務器來，加入本服務器組，然后把請求轉發之。

三 lvs集群的類型

lvs-nat：修改請求報文的目標IP；多目標IP的DNAT；

lvs-dr：操縱封裝新的MAC地址；

lvs-tun：在原請求IP報文之外新加一個IP首部；

lvs-fullnat：修改請求報文的源和目標IP；

1 lvs-nat

負載均衡器接受用戶的請求，轉發給具體服務器，服務器出來完請求后返回給負載均衡器，均衡器再重新返回給用戶。多目標IP的DNAT，通過將請求報文中的目標地址和目標端口修改為某挑出的RS的RIP和PORT實現轉發；

（1）RIP和DIP必須在同一個IP網絡，且應該使用私網地址；RS的網關要指向DIP；

（2）請求報文和響應報文都必須經由Director轉發；Director易于成為系統瓶頸；

（3）支持端口映射，可修改請求報文的目標PORT；

（4）vs必須是Linux系統，rs可以是任意系統；

2 lvs-dr

負載均衡器接收用戶請求，轉發給具體服務器，服務器處理完成后直接返回給用戶。需要支持IP Tunneling 協議，難以夸平臺。通過為請求報文重新封裝一個MAC首部進行轉發，源MAC是DIP所在的接口的MAC，目標MAC是某挑選出的RS的RIP所在接口的MAC地址；源IP/PORT，以及目標IP/PORT均保持不變；

通過為請求報文重新封裝一個MAC首部進行轉發，源MAC是DIP所在的接口的MAC，目標MAC是某挑選出的RS的RIP所在接口的MAC地址；源IP/PORT，以及目標IP/PORT均保持不變；

Director和各RS都得配置使用VIP；

（1）確保前端路由器將目標IP為VIP的請求報文發往Director：

(a) 在前端網關做靜態綁定；

(b) 在RS上使用arptables；

(c) 在RS上修改內核參數以限制arp通告及應答級別；

arp_announce

arp_ignore

（2）RS的RIP可以使用私網地址，也可以是公網地址；RIP與DIP在同一IP網絡；RIP的網關不能指向DIP，以確保響應報文不會經由Director；

（3）RS跟Director要在同一個物理網絡；

（4）請求報文要經由Director，但響應不能經由Director，而是由RS直接發往Client；

（5）不支持端口映射；

3 lvs-tun

轉發方式：不修改請求報文的IP首部（源IP為CIP，目標IP為VIP），而是在原IP報文之外再封裝一個IP首部（源IP是DIP，目標IP是RIP），將報文發往挑選出的目標RS；RS直接響應給客戶端（源IP是VIP，目標IP是CIP）；

（1）DIP, VIP, RIP都應該是公網地址；

（2）RS的網關不能，也不可能指向DIP；

（3）請求報文要經由Director，但響應不能經由Director；

（4） 不支持端口映射；

（5） RS的OS得支持隧道功能；

4 lvs-fullnat

通過同時修改請求報文的源IP地址和目標IP地址進行轉發；

（1）VIP是公網地址，RIP和DIP是私網地址，且通常不在同一IP網絡；因此，RIP的網關一般不會指向DIP；

（2）RS收到的請求報文源地址是DIP，因此，只能響應給DIP；但Director還要將其發往Client；

（3）請求和響應報文都經由Director；

（4）支持端口映射；

注意：此類型默認不支持；