1.1.3　以LVS作為負載均衡器

LVS英文全稱為Linux Virtual Server，這是章文嵩博士主持的自由項目。

LVS使用集群技術和Linux操作系統實現一個高性能、高可用的服務器，它具有很好的可伸縮性（Scalability）、可靠性（Reliability）和可管理性（Manageability），感謝章文嵩博士為我們提供如此強大實用的開源軟件。

LVS是一個負載均衡/高可用性集群，主要針對大業務量的網絡應用（如新聞服務、網上銀行、電子商務等）。它建立在一個主控服務器（通常為雙機）及若干真實服務器（Real-Server）所組成的集群之上。Real-Server負責實際提供服務，主控服務器根據指定的調度算法對Real-Server進行控制。而集群的結構對于用戶來說是透明的，客戶端只與單個的IP（集群系統的虛擬IP）進行通信，也就是說從客戶端的視角來看，這里只存在單個服務器。Real-Server可以提供眾多服務，如FTP、HTTP、DNS、Telnet、SMTP等，現在比較流行的是將其用于MySQL集群中。主控服務器負責對Real-Server進行控制?？蛻舳嗽谙騆VS發出服務請求時，后者會通過特定的調度算法指定由某個Real-Server來應答請求，客戶端只會與負載均衡器的IP（即VIP）進行通信。以上工作流程用LVS的工作拓撲圖來說明的話，效果可能更好，如圖1-1所示。

1.LVS集群的體系結構

通常來講，Linux集群在設計時需要考慮系統的透明性、可伸縮性、高可用性和易管理性。一般來說，LVS集群采用三層結構，這三層結構的主要組成部分如下。

·負載均衡器（load balancer），它是整個集群對外的前端機，負責將客戶的請求發送到一組服務器上執行，而客戶認為服務是來自一個IP地址（我們可稱之為虛擬IP地址）上的。

·服務器池（server pool），它是一組真正執行客戶請求的服務器，執行的服務有Web、MAIL、FTP和DNS等。

·共享存儲（shared storage），它為服務器池提供了一個共享的存儲區，這樣很容易使得服務器池擁有相同的內容，提供相同的服務。

負載均衡器是服務器集群系統的唯一入口點（Single Entry Point），它可以采用IP負載均衡技術、基于內容請求分發技術或者兩者相結合。在IP負載均衡技術中，需要服務器池擁有相同的內容，提供相同的服務。當客戶請求到達時，負載均衡器只需要根據服務器負載情況和設定的調度算法從服務器池中選出一個服務器，將該請求轉發到選出的服務器，并記錄這個調度即可；當這個請求的其他報文到達時，也會被轉發到前面選出的服務器上。對于基于內容請求分發技術，服務器可以提供不同的服務，當客戶請求到達時，負載均衡器可根據請求的內容選擇服務器來執行請求。因為所有的操作都是在Linux操作系統核心空間中將完成的，它的調度開銷很小，所以它具有很高的吞吐率。

圖1-1　LVS集群的體系結構

服務器池的節點數目是可變的。當整個系統收到的負載超過目前所有節點的處理能力時，可以通過在服務器池中增加服務器來滿足不斷增長的請求負載。對大多數網絡服務來說，各請求之間不存在很強的相關性，請求可以在不同的節點上并行執行，所以整個系統的性能基本上可以隨著服務器池節點數目的增加而線性增長。

共享存儲通常是通過數據庫、網絡文件系統或者分布式文件系統來實現的。服務器節點上需要動態更新的數據一般存儲在數據庫系統中，同時數據庫會保證并發訪問時數據的一致性。靜態數據可以存儲在網絡文件系統（如NFS/CIFS）中，但網絡文件系統的伸縮能力有限，一般來說，NFS/CIFS服務器只能支持3～6個繁忙的服務器節點。對于規模較大的集群系統，可以考慮用分布式文件系統，如AFS、GFS、Coda和Intermezzo等。分布式文件系統可為各服務器提供共享存儲區，它們訪問分布式文件系統就像訪問本地文件系統一樣，同時分布式文件系統可提供良好的伸縮性和可用性。此外，當不同服務器上的應用程序同時讀寫訪問分布式文件系統上的同一資源時，應用程序的訪問沖突需要消解才能使得資源處于一致狀態。這需要一個分布式鎖管理器（Distributed Lock Manager），它可能是分布式文件系統內部，也可能是外部提供的。開發者在編寫應用程序時，可以使用分布式鎖管理器來保證應用程序在不同節點上并發訪問的一致性。

負載均衡、服務器池和共享存儲系統通過高速網絡相連接，如100Mbit/s交換網絡、Myrinet和Gigabit網絡等。使用高速的網絡主要是為避免當系統規模擴大時互聯網絡成為整個系統的瓶頸。

2.LVS中的IP負載均衡算法

