就是要你懂負載均衡--lvs和轉發模式

本文但願闡述清楚LVS的各類轉發模式，以及他們的工做流程和優缺點，同時從網絡包的流轉原理上解釋清楚優缺點的來由，並結合阿里雲的slb來講明優缺點。

若是對網絡包是怎麼流轉的不太清楚，推薦先看這篇基礎：程序員的網絡知識 -- 一個網絡包的旅程，對後面理解LVS的各個轉發模式很是有幫助。

幾個術語和縮寫

cip：Client IP，客戶端地址
vip：Virtual IP，LVS實例IP
rip：Real IP，後端RS地址
RS: Real Server 後端真正提供服務的機器
LB： Load Balance 負載均衡器
LVS： Linux Virtual Server
sip： source ip
dip： destination

LVS的幾種轉發模式

• DR模型 -- （Director Routing-直接路由）
• NAT模型 -- (NetWork Address Translation-網絡地址轉換)
• fullNAT -- （full NAT）
• ENAT --（enhence NAT 或者叫三角模式/DNAT，阿里雲提供）
• IP TUN模型 -- (IP Tunneling - IP隧道)

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. 而後丟給交換機，交換機將這個包丟給選中的RS
4. 選中的RS看到MAC地址是本身的、dip也是本身的，愉快地手下並處理、回覆
5. 回覆包（sip 200.200.200.1， dip 200.200.200.2）
6. 通過交換機直接回復給client了（再也不走LVS）

咱們看到上面流程，請求包到達LVS後，LVS只對包的目的MAC地址做了修改，回覆包直接回給了client。

同時還能看到多個RS和LVS都共用了同一個IP可是用的不一樣的MAC，在二層路由不須要IP，他們又在同一個vlan，因此這裏沒問題。

RS上會將vip配置在lo迴環網卡上，同時route中添加相應的規則，這樣在第四步收到的包能被os正常處理。

優勢：

• DR模式是性能最好的一種模式，入站請求走LVS，回覆報文繞過LVS直接發給Client

缺點：

• 要求LVS和rs在同一個vlan；
• RS須要配置vip同時特殊處理arp；
• 不支持端口映射。

爲何要求LVS和RS在同一個vlan（或者說同一個二層網絡裏）

由於DR模式依賴多個RS和LVS共用同一個VIP，而後依據MAC地址來在LVS和多個RS之間路由，因此LVS和RS必須在一個vlan或者說同一個二層網絡裏

DR 模式爲何性能最好

由於回覆包不走LVS了，大部分狀況下都是請求包小，回覆包大，LVS很容易成爲流量瓶頸，同時LVS只須要修改進來的包的MAC地址。

DR 模式爲何回包不須要走LVS了

由於RS和LVS共享同一個vip，回覆的時候RS能正確地填好sip爲vip，再也不須要LVS來多修改一次（後面講的NAT、Full NAT都須要）

總結下 DR的結構

綠色是請求包進來，紅色是修改過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 rip）
3. 請求包到達rs， rs回覆（sip rip，dip 200.200.200.2）
4. 這個回覆包不能直接給client，由於rip不是VIP會被reset掉
5. 可是由於lvs是網關，因此這個回覆包先走到網關，網關有機會修改sip
6. 網關修改sip爲VIP，修改後的回覆包（sip 200.200.200.1，dip 200.200.200.2）發給client

優勢：

• 配置簡單
• 支持端口映射（看名字就知道）
• RIP通常是私有地址，主要用戶LVS和RS之間通訊

缺點：

• LVS和全部RS必須在同一個vlan
• 進出流量都要走LVS轉發
• LVS容易成爲瓶頸
• 通常而言須要將VIP配置成RS的網關

爲何NAT要求lvs和RS在同一個vlan

由於回覆包必須通過lvs再次修改sip爲vip，client才認，若是回覆包的sip不是client包請求的dip（也就是vip），那麼這個鏈接會被reset掉。若是LVS不是網關，由於回覆包的dip是cip，那麼可能從其它路由就走了，LVS沒有機會修改回覆包的sip

總結下NAT結構

注意這裏LVS修改進出包的(sip, dip)的時候只改了其中一個，因此纔有接下來的full NAT。固然NAT最大的缺點是要求LVS和RS必須在同一個vlan，這樣限制了LVS集羣和RS集羣的部署靈活性，尤爲是在阿里雲這種對外售賣的公有云環境下，NAT基本不實用。

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

基本流程（相似NAT）：

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

優勢：

• 解決了NAT對LVS和RS要求在同一個vlan的問題，適用更復雜的部署形式

缺點：

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

爲何full NAT解決了NAT中要求的LVS和RS必須在同一個vlan的問題

由於LVS修改進來的包的時候把(sip, dip)都修改了(這也是full的主要含義吧)，RS的回覆包目的地址是vip（NAT中是cip），因此只要vip和rs之間三層可通就行，這樣LVS和RS能夠在不一樣的vlan了，也就是LVS再也不要求是網關，從而LVS和RS能夠在更復雜的網絡環境下部署。

爲何full NAT後RS看不見cip了

由於cip被修改掉了，RS只能看到LVS的vip，在阿里內部會將cip放入TCP包的Option中傳遞給RS，RS上通常部署本身寫的toa模塊來從Options中讀取的cip，這樣RS能看到cip了, 固然這不是一個開源的通用方案。

總結下full NAT的結構

注意上圖中綠色的進包和紅色的出包他們的地址變化

那麼到如今full NAT解決了NAT的同vlan的要求，基本上能夠用於公有云了，可是仍是沒解決進出流量都走LVS的問題（LVS要修改進出的包）

那麼有沒有一個方案可以像full NAT同樣不限制lvs和RS之間的網絡關係，同時出去的流量跟DR模式同樣也不走LVS呢？

阿里雲的ENAT模式(enhence NAT)

優勢：

• 不要求LVS和RS在同一個vlan
• 出去的流量不須要走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

ENAT模式在內部也會被稱爲 三角模式或者DNAT/SNAT模式

爲何ENAT的回覆包不須要走回LVS了

由於以前full NAT模式下要走回去是須要LVS再次改寫回復包的IP，而ENAT模式下，這件事情在RS上被ctk模塊提早作掉了

爲何ENAT的LVS和RS能夠在不一樣的vlan

跟full NAT同樣

總結下 ENAT的結構

最後說一下不太經常使用的 TUN模型

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

基本流程：

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

優勢：

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

缺點：

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

DR模式中LVS修改的是目的MAC

爲何IP TUN不要求同一個vlan

由於IP TUN中不是修改MAC來路由，因此不要求同一個vlan，只要求lvs和rs之間ip能通就行。DR模式要求的是lvs和RS之間廣播能通

IP TUN性能

回包不走LVS，可是多作了一次封包解包，不如DR好

總結下 IP TUN的結構

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

DR可能在小公司用的比較多，IP TUN用的少一些，相對而言接下來的三種比較相似，用的也比較多，他們之間的可比較性很強，因此放在一塊了。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。