1 LVS介紹

博客轉自：http://superproxy.github.io/docs/lvs/index.html

1.1 簡介

負載均衡技術有很多實現方案，有基於DNS域名輪流解析的方法、有基於客戶端調度訪問的方法、有基於應用層系統負載的調度方法，還有基於IP地址的調度方法。本文介紹基於傳輸層的負載均衡器LVS。

LVS是Linux Virtual Server的簡稱，也就是Linux虛擬服務器, 用現在的觀點來看就是個4層（傳輸層tcp/udp）的負責均衡器。它是一個由章文嵩博士發起的自由軟件項目，它的官方站點是www.linuxvirtualserver.org。現在LVS已經是 Linux標準內核的一部分，在Linux2.4內核以前，使用LVS時必須要重新編譯內核以支持LVS功能模塊，但是從Linux2.4內核以後，已經完全內置了LVS的各個功能模塊，無需給內核打任何補丁，可以直接使用LVS提供的各種功能。

LVS技術要達到的目標是：通過LVS提供的負載均衡技術和Linux操作系統實現一個高性能、高可用的服務器羣集，它具有良好可靠性、可擴展性和可操作性。從而以低廉的成本實現最優的服務性能。

LVS自從1998年開始，發展到現在已經是一個比較成熟的技術項目了。可以利用LVS技術實現高可伸縮的、高可用的網絡服務，例如WWW服務、Cache服務、DNS服務、FTP服務、MAIL服務、視頻/音頻點播服務等等，有許多比較著名網站和組織都在使用LVS架設的集羣系統，例如：Linux的門戶網站（www.linux.com）、向RealPlayer提供音頻視頻服務而聞名的Real公司（www.real.com）、全球最大的開源網站（sourceforge.net）等。

1.2 主要功能

LVS目前有三種IP負載均衡技術（VS/NAT、VS/TUN和VS/DR）；十種調度算法（rrr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq）

1.3 優點

1.3.1 功能特性

1、抗負載能力強、是工作在網絡4層之上僅作分發之用，沒有流量的產生；

2、配置性比較低，這是一個缺點也是一個優點，因爲沒有可太多配置的東西，所以並不需要太多接觸，大大減少了人爲出錯的機率；

3、工作穩定，自身有完整的雙機熱備方案；

4、無流量，保證了均衡器IO的性能不會收到大流量的影響；

5、應用範圍比較廣，可以對所有應用做負載均衡；

1.3.2 高可用性

LVS是一個基於內核級別的應用軟件，因此具有很高的處理性能，用LVS構架的負載均衡集羣系統具有優秀的處理能力，每個服務節點的故障不會影響整個系統的正常使用，同時又實現負載的合理均衡，使應用具有超高負荷的服務能力，可支持上百萬個併發連接請求。如配置百兆網卡，採用VS/TUN或VS/DR調度技術，整個集羣系統的吞吐量可高達1Gbits/s；如配置千兆網卡，則系統的最大吞吐量可接近10Gbits/s。

1.3.3 高可靠性

LVS負載均衡集羣軟件已經在企業、學校等行業得到了很好的普及應用，國內外很多大型的、關鍵性的web站點也都採用了LVS集羣軟件，所以它的可靠性在實踐中得到了很好的證實。有很多以LVS做的負載均衡系統，運行很長時間，從未做過重新啓動。這些都說明了LVS的高穩定性和高可靠性。

1.3.4 適用環境

LVS對前端Director Server目前僅支持Linux和FreeBSD系統，但是支持大多數的TCP和UDP協議，支持TCP協議的應用有：HTTP，HTTPS ，FTP，SMTP，，POP3，IMAP4，PROXY，LDAP，SSMTP等等。支持UDP協議的應用有：DNS，NTP，ICP，視頻、音頻流播放協議等。

LVS對Real Server的操作系統沒有任何限制，Real Server可運行在任何支持TCP/IP的操作系統上，包括Linux，各種Unix（如FreeBSD、Sun Solaris、HP Unix等），Mac/OS和Windows等。