用戶通過虛擬IP地址（Virtual IP Address）訪問服務時，訪問請求的報文會到達負載均衡器，由它進行負載均衡調度，從一組真實服務器中選出一個，將報文的目標地址改寫成選定服務器的地址，然后將報文的目標端口改寫成選定服務器的相應端口，最后將報文發送給選定的服務器。真實服務器的回應報文經過負載均衡器時，會將報文的源地址和源端口改為Virtual IP Address和相應的端口，再把報文發給用戶。Berkeley的MagicRouter、Cisco的LocalDirector、Alteon的ACEDirector和F5的Big/IP等都是使用網絡地址轉換方法。MagicRouter是在Linux 1.3版本上應用快速報文插入技術，使得進行負載均衡調度的用戶進程訪問網絡設備時接近核心空間的速度，降低了上下文切換的處理開銷，但并不徹底，它只是研究的原型系統，沒有成為有用的系統存活下來。Cisco的LocalDirector、Alteon的ACEDirector和F5的Big/IP是非常昂貴的商品化系統，它們支持部分TCP/UDP，有些在ICMP處理上存在問題。

IBM的TCP Router使用修改過的網絡地址轉換方法在SP/2系統實現可伸縮的Web服務器。TCP Router修改請求報文的目標地址并把它轉發給選出的服務器，服務器能把響應報文的源地址置為TCP Router地址而非自己的地址。這種方法的好處是響應報文可以直接返回給客戶，壞處是每臺服務器的操作系統內核都需要修改。IBM的NetDispatcher是TCP Router的后繼者，它將報文轉發給服務器，而服務器在無ARP的設備上配置路由器的地址。這種方法與LVS集群中的VS/DR類似，它具有很高的可伸縮性，但一套IBM SP/2和NetDispatcher需要上百萬美元。

在貝爾實驗室的ONE-IP中，每臺服務器都有獨立的IP地址，但都會用IP Alias配置上同一VIP地址，并采用路由和廣播兩種方法分發請求，服務器收到請求后按VIP地址處理請求，并以VIP為源地址返回結果。這種方法也是為了避免回應報文的重寫，但是每臺服務器用IP Alias配置上同一VIP地址會導致地址沖突，有些操作系統甚至會出現網絡失效。通過廣播分發請求，同樣需要修改服務器操作系統的源碼來過濾報文，使得只有一臺服務器來處理廣播的請求。

微軟的Windows NT負載均衡服務（Windows NT Load Balancing Service，WLBS）是1998年年底收購Valence Research公司獲得的，它與ONE-IP中基于本地的過濾方法一樣。WLBS作為過濾器運行在網卡驅動程序和TCP/IP協議棧之間，獲得目標地址為VIP的報文，它通過過濾算法檢查報文的源IP地址和端口號，保證只有一臺服務器將報文交給上一層處理。但是，當有新節點加入或有節點失效時，所有服務器需要協商一個新的過濾算法，這會導致所有Session的連接中斷。同時，WLBS會要求所有服務器都有相同的配置，如網卡速度和處理能力。

3.通過NAT實現虛擬服務器（VS/NAT）

由于IPv4中IP地址空間日益緊張，且存在安全方面的問題，因此很多網絡會使用保留的IP地址（10.0.0.0/255.0.0.0、172.16.0.0/255.128.0.0和192.168.0.0/255.255.0.0）。這些地址不會在Internet上使用，它是專門為內部網絡預留的。當內部網絡中的主機要訪問Internet或被Internet訪問時，就需要采用網絡地址轉換（Network Address Translation，NAT），將內部地址轉化為Internet上可用的外部地址。NAT的工作原理是報文頭（目標地址、源地址和端口等）被正確改寫后，客戶相信它們連接了一個IP地址，而不同IP地址的服務器組也認為它們是與客戶直接相連的。因此，可以用NAT方法將不同IP地址的并行網絡服務變成在一個IP地址上的虛擬服務。

VS/NAT的體系結構比較簡單，在一組服務器前有一個負載均衡器，它們是通過Switch/HUB相連接的。這些服務器提供相同的網絡服務、相同的內容，即不管請求被發送到哪一臺服務器，執行的結果是一樣的。服務的內容可以復制到每臺服務器的本地硬盤上，可以通過網絡文件系統（如NFS）共享，也可以通過一個分布式文件系統來提供。

客戶通過Virtual IP Address（虛擬服務的IP地址）訪問網絡服務時，請求報文到達負載均衡器，負載均衡器會根據連接調度算法從一組真實服務器中選出一臺服務器，并將報文的目標地址Virtual IP Address改寫成選定服務器的地址，將報文的目標端口改寫成選定服務器的相應端口，最后將修改后的報文發送給選出的服務器。同時，負載均衡器會在連接Hash表中記錄這個連接，當這個連接的下一個報文到達時，從連接Hash表中可以得到原選定服務器的地址和端口，在進行同樣的改寫操作后，將報文傳給原選定的服務器。當來自真實服務器的響應報文經過負載均衡器時，負載均衡器會將報文的源地址和源端口改為Virtual IP Address和相應的端口，再把報文發送給用戶。我們在連接上引入一個狀態機時，不同的報文會使得連接處于不同的狀態，不同的狀態有不同的超時值。在TCP連接中，根據標準的TCP有限狀態機進行狀態遷移，這里不一一敘述，請參見W.Richard Stevens的TCP/IP Illustrated Volume I。在UDP中，我們只設置一個UDP狀態。不同狀態的超時值是可以設置的，在默認情況下，SYN狀態的超時時間為1分鐘，ESTABLISHED狀態的超時時間為15分鐘，FIN狀態的超時時間為1分鐘；UDP狀態的超時時間為5分鐘。若連接終止或超時，負載均衡器會將這個連接從連接Hash表中刪除。

