LVS NAT,DR,TUN三種負載原理

負載均衡簡單介紹

用通俗的話來講負載均衡，就是經過不一樣的調度機制將用戶的請求分派到後端不一樣的服務器。緩解服務器的請求壓力，實現負載均衡的方案有多種，下面簡單說說了解的幾種方式：

• DNS 負載：利用DNS的解析能夠實現區域的性用戶請求負載，這種負載方式是離用戶最近的負載方案，請求尚未到達內部系統架構服務前就已經被分流了。
• LVS ：就是本篇文件要整理的解決方案，LVS性能特別強，它是工做在linux系統內核的一個程序，LVS負載的特色是超強的分流功能，但它只能負載調度流量的去向，沒有辦法實如今業務層分流負載。
• Haproxy：haproxy能夠工做在ISO7層模型中的4層和7層，工做在4層時是基於IP的負載，這與LVS做用相同，工做在7層時是基於應用層的應用協議進行負載，能夠根據分析報文內容並結合算法來選擇後端服務
• Nginx： nginx也是應用層負載均衡器，能夠實現反向代理功能，nginx的特色是能夠將請求按照業務類型進行向後端調度，對請求從業務功能上進行了負載調度。

lVS工做組成

LVS由兩部分組成，包括ipvs和ipvsadm：

• ipvs：ipvs是工做在內核空間netfilter的input鏈上的框架，經過用戶空間工具進行管理，是真正生效實現調度的代碼。

• ipvsadm：ipvsadm負責爲ipvs內核框架編寫規則，管理配置內核中ipvs程序的用戶空間的管理工具

LVS工做原理

LVS是工做在linux內核空間的tcp/ip棧的應用程序，其程序名稱爲ipvs，ipvs會監聽input鏈上的請求，一旦請求的是集羣服務的話，ipvs鉤子函數會將請求拉出並進行報文修改，強制轉發到postrouting處理，關係圖以下圖所示：

在客戶端看來，負載層的LVS 就是一個真實的應用服務器，客戶端向LVS發送請求信息，LVS接收數據報文至內核空間，工做在input鏈上的ipvs模塊會判斷用戶請求是否是定義的後端服務器，若是用戶請求的就是定義的後端集羣服務，數據報文傳送到input鏈上時，input鏈會強行將數據報文轉發給postrouting，postrouting將數據報文傳送給後端真實服務器

LVS的4種工做模式

LVS有多種工做模式，類型以下：

• NAT：修改請求報文的目標IP，多目標IP的DNAT

• DR：操縱封裝新的MAC地址

• TUN：在原請求IP報文以外新加一個IP首部

• FullNAT：修改請求報文的源和目標IP

生產環境中大多使用DR模型工做

LVS-NAT模式

在客戶端看來，負載層的Director server 就是一個真實的應用服務器，客戶端向LVS發送請求信息，Director server接收數據報文至內核空間，工做在input鏈上的ipvs模塊會判斷用戶請求是否是定義的後端服務器，若是用戶請求的就是定義的後端集羣服務，數據報文傳送到input鏈上時，input鏈會強行將數據報文轉發給postrouting，postrouting將數據報文傳送給後端真實服務器。

LVS-NAT模型運行原理

NAT模式工做過程描述

• 1， Client向Director server發送帶有 [CIP-VIP] 的請求數據報文，PREROUTING 連接收數據報文發現目標ip是本機ip，隨後將報文轉發值INPUT鏈

• 2，工做在INPUT鏈上的IPVS比對數據包請求的服務是否爲集羣服務，若是是，修改數據包的目標IP地址爲後端服務器IP，而後將數據包發至POSTROUTING鏈。 此時報文的源IP爲CIP，目標IP爲RIP

• 3， POSTROUTING根據選路發給後端realy server，realy server收到數據包發現目標ip是本身，而後向Director響應請求，此時響應報文中的源IP地址信息爲 RIP,目標地址IP爲CIP

• 4，Director server在響應Client以前再將報文中ip信息源IP地址改成 VIP，目標IP仍爲CIP

NAT模式特色

本質是多目標IP的DNAT，經過將請求報文中的目標地址和目標端口修改成挑出的某個RS的RIP和PORT實現轉發

• 1，RIP和DIP應在同一個IP網絡，且應使用私網地址；RS的網關要指向DIP
• 2，請求報文和響應報文都必須經由Director轉發，Director易於成爲系統瓶頸
• 3， 支持端口映射，可修改請求報文的目標PORT
• 4， LVS必須是Linux系統，RS能夠是任意OS系統

LVS-DR模式

在DR工做模型中，Director收到請求經過修改數據數據報文中目的地址的MAC地址實現數據報文的轉發。在該模式下，Director和後端realy server都有一個相同VIP，且在同一物理網絡中，所以Client發送的請求報文到達INPUT鏈時，只要將報文中的[CIP-VIP]的MAC信息改爲【DIP-MAC | RIP-MAC】,後端realy server接收報文並構建響應，此時，響應報文再也不通過Director，realy server直接響應客戶端。