1.4 缺點

需要網絡環境的支持

不能針對上層協議分析

如果做成硬件會更完美

1.5 類似產品

1.5.1 介紹

現在網絡中常見的負載均衡主要分爲兩種：一種是通過硬件來進行進行，常見的硬件有比較昂貴的NetScaler、F5、Radware和Array等商用的負載均衡器，也有類似於LVS、Nginx、HAproxy的基於Linux的開源的負載均衡策略。

商用負載均衡裏面NetScaler從效果上比F5的效率上更高。對於負載均衡器來說，不過商用負載均衡由於可以建立在四~七層協議之上，因此適用面更廣所以有其不可替代性，他的優點就是有專業的維護團隊來對這些服務進行維護、缺點就是花銷太大，所以對於規模較小的網絡服務來說暫時還沒有需要使用。

另一種負載均衡的方式是通過軟件：比較常見的有LVS、Nginx、HAproxy等，其中LVS是建立在四層協議上面的，而另外Nginx和HAproxy是建立在七層協議之上的，下面分別介紹關於

Nginx的特點是：

1、工作在網絡的7層之上，可以針對http應用做一些分流的策略，比如針對域名、目錄結構；

2、Nginx對網絡的依賴比較小；

3、Nginx安裝和配置比較簡單，測試起來比較方便；

4、也可以承擔高的負載壓力且穩定，一般能支撐超過1萬次的併發；

5、Nginx可以通過端口檢測到服務器內部的故障，比如根據服務器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點，不過其中缺點就是不支持url來檢測；

6、Nginx對請求的異步處理可以幫助節點服務器減輕負載；

7、Nginx能支持http和Email，這樣就在適用範圍上面小很多；

8、不支持Session的保持、對Big request header的支持不是很好，另外默認的只有Round-robin和IP-hash兩種負載均衡算法。

HAProxy的特點是：

1、HAProxy是工作在網絡7層之上。

2、能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作

3、支持url檢測後端的服務器出問題的檢測會有很好的幫助。

4、更多的負載均衡策略比如：動態加權輪循(Dynamic Round Robin)，加權源地址哈希(Weighted Source Hash)，加權URL哈希和加權參數哈希(Weighted Parameter Hash)已經實現

5、單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度。

6、HAProxy可以對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡。

1.5.2 軟負載均衡器性能對比

上圖是網上的數據，LVS的實際性能可能沒有展示出來，肯定要比Nginx的併發量高。

2 LVS原理篇

2.1 工作模式

LVS的IP負載均衡技術是通過IPVS模塊來實現的，IPVS是LVS集羣系統的核心軟件，它的主要作用是：安裝在Director Server上，同時在Director Server上虛擬出一個IP地址，用戶必須通過這個虛擬的IP地址訪問服務。這個虛擬IP一般稱爲LVS的VIP，即Virtual IP。訪問的請求首先經過VIP到達負載調度器，然後由負載調度器從Real Server列表中選取一個服務節點響應用戶的請求。

當用戶的請求到達負載調度器後，調度器如何將請求發送到提供服務的Real Server節點，而Real Server節點如何返回數據給用戶，是IPVS實現的重點技術，IPVS實現負載均衡機制有三種，分別是NAT、TUN和DR。

注意：

director server 、ld 、lvs負責均衡器、調度器都是同一個概念

realserver 、後端服務器也代表一個意思。

2.1.1 轉發機制

2.1.1.1 三種轉發機制

VS/NAT：即（Virtual Server via Network Address Translation）

也就是網絡地址翻譯技術實現虛擬服務器，當用戶請求到達調度器時，調度器將請求報文的目標地址（即虛擬IP地址）改寫成選定的Real Server地址，同時報文的目標端口也改成選定的Real Server的相應端口，最後將報文請求發送到選定的Real Server。在服務器端得到數據後，Real Server返回數據給用戶時，需要再次經過負載調度器將報文的源地址和源端口改成虛擬IP地址和相應端口，然後把數據發送給用戶，完成整個負載調度過程。

