什麼是負載均衡

Load balancing，即負載均衡，是一種計算機技術，用來在多個計算機（計算機叢集）、網路連線、CPU、磁碟驅動器或其他資源中分配負載，以達到最優化資源使用、最大化吞吐率、最小化響應時間、同時避免過載的目的。

為什麼需要負載均衡

簡單點說就是現在使用者的訪問量過大，對於單機的計算機資源請求過多，導致負載過高，所以需要負載均衡技術。

簡單的負載均衡模型

最為簡單的負載均衡模型就是客戶端訪問負載均衡伺服器，然後由該伺服器轉發給真正的伺服器。如下圖所示：

該負載均衡伺服器也是理想中的伺服器，將其對應到OSI七層網路模型如下圖所示：

這裡的負載均衡伺服器預設是指LVS,所以是四層負載均衡伺服器，這裡對於為什麼是四層做一個簡單的解釋(個人理解)，首先該負載均衡伺服器沒有實現TCP握手功能但是具有路由轉發功能，那麼一定至少是工作在網路層的，也就是前三層，對於負載均衡伺服器它的主要功能是均衡負載，那麼如何判斷客戶端的請求過載呢？這裡就設計到第四層傳輸層，它需要知道有客戶端與服務端的連線數量，來判斷是否需要進行均衡負載，那麼這就需要負載均衡伺服器具有"窺視"傳輸層的埠的功能，也就是得看得到客戶端和服務端的連線，所以說是四層伺服器。

LVS模型中的常見專用術語：

1、 DS：Director Server。指的是前端負載均衡器節點，也即是四層負載均衡伺服器(LVS)。

2、 RS：Real Server。後端真實的工作伺服器。

3、 VIP：Virtual IP，向外部直接面向用戶請求，作為使用者請求的目標的IP地址。

4、 DIP：Director Server IP，主要用於和內部主機通訊的IP地址。

5、 RIP：Real Server IP，後端伺服器的IP地址。

6、 CIP：Client IP，訪問客戶端的IP地址

NAT模型推導(Network Address Translation，網路地址轉換)

假設現在有個客戶訪問www.baidu.com,在回車後該域名會解析為相應的ip地址，但是百度有很多伺服器，解析後的ip地址並不是真正的伺服器的地址，而是類似於這裡的負載均衡伺服器的ip,這個ip是固定的，無論真正的伺服器怎麼變化，對於客戶來說傳送的資料包只是一個源地址為CIP，目的地址為www.baidu.com域名解析後的虛擬地址VIP,如下圖所示：

而現在真正的伺服器對外暴露的IP為RIP，如果直接將該資料包轉發給服務端，服務端會丟棄，所以，這裡利用NAT的方式將傳送過來的資料包的目標IP地址更換為RIP，這樣就可以傳送到真正的伺服器。這裡假設傳送給Server2，那麼資料包會被轉化為CIP->RIP2，如下圖所示：

在Server2收到該請求後，會對其進行相應的處理，首先會在內部記錄該TCP連線——一個從RIP2到CIP的對映。

我們知道當我們在瀏覽器輸入www.baidu.com的時候瀏覽器會返回給我們一個頁面，也就是Server2收到客戶端的請求的時候，會返回一個數據包(這裡假設就一個)給客戶端，也就是一個源地址為RIP2目的地址為CIP的資料包，但是我們知道客戶端和服務端一般不在同一個網段，所以該資料包會根據路由表的預設路由傳送到地址為預設閘道器的地方，這裡也就是負載均衡伺服器的DIP。

這個資料包如果直接傳送給客戶端，客戶端統一不會接受而會拋棄，所以這裡傳送給客戶端的資料包也會被進行轉換為一個源地址為VIP，目標地址為CIP的資料包，這樣客戶端就會接受到服務端Server2返回的資料。

LVS的NAT模型的內容總結：

• 請求報文時，報文必須經過director(負債均衡伺服器)，才能達到負載均衡的效果。同時在director上修改目標ip為新的服務端地址(RIP)實現轉發,也就是進入負載均衡器時做DNAT。響應報文時，在director上修改源ip實現轉發，也就是響應出負載均衡器時做SNAT。
• Director的DIP和各real server的RIP必須在同一個物理網段中，並且RIP的閘道器要指向DIP。
• NAT模型中一般VIP是公網地址，DIP和RIP一般是私網地址。使用NAT模型主要的目的是隱藏伺服器ip。

LVS的NAT模型的弊端：

