架構設計：負載均衡層設計方案（4）——LVS原理

 

轉自：https://blog.csdn.net/yinwenjie/article/details/46742661

 

以前咱們花了兩篇文章的篇幅，詳細講解了Nginx的原理、安裝和特性組件。請參看《負載均衡層設計方案（2）——Nginx安裝》（http://blog.csdn.net/yinwenjie/article/details/46620711）和《架構設計：負載均衡層設計方案（3）——Nginx進階》（http://blog.csdn.net/yinwenjie/article/details/46742661）兩篇文章。雖然不包括Nginx的全部知識（也不可能所有包括），可是足夠讀者將Nginx應用到實際的生產中，並進行重要特性的優化，後面有時間咱們還會從新回到Nginx的講解上。從本篇文章開始，咱們將開始介紹LVS技術，包括基本概念、簡單使用和進階使用。

一、LVS介紹
請自行Google或者百度。

二、網絡協議基礎知識
根據官方文檔LVS支持三種負載工做方式：NAT方式、TUN方式和DR方式。爲了說明這三種方式的工做原理，咱們首先須要瞭解一下基礎的IP/TCP報文（注意，IP報文和TCP報文是兩種不一樣的報文格式），以及鏈路層對IP數據的封裝方式。而後咱們採用看圖說話的方式，以圖文結合的方式爲您介紹這三種工做方式中對報文或重寫或封裝的過程。

爲了說清楚咱們將要講解的基礎知識，就要提到OSI7層網絡模型。

章文嵩博士及其團隊是個人偶像，LVS體系之因此高效是由於其直接對鏈路層報文、IP報文、TCP報文進行了修改或封裝。因此要真正理解LVS的三種工做方式，就不能像網絡上的抄襲貼同樣轉幾句不知因此的文字就完了，必須對鏈路層報文、網絡層報文、傳輸層報文有所瞭解。下面咱們就進行概述。

爲了保證這個系列的博文不發生誤差，咱們只講解其中須要用到的屬性和含義，若是讀者對網絡的核心原理有興趣，能夠讀讀《TCP/IP詳解，卷1：協議》這本書。

2.一、鏈路層報文
鏈路層的數據格式有一個共同特色，都包括目標MAC地址和源MAC地址。下面這個圖主要說明了咱們最經常使用的Ethernet幀（以太幀）的報文格式：

目標MAC地址/源MAC地址：00:00:00:00:00:00——FF:FF:FF:FF:FF:FF這個範圍是全球MAC地址的可用範圍。一張物理網卡確定有一個惟一的MAC地址。實際上網絡層經常使用的IP協議，就是基於MAC地址的。一個子網範圍內某個IP對應的MAC地址是經過ARP查詢協議從NAT設備（多是路由器、交換機或者網絡代理設備）上查詢獲得的。

上層協議類型：鏈路層的報文是爲了承載網絡層的協議而存在的，因此鏈路層的數據格式中須要有一個屬性說明這個鏈路層所承載的上層協議是什麼類型。

IPv4: 0x0800
ARP:0x0806
PPPoE:0x8864
IPV6: 0x86DD
封裝的上層數據：最多能夠有1500個字節。

請記住這個鏈路層的數據格式，由於講到LVS-DR方式的時候，主要就是對鏈路層的數據格式進行修改，而不會對IP數據報文和TCP數據報文進行修改。

2.二、網絡層IP報文
TCP協議和IP協議是兩種不一樣的協議。對應的，也就是兩種不一樣的描述格式。

IP協議是網絡層協議，顧名思義，就是用來描述整個網絡構成狀況的；TCP協議是通信層協議，是用來表示兩個或多個網絡上的點如何進行通訊和當前通訊狀態的。

這兩種協議有不少共同特色，例如這兩種協議都分爲「頭部」和「數據部」；針對IP協議來講，TCP協議的描述就存放在其「數據部」。

咱們首先來看看IP協議是怎麼描述的：

好吧，圖我是直接從百度百科直接粘過來的，由於要我來畫，結構也是這樣^_^。其中有幾個重要的咱們後面要使用的屬性，要給你們說一下：

header.version：IP協議的版本號，你猜對了就是IPV4仍是IPV6。4表示IPV4版本，6表示IPV6。你要問我什麼是IPV4，仍是IPV6：192.168.220.141，這就是IPV4的格式；FE80:0000:0000:0000:AAAA:0000:00C2:0002，這就是IPV6的格式。

header.Total Length：總長度，這個總長度是IP頭和IP數據兩個區域的總長度。主要仍是用於生成頭驗證碼和爲了操做系統處理方便。