可以看出，在NAT方式下，用戶請求和響應報文都必須經過Director Server地址重寫，當用戶請求越來越多時，調度器的處理能力將稱爲瓶頸。

VS/TUN ：即（Virtual Server via IP Tunneling）l

也就是IP隧道技術實現虛擬服務器。它的連接調度和管理與VS/NAT方式一樣，只是它的報文轉發方法不同，VS/TUN方式中，調度器採用IP隧道技術將用戶請求轉發到某個Real Server，而這個Real Server將直接響應用戶的請求，不再經過前端調度器，此外，對Real Server的地域位置沒有要求，可以和Director Server位於同一個網段，也可以是獨立的一個網絡。因此，在TUN方式中，調度器將只處理用戶的報文請求，集羣系統的吞吐量大大提高。

VS/DR：即（Virtual Server via Direct Routing）l

也就是用直接路由技術實現虛擬服務器。它的連接調度和管理與VS/NAT和VS/TUN中的一樣，但它的報文轉發方法又有不同，VS/DR通過改寫請求報文的MAC地址，將請求發送到Real Server，而Real Server將響應直接返回給客戶，免去了VS/TUN中的IP隧道開銷。這種方式是三種負載調度機制中性能最高最好的，但是必須要求Director Server與Real Server都有一塊網卡連在同一物理網段上。

2.1.1.2 三種轉發機制流程

2.1.1.2.1 NAT

1. 客戶端發起請求到load balancer的虛擬ip

2. load banlancer把客戶請的目標地址改寫爲其中一個real server的，源地址改成不變。

3. realserver接受請求，並返回給load banlancer響應

4. load banlancer接受到響應，修改目標地址爲不變，源地址改成自己的。

5. 客戶端接受loader banlancer的響應

注意：

如果客戶端和realserver在同一個網段，不會執行nat轉換，realserver直接返回響應,客戶端也會拒收此報文。

2.1.1.2.2 TUNNEL

1. 客戶端發起請求到load balancer的虛擬ip

2. load banlancer把客戶的請求包包裹，然後轉發給其中的一個real server。

3. realserver接受請求，解包。得到客戶端發來的原始包。

4. realserver處理，把結果通過vip直接返回給客戶端。

5. 客戶端接受real server的響應。

注意：

a. load balancer和realserver 直接通過ip tunnel技術重新封裝、解包

b. load balancer和 realserver 使用相同的vip

c. load balnacer和realserver可以不再同一個網絡

2.1.1.2.3 DR

1. 客戶端發起請求到load balancer的虛擬ip

2. load banlancer把客戶發送的包，修改源mac地址爲vip的，目的mac地址爲realserver的，然後發送給realserver

3. realserver接受請求,並處理，然後把結果通過vip直接返回給客戶端。

4. 客戶端接受real server的響應。

注意

a. load balancer和 realserver 使用相同的vip

b. load balancer和realserver必須在同一個網絡，因爲load balancer需要知道realserver的mac地址。

2.1.1.2.4 LVS-DR工作原理詳解 (51CTO)

如下圖所示：VS/DR的體系結構：

我將結合這幅原理圖及具體的實例來講解一下LVS-DR的原理，包括數據包、數據幀的走向和轉換過程。

官方的原理說明：Director接收用戶的請求，然後根據負載均衡算法選取一臺realserver，將包轉發過去，最後由realserver直接回復給用戶。

實例場景設備清單：

說明：我這裏爲了方便，client是與vip同一網段的機器。如果是外部的用戶訪問，將client替換成gateway即可，因爲IP包頭是不變的，變的只是源mac地址。

① client向目標vip發出請求，Director接收。此時IP包頭及數據幀頭信息如下：

② VS根據負載均衡算法選擇一臺active的realserver(假設是192.168.57.122)，將此RIP所在網卡的mac地址作爲目標mac地址，發送到局域網裏。此時IP包頭及數據幀頭信息如下：

