【均衡負載之LVS 系列一】 - LVS 五種工做模式

本文主要闡述LVS的各類轉發模式，以CDN集羣爲例

當集羣服務能力遇到性能瓶頸，須要進行拓展時，有兩種解決思路：Scale-up 和 Scale-out，也稱做垂直擴展和水平擴展。

垂直擴展：提高單機處理能力。垂直擴展的方式又有兩種：

（1）加強單機硬件性能，例如：升級CPU，擴容硬盤及內存；
（2）提高單機架構性能，例如：使用Cache來減小IO次數，使用異步來增長單服務吞吐量，使用無鎖數據結構來減小響應時間；

在業務發展迅猛的早期，若是對成本不敏感，能夠採用 增長設備單機硬件能力 的方式來提升集羣的服務能力，但垂直拓展有個明顯缺點：單機設備能力有極限，而且隨着硬件設備能力提升對應的硬件成本會急劇增長，性價比低

水平擴展：增長服務器數量，線性擴充集羣。固然水平擴展對系統架構設計是有要求的，就CDN而言須要進行多層的均衡負載來實現。

常見的負載均衡

根據工做所在的協議層能夠分爲：

• 四層均衡負載：根據請求報文中IP和端口進行調度
• 七層均衡負載：根據請求報文中內容進行調度

根據軟硬件劃分

• 硬件均衡負載：
  F5 的 BIG-IP
  Citrix 的 NetScaler

這類硬件負載均衡器一般能同時提供四層和七層負載均衡，但同時也價格不菲。

• 軟件均衡負載
  基於四層：LVS，HaProxy，Nginx
  基於七層：Haproxy，Nginx，ATS（Apache Traffic Server），squid，varnish

LVS

以典型的四層均衡負載LVS爲例。因爲請求數據包須要通過LVS分配處理後到達後端RS，首先會想到經過相似於網關的NAT的方式來進行處理，分爲NAT、full NAT、ENAT三種模型，經過NAT的方式因爲請求包IP通過改寫，回包一樣須要根據映射表改寫回原IP，故數據流的兩個方向都要進行處理。若是要避免進行雙方向的數據處理就不能對IP包頭進行改寫，天然咱們會想到對更低的二層包信息進行改造，即網關將相應數據包指向LVS，LVS將數據包DIP對應的mac改成RS的mac，RS回包經過路由表選擇直接回給網關，因爲請求包數據量遠小於回包數據量，能大大下降LVS的壓力。除上述兩種方式外，還可經過封裝的方式將包分配（TUNNEL），下面咱們具體介紹各類模型的實現原理及優缺點

• DR模型 -- （Director Routing-直接路由）
• NAT模型 -- (NetWork Address Translation-網絡地址轉換)
• fullNAT -- （full NAT，雙向數據包都進行SNAT與DNAT）
• ENAT --（enhence NAT 或者叫三角模式/DNAT）
• IP TUN模型 -- (IP Tunneling - IP隧道)

幾個經常使用術語的縮寫

cip：Client IP，客戶端地址
vip：Virtual IP，虛IP
rip：Real IP，後端RS地址
RS: Real Server 後端真正提供服務的機器
LB： Load Balance 負載均衡器
LVS： Linux Virtual Server
sip： source ip，源IP
dip： destination ip，目的IP
NAT： Network Address Translation，網絡地址轉換
SNAT: Source Network Address Translation，源地址轉換
DNAT: Destination Network Address Translation，目的地址轉換

DR模型(Director Routing--直接路由)