header.IP Flags：這個位置有3位000，但實際只有後兩位纔有值010，這個就是「D」位=1，這個時候表示因爲要傳輸的整個數據不大，因此這個IP數據報的數據部分已經描述了整個數據描述，不須要進行IP數據報的分片；」D」爲=0，表示要傳輸的整個數據比較大，因此IP數據報進行了拆分，這個時候就要用到最後一位了：最後一位「M」中「1」表示還有後續分片；0表示這個數據報就是IP分片的最後一個數據片了。

header.Protocol：IP協議是網絡層協議，在網絡層以上是傳輸層協議。TCP、UDP、ICMP和IGMP是傳輸層協議。這個位置的8位說明IP協議數據部分攜帶的是哪一種上層協議。

header.Source Address：這個固然就是IP數據報的來源地址咯。

header. Destination Address：這個固然就是IP數據報的目標地址咯。

header.checksum：首部校驗值。這個值校驗IP數據報首部的傳輸完整性（注意校驗不包括IP數據報的數據部分）。這就意味着NAT設備重寫這個數據報的來源或者目標IP後，校驗值要從新進行計算。Source Address、Destination Address、Checksum是各類NAT設備主要的改寫屬性。並且不少時候NAT設備只改寫這三個值就能夠實現IP數據報的轉發（固然TCP報文中的端口也會被改寫，以便在端口映射的狀況下進行端口轉換）。

2.三、傳輸層TCP報文
上文已經說過，TCP的報文信息是裝在到IP報文的數據部分的，當成網絡上進行傳輸的數據從Srouce Address傳到Destination Address中。下面是TCP報文的信息：

頭.源端口號：TCP信息來源的端口號。

頭.目的端口號：TCP信息數據的目標端口。

頭.狀態位（URG/ACK/PSH/RST/SYN/FIN）：若是您已經看到我以前寫的《標準Web系統的架構分層》（http://blog.csdn.net/yinwenjie/article/details/46480485）這邊文章的第3.2小節，那麼您對ACK、SYN、FIN這三個標記確定不陌生，由於TCP的三次握手和鏈接中斷就要用到這三個標記，須要注意SYN SEQ和ACK SEQ就是TCP數據報的確認號；另外解釋一下PSH和RST兩個狀態標記。應用層的TCP數據報有一個緩存區，也就是說多個正確的TCP數據報會首先放到這個緩存區，達到必定條件後，再推送給上層的應用層協議，例如http。PSH爲1的時候，表示不須要再等到後續的TCP數據報文了，直接將目前接收方緩存中的tcp數據報進行數據段組合後推送給上層協議，而且清空緩存區；RST表示復位，您能夠理解成放棄當前緩存區的全部未發送給上層協議的TCP數據報文，通常這種狀況都是TCP報文傳輸出現了問題。

頭.TCP校驗和：TCP報文的校驗和比起IP頭校驗要稍微複雜點。TCP校驗的輸入包括三部分：TCP僞首部、TCP首部長度和TCP數據部長度。TCP僞首部是一個虛擬概念，它包括承載TCP數據報文的IP報文的一部分，和TCP首部的一部分數據（源IP、目標IP、IP報文中的protocoly、以及TCP報文的報文頭長度和TCP報文的數據長度）。

從上面的描述能夠看出，一旦IP報文中的源IP和目標IP發生改變了，TCP報文校驗信息就會改變。

三、LVS的三種工做方式
3.一、LVS-NAT工做方式
NAT方式是一種由LVS Master服務節點收到數據報，而後轉給下層的Real Server節點，當Real Server處理完成後回發給LVS Master節點而後又由LVS Master節點轉發出去的工做方式。LVS的管理程序IPVSADMIN負責綁定轉發規則，並完成IP數據報文和TCP數據報文中屬性的重寫。請用幾分鐘時間仔細看看下圖（爲了簡單，圖裏面只畫了一個Real Server。若是看不清楚，可點擊右鍵「查看原圖」）：

一、在正式的機房環境中，通常有兩種方式爲一個機器分配外網地址：在覈心交換機上直接綁定外網地址到主機網卡的，這樣使用ifconfig命令看到的IP地址爲外網地址；在覈心交換機上使用映射規則，將一個外網地址映射到內網地址，這樣使用ifconfig命令看到的IP地址爲內網地址。上圖中咱們採用的是後一種映射規則。若是使用前一種外網IP的分配規則，也不會影響LVS NAT的工做方式，由於這個IP被限制在LVS NAT工做之外。只不過eth1的IP從192.168.100.10換成100.64.92.199而已。

