Maxkit: 三種 LVS 的模式：LVS-NAT、LVS-TUN、LVS-DR

LVS(Linux Virtual Server) 是基於 Layer 4 的負載均衡，不支持複雜特性的負載均衡，效率比 Layer 7 高，nginx、haproxy都是 Layer 7 的負載均衡，可以根據特性進行負載均衡，比較靈活。

LVS 是利用iptables的 INPUT chain，攔截訪問集群服務的資料封包，修改進入 server 的資料 header，不同類型更改 header 的方式也不一樣，轉發給後端的RS，最後RS處理請求後再將結果回傳給 client。

LVS 有三種模式：LVS-NAT、LVS-TUN、LVS-DR

LVS-NAT

Virtual Server via NAT

LVS-NAT 的實體 Server 架構圖：

這個是通過網路地址轉換的方法來實現的。首先 Load Balancer 接收到客戶的request 時（目的IP為VIP），根據調度演算法決定將 request 發送給哪個後端的 Real Server。然後把客戶端發送的請求數據包的目標IP地址及端口改成後端真實服務器的IP地址（Real IP），這樣 Real Server 就能夠收到客戶的 request 了。Real Server 處理完成後，查看 default gateway（NAT模式下我們需要把 Real Server 的 default gateway 設置為 Load Balancer。）把 reqsponse 發送給 Load Balancer，Load Balancer 把 source address 改成虛擬地址（VIP）然後發送回給客戶端。

VS-NAT基本性質：

cluster nodes (Real Server) 和 Load Balancer 在同一網段
Real Server 的 RIP 地址一般為 Private IP
Load Balancer 負責處理 client 和 Real Server 之間的所有進出的封包
Real Server 將 Load Balancer 的內網 IP 作為 default gateway
只需要在 Load Balancer 上配置一個 Public IP 就可以了
Load Balancer 支援 Port Mapping
Real Server 可以使用任何一種 OS
因為 Load Balancer 負責所有資料的進出，所以在大型應用場景中，Load Balancer 容易成為系統瓶頸。因為 NAT 的關係，Load Balancer 必須將 reqeust 和 response 進行 IP 改寫，因此網站訪問量比較大的時候 Load Balancer 會有比較大的瓶頸，一般要求最多只能10-20台節點

LVS-TUN

Virtual Server via IP Tunneling

和 NAT 模式不同的是，Load Balacner 和 Real Server 之間的傳輸不用改寫IP地址。而是把 client request 封裝在一個 IP Tunnel 裡面，然後發送給 Real Server，Real Server 接收到之後解開 IP Tunnel 後，處理結果會直接把通過自己的 Pulbic IP 發送給 client，不用經過 Load Balancer。

VS-TUN 的基本性質：

cluster nodes 可跨越 Internet (處於不同的物理網路中)
Real Server 的 Real IP 必須是 Public IP
Load Balancer 只需要處理 reqeust，response 由 Real Server 直接發送給 client
只有支援 Tunnel 功能的 OS 才能用於 Real Server
Load Balancer 不支援 Port Mapping
Real Server 的 default gateway 不能指向 Load Balancer
Real Server 主機需要綁定VIP地址在LO接口上(各個服務器有相同的VIP和單獨的RIP)

LVS-DR

Virtual Server via Direct Routing

DR模式會改寫request的目標 MAC 地址，將 request 轉發給 Real Server，而 Real Server 的處理結果會直接回傳給 Client。當客戶端發送 request 給 cluster 提供的服務時，request 會直接發往 Load Balancer，Load Balancer 會檢查 request 中的 destination address 和 port number，如果和服務匹配，那麼就會根據調度算法來選擇一個 Real Server 處理 request 並且將此次連記入 hash table 中。然後 Load Balancer 轉發 request 給選擇的 Real Server。當連接結束或超時後，這個連接記錄將從 hash table 中刪除。

VS-DR的基本性質：

Load Balancer 與 Real Server 必須在同一個物理網路中；
Real Server 的 RIP 地址不必是私有地址，如可為 Public IP 可以實現遠端管理
Load Balancer 只負責處理 request，response 由 Real Server直接發往 client
Real Server 不能將 Gateway 指向 Load Balancer，而是直接配置為上層路由的 gateway
Load Balancer 不支援 port mapping
大多數 OS 都可以用在 Real Server
Real Server 主機需要綁定 VIP 地址在 LO 接口上 (有相同的VIP和單獨的RIP)，並且需要設定 ARP 抑制(由於網絡接口都會進行ARP廣播回應，但 cluster 的其他機器都有這個 VIP 的 lo port，都回應就會衝突。所以我們需要把 Real Server 的 lo 接口的 ARP 回應關閉掉)

