問題
如今，無論在企業網、園區網還是在廣域網如Internet上，業務量的發展都超出了過去最樂觀的估計；同時，用戶不斷地追求更高的機器性能，而升級單一的服務器系統，往往造成過高的投入和維護成本，性價比大大低於預期。這一切，不僅對硬件，也對軟件平臺提出了更高的要求：
- 可擴展性：良好可擴展性的計算機系統能夠使得性能隨着成本的增加而線性的增長。並且很容易對其進行精簡或者擴充。
- 全天候的可用性支持：嚴格的商業環境需要軟硬件系統提供透明的、自動適應的可用性支持，保證24×7的系統正常運行。
- 可管理性：系統可以很龐大，但是要能夠易於管理。
- 相對的成本/性能優勢：構造這樣的系統，在投入成本上是經濟的，容易根據具體的需求定製合適價位的目標系統。
解決
通過之前的分析我們知道，集羣系統在成本、效益上的的高度可擴展性正是解決這個問題的有效思路。通過相對總體成本較低的計算機羣集，可以實現單一系統無法提供的強大性能。這裏我們針對互聯網的應用情況提出具備以下特性的系統：
- 高可擴展性
- 高可用性
- 高性能
不妨稱之爲"三高"系統。
LVS體系結構介紹
Linux Virtual Server項目是由 章文嵩博士（ 開放源碼及Linux內核的開發者。著名的Linux集羣項目－－LVS(Linux Virtual Server) 的創始人和主要開發人員。他目前工作於國家並行與分佈式處理重點實驗室，主要從事集羣技術、操作系統、對象存儲與數據庫的研究。他還在自由軟件的開發上花費了大量時間，並以此爲樂。）主持的著名開放源碼項目，一個實現"三高"系統的解決方案。LVS旨在解決高速發展的Web商務中日益凸現的問題：如何在有限資金投入的情況下，最大幅度的提高Web站點的潛在服務性能。
LVS是一個Linux平臺下的軟件工具。通過LVS，你可以快捷方便的組建一個帶有第四層負載均衡功能的集羣系統。並且，藉助第三方的工具包，還可以實現對LVS集羣進行可用性支持的功能擴展。首先讓我們來看一下LVS的體系結構示意圖：
圖一：LVS的三層體系結構示意圖
從上圖我們看出，LVS的抽象體系結構分爲三個層次。 第一層是負載均衡器，這是集羣的唯一入口。從客戶端的角度看，集羣通過這層的服務體現爲一個基於IP地址的單一系統映像（SSI），整個集羣共用這個虛擬地址，通過它客戶端可以把整個集羣看作一個獨立的具有合法IP地址的主機系統，客戶端的所有訪問都發往這個虛擬IP地址。
但我們也發現，如果僅有一臺負載均衡器，容易造成負載均衡器成爲集羣的單點失效，使其成爲集羣中最脆弱的環節。因此，有必要提供容錯機制，能夠在負載均衡器失效的時候進行自動檢測並平滑替換，也就是常說的HA技術。在上圖的結構中，有一個以備份均衡身份運行的結點實時地監控負載均衡器的運行狀態，並根據檢測到的狀態做出響應：報警、接管、恢復。具體細節將在HA章節討論。
第二層是提供實際服務的服務器羣。客戶端發出的服務請求經過均衡器處理以後，轉交到服務池由具體的服務器響應請求並返回數據。通常我們會在服務結點池上提供Web服務、 FTP服務或者視頻點播服務。由於單一系統無法應付高峯值得數據訪問，那麼通過多臺服務器分擔這些負載就比較經濟可行了。
服務器結點也有可能出現暫時失效的情況，特別是在結點提供多種服務的時候，系統的隨機故障或外部環境的突變都可能造成該節點的某個服務暫時不可用。因此，由負載均衡擴展出的容錯機制要能夠識別這種錯誤，及時進行處理。同樣，當錯誤排除後，集羣能夠自動識別恢復事件，把好的結點重新納入集羣繼續運行。
第三層是存儲服務系統，爲整個集羣內部運行提供穩定、一致的文件存取服務。這一層作爲LVS集羣的擴展，可以爲集羣節點池提供單一的文件系統入口，即在每一臺服務結點上都共用同一個根（/）；並且自動完成不同結點訪問文件系統所引發的文件鎖定、負載均衡、容錯、內容一致、讀寫事務等底層功能，對應用層提供一個透明的文件訪問服務。
LVS集羣屬於鬆耦合集羣系統。由於LVS在IP層上實現了SSI，因此不需要在集羣中部署特殊的中間件層或者OS擴展，對服務器結點OS的兼容性比較好。對於部署LVS的內部結點而言，基本上可以兼容多數的IP應用，不需要做複雜的移植和安裝工作，每個內部結點可以看成相對獨立的服務器系統。即使在負載均衡器上，IPVS的核心功能也是透明的提供給用戶空間，不影響本機的正常的網絡應用。
其實在現實中，有許多技術能夠實現這樣的系統。它們藉助在某個層面上的負載均衡，將網絡請求化整爲零，由大量集羣的服務結點來共同分擔，以實現性能最大化的一項集羣技術。
負載均衡技術
其實，負載均衡並非傳統意義上的"均衡"，一般來說，它只是把有可能擁塞於一個地方的負載交給多個地方分擔。如果將其改稱爲"負載分擔"，也許更好懂一些。說得通俗一點，負載均衡在網絡中的作用就像輪流值日製度，把任務分給大家來完成，以免讓一個人累死累活。不過，這種意義上的均衡一般是靜態的，也就是事先確定的"輪值"策略 。
與輪流值日製度不同的是，動態負載均衡通過一些工具實時地分析數據包，掌握網絡中的數據流量狀況，把任務合理分配出去。結構上分爲本地負載均衡和地域負載均衡(全局負載均衡)，前一種是指對本地的服務器集羣做負載均衡，後一種是指對分別放置在不同的地理位置、在不同的網絡及服務器羣集之間作負載均衡。
負載均衡體系中，每個服務結點運行一個所需服務器程序的獨立拷貝，諸如Web、FTP、Telnet或e-mail服務器程序。對於某些服務（如運行在 Web服務器上的那些服務）而言，程序的一個拷貝運行在羣集內所有的主機上，而網絡負載均衡則將工作負載在這些主機間進行分配。對於其他服務（例如e- mail），只有一臺主機處理工作負載，針對這些服務，網絡負載均衡允許網絡通訊量流到一個主機上，並在該主機發生故障時將通訊量移至其他主機。
負載均衡實現結構
總的來說，在現有網絡結構之上，負載均衡提供了一種廉價有效的方法擴展服務器帶寬和增加吞吐量，加強網絡數據處理能力，提高網絡的靈活性和可用性。主要任務如下：
- 解決網絡擁塞問題，服務就近提供，實現地理位置無關性
- 爲用戶提供更好的訪問質量
- 提高服務器響應速度
- 提高服務器及其他資源的利用效率
- 避免了網絡關鍵部位出現單點失效
對這樣一個網絡的負載均衡技術，我們從網絡的不同實現層次入手，針對具體的性能瓶頸進行分析。從客戶端應用爲起點縱向考量，可以把負載均衡技術分爲客戶端負載均衡技術、應用服務器技術、高層協議交換、網絡接入協議交換等幾個不同層次的實現方式：
負載均衡的層次
目前在每一個層次都有大量的技術實現負載均衡的主要功能，其優缺點也各不相同，而對於我們瞭解LVS的目的而言，只需要關心網絡接入協議的負載均衡技術即可。這一層次的負載均衡技術特點是：
- 執行效率高，因爲基於底層的協議，可以通過硬件體系進行部署，也可以在OS的核心層實現。
- 兼容性強，接入協議往往能夠兼容大多數現有的主流網絡應用，比如IPv4體系中的IP層。
- 體系實現相對簡單，比起基於內容的高層交換，它不需要複雜的模式匹配機制，主要通過端口映射進行數據交換，規則簡單。
下面我們就分析一下基於負載均衡技術的LVS框架與實現方法。
LVS的IP負載均衡技術
根本上將，LVS的實現基礎是IP交換，也就是前面提到的接入協議交換技術。但LVS的體系結構具備一定的可擴展性，可以實現高性能、高可擴展性、易管理性等諸多特點，成爲一個以負載均衡爲核心的真正意義的集羣系統。
首先我們瞭解一下LVS的負載均衡模型，共有三種：地址轉換（NAT）、IP隧道（IP Tunneling）和直接路由（DR）模型。
◆地址轉換模式NAT
NAT結構圖與NAT包處理流程
我們看到，NAT的網絡結構呈現爲一種類似防火牆的私有網結構，中間的虛線表示網絡隔離帶。通過內部IP地址，將服務結點池同互聯網隔離開來。服務結點無法和客戶端直接通信，不論是請求數據還是應答數據，都需要經過負載均衡器進行IP包處理工作。
NAT 中主要的工作就是改寫IP包的源、目的地址信息，使得發向VIP的請求數據經過改寫後重新指向內部主機；同樣內部的應答數據經過負載均衡器改寫後，以 VIP作爲源地址發至請求者。這樣的模式也稱作網絡地址轉換（也有叫做IP地址僞裝），我們在代理服務器、Iptables、透明網關等應用中，都使用到這種模型，可以說這是一件比較成熟的技術。
由於使用NAT方式，要對進入和流出集羣的網絡包進行改寫包頭地址的工作，在負荷比較重的時候會影響整個集羣的性能，負載均衡器容易成爲瓶頸。
◆ IP隧道模式 IPIP
IPIP結構圖與IPIP包處理流程
IPIP 模式採用的是開放的網絡結構，服務結點擁有合法的互聯網IP地址，可以通過路由路徑將應答包直接返回給客戶端。因此，負載均衡器僅僅處理進入集羣的請求數據包，而返回包不經過路由器。因此，這種模式稱作單工連接模式（單方向連接工作模式）。負載均衡器和服務結點的連接可以是LAN，也可以在不同的網絡上，只需要保證負載均衡器能夠將IP包發送至服務結點即可。
負載均衡器收到客戶端的請求包後，通過IPIP協議爲該IP包重新處理，形成以選定的服務結點爲目的IP的新的IP包，原有的IP包數據則封裝在新的IP包裏。服務結點收到均衡器發來的IPIP數據後，將該包解開，根據其內的客戶端地址（源地址）將處理結果直接返回給客戶端，而應答包的源地址則成爲集羣的虛擬地址VIP。
IPIP模式的技術在其他領域也有體現，因爲對IP進行重新封裝，整個過程對應用層仍然是透明的。PPTP協議就是對IP隧道協議的一種應用。不過目前IPIP僅僅在 Linux系統上實現。該協議必須在Kernel中打開設備選項支持，通過tunel設備綁定VIP，服務結點在返回應答數據時，可以以VIP作爲源地址構築應答包。
◆ 直接路由模式 DR
DR結構圖與DR包處理流程
和IPIP模式一樣，DR模式也是採用單工的連接方式，應答數據不再經過均衡器而直接返回給客戶端。服務結點也必須擁有能夠到達客戶端的合法IP地址。而且，DR模式中，負載均衡器和服務結點必須位於同一個網段。
負載均衡器接收到客戶端請求後，選擇合適的服務結點，然後改寫該請求包的MAC地址部分，使之成爲目的服務結點的MAC地址，再將此包廣播到均衡器所在的網段。由於每個服務結點都擁有一個虛擬的網括設備（可以是dummy0或者lo:0），這些設備上綁定了和均衡器一樣的VIP，只是該設備並不響應對VIP 的RAP解析，不會和均衡器的Vip地址衝突。負載均衡器收到符合自身MAC的IP包後，經過處理後直接將應答數據返回給客戶，而此時的源地址仍然是 VIP。這樣，在客戶端看來，訪問的和接受響應的始終是集羣的VIP地址了。
綜合比較
雖然LVS支持三種負載均衡模式，但是從上面的分析我們發現，根據負載均衡器處理IP包的進出方式，LVS實際上包含了兩種模型：單工處理和雙工（雙向連接工作模式）處理。顯然，NAT地址轉換模式屬於雙工連接處理，在這種模式下，負載均衡器不但需要處理進入集羣的IP包，而且還要處理集羣內部節點返回的應答IP包，一個用戶從發出訪問請求到接受響應，都要經過集羣的核心負載均衡器的處理，因此稱之爲雙工連接處理。而其他兩種模式中，負載均衡器僅僅處理進入集羣的IP 請求包，而集羣內部結點的響應數據則不再通過負載均衡器返回客戶端，而是通過節點到客戶端的路由通道直接發送到目的地。由於均衡器僅處理一次完整連接的 IP請求部分，而對IP的應答數據則不處理，所以稱之爲單工連接模式。
二者比較，有什麼有缺點呢。要知道，在現今的Web 世界中，大多數的網絡請求比較小，無非是一些URL頁面請求，GET或者POST表單，在麼就是某些指令等等，這些數據基本上在幾百到幾K個字節。對這樣的IP數據包進行處理是比較輕鬆的事。而相反，Web中的應答數據通常很大，一個普通的Web頁面也要幾十K，更何況返回的如果是視頻、音頻流了，加上日益瘋狂的網絡下載，即使再強勁的處理器也無法承受這樣大量的IP包處理工作。
因此，在IP負載均衡中，如果使用雙工模式（NAT），不僅要對進入集羣的請求做出處理（改寫IP包的源、目的地址），還要對服務結點返回的大量數據做同樣的工作。那麼，隨着集羣服務節點池規模的增長，負載均衡器的處理能力很快就會達到飽和，也大大影響了LVS集羣的規模可擴展性。而使用IPIP或者DR模式，負載均衡器只需要處理相對很少的IP 數據包，對於大量的返回數據，都由服務節點通過路由器、交換機等設備直接返回給客戶端。因此在規模可擴展性這一點上，單工模式有可擴展性方面的優勢。
事物的存在總有他的道理。作者當初設計這三種負載模型，肯定是各有其有缺點的。NAT也並非一無是處。NAT雖然在性能表現上弱於其它兩種模型，但是集羣結點支持更多的操作系統，在網絡安全性方面也比較高一些。以下是三者在各方面的比較：
三種模式的比較
| NAT模式 | IPIP模式 | DR模式 | |
| 對服務結點的要求 | 服務結點可以是任何操作系統 | 服務結點必須支持IP隧道協議，目前只有Linux | 服務結點支持虛擬網卡設備，能夠禁用該設備的ARP響應功能 |
| 網絡要求 | 擁有私有IP地址的局域網絡 | 擁有合法IP地址的局域網或者廣域網 | 擁有合法IP地址的局域網，服務結點與均衡器必須在同一個網段 |
| 通常支持的結點數量 | 10~20個，試均衡器的處理能力而定 | 較高，可以支持到100個服務結點 | 較高，可以支持到100個服務結點 |
| 網關 | 均衡器即爲服務結點的網關 | 服務結點同自己的網關或者路由器連接，不經過均衡器 | 服務結點同自己的網關或者路由器連接，不經過均衡器 |
| 服務結點安全性 | 較好，採用內部IP，服務結點隱蔽 | 較差，採用公用IP地址，結點完全暴露 | 較差，採用公用IP地址，結點完全暴露 |
| IP要求 | 僅需要一個合法IP地址作爲VIP | 除VIP外，每個服務結點需擁有合法的IP地址，可以直接路由至客戶端 | 除VIP外，每個服務結點需擁有合法的IP地址，可以直接路由至客戶端 |
綜上所述，我們在選擇LVS作爲集羣負載均衡解決方案的時候，首先根據單前應用環境的情況確定使用哪一種IP負載均衡結構。如果你只擁有一個合法的IP地址，或者你需要構造一個安全的集羣，又不太擔心性能問題的話，完全可以使用NAT模式；如果對性能有比較高的要求，而應用又是基於Linux的話，使用 IPIP或者DR模式一定會給你一個驚喜。