LVS-DR模型運行原理

DR模式工做流程

• 1，當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP，目標IP爲VIP

• 2， PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈

• 3， IPVS比對數據包請求的服務是否爲集羣服務，如果，將請求報文中的源MAC地址修改成DIP的MAC地址，將目標MAC地址修改RIP的MAC地址，而後將數據包發至POSTROUTING鏈。 此時的源IP和目的IP均未修改，僅修改了源MAC地址爲DIP的MAC地址，目標MAC地址爲RIP的MAC地址

• 4， 因爲DS和RS在同一個網絡中，因此是經過二層來傳輸。POSTROUTING鏈檢查目標MAC地址爲RIP的MAC地址，那麼此時數據包將會發至Real Server。

• 5， RS發現請求報文的MAC地址是本身的MAC地址，就接收此報文。處理完成以後，將響應報文經過lo接口傳送給eth0網卡而後向外發出。 此時的源IP地址爲VIP，目標IP爲CIP

DR模式的特色

• 1，保證前端路由將目標地址爲VIP的報文所有發送給DS，而不是RS
• 2，RS的RIP可使用私有地址，但也可使用公網地址
• 3，RS和director必須在同一物理網絡中
• 4，請求報文有director調度，但響應報文不必定經由director
• 5，不支持端口映射
• 6，RS能夠支持大多數OS
• 7，RS的網關不能指向DIP

LVS-TUN模式

在TUN工做模式下，Client向Director server 發送請求報文，報文到達Director 內核空間不修改請求報文的ip首部，而是經過在原有ip首部[CIP-VIP]以外，再封裝一個ip首部[DIP-RIP]，RS收到報文後發現是本身的IP地址，就會將報文接受下來，拆除最外層的IP後，會發現裏面還有一層IP首部，並且目標地址是本身的lo接口VIP，那麼此時RS開始處理此請求，處理完成滯後，經過lo接口送給eth0網卡，而後向外傳遞。此時的源IP地址爲VIP，目標IP爲CIP

LVS-TUN模型運行原理

TUN模式工做流程

• 1，當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP，目標IP爲VIP 。
• 2， PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈
• 3，IPVS比對數據包請求的服務是否爲集羣服務，如果，在請求報文的首部再次封裝一層IP報文，封裝源IP爲爲DIP，目標IP爲RIP。而後發至POSTROUTING鏈。 此時源IP爲DIP，目標IP爲RIP
• 4，POSTROUTING鏈根據最新封裝的IP報文，將數據包發至RS（由於在外層封裝多了一層IP首部，因此能夠理解爲此時經過隧道傳輸）。 此時源IP爲DIP，目標IP爲RIP
• 5， RS接收到報文後發現是本身的IP地址，就將報文接收下來，拆除掉最外層的IP後，會發現裏面還有一層IP首部，並且目標是本身的lo接口VIP，那麼此時RS開始處理此請求，處理完成以後，經過lo接口送給eth0網卡，而後向外傳遞。 此時的源IP地址爲VIP，目標IP爲CIP

TUN模型特色

• 1，RIP、VIP、DIP全是公網地址
• 2，RS的網關不會也不可能指向DIP
• 3，全部的請求報文經由Director Server，但響應報文必須不能進過Director Server
• 4，不支持端口映射,
• 5，RS的系統必須支持隧道

LVS調度算法

• RR 輪詢

調度器將請求調度至後端服務器(這種方式最簡單，不考慮後端主機性能等因素，公平調度)

• WRR 加權輪詢

在輪詢的基礎上，調度器能夠給後端主機指定權重，考慮到後端主機性能不均衡的問題，可讓性能強的主機響應更多的請求

• LC 最少鏈接

調度器經過"最少鏈接"調度算法動態地將網絡請求調度到已創建的連接數最少的服務器上。若是集羣系統的真實服務器具備相近的系統性能，採用"最小鏈接"調度算法能夠較好地均衡負載。

• WLC 加權最少鏈接

調度器經過"加權輪叫"調度算法根據真實服務器的不一樣處理能力來調度訪問請求。這樣能夠保證處理能力強的服務器處理更多的訪問流量。調度器能夠自動問詢真實服務器的負載狀況，並動態地調整其權值。

• LBLC 基於局部性最少鏈接

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

• LBLCR 帶複製的基於局部性最少鏈接

它與LBLC算法的不一樣之處是它要維護從一個 目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。該算法根據請求的目標IP地址找出該目標IP地址對應的服務 器組，按"最小鏈接"原則從服務器組中選出一臺服務器，
若服務器沒有超載，將請求發送到該服務器，若服務器超載；則按"最小鏈接"原則從這個集羣中選出一 臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以下降複製的程度。

• DH 目標地址哈希

目標地址哈希，將發往同一個目標地址的請求始終轉發至第一次挑中的RS，典型使用場景是正向代理緩存場景中的負載均衡，如：寬帶運營商

• SH 源地址哈希

實現session sticky，源IP地址hash；未來自於同一個IP地址的請求始終發往第一次挑中的RS，從而實現會話綁定