二、咱們用中文描述一下轉換規則：凡是發送到「192.168.100.10:80」的數據報，目標地址所有改寫爲「192.168.220.121:8080」，因此來自於100.64.92.199:80的報文被改寫了。被改寫的屬性包括：IP.header.destinationIP、IP.header.checksum、TCP.header.sourcePort、TCP.header.targetPort、TCP.header.checksum。注意IP報文的Source IP不會發生變化，仍是「互聯網某個IP」。

三、這個包最終被送到了192.168.220.121的8080端口進行處理，並由下層的Real Server生成了返回的數據報（至於這個Real Server是否是「真正的Real Server」，LVS不會關心）。你要問它是怎麼被髮送過去的，請參考ARP查詢協議。

四、注意：由於LVS服務器和Real Server（可能有多個），組成了一個封閉的局域網。除了LVS節點之外，這個子網的任何節點都是沒法訪問外網的。因此要求192.168.220.121這個Real Server直接把數據報給「互聯網某個IP」這個外網地址，顯然是不行的，由於在局域網中根本就找不到這個IP。Real Server只能將數據報返給網關，再由網關去尋找這個外網地址。整個服務器中只有LVS節點可以找到這個外網地址，這就是爲何在LVS-NAT工做模式下，全部的Real Server節點必須設置本身的Gateway爲LVS節點的緣由。

五、收到來源於「192.168.220.121:8080」的數據報文後，IPVS又要進行數據報文的重寫了。重寫規則是：凡是來源於「192.168.220.121:8080」的數據報，源地址所有改寫爲「192.168.100.10:80」。因而數據報文的Source IP、Source Port被改寫成「192.168.100.10:80」。在外層的核心交換機（或者是機房之外的請求方）看來，LVS接受了數據報，並進行了處理，返回告終果。它並不知道LVS節點的下層還有什麼。

LVS-NAT的優勢在於：

配置管理簡單。LVS-NAT的工做方式是LVS三種工做模式中最容易理解、最容易配置、最容易管理的工做模式。

節省外網IP資源，通常機房分配給使用者的IP數量是有限的，特別是您購買的機架的數量很少時。LVS-NAT工做方式將您的系統架構封裝在局域網中，只須要LVS有一個外網地址或外網地址映射就能夠實現訪問了。

系統架構相對封閉。在內網環境下咱們對防火牆的設置要求不會很高，也相對容易進行物理服務器的運維。您能夠設置來源於外網的請求須要進行防火牆過濾，而對內網請求開放訪問。

另外改寫後轉給Real Server的數據報文，Real Server並不會關心它的真實性，只要TCP校驗和IP校驗都能經過，Real Server就能夠進行處理。因此LVS-NAT工做模式下Real Server能夠是任何操做系統，只要它支持TCP/IP協議便可。

固然做爲Linux系統忠實擁護者，我並不建議使用Window服務器。但若是您的Real Server是.Net系統，又有業務場景須要用到LVS，那麼LVS-NAT多是一個不錯的選擇。

LVS-NAT的缺點是因爲這種轉發模式自己所形成的：

轉發點就是瓶頸點。您能夠想象100臺Real Server將處理結果所有轉到一個LVS進行發送是一個怎麼樣的場景。事實上，LVS-NAT的極限負載是達不到100臺Real Server的。
3.二、LVS-DR工做方式
LVS的DR工做模式，是目前生產環境中最經常使用的一種工做模式，網上的資料也是最多的，有的文章對DR工做模式的講解仍是比較透徹的。這裏咱們經過圖文的方式再向您介紹一下DR的工做模式（一樣，若是看不清楚，請右鍵「查看原圖」）：

上圖反映了DR模式的整個工做過程，一樣爲了簡單起見，這裏的Real Server也只畫了一個。若是是多個Real Server的話，LVS會經過調度算法來決定發往哪臺Real Server。LVS-DR工做模式的幾個關鍵點在於：

被Real Server處理後造成的響應報文，再也不回發到LVS節點，而是直接路由給中心交換機而後發送出去。省去了LVS-NAT方式中的LVS回發過程。

LVS節點只會改寫鏈路層的報文封裝，對網絡層和傳輸層報文是不進行改寫的。

有網帖說DR工做模式，不能跨子網，也就是說LVS節點和各個Real Server節點必須處於同一個網段中。這是爲何呢？事實又真的是這樣嗎？不少網絡帖子沒有回答這個問題，這篇文章立刻回答一下（實際上章文嵩先生已經回答過這個問題）。

使用DR模式時，須要Real Server設置LVS上的VIP爲本身的一個迴環IP，否則包會被丟棄。這又是爲何呢？不少網貼一樣沒有回答這個問題，好吧，咱們立刻回答一下。