③ realserver(192.168.57.122)在局域網中收到這個幀，拆開後發現目標IP(VIP)與本地匹配，於是處理這個報文。隨後重新封裝報文，發送到局域網。此時IP包頭及數據幀頭信息如下：

④ 如果client與VS同一網段，那麼client(192.168.57.135)將收到這個回覆報文。如果跨了網段，那麼報文通過gateway/路由器經由Internet返回給用戶。

說明：

lvs的作者對這個寫了詳細的描述，請參考 http://www.linuxvirtualserver.org/zh/lvs3.html LVS集羣中的IP負載均衡技術

2.1.1.3 三種轉發機制的優缺點

◆Virtual Server via NAT

VS/NAT 的優點是服務器可以運行任何支持TCP/IP的操作系統，它只需要一個IP地址配置在LVS主機上，服務器組可以用私有的IP地址。缺點是它的擴充能力有限，當服務器結點數目升到20時，LVS主機本身有可能成爲系統的新瓶頸，因爲在VS/NAT中請求和響應封包都需要通過負載平衡LVS主機。在 Pentium 166主機上測得重寫封包的平均延時爲60us，假設TCP封包的平均長度爲536 Bytes，則LVS主機的最大吞吐量爲8.93 MBytes/s。再假設每臺服務器的吞吐量爲600KBytes/s，這樣一個LVS主機可以帶動16臺服務器。

◆Virtual Server via IP Tunneling

在VS/TUN 的集羣系統中，負載平衡LVS主機只將請求分配到不同的實際服務器，實際服務器將應答的資料直接返回給用戶。這樣，負載平衡LVS主機就可以處理巨量的請求，而不會成爲系統的瓶頸。即使負載平衡LVS主機只有100Mbps的全雙工網卡，虛擬服務器的最大吞吐量可以達到幾Gbps。所以，VS/TUN可以極大地增加負載平衡LVS主機分配的服務器數量，它可以用來構建高性能超級服務器。VS/TUN技術對服務器的要求是所有的服務器必須支持"IP Tunneling"或者"IP Encapsulation"協議。目前，VS/TUN 的後端服務器主要運行Linux操作系統。因爲"IP Tunneling"正成爲各個操作系統的標準協議，所以VS/TUN也會適用運行其它操作系統的後端服務器。

◆Virtual Server via Direct Routing

同VS/TUN 一樣，VS/DRLVS主機只處理客戶到服務器端的連接，響應資料可以直接從獨立的網絡路由返回給客戶。這可以極大地提高LVS集羣系統的伸縮性。同 VS/TUN相比，這種方法沒有IP隧道的開銷，但是要求負載平衡LVS主機與實際服務器都有一塊網卡連在同一物理網段上，服務器網絡設備或者設備別名不作 ARP 響應。

2.1.1.4 結論

	VS/NAT	VS/TUN	VS/DR
服務器(OS)	任意	支持隧道	多數(支持Non-arp )
服務器網絡	私有網絡	局域網/廣域網	局域網
服務器數目(100M網絡)	10~20	100	多(100)
服務器網關	負載均衡器	自己的路由	自己的路由
效率	一般	高	最高

三種IP負載均衡技術中特別是後兩種技術VS/TUN，VS/DR極大地提高系統的伸縮性。

2.1.2 調度算法

Director在接收到來自於Client的請求時，會基於"schedule"從RealServer中選擇一個響應給Client。ipvs支持以下調度算法：（1、2爲靜態調度算法，3、4、5、6、7、8爲動態調度算法）

1、輪詢（round robin, rr)

2．加權輪詢(Weighted round robin, wrr)——

新的連接請求被輪流分配至各RealServer；算法的優點是其簡潔性，它無需記錄當前所有連接的狀態，所以它是一種無狀態調度。輪叫調度算法假設所有服務器處理性能均相同，不管服務器的當前連接數和響應速度。該算法相對簡單，不適用於服務器組中處理性能不一的情況，而且當請求服務時間變化比較大時，輪叫調度算法容易導致服務器間的負載不平衡。

2、目標地址散列調度（Destination Hashing，dh）