LVS 的調度演算法

LVS集群的負載調度

LVS Scheduling Method LVS的調度方法可以分為兩大類：

1.Fixed Scheduling Method 靜態調度方法

RR 輪詢，假設所有服務器處理性能均相同時使用，當所有 Server 的性能不一，request 服務時間變化比較大時，輪叫調度算法容易導致服務器間的負載不平衡。
WRR 加權輪詢，假設服務器 A 的權值為 1，B 的權值為 2，則表示服務器B的處理性能是A的兩倍。加權輪詢調度算法是按權值的高低和輪詢方式分配請求到各服務器。
DH destination address hash
SH source address hash，SH 與 DH 可用在 firewall clustering 裡面。

2.Dynamic Scheduling Method 動態調度方法

LC (最少連接) 把新的連接請求分配到當前連接數最小的服務器，當各個服務器的處理能力不同時，該算法並不理想，因為TCP連接處理請求後會進入TIMEWAIT狀態，TCP的TIMEWAIT一般為2分鐘，此時連接還佔用服務器的資源，所以會出現這樣情形：性能高的服務器已處理所收到的連接，連接處於TIME_WAIT狀態，而性能低的服務器忙於處理所收到的連接，還不斷地收到新的連接請求。
WLC 加權最少連接
SED Shortest Expected Delay Scheduling 最少期望延遲指定期望中最短 delay 時間的 Real Server，expected delay 是以 (Ci + 1) / Ui 計算，i 是第 i 個 server，Ci 是第 i 個 server 的連線數，Ui 是固定的服務速度，也可以視為加權值，服務速度越短，計算出來的結果越大。
NQ Never Queue Scheduling 從不排隊調度方法如果有 idle server，就會馬上選擇這個 server，如果沒有 idle server，就採用上面的 SED (Shortest Expected Delay Scheduling) 演算法，找到適合的 server。
LBLC Locality-Based Least Connections Scheduling 基於局部性的最少鏈接調度針對 request 的 destination IP address 的負載均衡調度，目前主要用於Cache cluster，因為在 Cache 集群中，client request 的目標IP地址是變化的。這裡假設任何後端服務器都可以處理任一請求，算法的設計目標是在服務器的負載基本平衡情況下，將相同目標IP地址的request 轉發到同一台服務器，來提高各台服務器的訪問局部性和主存Cache命中率，從而整個集群系統的處理能力。
LBLCR Locality-Based Least Connections with Replication Scheduling 帶複製的基於局部性最少鏈接調度也是針對目標IP地址的負載均衡，目前主要用於Cache集群系統。它與LBLC算法的不同之處是它要維護從一個目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一台服務器的映射。對於一個“熱門”站點的服務請求，一台Cache 服務器可能會忙不過來處理這些請求。這時，LBLC調度算法會從所有的Cache服務器中按“最小連接”原則選出一台Cache服務器，映射該“熱門”站點到這台Cache服務器，很快這台Cache服務器也會超載，就會重複上述過程選出新的Cache服務器。這樣，可能會導致該“熱門”站點的映像會出現在所有的Cache服務器上，降低了Cache服務器的使用效率。LBLCR調度算法將“熱門”站點映射到一組Cache服務器（服務器集合），當該“熱門”站點的請求負載增加時，會增加集合裡的Cache服務器，來處理不斷增長的負載；當該“熱門”站點的請求負載降低時，會減少集合裡的Cache服務器數目。這樣，該“熱門”站點的映像不太可能出現在所有的Cache服務器上，從而提供Cache集群系統的使用效率。

三種模式的比較

三種 IP 負載均衡技術的優缺點比較

選項	VS/NAT	VS/TUN	VS/DR
Server OS	任意	OS 要支援 IP Tunnel (目前只有 linux 有支援)	多數(支援 Non-ARP )
服務器網路	LAN	LAN/WAN	LAN
Real Server 數目(100M網絡)	10-20	100	100
Server 的網路 Gateway	Load Balancer	自己的路由	自己的路由
效率	一般	高	最高
擴展性	差，所有 traffic 都要經過 Load Balancer	好，但需要建立 IP Tunnel，適合用在跨越 Data Center 的環境	好，但要求 Load Balancer 跟 Real Server 在同一個 LAN 裡面
Server 安全性	好，Real Server 使用內部 IP，隱密	差，Real Server 使用 Public IP	差，Real Server 使用 Public IP
Public IP 需求	需要一個 IP 作為 Server VIP(Virtual IP)	除了 VIP 之外，每個 Server 都需要有合法的 IP 可直接連結到客戶端	除了 VIP 之外，每個 Server 都需要有合法的 IP 可直接連結到客戶端