先來講一說上圖的工做原理：

一、一樣的，咱們爲了演示整個生產環境中，從機房中心交換機收到一個數據報文後開始講解。中心交換機一樣採起的IP映射方式。可是與LVS-NAT方式不同，Real Server在機房的中心交換機上也須要綁定一個外網映射。這樣保證Real Server回發的響應報文可以被髮送到外網。

二、LVS節點接收到請求報文後，會改寫報文的數據鏈路層格式。將Target Mac改寫成Real Server的Mac，可是網絡層和傳輸層報文不會改寫，而後從新回發給交換機。這裏就涉及一個問題，如今target Mac和Destination IP的對應關係的錯誤的，這個數據報文到了交換機後，因爲這種錯位的關係，是不能進行三層交換的，只能進行二層交換（一旦進行IP交換，數據報文的驗證就會出錯，被丟棄）。因此LVS-DR方式要求Real Server和LVS節點必須在同一個局域網內，或者這樣說更確切：LVS節點須要找到一個二層鏈路，將改寫了Mac地址的報文發送給Real Server，而不能進行三層交換的校驗。這樣來看，實際上LVS節點和Real Server界面不必定要在同一個子網，您用一個獨立網卡獨立組網，傳送報文也是可行的。

三、經過二層交換，數據被髮送到Real Server節點。那麼Real Server節點怎麼來判斷這個包的正確性呢？首先固然是傳輸層TCP/IP報文校驗沒有問題，LVS-NAT沒有改寫TCP/IP，固然校驗就沒有問題（除非報文自己就存在問題）；而後是鏈路層的MAC地址可以被識別，這時就是迴環IP的功勞了。對於Real Server節點來講，192.168.100.10這個VIP就是本身的迴環IP，綁定的MAC也就是被LVS替換後的target mac。那麼Real Server會認爲這個包是在本機運行的某一個應用程序經過迴環IP發給本身的，因此這個包不能被丟棄，必須處理。

四、被處理後的生成的響應報文，被直接發送給網管。這個就沒有太多的解釋的了，只要保證Real server的默認路由設置成到核心交換機的192.168.100.1就OK了。另外，須要說明的是，因爲LVS-DR模式並無更改原有的IP報文和TCP報文，因此LVS-DR模式自己是不支持端口映射的，實際上在平常使用實踐中，咱們通常使用Nginx作端口映射，由於: 靈.活.。

LVS-DR工做模式的優勢在於：

解決了LVS-NAT工做模式中的轉發瓶頸問題，可以支撐規模更大的負載均衡場景。

比較耗費網外IP資源，機房的外網IP資源都是有限的，若是在正式生產環境中確實存在這個問題，能夠採用LVS-NAT和LVS-DR混合使用的方式來緩解。

LVS-DR固然也有缺點：

配置工做較LVS-NAT方式稍微麻煩一點，您至少須要瞭解LVS-DR模式的基本工做方式才能更好的指導本身進行LVS-DR模式的配置和運行過程當中問題的解決。

因爲LVS-DR模式的報文改寫規則，致使LVS節點和Real Server節點必須在一個網段，由於二層交換是無法跨子網的。可是這個問題針對大多數系統架構方案來講，實際上並無本質限制。

3.三、LVS-TUN工做方式
不少網絡上的文章都爲讀者介紹DR和TUN的工做方式相似，要麼就是直接講解DR模式和TUN模式的安裝配置方式，而後總結兩種模式相似。那爲何有了DR模式後還須要TUN模式呢？爲何ipvsadmin針對兩種模式的配置參數不同呢？

實際上LVS-DR模式和LVS-TUN模式的工做原理徹底不同，工做場景徹底不同。DR基於數據報文重寫，TUN模式基於IP隧道，後者是對數據報文的從新封裝。下面咱們就來說解一下LVS-TUN模式的工做原理。

首先要介紹一個概念IPIP隧道。將一個完整的IP報文封裝成另外一個新的IP報文的數據部分，並經過路由器傳送到指定的地點。在這個過程當中路由器並不在乎被封裝的原始協議的內容。到達目的地點後，由目的地方依靠本身的計算能力和對IPIP隧道協議的支持，打開封裝協議，取得原始協議。以下圖：

能夠說隧道協議就是爲了解決跨子網傳輸準備的，在生產環境中因爲業務須要、技術須要或者安全須要，可能使用交換機進行VLAN隔離（即造成若干個虛擬的獨立的局域網），咱們可能須要LVS節點在局域網A，而須要進行負載的多臺Mysql讀服務器可能在局域網B中。這個時候，咱們就要配置LVS的隧道方式。LVS-TUN模式以下圖所示（注意，目標節點要可以解開隧道協議，好消息是Linux支持IPIP隧道協議）：