算法也是針對目標IP地址的負載均衡，但它是一種靜態映射算法，通過一個散列（Hash）函數將一個目標IP地址映射到一臺服務器。目標地址散列調度算法先根據請求的目標IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。

3、源地址散列調度（Source Hashing，sh）

算法正好與目標地址散列調度算法相反，它根據請求的源IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。它採用的散列函數與目標地址散列調度算法的相同。除了將請求的目標IP地址換成請求的源IP地址外，它的算法流程與目標地址散列調度算法的基本相似。在實際應用中，源地址散列調度和目標地址散列調度可以結合使用在防火牆集羣中，它們可以保證整個系統的唯一出入口。

4、最少連接(least connected, lc)，加權最少連接(weighted least connection, wlc)——

新的連接請求將被分配至當前連接數最少的RealServer；最小連接調度是一種動態調度算法，它通過服務器當前所活躍的連接數來估計服務器的負載情況。調度器需要記錄各個服務器已建立連接的數目，當一個請求被調度到某臺服務器，其連接數加1；當連接中止或超時，其連接數減一。

lc：256*A+I=當前連接數 wlc：（256*A+I）/W=當前連接數【A：活動連接數 I:非活動連接數 W：權重值】

5、基於局部性的最少鏈接調度（Locality-Based Least Connections Scheduling，lblc）——

針對請求報文的目標IP地址的負載均衡調度，目前主要用於Cache集羣系統，因爲在Cache集羣中客戶請求報文的目標IP地址是變化的。這裏假設任何後端服務器都可以處理任一請求，算法的設計目標是在服務器的負載基本平衡情況下，將相同目標IP地址的請求調度到同一臺服務器，來提高各臺服務器的訪問局部性和主存Cache命中率，從而整個集羣系統的處理能力。LBLC調度算法先根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於其一半的工作負載，則用“最少鏈接”的原則選出一個可用的服務器，將請求發送到該服務器。

6、帶複製的基於局部性最少鏈接調度（Locality-Based Least Connections with Replication Scheduling，lblcr）

——也是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。它與LBLC算法的不同之處是它要維護從一個目標IP地址到一組服務器的映射，而 LBLC算法維護從一個目標IP地址到一臺服務器的映射。對於一個“熱門”站點的服務請求，一臺Cache 服務器可能會忙不過來處理這些請求。這時，LBLC調度算法會從所有的Cache服務器中按“最小連接”原則選出一臺Cache服務器，映射該“熱門”站點到這臺Cache服務器，很快這臺Cache服務器也會超載，就會重複上述過程選出新的Cache服務器。這樣，可能會導致該“熱門”站點的映像會出現在所有的Cache服務器上，降低了Cache服務器的使用效率。LBLCR調度算法將“熱門”站點映射到一組Cache服務器（服務器集合），當該“熱門”站點的請求負載增加時，會增加集合裏的Cache服務器，來處理不斷增長的負載；當該“熱門”站點的請求負載降低時，會減少集合裏的Cache服務器數目。這樣，該“熱門”站點的映像不太可能出現在所有的Cache服務器上，從而提供Cache集羣系統的使用效率。LBLCR算法先根據請求的目標IP地址找出該目標IP地址對應的服務器組；按“最小連接”原則從該服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載；則按“最小連接”原則從整個集羣中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低複製的程度。

7、最短的期望的延遲（Shortest Expected Delay Scheduling ,sed）

sed: (A+1)/w=當前連接數

8、最少隊列調度（Never Queue Scheduling ,nq）

無需隊列。如果有臺realserver的連接數＝0就直接分配過去，不需要在進行sed運算

四、關於LVS追蹤標記fwmark

如果LVS放置於多防火牆的網絡中，並且每個防火牆都用到了狀態追蹤的機制，那麼在迴應一個針對於LVS的連接請求時必須經過此請求連接進來時的防火牆，否則，這個響應的數據包將會被丟棄

說明：作者寫了詳細的調度算法優缺點可以查看

http://www.linuxvirtualserver.org/zh/lvs4.html LVS集羣的負載調度