在我們輸入一個網站的時候，瀏覽器也就是服務端會給我們返回一個遠遠大於客戶端傳送的訊息的資料，簡單點說就是在同一條道路上，奔向服務端的是卡丁車，而返回給客戶端的卻是擎天柱樣的重卡。這樣客戶端的資料流通就是不對稱的，在高併發的情形下，對負載均衡伺服器的算力和頻寬都是極大的考驗，並且容易成為瓶頸。所以在負載均衡伺服器中不使用該模式。

DR模型（直接路由模式）

我們回顧NAT模式的弊端在於服務端返回的資料遠遠大於客戶端傳送的資料這樣對於負載均衡伺服器有較大的壓力，我們注意到，在服務端以及記錄了RIP2->CIP的連線了，為什麼不直接將返回的資料傳送給客戶端呢？這樣就不用通過負載均衡伺服器了，現在我們假設該想法可以實現，那麼該模型被修改為如下圖所示：

但是我們知道客戶端只接受從VIP傳送來的資料，所以，如果直接傳送給客戶端，客戶端會丟棄，我們在往前看，服務端之所以會發送一個從RIP2到CIP的資料包，是因為接受到的資料包是從CIP到VIP的，所以才會儲存一個從RIP2->CIP的連線，那麼如果我們傳送給服務端的資料就是一個源地址為CIP目標地址為VIP的資料包的話，服務端也就會儲存一個從VIP->CIP的連線，自然就傳送了一個源地址為VIP到CIP的包，如果客戶端可以接受到的話，那麼自然就會接受了。到這一步，模型的演變為如下圖所示：

那麼問題又來了，如果負載均衡伺服器傳送一個CIP->VIP的資料包，服務端不會接受，在這裡我們假設負載均衡伺服器和服務端在同一個區域網中，那麼負載均衡伺服器就是知道服務端的MAC地址，在同一區域網的主機通過MAC實現資料包的交換，同時需要服務端內部得有一個隱藏的地址VIP，這樣資料包根據MAC傳送到Server端，然後由於內部有一個VIP地址，該資料包就會被接受。如下圖所示：

這樣我們就得到了LVS的直接路由模式(DR)

LVS的DR模式內容總結如下：

• client傳送請求到vip，lvs會對vip響應arp，因此client將請求發到LVS。
• LVS機器收到發往vip的報文後，根據目的IP和目的port匹配ipvs規則，將報文目的mac改為real server的mac，同時將源mac改為LVS的mac後，傳送到real server。
• real server收到之後，mac/IP都是本機的，就將報文交由系統處理。
• 響應報文因real server收到的報文源IP就是client IP，real server直接將請求回給client。如果client和real server是同一個網段，響應報文直接通過二層透傳發送給client，報文目的mac即為client mac；如果client和real server不是同一個網段，響應報文先發送到gateway，再走三層轉發返回client。

LVS的DR模式的侷限性：

需要負載均衡伺服器與服務端在同一個區域網中。

LVS的TUN模式（tunneling）

在LVS的DR模式中，我們需要負載均衡伺服器與服務端在同一個區域網中，從而實現了MAC地址欺騙，而我們現在考慮負載均衡伺服器與服務端不在一個區域網的場景(該場景非常常見)，我們同樣採用DR的思路，將客戶端傳送過來的資料包地址進行修改，但是DR模式知識在資料鏈路層進行了修改，無法實現網路的跳轉，所以只要我們實現網路層的地址修改(欺騙)，那麼就無需讓負載均衡伺服器和服務端在同一個區域網了。也就是說我們在CIP->VIP的外面包裹一層資料包(DIP->RIP2)，那麼這樣服務端既可以接受該資料包，同時也實現負載均衡伺服器和服務端不在一個區域網的場景。

LVS的TUN模式內容總結：

• 客戶請求資料包，目標地址VIP傳送到負載均衡伺服器上。
• 負載均衡伺服器接收到客戶請求包，進行IP Tunnel封裝。即在原有的包頭加上IP Tunnel的包頭。然後傳送出去。
• RS節點伺服器根據IP Tunnel包頭資訊（此時就又一種邏輯上的隱形隧道，只有負載均衡伺服器和RS之間懂）收到請求包，然後解開IP Tunnel包頭資訊，得到客戶的請求包並進行響應處理。
• 響應處理完畢之後，RS伺服器使用自己的出公網的線路，將這個響應資料包傳送給客戶端。源IP地址還是VIP地址。

LVS的TUN模式的缺點：

這種方式需要所有的伺服器支援"IP Tunneling"(IP Encapsulation)協議