LVS套用架構這裡在分析 伺服器集群實現 虛擬網路服務的相關技術上，詳細描述了LVS集群中實現的三種IP負載均衡技術
VS/NAT
VS/TUN
VS/DR
的工作原理，以及它們的優缺點。
簡述
可伸縮網路服務涉及到幾種不同的結構，它們都需要一個前端的負載調度器（或者多個進行主從備份）。
先分析實現虛擬網路服務的主要技術，指出 IP 負載均衡技術是在負載調度器的實現技術中效率最高的。在已有的IP負載均衡技術中，主要有通過網路地址轉換NAT（Network Address Translation）將一組伺服器構成一個高性能的、高可用的虛擬伺服器，稱之為VS/NAT技術（Virtual Server via Network Address Translation）。在分析VS/NAT的缺點和網路服務的非對稱性的基礎上，提出了通過IP隧道實現虛擬伺服器的方法VS/TUN （Virtual Server via IP Tunneling），和通過直接路由實現虛擬伺服器的方法VS/DR（Virtual Server via Direct Routing），它們可以極大地提高系統的伸縮性。VS/NAT、VS/TUN和VS/DR技術是LVS集群中實現的三種IP負載均衡技術，後面將詳細描述它們的工作原理和各自的優缺點。
實現虛擬服務的相關方法
在網路服務中，一端是客戶程式，另一端是服務程式，在中間可能有代理程式。由此看來，可以在不同的層次上實現多台伺服器的負載均衡。用集群解決網路服務性能問題的現有方法主要分為以下四類。
基於RR-DNS的解決方法
NCSA的可伸縮的WEB伺服器系統就是最早基於RR-DNS（Round-Robin Domain Name System）的原型系統。它的結構和工作流程如下圖所示：
基於RR-DNS的可伸縮WEB伺服器有一組WEB伺服器，他們通過分散式檔案系統 AFS(Andrew File System)來共享所有的HTML文檔。這組伺服器擁有相同的域名（如www.ncsa.uiuc.edu），當用戶按照這個域名訪問時,RR-DNS伺服器會把域名輪流解析到這組伺服器的不同IP位址，從而將訪問負載分到各台伺服器上。
這種方法帶來幾個問題。第一，域名伺服器是一個分散式系統，是按照一定的層次結構組織的。當用戶就域名解析請求提交給本地的域名伺服器，它會因不能直接解析而向上一級域名伺服器提交，上一級域名伺服器再依次向上提交，直到RR-DNS域名服器把這個域名解析到其中一台伺服器的IP位址。可見，從用戶到RR-DNS間存在多台域名服器，而它們都會緩衝已解析的名字到IP位址的映射,這會導致該域名服器組下所有用戶都會訪問同一WEB伺服器，出現不同WEB伺服器間嚴重的負載不平衡。為了保證在域名伺服器中域名到IP位址的映射不被長久緩衝，RR-DNS在域名到IP位址的映射上設定一個TTL(TimeToLive)值，過了這一段時間，域名伺服器將這個映射從緩衝中淘汰。當用戶請求，它會再向上一級域名服器提交請求並進行重新影射。這就涉及到如何設定這個TTL值，若這個值太大，在這個TTL期間，很多請求會被映射到同一台WEB伺服器上，同樣會導致嚴重的負載不平衡。若這個值太小，例如是０，會導致本地域名伺服器頻繁地向RR-DNS提交請求，增加了域名解析的網路流量，同樣會使RR-DNS伺服器成為系統中一個新的瓶頸。
第二，用戶機器會緩衝從名字到IP位址的映射，而不受TTL值的影響，用戶的訪問請求會被送到同一台WEB伺服器上。由於用戶訪問請求的突發性和訪問方式不同，例如有的人訪問一下就離開了，而有的人訪問可長達幾個小時，所以各台伺服器間的負載仍存在傾斜（Skew）而不能控制。假設用戶在每個會話中平均請求數為20，負載最大的伺服器獲得的請求數額高於各伺服器平均請求數的平均比率超過百分之三十。也就是說，當TTL值為0時，因為用戶訪問的突發性也會存在著較嚴重的負載不平衡。
第三，系統的可靠性和可維護性差。若一台伺服器失效，會導致將域名解析到該伺服器的用戶看到服務中斷，即使用戶按“Reload”按鈕，也無濟於事。系統管理員也不能隨時地將一台伺服器切出服務進行系統維護，如進行作業系統和套用軟體升級，這需要修改RR-DNS伺服器中的IP位址列表，把該伺服器的IP位址從中劃掉，然後等上幾天或者更長的時間，等所有域名服器將該域名到這台伺服器的映射淘汰，和所有映射到這台伺服器的客戶機不再使用該站點為止。
基於客戶端的解決方法
基於客戶端的解決方法需要每個客戶程式都有一定的伺服器集群的知識，進而把以負載均衡的方式將請求發到不同的伺服器。例如，Netscape Navigator瀏覽器訪問Netscape的主頁時，它會隨機地從一百多台伺服器中挑選第N台，最後將請求送往wwwN.netscape.com。然而，這不是很好的解決方法，Netscape只是利用它的Navigator避免了RR-DNS解析的麻煩，當使用IE等其他瀏覽器不可避免的要進行RR-DNS解析。
Smart Client是Berkeley做的另一種基於客戶端的解決方法。服務提供一個Java Applet在客戶方瀏覽器中運行，Applet向各個伺服器發請求來收集伺服器的負載等信息，再根據這些信息將客戶的請求發到相應的伺服器。高可用性也在Applet中實現，當伺服器沒有回響時，Applet向另一個伺服器轉發請求。這種方法的透明性不好，Applet向各伺服器查詢來收集信息會增加額外的網路流量，不具有普遍的適用性。
基於套用層負載均衡調度的解決方法
多台伺服器通過高速的網際網路連線成一個集群系統，在前端有一個基於套用層的負載調度器。當用戶訪問請求到達調度器時，請求會提交給作負載均衡調度的應用程式，分析請求，根據各個伺服器的負載情況，選出一台伺服器，重寫請求並向選出的伺服器訪問，取得結果後，再返回給用戶。
套用層負載均衡調度的典型代表有Zeus負載調度器、pWeb、Reverse-Proxy和SWEB等。Zeus負載調度器是Zeus公司的商業產品，它是在Zeus Web伺服器程式改寫而成的，採用單進程事件驅動的伺服器結構。pWeb就是一個基於Apache 1.1伺服器程式改寫而成的並行WEB調度程式，當一個HTTP請求到達時，pWeb會選出一個伺服器，重寫請求並向這個伺服器發出改寫後的請求，等結果返回後，再將結果轉發給客戶。Reverse-Proxy利用Apache 1.3.1中的Proxy模組和Rewrite模組實現一個可伸縮WEB伺服器，它與pWeb的不同之處在於它要先從Proxy的cache中查找後，若沒有這個副本，再選一台伺服器，向伺服器傳送請求，再將伺服器返回的結果轉發給客戶。SWEB是利用HTTP中的redirect錯誤代碼，將客戶請求到達一台WEB伺服器後，這個WEB伺服器根據自己的負載情況，自己處理請求，或者通過redirect錯誤代碼將客戶引到另一台WEB伺服器，以實現一個可伸縮的WEB伺服器。
基於套用層負載均衡調度的多伺服器解決方法也存在一些問題。第一，系統處理開銷特別大，致使系統的伸縮性有限。當請求到達負載均衡調度器至處理結束時，調度器需要進行四次從核心到用戶空間或從用戶空間到核心空間的上下文切換和記憶體複製；需要進行二次TCP連線，一次是從用戶到調度器，另一次是從調度器到真實伺服器；需要對請求進行分析和重寫。這些處理都需要不小的ＣＰＵ、記憶體和網路等資源開銷，且處理時間長。所構成系統的性能不能接近線性增加的，一般伺服器組增至3或4台時，調度器本身可能會成為新的瓶頸。所以，這種基於套用層負載均衡調度的方法的伸縮性極其有限。第二，基於套用層的負載均衡調度器對於不同的套用，需要寫不同的調度器。以上幾個系統都是基於HTTP協定，若對於FTP、Mail、POP3等套用，都需要重寫調度器。
基於IP層負載均衡調度的解決方法
用戶通過虛擬IP位址（Virtual IP Address）訪問服務時，訪問請求的報文會到達負載調度器，由它進行負載均衡調度，從一組真實伺服器選出一個，將報文的目標地址Virtual IP Address改寫成選定伺服器的地址，報文的目標連線埠改寫成選定伺服器的相應連線埠，最後將報文傳送給選定的伺服器。真實伺服器的回應報文經過負載調度器時，將報文的源地址和源連線埠改為Virtual IP Address和相應的連線埠，再把報文發給用戶。Berkeley的Magic Router、Cisco的Local Director、Alteon的ACE Director和F5的Big/IP等都是使用網路地址轉換方法。Magic Router是在Linux 1.3版本上套用快速報文插入技術，使得進行負載均衡調度的用戶進程訪問網路設備接近核心空間的速度，降低了上下文切換的處理開銷，但並不徹底，它只是研究的原型系統，沒有成為有用的系統存活下來。Cisco的Local Director、Alteon的ACE Director和F5的Big/IP是非常昂貴的商品化系統，它們支持部分TCP/UDP協定，有些在ICMP處理上存在問題。
IBM的TCP Router使用修改過的網路地址轉換方法在SP/2系統實現可伸縮的WEB伺服器。TCP Router修改請求報文的目標地址並把它轉發給選出的伺服器，伺服器能把回響報文的源地址置為TCP Router地址而非自己的地址。這種方法的好處是回響報文可以直接返回給客戶，壞處是每台伺服器的作業系統核心都需要修改。IBM的 NetDispatcher[10]是TCP Router的後繼者，它將報文轉發給伺服器，而伺服器在non-ARP的設備配置路由器的地址。這種方法與LVS集群中的VS/DR類似，它具有很高的可伸縮性，但一套在IBM SP/2和Net Dispatcher需要上百萬美金。總的來說，IBM的技術還挺不錯的。
在貝爾實驗室的 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需要所有的伺服器有相同的配置，如網卡速度和處理能力。
通過NAT實現虛擬伺服器（VS/NAT）
由於IPv4中IP位址空間的日益緊張和安全方面的原因，很多網路使用保留IP位址（10.0.0.0/255.0.0.0、172.16.0.0/255.240.0.0和192.168.0.0/255.255.0.0）。這些地址不在Internet上使用，而是專門為內部網路預留的。當內部網路中的主機要訪問Internet或被Internet訪問時，就需要採用網路地址轉換（Network Address Translation, 以下簡稱NAT），將內部地址轉化為Internets上可用的外部地址。NAT的工作原理是報文頭（目標地址、源地址和連線埠等）被正確改寫後，客戶相信它們連線一個IP位址，而不同IP位址的伺服器組也認為它們是與客戶直接相連的。由此，可以用NAT方法將不同IP位址的並行網路服務變成在一個IP位址上的一個虛擬服務。
VS/NAT的體系結構如下圖所示。在一組伺服器前有一個調度器，它們是通過 Switch/ HUB相連線的。這些伺服器提供相同的網路服務、相同的內容，即不管請求被傳送到哪一台伺服器，執行結果是一樣的。服務的內容可以複製到每台伺服器的本地硬碟上，可以通過網路檔案系統（如NFS）共享，也可以通過一個分散式檔案系統來提供。
VS/NAT的體系結構客戶通過Virtual IP Address（虛擬服務的IP位址）訪問網路服務時，請求報文到達調度器，調度器根據連線調度算法從一組真實伺服器中選出一台伺服器，將報文的目標地址Virtual IP Address改寫成選定伺服器的地址，報文的目標連線埠改寫成選定伺服器的相應連線埠，最後將修改後的報文傳送給選出的伺服器。同時，調度器在連線Hash表中記錄這個連線，當這個連線的下一個報文到達時，從連線Hash表中可以得到原選定伺服器的地址和連線埠，進行同樣的改寫操作，並將報文傳給原選定的伺服器。當來自真實伺服器的回響報文經過調度器時，調度器將報文的源地址和源連線埠改為Virtual IP Address和相應的連線埠，再把報文發給用戶。在連線上引入一個狀態機，不同的報文會使得連線處於不同的狀態，不同的狀態有不同的逾時值。在TCP連線中，根據標準的TCP有限狀態機進行狀態遷移，這裡不一一敘述，請參見W.RichardStevens的《TCP/IPIllustratedVolumeI》；在UDP中，只設定一個UDP狀態。不同狀態的逾時值是可以設定的，在預設情況下，SYN狀態的逾時為1分鐘，ESTABLISHED狀態的逾時為15分鐘，FIN狀態的逾時為1分鐘；UDP狀態的逾時為5分鐘。當連線終止或逾時，調度器將這個連線從連線Hash表中刪除。
這樣，客戶所看到的只是在Virtual IP Address上提供的服務，而伺服器集群的結構對用戶是透明的。對改寫後的報文，套用增量調整Checksum的算法調整TCP Checksum的值，避免了掃描整個報文來計算Checksum的開銷。
在一些網路服務中，它們將IP位址或者連線埠號在報文的數據中傳送，若只對報文頭的IP位址和連線埠號作轉換，這樣就會出現不一致性，服務會中斷。所以，針對這些服務，需要編寫相應的套用模組來轉換報文數據中的IP位址或者連線埠號。所知道有這個問題的網路服務有FTP、IRC、H.323、CUSeeMe、RealAudio、RealVideo、Vxtreme/Vosiac、VDOLive、VIVOActive、TrueSpeech、RSTP、PPTP、StreamWorks、NTTAudioLink、NTTSoftwareVision、YamahaMIDPlug、iChatPager、Quake和Diablo。
下面，舉個例子來進一步說明VS/NAT，如圖所示：
VS/NAT的例子VS/NAT的配置如下所示，所有到IP位址為202.103.106.5和連線埠為80的流量都被負載均衡地調度的真實伺服器172.16.0.2:80和 172.16.0.3:8000上。目標地址為202.103.106.5:21的報文被轉移到172.16.0.3:21上。而到其他連線埠的報文將被拒絕。
Protocol Virtual IP Address Port Real IP Address Port Weight
TCP 202.103.106.5 80 172.16.0.2 80 1
172.16.0.38000 2
TCP202.103.106.5 21172.16.0.321 1
從以下的例子中，可以更詳細地了解報文改寫的流程。
訪問Web服務的報文可能有以下的源地址和目標地址：
SOURCE 202.100.1.2:3456 DEST 202.103.106.5:80
調度器從調度列表中選出一台伺服器，例如是172.16.0.3:8000。該報文會被改寫為如下地址，並將它傳送給選出的伺服器。
SOURCE202.100.1.2:3456 DEST 172.16.0.3:8000
從伺服器返回到調度器的回響報文如下：
SOURCE172.16.0.3:8000 DEST202.100.1.2:3456
回響報文的源地址會被改寫為虛擬服務的地址，再將報文傳送給客戶：
SOURCE202.103.106.5:80 DEST 202.100.1.2:3456
這樣，客戶認為是從202.103.106.5:80服務得到正確的回響，而不會知道該請求是伺服器172.16.0.2還是伺服器172.16.0.3處理的。
通過IP隧道實現虛擬伺服器（VS/TUN）
在VS/NAT的集群系統中，請求和回響的數據報文都需要通過負載調度器，當真實伺服器的數目在10台和20台之間時，負載調度器將成為整個集群系統的新瓶頸。大多數Internet服務都有這樣的特點：請求報文較短而回響報文往往包含大量的數據。如果能將請求和回響分開處理，即在負載調度器中只負責調度請求而回響直接返回給客戶，將極大地提高整個集群系統的吞吐量。
IP隧道（IP tunneling）是將一個IP報文封裝在另一個IP報文的技術，這可以使得目標為一個IP位址的數據報文能被封裝和轉發到另一個IP位址。IP隧道技術亦稱為IP封裝技術（IPencapsulation）。IP隧道主要用於移動主機和虛擬私有網路（Virtua lP rivate Network），在其中隧道都是靜態建立的，隧道一端有一個IP位址，另一端也有唯一的IP位址。
利用IP隧道技術將請求報文封裝轉發給後端伺服器，回響報文能從後端伺服器直接返回給客戶。但在這裡，後端伺服器有一組而非一個，所以不可能靜態地建立一一對應的隧道，而是動態地選擇一台伺服器，將請求報文封裝和轉發給選出的伺服器。這樣，可以利用IP隧道的原理將一組伺服器上的網路服務組成在一個IP位址上的虛擬網路服務。VS/TUN的體系結構如圖所示，各個伺服器將VIP位址配置在自己的IP隧道設備上。
VS/TUN的體系結構VS/TUN 的工作流程如上圖所示：它的連線調度和管理與VS/NAT中的一樣，只是它的報文轉發方法不同。調度器根據各個伺服器的負載情況，動態地選擇一台伺服器，將請求報文封裝在另一個IP報文中，再將封裝後的IP報文轉發給選出的伺服器；伺服器收到報文後，先將報文解封獲得原來目標地址為VIP的報文，伺服器發現VIP位址被配置在本地的IP隧道設備上，所以就處理這個請求，然後根據路由表將回響報文直接返回給客戶。
VS/TUN的工作流程需要指出，根據預設的TCP/IP協定棧處理，請求報文的目標地址為VIP，回響報文的源地址肯定也為VIP，所以回響報文不需要作任何修改，可以直接返回給客戶，客戶認為得到正常的服務，而不會知道究竟是哪一台伺服器處理的。
半連線的TCP有限狀態機通過直接路由實現虛擬伺服器（VS/DR）
跟VS/TUN方法相同，VS/DR利用大多數Internet服務的非對稱特點，負載調度器中只負責調度請求，而伺服器直接將回響返回給客戶，可以極大地提高整個集群系統的吞吐量。該方法與IBM的Net Dispatcher產品中使用的方法類似（其中伺服器上的IP位址配置方法是相似的），但IBM的Net Dispatcher是非常昂貴的商品化產品，也不清楚它內部所使用的機制，其中有些是IBM的專利。
VS/DR的體系結構如圖所示：調度器和伺服器組都必須在物理上有一個網卡通過不分斷的區域網路相連，如通過高速的交換機或者HUB相連。VIP位址為調度器和伺服器組共享，調度器配置的VIP位址是對外可見的，用於接收虛擬服務的請求報文；所有的伺服器把VIP位址配置在各自的Non-ARP網路設備上，它對外面是不可見的，只是用於處理目標地址為VIP的網路請求。
VS/DR的體系結構VS/DR的工作流程如上圖所示：它的連線調度和管理與VS/NAT和VS/TUN中的一樣，它的報文轉發方法又有不同，將報文直接路由給目標伺服器。在VS/DR中，調度器根據各個伺服器的負載情況，動態地選擇一台伺服器，不修改也不封裝IP報文，而是將數據幀的MAC地址改為選出伺服器的MAC地址，再將修改後的數據幀在與伺服器組的區域網路上傳送。因為數據幀的MAC地址是選出的伺服器，所以伺服器肯定可以收到這個數據幀，從中可以獲得該IP報文。當伺服器發現報文的目標地址VIP是在本地的網路設備上，伺服器處理這個報文，然後根據路由表將回響報文直接返回給客戶。
VS/DR的工作流程在VS/DR中，根據預設的TCP/IP協定棧處理，請求報文的目標地址為VIP，回響報文的源地址肯定也為VIP，所以回響報文不需要作任何修改，可以直接返回給客戶，客戶認為得到正常的服務，而不會知道是哪一台伺服器處理的。
VS/DR負載調度器跟VS/TUN一樣只處於從客戶到伺服器的半連線中，按照半連線的TCP有限狀態機進行狀態遷移。
三種方法的優缺點比較
三種IP負載均衡技術的優缺點歸納在下表中：
| VS/NAT | VS/TUN | VS/DR | |
| server any | Tunneling | Non-arp | device |
| server network | private | LAN/WAN | LAN |
| server number | low(10~20) | High(100) | High(100) |
| server gateway | load balancer | own router | own router |
註：以上三種方法所能支持最大伺服器數目的估計是假設調度器使用100M網卡，調度器的硬體配置與後端伺服器的硬體配置相同，而且是對一般Web服務。使用更高的硬體配置（如千兆網卡和更快的處理器）作為調度器，調度器所能調度的伺服器數量會相應增加。當套用不同時，伺服器的數目也會相應地改變。所以，以上數據估計主要是為三種方法的伸縮性進行量化比較。
Virtual Server via NAT
VS/NAT的優點是伺服器可以運行任何支持TCP/IP的作業系統，它只需要一個IP位址配置在調度器上，伺服器組可以用私有的IP位址。缺點是它的伸縮能力有限，當伺服器結點數目升到20時，調度器本身有可能成為系統的新瓶頸，因為在VS/NAT中請求和回響報文都需要通過負載調度器。在Pentium 166 處理器的主機上測得重寫報文的平均延時為60us，性能更高的處理器上延時會短一些。假設TCP報文的平均長度為536 Bytes，則調度器的最大吞吐量為8.93 MBytes/s. 再假設每台伺服器的吞吐量為800KBytes/s，這樣一個調度器可以帶動10台伺服器。
基於VS/NAT的集群系統可以適合許多伺服器的性能要求。如果負載調度器成為系統新的瓶頸，可以有三種方法解決這個問題：混合方法、VS/TUN和 VS/DR。在DNS混合集群系統中，有若干個VS/NAT負載調度器，每個負載調度器帶自己的伺服器集群，同時這些負載調度器又通過RR-DNS組成簡單的域名。但VS/TUN和VS/DR是提高系統吞吐量的更好方法。
對於那些將IP位址或者連線埠號在報文數據中傳送的網路服務，需要編寫相應的套用模組來轉換報文數據中的IP位址或者連線埠號。這會帶來實現的工作量，同時套用模組檢查報文的開銷會降低系統的吞吐率。
Virtual Server via IP Tunneling
在VS/TUN的集群系統中，負載調度器只將請求調度到不同的後端伺服器，後端伺服器將應答的數據直接返回給用戶。這樣，負載調度器就可以處理大量的請求，它甚至可以調度百台以上的伺服器（同等規模的伺服器），而它不會成為系統的瓶頸。即使負載調度器只有100Mbps的全雙工網卡，整個系統的最大吞吐量可超過 1Gbps。所以，VS/TUN可以極大地增加負載調度器調度的伺服器數量。VS/TUN調度器可以調度上百台伺服器，而它本身不會成為系統的瓶頸，可以用來構建高性能的超級伺服器。
VS/TUN技術對伺服器有要求，即所有的伺服器必須支持“IP Tunneling”或者“IP Encapsulation”協定。目前，VS/TUN的後端伺服器主要運行Linux作業系統，。因為“IP Tunneling”正成為各個作業系統的標準協定，所以VS/TUN應該會適用運行其他作業系統的後端伺服器。
Virtual Server via Direct Routing
跟VS/TUN方法一樣，VS/DR調度器只處理客戶到伺服器端的連線，回響數據可以直接從獨立的網路路由返回給客戶。這可以極大地提高LVS集群系統的伸縮性。
跟VS/TUN相比，這種方法沒有IP隧道的開銷，但是要求負載調度器與實際伺服器都有一塊網卡連在同一物理網段上，伺服器網路設備（或者設備別名）不作ARP回響，或者能將報文重定向（Redirect）到本地的Socket連線埠上。
總結
以上主要講述了LVS集群中的三種IP負載均衡技術。在分析網路地址轉換方法（VS/NAT）的缺點和網路服務的非對稱性的基礎上，我們給出了通過IP隧道實現虛擬伺服器的方法VS/TUN，和通過直接路由實現虛擬伺服器的方法VS/DR，極大地提高了系統的伸縮性。