如上圖所示基本流程(假設 cip 是200.200.200.2， vip是200.200.200.1）：

1. 請求流量(sip 200.200.200.2, dip 200.200.200.1) 先到達 LVS
2. 而後LVS，根據負載策略挑選衆多 RS中的一個，而後將這個網絡包的MAC地址修改爲這個選中的RS的MAC
3. LVS將處理事後的數據包丟給交換機，交換機根據二層MAC信息將這個包丟給選中的RS
4. 接收到數據包的RS看到MAC地址是本身的、dip也是本身的（VIP配置在lo），愉快地收下並處理，並根據路由表將回復包（sip 200.200.200.1， dip 200.200.200.2）返回給交換機
5. 回覆包（sip 200.200.200.1， dip 200.200.200.2）通過交換機直接回復給client（再也不走LVS）

能夠看到通過上面的流程，請求包到達LVS後，LVS只對包的目的MAC地址做了修改，RS將回包直接回給了client。
因爲LVS、RS都會接收處理到DIP爲VIP的數據包，因此VIP必須綁定在網卡上，考慮到vlan內不能有多個設備對同一VIP進行ARP廣播或應答，RS需將VIP配置在lo迴環網卡上，而且對ARP進行相應的配置。

優勢：

• DR模型下，LVS只需對請求的數據包進行處理，回包繞過LVS直接發給Client，大大下降了LVS的壓力（請求包遠少於數據包，而且只改二層mac信息）

缺點：

• LVS和RS必須在一個VLAN中（修改mac後數據包只在二層網絡中路由）
• RS需將VIP綁在lo，並對ARP進行特殊配置

綠色是請求包進來，紅色是修改過MAC的請求包

NAT模型(NetWork Address Translation - 網絡地址轉換)

nat模式的結構圖以下：

基本流程：

1. client發出請求（sip 200.200.200.2，dip 200.200.200.1）
2. 請求包到達lvs，lvs修改請求包爲（sip 200.200.200.2， dip 10.10.10.2）
3. 請求包到達rs， rs回覆（sip 10.10.10.2，dip 200.200.200.2）
4. 這個回覆包不能直接給client，由於sip不是200.200.200.1（vip）會被reset掉
5. 設置lvs爲網關，因此這個回覆包先走到lvs，lvs有機會修改sip
6. lvs修改sip爲VIP，修改後的回覆包（sip 200.200.200.1，dip 200.200.200.2）發給client

優勢：

• 配置簡單，通用性強
• 支持映射（NAT映射表）
• RIP能夠是私網IP，用於LVS與RS之間通信

缺點：

• LVS和RS必須在一個VLAN中（RS將LVS配置爲網關，若是不在一個子網回包會通過路由器網關直接路由走，LVS沒機會修改數據包）
• 進出流量都須要LVS進行處理，LVS容易成爲集羣瓶頸
• 須要將LVS配置爲RS的網關

注意這裏LVS修改進出包的(sip, dip)的時候只改了其中一個，進方向進行DNAT，出方向進行SNAT，要求LVS和RS必須在同一個vlan，限制了LVS集羣和RS集羣的部署靈活性，因此纔有接下來的full NAT。

full NAT模型(full NetWork Address Translation-所有網絡地址轉換)

基本流程（相似NAT）：

• client發出請求（sip 200.200.200.2 dip 200.200.200.1）
• 請求包到達lvs，lvs修改請求包爲（sip 200.200.200.1， dip rip） 注意這裏sip/dip都被修改了
• 請求包到達rs， rs回覆（sip rip，dip 200.200.200.1）
• 這個回覆包的目的IP是VIP(不像NAT中是 cip)，因此LVS和RS不在一個vlan經過IP路由也能到達lvs
• lvs修改sip爲vip， dip爲cip，修改後的回覆包（sip 200.200.200.1，dip 200.200.200.2）發給client

優勢：

• 解決了NAT對LVS和RS要求在同一個vlan的問題，適用更復雜的部署形式
• 不要求配置LVS爲網關（LVS與RS能夠經過三層通信）

缺點：

• RS看不到cip（NAT模式下能夠看到）
• 進出流量仍是都走的lvs，容易成爲瓶頸（跟NAT同樣都有這個問題）

爲何RS看不到CIP

RS接受到的數據包爲（sip 200.200.200.1， dip rip），只能看到sip對應的VIP，通常會將cip放入TCP包的Option中傳遞給RS，RS上通常部署本身寫的toa模塊來從Options中讀取的cip，這樣RS能看到cip了, 固然這不是一個開源的通用方案。

full NAT解決了NAT模式下須要同vlan的問題，可是仍是沒解決進出流量都走LVS的問題（LVS要修改進出的包），那麼有沒有一個方案可以像full NAT同樣不限制lvs和RS之間的網絡關係，出去的流量跟DR模式同樣也不走LVS呢？
有個方案，將回包方向的NAT處理放在RS上完成

ENAT模式(enhence NAT)

優勢：

• 不要求LVS和RS在同一個vlan
• 出方向流量不須要走LVS，減少對LVS壓力

缺點：

• 自定義方案，須要在全部RS上安裝ctk組件（相似full NAT中的toa）

基本流程：

1.client發出請求（cip，vip）
2.請求包到達lvs，lvs修改請求包爲（vip，rip），並將cip放入TCP Option中
3.請求包根據ip路由到達rs， ctk模塊讀取TCP Option中的cip
4.回覆包(RIP, vip)被ctk模塊截獲，並將回覆包改寫爲（vip, cip)
5.由於回覆包的目的地址是cip因此不須要通過lvs，能夠直接發給client

IP TUN模型(IP Tunneling - IP隧道)

基本流程：

• 請求包到達LVS後，LVS將請求包封裝成一個新的IP報文
• 新的IP包的目的IP是某一RS的IP，而後轉發給RS
• RS收到報文後IPIP內核模塊解封裝，取出用戶的請求報文
• 發現目的IP是VIP，而本身的tunl0網卡上配置了這個IP，從而愉快地處理請求並將結果直接發送給客戶

優勢：

• 集羣節點能夠跨vlan
• 跟DR同樣，響應報文直接發給client

缺點：

• RS上必須安裝運行IPIP模塊
• 多增長了一個IP頭
• LVS和RS上的tunl0虛擬網卡上配置同一個VIP（相似DR）

圖中紅線是再次封裝過的包，ipip是操做系統的一個內核模塊。

參考文章

https://yq.aliyun.com/article...