這樣，客戶看到的只是在Virtual IP Address上提供的服務，而服務器集群的結構對用戶是透明的。對改寫后的報文，應用增量調整校驗和的算法來調整TCP校驗和的值，避免了掃描整個報文來計算校驗和的開銷。

4.通過IP隧道實現虛擬服務器（VS/TUN）

在VS/NAT的集群系統中，請求和響應的數據報文都需要通過負載均衡器，當真實服務器的數目在10臺和20臺之間時，負載均衡器將成為整個集群系統的新瓶頸。大多數Internet服務都有這樣的特點：請求報文較短而響應報文往往包含大量的數據。如果能將請求和響應分開處理，即負載均衡器只負責調度請求而響應直接返回給客戶，將極大地提高整個集群系統的吞吐量。

IP隧道（IP tunneling）是將一個IP報文封裝在另一個IP報文中的技術，它使得一個IP地址的數據報文可被封裝和轉發到另一個IP地址。IP隧道技術亦稱為IP封裝技術（IP encapsulation）。IP隧道主要用于移動主機和虛擬私有網絡（Virtual Private Network），其中隧道都是靜態建立的，隧道的一端有一個IP地址，另一端也有唯一的IP地址。

我們利用IP隧道技術將請求報文封裝轉發給后端服務器后，響應報文能從后端服務器直接返回給客戶。但在這里，后端服務器有一組而非一個，所以我們不可能靜態地建立一一對應的隧道，而是會動態地選擇一臺服務器，將請求報文封裝和轉發給選出的服務器。這樣，就可以利用IP隧道的原理將一組服務器上的網絡服務變成在一個IP地址上的虛擬網絡服務。

5.通過直接路由實現虛擬服務器（VS/DR）

與VS/TUN方法相同，VS/DR利用大多數Internet服務的非對稱特點來實現虛擬服務器，負載均衡器只負責調度請求，由服務器直接將響應返回給客戶，可以極大地提高整個集群系統的吞吐量。該方法與IBM的NetDispatcher產品中使用的方法類似（服務器上IP地址的配置方法也是相似的），但IBM的NetDispatcher是非常昂貴的商品化產品，我們也不知道它內部所使用的機制，其中有些是IBM的專利。

VS/DR的體系結構比較簡單：負載均衡器和服務器組都必須在物理上有一個網卡，通過不分段的局域網相連，如通過高速的交換機或者HUB相連。VIP地址為負載均衡器和服務器組共享，負載均衡器配置的VIP地址是對外可見的，用于接收虛擬服務的請求報文；所有的服務器都會把VIP地址配置在各自的Non-ARP網絡設備上，它對外是不可見的，只是用于處理目標地址為VIP的網絡請求。

VS/DR的連接調度和管理與VS/NAT和VS/TUN一樣，它的報文轉發方法又有不同，它會將報文直接路由給目標服務器。在VS/DR中，負載均衡器根據各個服務器的負載情況，動態地選擇一臺服務器，不修改也不封裝IP報文，而是將數據幀的MAC地址改為選出的服務器的MAC地址，再將修改后的數據幀在服務器組的局域網上發送。因為數據幀的MAC地址是選出的服務器，所以服務器肯定可以接收到這個數據幀，從中獲得該IP報文。當服務器發現報文的目標地址VIP是在本地的網絡設備上時，服務器會處理這個報文，然后根據路由表將響應報文直接返回給客戶。

在VS/DR中，會根據默認的TCP/IP協議棧進行處理，既然請求報文的目標地址為VIP，響應報文的源地址肯定也為VIP，所以響應報文不需要做任何修改，即可直接返回給客戶，客戶得到正常的服務，但他不會知道是哪一臺服務器處理的。VS/DR負載均衡器與VS/TUN一樣只處于從客戶到服務器的半連接中，它會按照半連接的TCP有限狀態機進行狀態遷移。

6.LVS新模式FULLNAT簡介

在大規模的網絡下，如在淘寶網的業務中，官方LVS滿足不了需求，原因有以下3點：

1）三種轉發模式的部署成本比較高。

2）與商用的負載均衡比，LVS沒有DDoS防御攻擊功能。

3）它是主備部署模式，性能無法擴展。

針對這些問題，淘寶網技術團隊開發了LVS的FullNAT模式，它既可以跨VLAN通信，還有DDoS防御攻擊能力。最重要的是，它可以采用Cluster部署模式，可以基于FULLNAT模式做橫向擴展。

更詳細的文檔和資料說明請大家參考：

http://www.infoq.com/cn/news/2014/10/lvs-use-at-large-scala-network