上圖中的線優勢多，您只須要關注關心「有箭頭」的虛線就能夠了。

一、一旦LVS節點發現來目標爲192.168.100.10VIP的請求，就會使用IPIP隧道協議對這個請求報文進行封裝。而不是像LVS-DR模式重寫數據報文的MAC信息。若是配置了多個Real Server，那麼LVS會使用設置的調度算法肯定一個Real Server（這裏爲了簡單，就只畫了一個Real Server節點）。

二、從新封裝後的IPIP隧道協議報文會從新被回發到路由器，路由器（或三層交換機）會根據設置的LVAN映射狀況，找到目標服務器，並將這個IPIP隧道報文發送過去。

三、Real Server收到這個IPIP隧道報文後，會將這個報文進行解包。這裏注意一下，通常狀況下IPIP隧道報文會進行分片，就如同IP報文分片同樣，只是爲了講解方便，咱們假定這個報文不須要分片。解壓後獲得的數據報文就是原來發送給VIP的請求報文。

四、Real Server設置的迴環IP，讓Real Server認爲原始的請求報文是從本身本地的某個應用程序發出的，完成原始報文的校驗後，它會對這個報文進行處理。剩下的過程就和LVS-DR相同了，這裏就再也不進行復述了。

能夠說LVS-TUN方式基本上具備LVS-DR的優勢。在此基礎上又支持跨子網間穿透。這樣的敷在方案可以給咱們架構師足夠的系統設計場景。

四、LVS調度方式
在本文第3節中，爲了集中介紹LVS的三種工做模式，咱們在三幅圖中都爲LVS畫了一個Real Server。但實際應用中，通常都是多個Real Server。LVS使用多種調度算法來決定「當前的數據報文」由哪一個Real Server進行處理。在個人上篇文章《架構設計：負載均衡層設計方案（2）——Nginx安裝》（http://blog.csdn.net/yinwenjie/article/details/46620711）中，已經花了較多的篇幅介紹了Nginx中的調度方式，並明確說明了這些調度方式是萬變不離其宗的。

文章中包括了Hash算法，而且說明了任何屬性均可以作Hash，包括IP、用戶名等；還介紹了輪詢和加權輪詢，加權輪詢也能夠依據各類屬性做爲權值，例如節點的CPU使用狀況、內存使用狀況、或者管理員本身設置的一個固定權值。LVS的調度也是這樣的。

利用一致性Hash算法完成調度

目標地址Hash（DH）：調度算法根據請求的目標IP地址，做爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空。
原地址Hash（SH）：根據請求的源IP地址，做爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空。
輪詢調度

最簡輪詢（RR）：調度算法將外部請求按順序輪流分配到集羣中的真實服務器上，它均等地對待每一臺服務器，而無論服務器上實際的鏈接數和系統負載。

最少鏈接輪詢（LC）：請注意「最少鏈接輪詢」和「最少鏈接加權輪詢」兩種調度算法的區別。調度器經過「最少鏈接」調度算法動態地將網絡請求調度到已創建的連接數最少的服務器上。注意請求確定會被分配到這臺目前鏈接數最少的Real Server上面，不會考慮概率問題

加權輪詢調度：

性能加權輪詢（WRR）：調度算法根據真實服務器的不一樣處理能力來調度訪問請求。這樣能夠保證處理能力強的服務器能處理更多的訪問流量。調度器能夠自動問詢真實服務器的負載狀況，並動態地調整其權值。
最少鏈接數的加權輪詢（WLC）：具備較高權值的服務器將承受較大比例的活動鏈接負載。調度器能夠自動問詢真實服務器的負載狀況，並動態地調整其權值。注意，是按照一個比例，有較高的分配概率，而不是LC同樣「確定分配」。
在LVS官方中文資料中，提到了更爲完整的調度算法。能夠進行參考（http://zh.linuxvirtualserver.org/node/2903）。但必定記住各類調度算法確定是逃不開哈希一致性、輪詢、加權輪詢這大思路的。

五、後文介紹這篇文章咱們的重點是說明LVS的工做原理，並詳細介紹了LVS三種工做模式的工做過程、優缺點、應用場景。只要您理解了原理，那麼下一篇介紹的LVS的安裝和配置就是小菜一碟。咱們在下一篇文章中，將介紹LVS三種工做模式的安裝和配置方式，以後咱們介紹LVS + Keepalived的安裝和配置方式。有了這個知識基礎，咱們將回到Nginx，介紹LVS + Keepalived + Nginx的安裝和配置方式。、！