Linux服務器集羣系統――LVS（Linux Virtual Server）項目
標籤：linux
背景 當今計算機技術已進入以網絡爲中心的計算時期。由於客戶/服務器模型的簡單性、易管理性和易維護性，客戶/服務器計算模式在網上被大量採用。在九十年代中期，萬維網（World Wide Web）的出現以其簡單操作方式將圖文並茂的網上信息帶給普通大衆，Web也正在從一種內
容發送機製成爲一種服務平臺，大量的服務和應用（如新聞服務、網上銀行、電子商務等）都是圍繞着Web進行。這促進Internet用戶劇烈增長和Internet流量爆炸式地增長，圖1顯示了1995至2000年與Internet連接主機數的變化情況，可見增長趨勢較以往更迅猛。
Internet的飛速發展給網絡帶寬和服務器帶來巨大的挑戰。從網絡技術的發展來看，網絡帶寬的增長遠高於處理器速度和內存訪問速度的增長，如100M Ethernet、ATM、Gigabit Ethernet等不斷地涌現，10Gigabit Ethernet即將就緒，在主幹網上密集波分複用（DWDM）將成爲
寬帶IP的主流技術[2,3]，Lucent已經推出在一根光纖跑800Gigabit的WaveStar? OLS 800G產品[4]。所以，我們深信越來越多的瓶頸會出現在服務器端。很多研究顯示Gigabit Ethernet在服務器上很難使得其吞吐率達到1Gb/s的原因是協議棧（TCP/IP）和操作系統的低效，以及處理器的
低效，這需要對協議的處理方法、操作系統的調度和IO的處理作更深入的研究。在高速網絡上，重新設計單臺服務器上的網絡服務程序也是個重要課題。
比較熱門的站點會吸引前所未有的訪問流量，例如根據Yahoo的新聞發佈，Yahoo已經每天發送6.25億頁面。一些網絡服務也收到鉅額的流量，如American Online的Web Cache系統每天處理50.2億個用戶訪問Web的請求，每個請求的平均響應長度爲5.5Kbytes。與此同時，很多網絡
服務因爲訪問次數爆炸式地增長而不堪重負，不能及時處理用戶的請求，導致用戶進行長時間的等待，大大降低了服務質量。如何建立可伸縮的網絡服務來滿足不斷增長的負載需求已成爲迫在眉睫的問題。
大部分網站都需要提供每天24小時、每星期7天的服務，對電子商務等網站尤爲突出，任何服務中斷和關鍵性的數據丟失都會造成直接的商業損失。例如，根據Dell的新聞發佈[6]，Dell現在每天在網站上的交易收入爲一千四百萬美元，一個小時的服務中斷都會造成平均五十八萬美
元的損失。所以，這對網絡服務的可靠性提出了越來越高的要求。
現在Web服務中越來越多地使用CGI、動態主頁等CPU密集型應用，這對服務器的性能有較高要求。未來的網絡服務會提供更豐富的內容、更好的交互性、更高的安全性等，需要服務器具有更強的CPU和I/O處理能力。例如，通過HTTPS（Secure HTTP）取一個靜態頁面需要的處理性能
比通過HTTP的高一個數量級，HTTPS正在被電子商務站點廣爲使用。所以，網絡流量並不能說明全部問題，要考慮到應用本身的發展也需要越來越強的處理性能。
因此，對用硬件和軟件方法實現高可伸縮、高可用網絡服務的需求不斷增長，這種需求可以歸結以下幾點：
·可伸縮性（Scalability），當服務的負載增長時，系統能被擴展來滿足需求，且不降低服務質量。
·高可用性（Availability），儘管部分硬件和軟件會發生故障，整個系統的服務必須是每天24小時每星期7天可用的。
·可管理性（Manageability），整個系統可能在物理上很大，但應該容易管理。
·價格有效性（Cost-effectiveness），整個系統實現是經濟的、易支付的。
2. 服務器集羣系統
對稱多處理（Symmetric Multi-Processor，簡稱SMP）是由多個對稱的處理器、和通過總線共享的內存和I/O部件所組成的計算機系統。SMP是一種低並行度的結構，是我們通常所說的"緊耦合多處理系統"，它的可擴展能力有限，但SMP的優點是單一系統映像（Single System Im
age），有共享的內存和I/O，易編程。
由於SMP的可擴展能力有限，SMP服務器顯然不能滿足高可伸縮、高可用網絡服務中的負載處理能力不斷增長需求。隨着負載不斷增長，會導致服務器不斷地升級。這種服務器升級有下列不足：一是升級過程繁瑣，機器切換會使服務暫時中斷，並造成原有計算資源的浪費；二是越往
高端的服務器，所花費的代價越大；三是SMP服務器是單一故障點（Single Point of Failure），一旦該服務器或應用軟件失效，會導致整個服務的中斷。
通過高性能網絡或局域網互聯的服務器集羣正成爲實現高可伸縮的、高可用網絡服務的有效結構。這種鬆耦合結構的服務器集羣系統有下列優點：
性能
網絡服務的工作負載通常是大量相互獨立的任務，通過一組服務器分而治之，可以獲得很高的整體性能。
性能/價格比
組成集羣系統的PC服務器或RISC服務器和標準網絡設備因爲大規模生產降低成本，價格低，具有最高的性能/價格比。若整體性能隨着結點數的增長而接近線性增加，該系統的性能/價格比接近於PC服務器。所以，這種鬆耦合結構比緊耦合的多處理器系統具有更好的性能/價格比。
可伸縮性
集羣系統中的結點數目可以增長到幾千個，乃至上萬個，其伸縮性遠超過單臺超級計算機。
高可用性
在硬件和軟件上都有冗餘，通過檢測軟硬件的故障，將故障屏蔽，由存活結點提供服務，可實現高可用性。
當然，用服務器集羣系統實現可伸縮網絡服務也存在很多挑戰性的工作：
透明性（Transparency）
如何高效地使得由多個獨立計算機組成的鬆藕合的集羣系統構成一個虛擬服務器；客戶端應用程序與集羣系統交互時，就像與一臺高性能、高可用的服務器交互一樣，客戶端無須作任何修改。部分服務器的切入和切出不會中斷服務，這對用戶也是透明的。
性能（Performance）
性能要接近線性加速，這需要設計很好的軟硬件的體系結構，消除系統可能存在的瓶頸。將負載較均衡地調度到各臺服務器上。
高可用性（Availability）
需要設計和實現很好的系統資源和故障的監測和處理系統。當發現一個模塊失敗時，要這模塊上提供的服務遷移到其他模塊上。在理想狀況下，這種遷移是即時的、自動的。
可管理性（Manageability）
要使集羣系統變得易管理，就像管理一個單一映像系統一樣。在理想狀況下，軟硬件模塊的插入能做到即插即用（Plug & Play）。
可編程性（Programmability）
在集羣系統上，容易開發應用程序。
3. Linux Virtual Server項目
針對高可伸縮、高可用網絡服務的需求，我們給出了基於IP層和基於內容請求分發的負載平衡調度解決方法，並在Linux內核中實現了這些方法，將一組服務器構成一個實現可伸縮的、高可用網絡服務的虛擬服務器。
虛擬服務器的體系結構如圖2所示，一組服務器通過高速的局域網或者地理分佈的廣域網相互連接，在它們的前端有一個負載調度器（Load Balancer）。負載調度器能無縫地將網絡請求調度到真實服務器上，從而使得服務器集羣的結構對客戶是透明的，客戶訪問集羣系統提供的
網絡服務就像訪問一臺高性能、高可用的服務器一樣。客戶程序不受服務器集羣的影響不需作任何修改。系統的伸縮性通過在服務機羣中透明地加入和刪除一個節點來達到，通過檢測節點或服務進程故障和正確地重置系統達到高可用性。由於我們的負載調度技術是在Linux內核中實現的，
我們稱之爲Linux虛擬服務器（Linux Virtual Server）。
在1998年5月，我成立了Linux Virtual Server的自由軟件項目，進行Linux服務器集羣的開發工作。同時，Linux Virtual Server項目是國內最早出現的自由軟件項目之一。
Linux Virtual Server項目的目標：使用集羣技術和Linux操作系統實現一個高性能、高可用的服務器，它具有很好的可伸縮性（Scalability）、可靠性（Reliability）和可管理性（Manageability）。
目前，LVS項目已提供了一個實現可伸縮網絡服務的Linux Virtual Server框架，如圖3所示。在LVS框架中，提供了含有三種IP負載均衡技術的IP虛擬服務器軟件IPVS、基於內容請求分發的內核Layer-7交換機KTCPVS和集羣管理軟件。可以利用LVS框架實現高可伸縮的、高可用的W
eb、Cache、Mail和Media等網絡服務；在此基礎上，可以開發支持龐大用戶數的、高可伸縮的、高可用的電子商務應用。
3.1 IP虛擬服務器軟件IPVS
在調度器的實現技術中，IP負載均衡技術是效率最高的。在已有的IP負載均衡技術中有通過網絡地址轉換（Network Address Translation）將一組服務器構成一個高性能的、高可用的虛擬服務器，我們稱之爲VS/NAT技術（Virtual Server via Network Address Translati
on），大多數商品化的IP負載均衡調度器產品都是使用此方法，如Cisco的LocalDirector、F5的Big/IP和Alteon的ACEDirector。在分析VS/NAT的缺點和網絡服務的非對稱性的基礎上，我們提出通過IP隧道實現虛擬服務器的方法VS/TUN（Virtual Server via IP Tunneling），和通過直
接路由實現虛擬服務器的方法VS/DR（Virtual Server via Direct Routing），它們可以極大地提高系統的伸縮性。所以，IPVS軟件實現了這三種IP負載均衡技術，它們的大致原理如下（我們將在其他章節對其工作原理進行詳細描述），
Virtual Server via Network Address Translation（VS/NAT）
通過網絡地址轉換，調度器重寫請求報文的目標地址，根據預設的調度算法，將請求分派給後端的真實服務器；真實服務器的響應報文通過調度器時，報文的源地址被重寫，再返回給客戶，完成整個負載調度過程。
Virtual Server via IP Tunneling（VS/TUN）
採用NAT技術時，由於請求和響應報文都必須經過調度器地址重寫，當客戶請求越來越多時，調度器的處理能力將成爲瓶頸。爲了解決這個問題，調度器把請求報文通過IP隧道轉發至真實服務器，而真實服務器將響應直接返回給客戶，所以調度器只處理請求報文。由於一般網絡服
務應答比請求報文大許多，採用VS/TUN技術後，集羣系統的最大吞吐量可以提高10倍。
Virtual Server via Direct Routing（VS/DR）
VS/DR通過改寫請求報文的MAC地址，將請求發送到真實服務器，而真實服務器將響應直接返回給客戶。同VS/TUN技術一樣，VS/DR技術可極大地提高集羣系統的伸縮性。這種方法沒有IP隧道的開銷，對集羣中的真實服務器也沒有必須支持IP隧道協議的要求，但是要求調度器與真實
服務器都有一塊網卡連在同一物理網段上。
針對不同的網絡服務需求和服務器配置，IPVS調度器實現瞭如下八種負載調度算法：
輪叫（Round Robin）
調度器通過"輪叫"調度算法將外部請求按順序輪流分配到集羣中的真實服務器上，它均等地對待每一臺服務器，而不管服務器上實際的連接數和系統負載。
加權輪叫（Weighted Round Robin）
調度器通過"加權輪叫"調度算法根據真實服務器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的服務器處理更多的訪問流量。調度器可以自動問詢真實服務器的負載情況，並動態地調整其權值。
最少鏈接（Least Connections）
調度器通過"最少連接"調度算法動態地將網絡請求調度到已建立的鏈接數最少的服務器上。如果集羣系統的真實服務器具有相近的系統性能，採用"最小連接"調度算法可以較好地均衡負載。
加權最少鏈接（Weighted Least Connections）
在集羣系統中的服務器性能差異較大的情況下，調度器採用"加權最少鏈接"調度算法優化負載均衡性能，具有較高權值的服務器將承受較大比例的活動連接負載。調度器可以自動問詢真實服務器的負載情況，並動態地調整其權值。
基於局部性的最少鏈接（Locality-Based Least Connections）
"基於局部性的最少鏈接" 調度算法是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於
一半的工作負載，則用"最少鏈接"的原則選出一個可用的服務器，將請求發送到該服務器。
帶複製的基於局部性最少鏈接（Locality-Based Least Connections with Replication）
"帶複製的基於局部性最少鏈接"調度算法也是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。它與LBLC算法的不同之處是它要維護從一個目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。該算法根據請求的目標IP地址找出該目
標IP地址對應的服務器組，按"最小連接"原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器，若服務器超載；則按"最小連接"原則從這個集羣中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修
改，將最忙的服務器從服務器組中刪除，以降低複製的程度。
目標地址散列（Destination Hashing）
"目標地址散列"調度算法根據請求的目標IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
源地址散列（Source Hashing）
"源地址散列"調度算法根據請求的源IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
3.2 內核Layer-7交換機KTCPVS
在基於IP負載調度技術中，當一個TCP連接的初始SYN報文到達時，調度器就選擇一臺服務器，將報文轉發給它。此後通過查發報文的IP和TCP報文頭地址，保證此連接的後繼報文被轉發到該服務器。這樣，IPVS無法檢查到請求的內容再選擇服務器，這就要求後端服務器組提供相同
的服務，不管請求被髮送到哪一臺服務器，返回結果都是一樣的。但是，在有些應用中後端服務器功能不一，有的提供HTML文檔，有的提供圖片，有的提供CGI，這就需要基於內容的調度(Content-Based Scheduling)。
由於用戶空間TCP Gateway的開銷太大，我們提出在操作系統的內核中實現Layer-7交換方法，來避免用戶空間與核心空間的切換和內存複製的開銷。在Linux操作系統的內核中，我們實現了Layer-7交換，稱之爲KTCPVS（Kernel TCP Virtual Server）。目前，KTCPVS已經能對H
TTP請求進行基於內容的調度，但它還不很成熟，在其調度算法和各種協議的功能支持等方面，有大量的工作需要做。
雖然應用層交換處理複雜，它的伸縮性有限，但應用層交換帶來以下好處：
相同頁面的請求被髮送到同一服務器，可以提高單臺服務器的Cache命中率。
一些研究[5]表明WEB訪問流中存在局部性。Layer-7交換可以充分利用訪問的局部性，將相同類型的請求發送到同一臺服務器，使得每臺服務器收到的請求具有更好的相似性，可進一步提高單臺服務器的Cache命中率。
後端服務器可運行不同類型的服務，如文檔服務，圖片服務，CGI服務和數據庫服務等。
4. LVS集羣的特點
LVS集羣的特點可以歸結如下：
功能
有實現三種IP負載均衡技術和八種連接調度算法的IPVS軟件。在IPVS內部實現上，採用了高效的Hash函數和垃圾回收機制，能正確處理所調度報文相關的ICMP消息（有些商品化的系統反而不能）。虛擬服務的設置數目沒有限制，每個虛擬服務有自己的服務器集。它支持持久的虛擬
服務（如HTTP Cookie和HTTPS等需要該功能的支持），並提供詳盡的統計數據，如連接的處理速率和報文的流量等。針對大規模拒絕服務（Deny of Service）攻擊，實現了三種防衛策略。
有基於內容請求分發的應用層交換軟件KTCPVS，它也是在Linux內核中實現。有相關的集羣管理軟件對資源進行監測，能及時將故障屏蔽，實現系統的高可用性。主、從調度器能週期性地進行狀態同步，從而實現更高的可用性。
適用性
後端服務器可運行任何支持TCP/IP的操作系統，包括Linux，各種Unix（如FreeBSD、Sun Solaris、HP Unix等），Mac/OS和Windows NT/2000等。
負載調度器能夠支持絕大多數的TCP和UDP協議：
協議 內 容
TCP HTTP，FTP，PROXY，SMTP，POP3，IMAP4，DNS，LDAP，HTTPS，SSMTP等
UDP DNS，NTP，ICP，視頻、音頻流播放協議等
無需對客戶機和服務器作任何修改，可適用大多數Internet服務。
性能
LVS服務器集羣系統具有良好的伸縮性，可支持幾百萬個併發連接。配置100M網卡，採用VS/TUN或VS/DR調度技術，集羣系統的吞吐量可高達1Gbits/s；如配置千兆網卡，則系統的最大吞吐量可接近10Gbits/s。
可靠性
LVS服務器集羣軟件已經在很多大型的、關鍵性的站點得到很好的應用，所以它的可靠性在真實應用得到很好的證實。有很多調度器運行一年多，未作一次重啓動。
軟件許可證
LVS集羣軟件是按GPL（GNU Public License）許可證發行的自由軟件，這意味着你可以得到軟件的源代碼，有權對其進行修改，但必須保證你的修改也是以GPL方式發行。
5. LVS集羣的應用
LVS項目從成立到現在爲止，受到不少關注，LVS集羣系統已被應用於很多重負載的站點，就我所知該系統已在美、英、德、澳等國的幾十個站點上正式使用。
我們沒有上百臺機器和高速的網絡來實際測試LVS的終極性能，所以舉LVS的應用實例來說明LVS的高性能和穩定性。我們所知的一些大型LVS應用實例如下：
英國國家JANET Cache Service（wwwcache.ja.net）是爲英國150所以上的大學提供Web Cache服務。他們用28個結點的LVS集羣代替了原有現50多臺相互獨立的Cache服務器，用他們的話說現在速度就跟夏天一樣，因爲夏天是放假期間沒有很多人使用網絡。
Linux的門戶站點（[url]www.linux.com[/url]）用LVS將很多臺VA Linux SMP服務器組成高性能的WEB服務，已使用將近一年。
SourceForge（sourceforge.net）是在全球範圍內爲開發源碼項目提供WEB、FTP、Mailing List和CVS等服務，他們也使用LVS將負載調度到十幾臺機器上。
世界上最大的PC製造商之一採用了兩個LVS集羣系統，一個在美洲，一個在歐洲，用於網上直銷系統。
以RealPlayer提供音頻視頻服務而聞名的Real公司（[url]www.real.com[/url]）使用由20臺服務器組成的LVS集羣，爲其全球用戶提供音頻視頻服務。在2000年3月時，整個集羣系統已收到平均每秒20,000個連接的請求流。
NetWalk（[url]www.netwalk.com[/url]）用多臺服務器構造LVS系統，提供1024個虛擬服務，其中本項目的一個美國鏡像站點（[url]www.us.linuxvirtualserver.org[/url]）。
RedHat（[url]www.redhat.com[/url]）從其6.1發行版起已包含LVS代碼，他們開發了一個LVS集羣管理工具叫Piranha，用於控制LVS集羣，並提供了一個圖形化的配置界面。
VA Linux（[url]www.valinux.com[/url]）向客戶提供基於LVS的服務器集羣系統，並且提供相關的服務和支持。
TurboLinux的"世界一流Linux集羣產品"TurboCluster實際上是基於LVS的想法和代碼的，只是他們在新聞發佈和產品演示時忘了致謝。
紅旗Linux和中軟都提供基於LVS的集羣解決方案，並在2000年9月召開的Linux World China 2000上展示。
在這裏，再引用兩位LVS用戶的評論，來進一步說明LVS的性能和可靠性。
"We tried virtually all of the commercial load balancers, LVS beats them all for reliability, cost, manageability, you-name-it"
Jerry Glomph Black, Director, Internet & Technical Operations, Real Networks, Seattle Washington, USA
[url]http://marc.theaimsgroup.com/?1=linux-virtual-server&m=95385809030794&w=2[/url]
"I can say without a doubt that lvs toasts F5/BigIP solutions, at least in our real world implementations. I wouldn't trade a good lvs box for a Cisco Local Director either"
Drew Streib, Information Architect, VA Linux Systems, USA
[url]http://marc.theaimsgroup.com/?1=linux-virtual-server&m=95385694529750&w=2[/url]
6. LVS項目的開發進展與感觸
LVS項目於1998年5月在網站上發佈IPVS第一個版本源程序，一直得到了來自 Internet 的用戶和開發者的鼓勵和支持。應該說，剛開始發佈的程序是非常簡單的，由於用戶的使用、反饋和期望，讓我覺得這項工作的價值，並不斷地化時間對該軟件添加新功能和完善，其中也得到
其他開發者的幫助，所以該軟件逐漸發展成爲功能較齊全、有用的系統，這遠遠超出我當初成立項目時的想象。在這裏，我要感謝Julian Anastasov提供了很多系統的Bug fixes和改進，Joseph Mack博士編寫了LVS HOWTO文檔；還感謝一些廠商贊助我開發（如硬件設備等），和贊助我
多次出國作相關的技術報告。
目前，正在進行的 LVS項目開發工作包括：
擴充IPVS對其他傳輸協議的支持，如AH（Authentication Header）和ESP（Encapsulating Security Payload ）等，這樣IPVS調度器將實現IPSec的服務器集羣。
提供一個統一的、功能較完善、更靈活的LVS集羣管理軟件。
擴充和改進KTCPVS的調度算法和多種協議的支持，使之功能較完備和系統更穩定。
在TCP粘合（TCP Splicing）和TCP轉移（TCP Handoff）等方面，做一些嘗試性工作，進一步改進LVS集羣中的應用層調度。
最後，我談一下自己多年來做自由軟件開發的幾點感觸。一是通過自由軟件方式可以使得軟件具有頑強的生命力；我以前也做過幾個獨立的系統，如在SUN上用Common Lisp開發的知識庫系統和基於C++的對象數據庫系統，有些地方也是做得非常漂亮的（如元級反射機制和對象的關
系處理），但因爲種種原因這些軟件沒有以開放源碼方式發佈，現在它們在我導師的軟件倉庫裏已無人問津，我也已經忘記裏面的實現細節；而LVS項目是我做着玩的，一開始只是個很簡單的程序，通過自由軟件的發佈和開發，它發展成一個有用的、功能較齊全的軟件，體現了自由軟件的
強大生命力。二是通過自由軟件的集市開發，可以使得初始的想法不斷地深入，可以學到很多東西。三是做自由軟件後時間會更有效率，由於用戶的反饋和期待，會自覺不斷地改進和完善系統，於是沒有時間去玩遊戲和網上聊天。四是做自由軟件會使得你有一點點成就感，每當收到用戶的
致謝和想到你的軟件在實際系統中運行，會有一點滿足。所以，行動起來吧，花一些時間做自由軟件，你會有意想不到的收穫。
[目錄]
體系結構
本文主要介紹了LVS集羣的體系結構。先給出LVS集羣的通用體系結構，並討論了其的設計原則和相應的特點；最後將LVS集羣應用於建立可伸縮的Web、Media、Cache和Mail等網絡服務。
1.引言
在過去的十幾年中，Internet從幾個研究機構相連爲信息共享的網絡發展成爲擁有大量應用和服務的全球性網絡，它正成爲人們生活中不可缺少的一部分。雖然Internet發展速度很快，但建設和維護大型網絡服務依然是一項挑戰性的任務，因爲系統必須是高性能的、高可靠的，尤
其當訪問負載不斷增長時，系統必須能被擴展來滿足不斷增長的性能需求。由於缺少建立可伸縮網絡服務的框架和設計方法，這意味着只有擁有非常出色工程和管理人才的機構才能建立和維護大型的網絡服務。
針對這種情形，本文先給出LVS集羣的通用體系結構，並討論了其的設計原則和相應的特點；最後將LVS集羣應用於建立可伸縮的Web、Media、Cache和Mail等網絡服務。
2.LVS集羣的通用體系結構
LVS集羣採用IP負載均衡技術和基於內容請求分發技術。調度器具有很好的吞吐率，將請求均衡地轉移到不同的服務器上執行，且調度器自動屏蔽掉服務器的故障，從而將一組服務器構成一個高性能的、高可用的虛擬服務器。整個服務器集羣的結構對客戶是透明的，而且無需修改
客戶端和服務器端的程序。
爲此，在設計時需要考慮系統的透明性、可伸縮性、高可用性和易管理性。一般來說，LVS集羣採用三層結構，其體系結構如圖1所示，三層主要組成部分爲：
負載調度器（load balancer），它是整個集羣對外面的前端機，負責將客戶的請求發送到一組服務器上執行，而客戶認爲服務是來自一個IP地址（我們可稱之爲虛擬IP地址）上的。
服務器池（server pool），是一組真正執行客戶請求的服務器，執行的服務有WEB、MAIL、FTP和DNS等。
共享存儲（shared storage），它爲服務器池提供一個共享的存儲區，這樣很容易使得服務器池擁有相同的內容，提供相同的服務。
調度器是服務器集羣系統的唯一入口點（Single Entry Point），它可以採用IP負載均衡技術、基於內容請求分發技術或者兩者相結合。在IP負載均衡技術中，需要服務器池擁有相同的內容提供相同的服務。當客戶請求到達時，調度器只根據服務器負載情況和設定的調度算法從
服務器池中選出一個服務器，將該請求轉發到選出的服務器，並記錄這個調度；當這個請求的其他報文到達，也會被轉發到前面選出的服務器。在基於內容請求分發技術中，服務器可以提供不同的服務，當客戶請求到達時，調度器可根據請求的內容選擇服務器執行請求。因爲所有的操作都
是在Linux操作系統核心空間中將完成的，它的調度開銷很小，所以它具有很高的吞吐率。
服務器池的結點數目是可變的。當整個系統收到的負載超過目前所有結點的處理能力時，可以在服務器池中增加服務器來滿足不斷增長的請求負載。對大多數網絡服務來說，請求間不存在很強的相關性，請求可以在不同的結點上並行執行，所以整個系統的性能基本上可以隨着服務
器池的結點數目增加而線性增長。
共享存儲通常是數據庫、網絡文件系統或者分佈式文件系統。服務器結點需要動態更新的數據一般存儲在數據庫系統中，同時數據庫會保證併發訪問時數據的一致性。靜態的數據可以存儲在網絡文件系統（如NFS/CIFS）中，但網絡文件系統的伸縮能力有限，一般來說，NFS/CIFS服
務器只能支持3~6個繁忙的服務器結點。對於規模較大的集羣系統，可以考慮用分佈式文件系統，如AFS[1]、GFS[2.3]、Coda[4]和Intermezzo[5]等。分佈式文件系統可爲各服務器提供共享的存儲區，它們訪問分佈式文件系統就像訪問本地文件系統一樣，同時分佈式文件系統可提供良好的
伸縮性和可用性。此外，當不同服務器上的應用程序同時讀寫訪問分佈式文件系統上同一資源時，應用程序的訪問衝突需要消解才能使得資源處於一致狀態。這需要一個分佈式鎖管理器（Distributed Lock Manager），它可能是分佈式文件系統內部提供的，也可能是外部的。開發者在寫
應用程序時，可以使用分佈式鎖管理器來保證應用程序在不同結點上併發訪問的一致性。
負載調度器、服務器池和共享存儲系統通過高速網絡相連接，如100Mbps交換網絡、Myrinet和Gigabit網絡等。使用高速的網絡，主要爲避免當系統規模擴大時互聯網絡成爲整個系統的瓶頸。
Graphic Monitor是爲系統管理員提供整個集羣系統的監視器，它可以監視系統的狀態。Graphic Monitor是基於瀏覽器的，所以無論管理員在本地還是異地都可以監測系統的狀況。爲了安全的原因，瀏覽器要通過HTTPS（Secure HTTP）協議和身份認證後，才能進行系統監測，
並進行系統的配置和管理。
2.1. 爲什麼使用層次的體系結構
層次的體系結構可以使得層與層之間相互獨立，每一個層次提供不同的功能，在一個層次可以重用不同的已有軟件。例如，調度器層提供了負載平衡、可伸縮性和高可用性等，在服務器層可以運行不同的網絡服務，如Web、Cache、Mail和Media等，來提供不同的可伸縮網絡服務。
明確的功能劃分和清晰的層次結構使得系統容易建設，以後整個系統容易維護，而且系統的性能容易被擴展。
2.2. 爲什麼是共享存儲
共享存儲如分佈式文件系統在這個LVS集羣系統是可選項。當網絡服務需要有相同的內容，共享存儲是很好的選擇，否則每臺服務器需要將相同的內容複製到本地硬盤上。當系統存儲的內容越多，這種無共享結構（Shared-nothing Structure）的代價越大，因爲每臺服務器需要一
樣大的存儲空間，任何的更新需要涉及到每臺服務器，系統的維護代價會非常高。
共享存儲爲服務器組提供統一的存儲空間，這使得系統的內容維護工作比較輕鬆，如Webmaster只需要更新共享存儲中的頁面，對所有的服務器都有效。分佈式文件系統提供良好的伸縮性和可用性，當分佈式文件系統的存儲空間增加時，所有服務器的存儲空間也隨之增大。對於大
多數Internet服務來說，它們都是讀密集型（Read-intensive）的應用，分佈式文件系統在每臺服務器使用本地硬盤作Cache（如2Gbytes的空間），可以使得訪問分佈式文件系統本地的速度接近於訪問本地硬盤。
此外，存儲硬件技術的發展也促使從無共享的集羣向共享存儲的集羣遷移。存儲區域網（Storage Area Networks）技術解決了集羣的每個結點可以直接連接/共享一個龐大的硬盤陣列，硬件廠商也提供多種硬盤共享技術，如光纖通道（Fiber Channel）、共享SCSI（Shared SC
SI）。InfiniBand是一個通用的高性能I/O規範，使得存儲區域網中以更低的延時傳輸I/O消息和集羣通訊消息，並且提供很好的伸縮性。InfiniBand得到絕大多數的大廠商的支持，如Compaq、Dell、Hewlett-Packard、IBM、Intel、Microsoft和SUN Microsystems等，它正在成爲一個業界
的標準。這些技術的發展使得共享存儲變得容易，規模生產也會使得成本逐步降低。
2.3. 高可用性
集羣系統的特點是它在軟硬件上都有冗餘。系統的高可用性可以通過檢測節點或服務進程故障和正確地重置系統來實現，使得系統收到的請求能被存活的結點處理。
通常，我們在調度器上有資源監測進程來時刻監視各個服務器結點的健康狀況。當服務器對ICMP ping不可達時或者探測她的網絡服務在指定的時間沒有響應時，資源監測進程通知操作系統內核將該服務器從調度列表中刪除或者失效。這樣，新的服務請求就不會被調度到壞的結點
。資源監測進程能通過電子郵件或傳呼機向管理員報告故障。一旦監測進程到服務器恢復工作，通知調度器將其加入調度列表進行調度。另外，通過系統提供的管理程序，管理員可發命令隨時可以將新機器加入服務來提高系統的處理性能，也可以將已有的服務器切出服務，以便對服務器進
行系統維護。
現在前端的調度器有可能成爲系統的單一失效點（Single Point of Failure）。一般來說，調度器的可靠性較高，因爲調度器上運行的程序較少而且大部分程序早已經遍歷過，但我們不能排除硬件老化、網絡線路或者人爲誤操作等主要故障。爲了避免調度器失效而導致整個系
統不能工作，我們需要設立一個從調度器作爲主調度器的備份。兩個心跳（Heartbeat）進程[6]分別在主、從調度器上運行，它們通過串口線和UDP等心跳線來相互定時地彙報各自的健康狀況。當從調度器不能聽得主調度器的心跳時，從調度器通過ARP欺騙（Gratuitous ARP）來接管集羣
對外的Virtual IP Address，同時接管主調度器的工作來提供負載調度服務。當主調度器恢復時，這裏有兩種方法，一是主調度器自動變成從調度器，二是從調度器釋放Virtual IP Address，主調度器收回Virtual IP Address並提供負載調度服務。這裏，多條心跳線可以使得因心跳
線故障導致誤判（即從調度器認爲主調度器已經失效，其實主調度器還在正常工作）的概論降到最低。
通常，當主調度器失效時，主調度器上所有已建立連接的狀態信息將丟失，已有的連接會中斷。客戶需要向重新連接，從調度器纔會將新連接調度到各個服務器上，這對客戶會造成一定的不便。爲此，IPVS調度器在Linux 內核中實現一種高效狀態同步機制，將主調度器的狀態信
息及時地同步到從調度器。當從調度器接管時，絕大部分已建立的連接會持續下去。
3.可伸縮Web服務
基於LVS的Web集羣的體系結構如圖2所示：第一層是負載調度器，一般採用IP負載均衡技術，可以使得整個系統有較高的吞吐率；第二層是Web服務器池，在每個結點上可以分別運行HTTP服務或HTTPS服務、或者兩者都運行；第三層是共享存儲，它可以是數據庫，可以是網絡文件系
統或分佈式文件系統，或者是三者的混合。集羣中各結點是通過高速網絡相連接的。
對於動態頁面（如PHP、JSP和ASP等），需要訪問的動態數據一般存儲在數據庫服務器中。數據庫服務運行在獨立的服務器上，爲所有Web服務器共享。無論同一Web服務器上多個動態頁面訪問同一數據，還是不同Web服務器上多個動態頁面訪問同一數據，數據庫服務器有鎖機制使得
這些訪問有序地進行，從而保證數據的一致性。
對於靜態的頁面和文件（如HTML文檔和圖片等），可以存儲在網絡文件系統或者分佈式文件系統中。至於選擇哪一種，看系統的規模和需求而定。通過共享的網絡文件系統或者分佈式文件系統，Webmaster可以看到統一的文檔存儲空間，維護和更新頁面比較方便，對共享存儲中頁
面的修改對所有的服務器都有效。
在這種結構下，當所有服務器結點超載時，管理員可以很快地加入新的服務器結點來處理請求，而無需將Web文檔等複製到結點的本地硬盤上。
有些Web服務可能用到HTTP Cookie，它是將數據存儲在客戶的瀏覽器來追蹤和標識客戶的機制。使用HTTP Cookie後，來同一客戶的不同連接存在相關性，這些連接必須被髮送到同一Web服務器。一些Web服務使用安全的HTTPS協議，它是HTTP協議加SSL（Secure Socket Layer）
協議。另有些Web服務可能使用安全的HTTPS協議，它是HTTP協議加SSL協議。當客戶訪問HTTPS服務（HTTPS的缺省端口爲443）時，會先建立一個SSL連接，來交換對稱公鑰加密的證書並協商一個SSL Key，來加密以後的會話。在SSL Key的生命週期內，後續的所有HTTPS連接都使用這個SSL
Key，所以同一客戶的不同HTTPS連接也存在相關性。針對這些需要，IPVS調度器提供了持久服務的功能，它可以使得在設定的時間內，來自同一IP地址的不同連接會被髮送到集羣中同一個服務器結點，可以很好地解決客戶連接的相關性問題。
4.可伸縮媒體服務
基於LVS的媒體集羣的體系結構如圖3所示：第一層是負載調度器，一般採用IP負載均衡技術，可以使得整個系統有較高的吞吐率；第二層是Web服務器池，在每個結點上可以運行相應的媒體服務；第三層是共享存儲，通過網絡文件系統/分佈式文件系統存儲媒體節目。集羣中各結點
是通過高速網絡相連接。
IPVS負載調度器一般使用直接路由方法（即VS/DR方法，將在以後文章中詳細敘述），來架構媒體集羣系統。調度器將媒體服務請求較均衡地分發到各個服務器上，而媒體服務器將響應數據直接返回給客戶，這樣可以使得整個媒體集羣系統具有很好的伸縮性。
媒體服務器可以運行各種媒體服務軟件。目前，LVS集羣對於Real Media、Windows Media和Apple Quicktime媒體服務都有很好的支持，都有真實的系統在運行。一般來說，流媒體服務都會使用一個TCP連接（如RTSP協議：Real-Time Streaming Protocol）進行帶寬的協商和
流速的控制，通過UDP將流數據返回客戶。這裏，IPVS調度器提供功能將TCP和UDP集中考慮，保證來自同一客戶的媒體TCP和UDP連接會被轉發到集羣中同一臺媒體服務器，使得媒體服務準確無誤地進行。
共享存儲是媒體集羣系統中最關鍵的問題，因爲媒體文件往往非常大（一部片子需要幾百兆到幾千兆的存儲空間），這對存儲的容量和讀的速度有較高的要求。對於規模較小的媒體集羣系統，例如有3至6個媒體服務器結點，存儲系統可以考慮用帶千兆網卡的Linux服務器，使用軟
件RAID和日誌型文件系統，再運行內核的NFS服務，會有不錯的效果。對於規模較大的媒體集羣系統，最好選擇對文件分段（File Stripping）存儲和文件緩存有較好支持的分佈式文件系統；媒體文件分段存儲在分佈式文件系統的多個存儲結點上，可以提高文件系統的性能和存儲結點間的
負載均衡；媒體文件在媒體服務器上自動地被緩存，可提高文件的訪問速度。否則，可以考慮自己在媒體服務器上開發相應的工具，如緩存工具能定時地統計出最近的熱點媒體文件，將熱點文件複製到本地硬盤上，並替換緩存中的非熱點文件，最後通知其他媒體服務器結點它所緩存的媒體
文件以及負載情況；在媒體服務器上有應用層調度工具，它收到客戶的媒體服務請求，若所請求的媒體文件緩存在本地硬盤上，則直接轉給本地媒體服務進程服務，否則先考慮該文件是否被其他媒體服務器緩存；如該文件被其他服務器緩存並且該服務器不忙，則將請求轉給該服務器上的媒
體服務進程處理，否則直接轉給本地媒體服務進程，從後端的共享存儲中讀出媒體文件。
共享存儲的好處是媒體文件的管理人員看到統一的存儲空間，使得媒體文件維護工作比較方便。當客戶訪問不斷增加使得整個系統超載時，管理員可以很快地加入新的媒體服務器結點來處理請求。
Real公司以其高壓縮比的音頻視頻格式、Real媒體服務器和媒體播放器RealPlayer而聞名。Real公司正在使用以上結構將由20多臺服務器組成的LVS可伸縮Web和媒體集羣，爲其全球用戶提供Web和音頻視頻服務。Real公司的高級技術主管聲稱LVS擊敗所有他們嘗試過的商品化負載均
衡產品[7]。
5.可伸縮Cache服務
有效的網絡Cache系統可以大大地減少網絡流量、降低響應延時以及服務器的負載。但是，若Cache服務器超載而不能及時地處理請求，反而會增加響應延時。所以，Cache服務的可伸縮性很重要，當系統負載不斷增長時，整個系統能被擴展來提高Cache服務的處理能力。尤其，在主
幹網上的Cache服務可能需要幾個Gbps的吞吐率，單臺服務器（例如SUN目前最高端的Enterprise 10000服務器）遠不能達到這個吞吐率。可見，通過PC服務器集羣實現可伸縮Cache服務是很有效的方法，也是性能價格比最高的方法。
基於LVS的Cache集羣的體系結構如圖4所示：第一層是負載調度器，一般採用IP負載均衡技術，可以使得整個系統有較高的吞吐率；第二層是Cache服務器池，一般Cache服務器放置在接近主幹Internet連接處，它們可以分佈在不同的網絡中。調度器可以有多個，放在離客戶接近的
地方。
IPVS負載調度器一般使用IP隧道方法（即VS/TUN方法，將在以後文章中詳細敘述），來架構Cache集羣系統，因爲Cache服務器可能被放置不同的地方（例如在接近主幹Internet連接處），而調度器與Cache服務器池可能不在同一個物理網絡中。採用VS/TUN方法，調度器只調度Web
Cache請求，而Cache服務器將響應數據直接返回給客戶。在請求對象不能在本地命中的情況下，Cache服務器要向源服務器發請求，將結果取回，最後將結果返回給客戶；若採用NAT技術的商品化調度器，需要四次進出調度器，完成這個請求。而用VS/TUN方法（或者VS/DR方法），調度器只
調度一次請求，其他三次都由Cache服務器直接訪問Internet完成。所以，這種方法對Cache集羣系統特別有效。
Cache服務器採用本地硬盤來存儲可緩存的對象，因爲存儲可緩存的對象是寫操作，且佔有一定的比例，通過本地硬盤可以提高I/O的訪問速度。Cache服務器間有專用的多播通道（Multicast Channel），通過ICP協議（Internet Cache Protocol）來交互信息。當一臺Cache服務
器在本地硬盤中未命中當前請求時，它可以通過ICP查詢其他Cache服務器是否有請求對象的副本，若存在，則從鄰近的Cache服務器取該對象的副本，這樣可以進一步提高Cache服務的命中率。
爲150多所大學和地區服務的英國國家JANET Web Cache網在1999年11月用以上LVS結構實現可伸縮的Cache集羣[8]，只用了原有50多臺相互獨立Cache服務器的一半，用戶反映網絡速度跟夏天一樣快（學生放暑假）。可見，通過負載調度可以摸平單臺服務器訪問的毛刺（Burst）
，提高整個系統的資源利用率。
6.可伸縮郵件服務
隨着Internet用戶不斷增長，很多ISP面臨他們郵件服務器超載的問題。當郵件服務器不能容納更多的用戶帳號時，有些ISP買更高檔的服務器來代替原有的，將原有服務器的信息（如用戶郵件）遷移到新服務器是很繁瑣的工作，會造成服務的中斷；有些ISP設置新的服務器和新的
郵件域名，新的郵件用戶放置在新的服務器上，如上海電信現在用不同的郵件服務器public1.sta.net.cn、public2.sta.net.cn到public9.sta.net.cn放置用戶的郵件帳號，這樣靜態地將用戶分割到不同的服務器上，會造成郵件服務器負載不平衡，系統的資源利用率低，對用戶來說郵件的
地址比較難記。
可以利用LVS框架實現高可伸縮、高可用的郵件服務系統。它的體系結構如圖5所示：在前端是一個採用IP負載均衡技術的負載調度器；第二層是服務器池，有LDAP（Light-weight Directory Access Protocol）服務器和一組郵件服務器。第三層是數據存儲，通過分佈式文件系
統來存儲用戶的郵件。集羣中各結點是通過高速網絡相連接。
用戶的信息如用戶名、口令、主目錄和郵件容量限額等存儲在LDAP服務器中，可以通過HTTPS讓管理員進行用戶管理。在各個郵件服務器上運行SMTP（Simple Mail Transfer Protocol）、POP3（Post Office Protocol version 3）、IMAP4（Internet Message Access P
rotocol version 4）和HTTP/HTTPS服務。SMTP接受和轉發用戶的郵件，SMTP服務進程查詢LDAP服務器獲得用戶信息，再存儲郵件。POP3和IMAP4通過LDAP服務器獲得用戶信息，口令驗證後，處理用戶的郵件訪問請求。這裏，需要有機制避免不同服務器上的SMTP、POP3和IMAP4服務進程對
用戶郵件的讀寫衝突。HTTP/HTTPS服務是讓用戶通過瀏覽器可以訪問郵件。
IPVS調度器將SMTP、POP3、IMAP4和HTTP/HTTPS請求流負載較均衡地分發到各郵件服務器上，從上面各服務的處理流程來看，不管請求被髮送到哪一臺郵件服務器處理，其結果是一樣的。這裏，將SMTP、POP3、IMAP4和HTTP/HTTPS運行在各個郵件服務器上進行集中調度，有利於提高
整個系統的資源利用率。
系統中可能的瓶頸是LDAP服務器，對LDAP服務中B+樹的參數進行優化，再結合高端的服務器，可以獲得較高的性能。若分佈式文件系統沒有多個存儲結點間的負載均衡機制，則需要相應的郵件遷移機制來避免郵件訪問的傾斜。
這樣，這個集羣系統對用戶來說就像一個高性能、高可靠的郵件服務器（例如上海電信只要用一個郵件域名public.sta.net.cn就可以）。當郵件用戶不斷增長時，只要在集羣中增加服務器結點和存儲結點。用戶信息的集中存儲使得用戶管理變得容易，且集羣系統有利於提高資源
利用率。
7.小結
本文給出LVS集羣的通用體系結構，並討論了它的設計原則和相應的特點；最後將LVS集羣應用於建立可伸縮的Web、Media、Cache和Mail網絡服務，並指出了系統架設時應注意的要點。我們將在後續的文章中詳細解釋LVS集羣的技術、實現和應用。
[目錄]
IP負載均衡
本文在分析服務器集羣實現虛擬網絡服務的相關技術上，詳細描述了LVS集羣中實現的三種IP負載均衡技術（VS/NAT、VS/TUN和VS/DR）的工作原理，以及它們的優缺點。
1.前言
在前面文章中，講述了可伸縮網絡服務的幾種結構，它們都需要一個前端的負載調度器（或者多個進行主從備份）。我們先分析實現虛擬網絡服務的主要技術，指出IP負載均衡技術是在負載調度器的實現技術中效率最高的。在已有的IP負載均衡技術中，主要有通過網絡地址轉換（
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負載均衡技術，我們將在文章中詳細描述它們的工作原理和
各自的優缺點。
在以下描述中，我們稱客戶的socket和服務器的socket之間的數據通訊爲連接，無論它們是使用TCP還是UDP協議。下面簡述當前用服務器集羣實現高可伸縮、高可用網絡服務的幾種負載調度方法，並列舉幾個在這方面有代表性的研究項目。
2.實現虛擬服務的相關方法
在網絡服務中，一端是客戶程序，另一端是服務程序，在中間可能有代理程序。由此看來，可以在不同的層次上實現多臺服務器的負載均衡。用集羣解決網絡服務性能問題的現有方法主要分爲以下四類。
2.1. 基於RR-DNS的解決方法
NCSA的可伸縮的WEB服務器系統就是最早基於RR-DNS（Round-Robin Domain Name System）的原型系統[1,2]。它的結構和工作流程如下圖所示：
有一組WEB服務器，他們通過分佈式文件系統AFS(Andrew File System)來共享所有的HTML文檔。這組服務器擁有相同的域名（如[url]www.ncsa.uiuc.edu[/url]），當用戶按照這個域名訪問時, RR-DNS服務器會把域名輪流解析到這組服務器的不同IP地址，從而將訪問負載分到各臺服務器上
。
這種方法帶來幾個問題。第一，域名服務器是一個分佈式系統，是按照一定的層次結構組織的。當用戶就域名解析請求提交給本地的域名服務器，它會因不能直接解析而向上一級域名服務器提交，上一級域名服務器再依次向上提交，直到RR-DNS域名服器把這個域名解析到其中一臺
服務器的IP地址。可見，從用戶到RR-DNS間存在多臺域名服器，而它們都會緩衝已解析的名字到IP地址的映射,這會導致該域名服器組下所有用戶都會訪問同一WEB服務器，出現不同WEB服務器間嚴重的負載不平衡。爲了保證在域名服務器中域名到IP地址的映射不被長久緩衝，RR-DNS在域名
到IP地址的映射上設置一個TTL(Time To Live)值，過了這一段時間，域名服務器將這個映射從緩衝中淘汰。當用戶請求，它會再向上一級域名服器提交請求並進行重新影射。這就涉及到如何設置這個TTL值，若這個值太大，在這個TTL期間，很多請求會被映射到同一臺WEB服務器上，同樣
會導致嚴重的負載不平衡。若這個值太小，例如是０，會導致本地域名服務器頻繁地向RR-DNS提交請求，增加了域名解析的網絡流量，同樣會使RR-DNS服務器成爲系統中一個新的瓶頸。
第二，用戶機器會緩衝從名字到IP地址的映射，而不受TTL值的影響，用戶的訪問請求會被送到同一臺WEB服務器上。由於用戶訪問請求的突發性和訪問方式不同，例如有的人訪問一下就離開了，而有的人訪問可長達幾個小時，所以各臺服務器間的負載仍存在傾斜（Skew）而不能控
制。假設用戶在每個會話中平均請求數爲20，負載最大的服務器獲得的請求數額高於各服務器平均請求數的平均比率超過百分之三十。也就是說，當TTL值爲0時，因爲用戶訪問的突發性也會存在着較嚴重的負載不平衡。
第三，系統的可靠性和可維護性差。若一臺服務器失效，會導致將域名解析到該服務器的用戶看到服務中斷，即使用戶按“Reload”按鈕，也無濟於事。系統管理員也不能隨時地將一臺服務器切出服務進行系統維護，如進行操作系統和應用軟件升級，這需要修改RR-DNS服務器中的
IP地址列表，把該服務器的IP地址從中劃掉，然後等上幾天或者更長的時間，等所有域名服器將該域名到這臺服務器的映射淘汰，和所有映射到這臺服務器的客戶機不再使用該站點爲止。
2.2. 基於客戶端的解決方法
基於客戶端的解決方法需要每個客戶程序都有一定的服務器集羣的知識，進而把以負載均衡的方式將請求發到不同的服務器。例如，Netscape Navigator瀏覽器訪問Netscape的主頁時，它會隨機地從一百多臺服務器中挑選第N臺，最後將請求送往wwwN.netscape.com。然而，這不
是很好的解決方法，Netscape只是利用它的Navigator避免了RR-DNS解析的麻煩，當使用IE等其他瀏覽器不可避免的要進行RR-DNS解析。
Smart Client[3]是Berkeley做的另一種基於客戶端的解決方法。服務提供一個Java Applet在客戶方瀏覽器中運行，Applet向各個服務器發請求來收集服務器的負載等信息，再根據這些信息將客戶的請求發到相應的服務器。高可用性也在Applet中實現，當服務器沒有響應時，Ap
plet向另一個服務器轉發請求。這種方法的透明性不好，Applet向各服務器查詢來收集信息會增加額外的網絡流量，不具有普遍的適用性。
2.3. 基於應用層負載均衡調度的解決方法
多臺服務器通過高速的互聯網絡連接成一個集羣系統，在前端有一個基於應用層的負載調度器。當用戶訪問請求到達調度器時，請求會提交給作負載均衡調度的應用程序，分析請求，根據各個服務器的負載情況，選出一臺服務器，重寫請求並向選出的服務器訪問，取得結果後，再
返回給用戶。
應用層負載均衡調度的典型代表有Zeus負載調度器[4]、pWeb[5]、Reverse-Proxy[6]和SWEB[7]等。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等應用，都需要重寫調度器。
2.4. 基於IP層負載均衡調度的解決方法
用戶通過虛擬IP地址（Virtual IP Address）訪問服務時，訪問請求的報文會到達負載調度器，由它進行負載均衡調度，從一組真實服務器選出一個，將報文的目標地址Virtual IP Address改寫成選定服務器的地址，報文的目標端口改寫成選定服務器的相應端口，最後將報文
發送給選定的服務器。真實服務器的迴應報文經過負載調度器時，將報文的源地址和源端口改爲Virtual IP Address和相應的端口，再把報文發給用戶。Berkeley的MagicRouter[8]、Cisco的LocalDirector、Alteon的ACEDirector和F5的Big/IP等都是使用網絡地址轉換方法。MagicRouter
是在Linux 1.3版本上應用快速報文插入技術，使得進行負載均衡調度的用戶進程訪問網絡設備接近核心空間的速度，降低了上下文切換的處理開銷，但並不徹底，它只是研究的原型系統，沒有成爲有用的系統存活下來。Cisco的LocalDirector、Alteon的ACEDirector和F5的Big/IP是非常
昂貴的商品化系統，它們支持部分TCP/UDP協議，有些在ICMP處理上存在問題。
IBM的TCP Router[9]使用修改過的網絡地址轉換方法在SP/2系統實現可伸縮的WEB服務器。TCP Router修改請求報文的目標地址並把它轉發給選出的服務器，服務器能把響應報文的源地址置爲TCP Router地址而非自己的地址。這種方法的好處是響應報文可以直接返回給客戶，壞
處是每臺服務器的操作系統內核都需要修改。IBM的NetDispatcher[10]是TCP Router的後繼者，它將報文轉發給服務器，而服務器在non-ARP的設備配置路由器的地址。這種方法與LVS集羣中的VS/DR類似，它具有很高的可伸縮性，但一套在IBM SP/2和NetDispatcher需要上百萬美金。總的
來說，IBM的技術還挺不錯的。
在貝爾實驗室的ONE-IP[11]中，每臺服務器都獨立的IP地址，但都用IP Alias配置上同一VIP地址，採用路由和廣播兩種方法分發請求，服務器收到請求後按VIP地址處理請求，並以VIP爲源地址返回結果。這種方法也是爲了避免迴應報文的重寫，但是每臺服務器用IP Alias配置
上同一VIP地址，會導致地址衝突，有些操作系統會出現網絡失效。通過廣播分發請求，同樣需要修改服務器操作系統的源碼來過濾報文，使得只有一臺服務器處理廣播來的請求。
微軟的Windows NT負載均衡服務（Windows NT Load Balancing Service，WLBS）[12]是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）[64, 65, 66]。這些地址不在Internet上使用，而是專門爲內部網絡預留的。當內部網絡中的主機要訪問Internet或
被Internet訪問時，就需要採用網絡地址轉換（Network Address Translation, 以下簡稱NAT），將內部地址轉化爲Internets上可用的外部地址。NAT的工作原理是報文頭（目標地址、源地址和端口等）被正確改寫後，客戶相信它們連接一個IP地址，而不同IP地址的服務器組也認爲它
們是與客戶直接相連的。由此，可以用NAT方法將不同IP地址的並行網絡服務變成在一個IP地址上的一個虛擬服務。
VS/NAT的體系結構如圖2所示。在一組服務器前有一個調度器，它們是通過Switch/HUB相連接的。這些服務器提供相同的網絡服務、相同的內容，即不管請求被髮送到哪一臺服務器，執行結果是一樣的。服務的內容可以複製到每臺服務器的本地硬盤上，可以通過網絡文件系統（如N
FS）共享，也可以通過一個分佈式文件系統來提供。
客戶通過Virtual IP Address（虛擬服務的IP地址）訪問網絡服務時，請求報文到達調度器，調度器根據連接調度算法從一組真實服務器中選出一臺服務器，將報文的目標地址Virtual IP Address改寫成選定服務器的地址，報文的目標端口改寫成選定服務器的相應端口，最後
將修改後的報文發送給選出的服務器。同時，調度器在連接Hash表中記錄這個連接，當這個連接的下一個報文到達時，從連接Hash表中可以得到原選定服務器的地址和端口，進行同樣的改寫操作，並將報文傳給原選定的服務器。當來自真實服務器的響應報文經過調度器時，調度器將報文的
源地址和源端口改爲Virtual IP Address和相應的端口，再把報文發給用戶。我們在連接上引入一個狀態機，不同的報文會使得連接處於不同的狀態，不同的狀態有不同的超時值。在TCP連接中，根據標準的TCP有限狀態機進行狀態遷移，這裏我們不一一敘述，請參見W. Richard Steve
ns的《TCP/IP Illustrated Volume I》；在UDP中，我們只設置一個UDP狀態。不同狀態的超時值是可以設置的，在缺省情況下，SYN狀態的超時爲1分鐘，ESTABLISHED狀態的超時爲15分鐘，FIN狀態的超時爲1分鐘；UDP狀態的超時爲5分鐘。當連接終止或超時，調度器將這個連接從連接H
ash表中刪除。
這樣，客戶所看到的只是在Virtual IP Address上提供的服務，而服務器集羣的結構對用戶是透明的。對改寫後的報文，應用增量調整Checksum的算法調整TCP Checksum的值，避免了掃描整個報文來計算Checksum的開銷。
在一些網絡服務中，它們將IP地址或者端口號在報文的數據中傳送，若我們只對報文頭的IP地址和端口號作轉換，這樣就會出現不一致性，服務會中斷。所以，針對這些服務，需要編寫相應的應用模塊來轉換報文數據中的IP地址或者端口號。我們所知道有這個問題的網絡服務有FT
P、IRC、H.323、CUSeeMe、Real Audio、Real Video、Vxtreme / Vosiac、VDOLive、VIVOActive、True Speech、RSTP、PPTP、StreamWorks、NTT AudioLink、NTT SoftwareVision、Yamaha MIDPlug、iChat Pager、Quake和Diablo。
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.3 8000 2
TCP 202.103.106.5 21 172.16.0.3 21 1
從以下的例子中，我們可以更詳細地瞭解報文改寫的流程。
訪問Web服務的報文可能有以下的源地址和目標地址：
SOURCE 202.100.1.2:3456 DEST 202.103.106.5:80
調度器從調度列表中選出一臺服務器，例如是172.16.0.3:8000。該報文會被改寫爲如下地址，並將它發送給選出的服務器。
SOURCE 202.100.1.2:3456 DEST 172.16.0.3:8000
從服務器返回到調度器的響應報文如下：
SOURCE 172.16.0.3:8000 DEST 202.100.1.2:3456
響應報文的源地址會被改寫爲虛擬服務的地址，再將報文發送給客戶：
SOURCE 202.103.106.5:80 DEST 202.100.1.2:3456
這樣，客戶認爲是從202.103.106.5:80服務得到正確的響應，而不會知道該請求是服務器172.16.0.2還是服務器172.16.0.3處理的。
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地址上的虛擬網絡服務。VS/TUN的體系結構如圖4所示，各個服務器將VIP地址配置在自己的IP隧道設備上。
VS/TUN的工作流程如圖5所示：它的連接調度和管理與VS/NAT中的一樣，只是它的報文轉發方法不同。調度器根據各個服務器的負載情況，動態地選擇一臺服務器，將請求報文封裝在另一個IP報文中，再將封裝後的IP報文轉發給選出的服務器；服務器收到報文後，先將報文解封獲
得原來目標地址爲VIP的報文，服務器發現VIP地址被配置在本地的IP隧道設備上，所以就處理這個請求，然後根據路由表將響應報文直接返回給客戶。
在這裏需要指出，根據缺省的TCP/IP協議棧處理，請求報文的目標地址爲VIP，響應報文的源地址肯定也爲VIP，所以響應報文不需要作任何修改，可以直接返回給客戶，客戶認爲得到正常的服務，而不會知道究竟是哪一臺服務器處理的。
5. 通過直接路由實現虛擬服務器（VS/DR）
跟VS/TUN方法相同，VS/DR利用大多數Internet服務的非對稱特點，負載調度器中只負責調度請求，而服務器直接將響應返回給客戶，可以極大地提高整個集羣系統的吞吐量。該方法與IBM的NetDispatcher產品中使用的方法類似（其中服務器上的IP地址配置方法是相似的），但IBM
的NetDispatcher是非常昂貴的商品化產品，我們也不知道它內部所使用的機制，其中有些是IBM的專利。
VS/DR的體系結構如圖7所示：調度器和服務器組都必須在物理上有一個網卡通過不分斷的局域網相連，如通過高速的交換機或者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.三種方法的優缺點比較
三種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服務。使用更高的硬件配置（如千兆網卡和更快的處理器）作爲調度器，調度器所能調度的服務器數量會相應增加。當應用不同時，
服務器的數目也會相應地改變。所以，以上數據估計主要是爲三種方法的伸縮性進行量化比較。
6.1. 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-D
NS組成簡單的域名。但VS/TUN和VS/DR是提高系統吞吐量的更好方法。
對於那些將IP地址或者端口號在報文數據中傳送的網絡服務，需要編寫相應的應用模塊來轉換報文數據中的IP地址或者端口號。這會帶來實現的工作量，同時應用模塊檢查報文的開銷會降低系統的吞吐率。
6.2. 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應該會適用運行其他操
作系統的後端服務器。
6.3. Virtual Server via Direct Routing
跟VS/TUN方法一樣，VS/DR調度器只處理客戶到服務器端的連接，響應數據可以直接從獨立的網絡路由返回給客戶。這可以極大地提高LVS集羣系統的伸縮性。
跟VS/TUN相比，這種方法沒有IP隧道的開銷，但是要求負載調度器與實際服務器都有一塊網卡連在同一物理網段上，服務器網絡設備（或者設備別名）不作ARP響應，或者能將報文重定向（Redirect）到本地的Socket端口上。
7.小結
本文主要講述了LVS集羣中的三種IP負載均衡技術。在分析網絡地址轉換方法（VS/NAT）的缺點和網絡服務的非對稱性的基礎上，我們給出了通過IP隧道實現虛擬服務器的方法VS/TUN，和通過直接路由實現虛擬服務器的方法VS/DR，極大地提高了系統的伸縮性。
[目錄]
負載調度
本文主要講述了LVS集羣的IP負載均衡軟件IPVS在內核中實現的各種連接調度算法。針對請求的服務時間變化很大，給出一個動態反饋負載均衡算法，它結合內核中的加權連接調度算法，根據動態反饋回來的負載信息來調整服務器的權值，來進一步避免服務器間的負載不平衡。
1. 前言
在上一篇文章中，我們主要講述了LVS集羣中實現的三種IP負載均衡技術，它們主要解決系統的可伸縮性和透明性問題，如何通過負載調度器將請求高效地分發到不同的服務器執行，使得由多臺獨立計算機組成的集羣系統成爲一臺虛擬服務器；客戶端應用程序與集羣系統交互時，
就像與一臺高性能的服務器交互一樣。
本文將主要講述在負載調度器上的負載調度策略和算法，如何將請求流調度到各臺服務器，使得各臺服務器儘可能地保持負載均衡。文章主要由兩個部分組成。第一部分描述IP負載均衡軟件IPVS在內核中所實現的各種連接調度算法；第二部分給出一個動態反饋負載均衡算法（Dyna
mic-feedback load balancing），它結合內核中的加權連接調度算法，根據動態反饋回來的負載信息來調整服務器的權值，來進一步避免服務器間的負載不平衡。
在下面描述中，我們稱客戶的socket和服務器的socket之間的數據通訊爲連接，無論它們是使用TCP還是UDP協議。對於UDP數據報文的調度，IPVS調度器也會爲之建立調度記錄並設置超時值（如5分鐘）；在設定的時間內，來自同一地址（IP地址和端口）的UDP數據包會被調度到同
一臺服務器。
2. 內核中的連接調度算法
IPVS在內核中的負載均衡調度是以連接爲粒度的。在HTTP協議（非持久）中，每個對象從WEB服務器上獲取都需要建立一個TCP連接，同一用戶的不同請求會被調度到不同的服務器上，所以這種細粒度的調度在一定程度上可以避免單個用戶訪問的突發性引起服務器間的負載不平衡。
在內核中的連接調度算法上，IPVS已實現了以下八種調度算法：
輪叫調度（Round-Robin Scheduling）
加權輪叫調度（Weighted Round-Robin Scheduling）
最小連接調度（Least-Connection Scheduling）
加權最小連接調度（Weighted Least-Connection Scheduling）
基於局部性的最少鏈接（Locality-Based Least Connections Scheduling）
帶複製的基於局部性最少鏈接（Locality-Based Least Connections with Replication Scheduling）
目標地址散列調度（Destination Hashing Scheduling）
源地址散列調度（Source Hashing Scheduling）
下面，我們先介紹這八種連接調度算法的工作原理和算法流程，會在以後的文章中描述怎麼用它們。
2.1. 輪叫調度
輪叫調度（Round Robin Scheduling）算法就是以輪叫的方式依次將請求調度不同的服務器，即每次調度執行i = (i + 1) mod n，並選出第i臺服務器。算法的優點是其簡潔性，它無需記錄當前所有連接的狀態，所以它是一種無狀態調度。
在系統實現時，我們引入了一個額外條件，當服務器的權值爲零時，表示該服務器不可用而不被調度。這樣做的目的是將服務器切出服務（如屏蔽服務器故障和系統維護），同時與其他加權算法保持一致。所以，算法要作相應的改動，它的算法流程如下：
輪叫調度算法流程
假設有一組服務器S = {S0, S1, …, Sn-1}，一個指示變量i表示上一次選擇的
服務器，W(Si)表示服務器Si的權值。變量i被初始化爲n-1，其中n > 0。
j = i;
do {
j = (j + 1) mod n;
if (W(Sj) > 0) {
i = j;
return Si;
}
} while (j != i);
return NULL;
輪叫調度算法假設所有服務器處理性能均相同，不管服務器的當前連接數和響應速度。該算法相對簡單，不適用於服務器組中處理性能不一的情況，而且當請求服務時間變化比較大時，輪叫調度算法容易導致服務器間的負載不平衡。
雖然Round-Robin DNS方法也是以輪叫調度的方式將一個域名解析到多個IP地址，但輪叫DNS方法的調度粒度是基於每個域名服務器的，域名服務器對域名解析的緩存會妨礙輪叫解析域名生效，這會導致服務器間負載的嚴重不平衡。這裏，IPVS輪叫調度算法的粒度是基於每個連接
的，同一用戶的不同連接都會被調度到不同的服務器上，所以這種細粒度的輪叫調度要比DNS的輪叫調度優越很多。
2.2. 加權輪叫調度
加權輪叫調度（Weighted Round-Robin Scheduling）算法可以解決服務器間性能不一的情況，它用相應的權值表示服務器的處理性能，服務器的缺省權值爲1。假設服務器A的權值爲1，B的權值爲2，則表示服務器B的處理性能是A的兩倍。加權輪叫調度算法是按權值的高低和輪叫
方式分配請求到各服務器。權值高的服務器先收到的連接，權值高的服務器比權值低的服務器處理更多的連接，相同權值的服務器處理相同數目的連接數。加權輪叫調度算法流程如下：
加權輪叫調度算法流程
假設有一組服務器S = {S0, S1, …, Sn-1}，W(Si)表示服務器Si的權值，一個
指示變量i表示上一次選擇的服務器，指示變量cw表示當前調度的權值，max(S)
表示集合S中所有服務器的最大權值，gcd(S)表示集合S中所有服務器權值的最大
公約數。變量i和cw最初都被初始化爲零。
while (true) {
if (i == 0) {
cw = cw - gcd(S);
if (cw <= 0) {
cw = max(S);
if (cw == 0)
return NULL;
}
} else i = (i + 1) mod n;
if (W(Si) >= cw)
return Si;
}
例如，有三個服務器A、B和C分別有權值4、3和2，則在一個調度週期內(mod sum(W(Si)))調度序列爲AABABCABC。加權輪叫調度算法還是比較簡單和高效。當請求的服務時間變化很大，單獨的加權輪叫調度算法依然會導致服務器間的負載不平衡。
從上面的算法流程中，我們可以看出當服務器的權值爲零時，該服務器不被被調度；當所有服務器的權值爲零，即對於任意i有W(Si)=0，則沒有任何服務器可用，算法返回NULL，所有的新連接都會被丟掉。加權輪叫調度也無需記錄當前所有連接的狀態，所以它也是一種無狀態調度
。
2.3. 最小連接調度
最小連接調度（Least-Connection Scheduling）算法是把新的連接請求分配到當前連接數最小的服務器。最小連接調度是一種動態調度算法，它通過服務器當前所活躍的連接數來估計服務器的負載情況。調度器需要記錄各個服務器已建立連接的數目，當一個請求被調度到某臺服
務器，其連接數加1；當連接中止或超時，其連接數減一。
在系統實現時，我們也引入當服務器的權值爲零時，表示該服務器不可用而不被調度，它的算法流程如下：
最小連接調度算法流程
假設有一組服務器S = {S0, S1, ..., Sn-1}，W(Si)表示服務器Si的權值，
C(Si)表示服務器Si的當前連接數。
for (m = 0; m < n; m++) {
if (W(Sm) > 0) {
for (i = m+1; i < n; i++) {
if (W(Si) <= 0)
continue;
if (C(Si) < C(Sm))
m = i;
}
return Sm;
}
}
return NULL;
當各個服務器有相同的處理性能時，最小連接調度算法能把負載變化大的請求分佈平滑到各個服務器上，所有處理時間比較長的請求不可能被髮送到同一臺服務器上。但是，當各個服務器的處理能力不同時，該算法並不理想，因爲TCP連接處理請求後會進入TIME_WAIT狀態，TCP的T
IME_WAIT一般爲2分鐘，此時連接還佔用服務器的資源，所以會出現這樣情形，性能高的服務器已處理所收到的連接，連接處於TIME_WAIT狀態，而性能低的服務器已經忙於處理所收到的連接，還不斷地收到新的連接請求。
2.4. 加權最小連接調度
加權最小連接調度（Weighted Least-Connection Scheduling）算法是最小連接調度的超集，各個服務器用相應的權值表示其處理性能。服務器的缺省權值爲1，系統管理員可以動態地設置服務器的權值。加權最小連接調度在調度新連接時儘可能使服務器的已建立連接數和其權
值成比例。加權最小連接調度的算法流程如下：
加權最小連接調度的算法流程
假設有一組服務器S = {S0, S1, ..., Sn-1}，W(Si)表示服務器Si的權值，
C(Si)表示服務器Si的當前連接數。所有服務器當前連接數的總和爲
CSUM = ΣC(Si) (i=0, 1, .. , n-1)。當前的新連接請求會被髮送服務器Sm，
當且僅當服務器Sm滿足以下條件
(C(Sm) / CSUM)/ W(Sm) = min { (C(Si) / CSUM) / W(Si)} (i=0, 1, . , n-1)
其中W(Si)不爲零
因爲CSUM在這一輪查找中是個常數，所以判斷條件可以簡化爲
C(Sm) / W(Sm) = min { C(Si) / W(Si)} (i=0, 1, . , n-1)
其中W(Si)不爲零
因爲除法所需的CPU週期比乘法多，且在Linux內核中不允許浮點除法，服務器的
權值都大於零，所以判斷條件C(Sm) / W(Sm) > C(Si) / W(Si) 可以進一步優化
爲C(Sm)*W(Si) > C(Si)* W(Sm)。同時保證服務器的權值爲零時，服務器不被調
度。所以，算法只要執行以下流程。
for (m = 0; m < n; m++) {
if (W(Sm) > 0) {
for (i = m+1; i < n; i++) {
if (C(Sm)*W(Si) > C(Si)*W(Sm))
m = i;
}
return Sm;
}
}
return NULL;
2.5. 基於局部性的最少鏈接調度
基於局部性的最少鏈接調度（Locality-Based Least Connections Scheduling，以下簡稱爲LBLC）算法是針對請求報文的目標IP地址的負載均衡調度，目前主要用於Cache集羣系統，因爲在Cache集羣中客戶請求報文的目標IP地址是變化的。這裏假設任何後端服務器都可以處理
任一請求，算法的設計目標是在服務器的負載基本平衡情況下，將相同目標IP地址的請求調度到同一臺服務器，來提高各臺服務器的訪問局部性和主存Cache命中率，從而整個集羣系統的處理能力。
LBLC調度算法先根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於其一半的工作負載，則用“最少鏈接”的原則選出一個可用的服務器，將請求發送到該服務
器。該算法的詳細流程如下：
LBLC調度算法流程
假設有一組服務器S = {S0, S1, ..., Sn-1}，W(Si)表示服務器Si的權值，
C(Si)表示服務器Si的當前連接數。ServerNode[dest_ip]是一個關聯變量，表示
目標IP地址所對應的服務器結點，一般來說它是通過Hash表實現的。WLC(S)表示
在集合S中的加權最小連接服務器，即前面的加權最小連接調度。Now爲當前系統
時間。
if (ServerNode[dest_ip] is NULL) then {
n = WLC(S);
if (n is NULL) then return NULL;
ServerNode[dest_ip].server = n;
} else {
n = ServerNode[dest_ip].server;
if ((n is dead) OR
(C(n) > W(n) AND
there is a node m with C(m) < W(m)/2))) then {
n = WLC(S);
if (n is NULL) then return NULL;
ServerNode[dest_ip].server = n;
}
}
ServerNode[dest_ip].lastuse = Now;
return n;
此外，對關聯變量ServerNode[dest_ip]要進行週期性的垃圾回收（Garbage Collection），將過期的目標IP地址到服務器關聯項進行回收。過期的關聯項是指哪些當前時間（實現時採用系統時鐘節拍數jiffies）減去最近使用時間超過設定過期時間的關聯項，系統缺省的設定過
期時間爲24小時。
2.6. 帶複製的基於局部性最少鏈接調度
帶複製的基於局部性最少鏈接調度（Locality-Based Least Connections with Replication Scheduling，以下簡稱爲LBLCR）算法也是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。它與LBLC算法的不同之處是它要維護從一個目標IP地址到一組服務器的映射，
而LBLC算法維護從一個目標IP地址到一臺服務器的映射。對於一個“熱門”站點的服務請求，一臺Cache服務器可能會忙不過來處理這些請求。這時，LBLC調度算法會從所有的Cache服務器中按“最小連接”原則選出一臺Cache服務器，映射該“熱門”站點到這臺Cache服務器，很快這臺Cach
e服務器也會超載，就會重複上述過程選出新的Cache服務器。這樣，可能會導致該“熱門”站點的映像會出現在所有的Cache服務器上，降低了Cache服務器的使用效率。LBLCR調度算法將“熱門”站點映射到一組Cache服務器（服務器集合），當該“熱門”站點的請求負載增加時，會增加集
合裏的Cache服務器，來處理不斷增長的負載；當該“熱門”站點的請求負載降低時，會減少集合裏的Cache服務器數目。這樣，該“熱門”站點的映像不太可能出現在所有的Cache服務器上，從而提供Cache集羣系統的使用效率。
LBLCR算法先根據請求的目標IP地址找出該目標IP地址對應的服務器組；按“最小連接”原則從該服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載；則按“最小連接”原則從整個集羣中選出一臺服務器，將該服務器加入到服務器組中，將請
求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低複製的程度。LBLCR調度算法的流程如下：
LBLCR調度算法流程
假設有一組服務器S = {S0, S1, ..., Sn-1}，W(Si)表示服務器Si的權值，
C(Si)表示服務器Si的當前連接數。ServerSet[dest_ip]是一個關聯變量，表示
目標IP地址所對應的服務器集合，一般來說它是通過Hash表實現的。WLC(S)表示
在集合S中的加權最小連接服務器，即前面的加權最小連接調度；WGC(S)表示在
集合S中的加權最大連接服務器。Now爲當前系統時間，lastmod表示集合的最近
修改時間，T爲對集合進行調整的設定時間。
if (ServerSet[dest_ip] is NULL) then {
n = WLC(S);
if (n is NULL) then return NULL;
add n into ServerSet[dest_ip];
} else {
n = WLC(ServerSet[dest_ip]);
if ((n is NULL) OR
(n is dead) OR
(C(n) > W(n) AND
there is a node m with C(m) < W(m)/2))) then {
n = WLC(S);
if (n is NULL) then return NULL;
add n into ServerSet[dest_ip];
} else
if (|ServerSet[dest_ip]| > 1 AND
Now - ServerSet[dest_ip].lastmod > T) then {
m = WGC(ServerSet[dest_ip]);
remove m from ServerSet[dest_ip];
}
}
ServerSet[dest_ip].lastuse = Now;
if (ServerSet[dest_ip] changed) then
ServerSet[dest_ip].lastmod = Now;
return n;
此外，對關聯變量ServerSet[dest_ip]也要進行週期性的垃圾回收（Garbage Collection），將過期的目標IP地址到服務器關聯項進行回收。過期的關聯項是指哪些當前時間（實現時採用系統時鐘節拍數jiffies）減去最近使用時間（lastuse）超過設定過期時間的關聯項，系統
缺省的設定過期時間爲24小時。
2.7. 目標地址散列調度
目標地址散列調度（Destination Hashing Scheduling）算法也是針對目標IP地址的負載均衡，但它是一種靜態映射算法，通過一個散列（Hash）函數將一個目標IP地址映射到一臺服務器。
目標地址散列調度算法先根據請求的目標IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。該算法的流程如下：
目標地址散列調度算法流程
假設有一組服務器S = {S0, S1, ..., Sn-1}，W(Si)表示服務器Si的權值，
C(Si)表示服務器Si的當前連接數。ServerNode[]是一個有256個桶（Bucket）的
Hash表，一般來說服務器的數目會運小於256，當然表的大小也是可以調整的。
算法的初始化是將所有服務器順序、循環地放置到ServerNode表中。若服務器的
連接數目大於2倍的權值，則表示服務器已超載。
n = ServerNode[hashkey(dest_ip)];
if ((n is dead) OR
(W(n) == 0) OR
(C(n) > 2*W(n))) then
return NULL;
return n;
在實現時，我們採用素數乘法Hash函數，通過乘以素數使得散列鍵值儘可能地達到較均勻的分佈。所採用的素數乘法Hash函數如下：
素數乘法Hash函數
static inline unsigned hashkey(unsigned int dest_ip)
{
return (dest_ip* 2654435761UL) & HASH_TAB_MASK;
}
其中，2654435761UL是2到2^32 (4294967296)間接近於黃金分割的素數，
(sqrt(5) - 1) / 2 = 0.618033989
2654435761 / 4294967296 = 0.618033987
2.8. 源地址散列調度
源地址散列調度（Source Hashing Scheduling）算法正好與目標地址散列調度算法相反，它根據請求的源IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。它採用的散列函數與目標
地址散列調度算法的相同。它的算法流程與目標地址散列調度算法的基本相似，除了將請求的目標IP地址換成請求的源IP地址，所以這裏不一一敘述。
在實際應用中，源地址散列調度和目標地址散列調度可以結合使用在防火牆集羣中，它們可以保證整個系統的唯一出入口。
3. 動態反饋負載均衡算法
動態反饋負載均衡算法考慮服務器的實時負載和響應情況，不斷調整服務器間處理請求的比例，來避免有些服務器超載時依然收到大量請求，從而提高整個系統的吞吐率。圖1顯示了該算法的工作環境，在負載調度器上運行Monitor Daemon進程，Monitor Daemon來監視和收集各
個服務器的負載信息。Monitor Daemon可根據多個負載信息算出一個綜合負載值。Monitor Daemon將各個服務器的綜合負載值和當前權值算出一組新的權值，若新權值和當前權值的差值大於設定的閥值，Monitor Daemon將該服務器的權值設置到內核中的IPVS調度中，而在內核中連接調
度一般採用加權輪叫調度算法或者加權最小連接調度算法。
3.1. 連接調度
當客戶通過TCP連接訪問網絡訪問時，服務所需的時間和所要消耗的計算資源是千差萬別的，它依賴於很多因素。例如，它依賴於請求的服務類型、當前網絡帶寬的情況、以及當前服務器資源利用的情況。一些負載比較重的請求需要進行計算密集的查詢、數據庫訪問、很長響應數
據流；而負載比較輕的請求往往只需要讀一個HTML頁面或者進行很簡單的計算。
請求處理時間的千差萬別可能會導致服務器利用的傾斜（Skew），即服務器間的負載不平衡。例如，有一個WEB頁面有A、B、C和D文件，其中D是大圖像文件，瀏覽器需要建立四個連接來取這些文件。當多個用戶通過瀏覽器同時訪問該頁面時，最極端的情況是所有D文件的請求被髮
到同一臺服務器。所以說，有可能存在這樣情況，有些服務器已經超負荷運行，而其他服務器基本是閒置着。同時，有些服務器已經忙不過來，有很長的請求隊列，還不斷地收到新的請求。反過來說，這會導致客戶長時間的等待，覺得系統的服務質量差。
3.1.1. 簡單連接調度
簡單連接調度可能會使得服務器傾斜的發生。在上面的例子中，若採用輪叫調度算法，且集羣中正好有四臺服務器，必有一臺服務器總是收到D文件的請求。這種調度策略會導致整個系統資源的低利用率，因爲有些資源被用盡導致客戶的長時間等待，而其他資源空閒着。
3.1.2. 實際TCP/IP流量的特徵
網絡流量是呈波浪型發生的，在一段較長時間的小流量後，會有一段大流量的訪問，然後是小流量，這樣跟波浪一樣週期性地發生。文獻[2,3,4,5]揭示在WAN和LAN上網絡流量存在自相似的特徵，在WEB訪問流也存在自相似性。這就需要一個動態反饋機制，利用服務器組的狀態來應
對訪問流的自相似性。
3.2. 動態反饋負載均衡機制
TCP/IP流量的特徵通俗地說是有許多短事務和一些長事務組成，而長事務的工作量在整個工作量佔有較高的比例。所以，我們要設計一種負載均衡算法，來避免長事務的請求總被分配到一些機器上，而是儘可能將帶有毛刺（Burst）的分佈分割成相對較均勻的分佈。
我們提出基於動態反饋負載均衡機制，來控制新連接的分配，從而控制各個服務器的負載。例如，在IPVS調度器的內核中使用加權輪叫調度（Weighted Round-Robin Scheduling）算法來調度新的請求連接；在負載調度器的用戶空間中運行Monitor Daemon。Monitor Daemon定
時地監視和收集各個服務器的負載信息，根據多個負載信息算出一個綜合負載值。Monitor Daemon將各個服務器的綜合負載值和當前權值算出一組新的權值。當綜合負載值表示服務器比較忙時，新算出的權值會比其當前權值要小，這樣新分配到該服務器的請求數就會少一些。當綜合負載
值表示服務器處於低利用率時，新算出的權值會比其當前權值要大，來增加新分配到該服務器的請求數。若新權值和當前權值的差值大於設定的閥值，Monitor Daemon將該服務器的權值設置到內核中的IPVS調度中。過了一定的時間間隔（如2秒鐘），Monitor Daemon再查詢各個服務器的
情況，並相應調整服務器的權值；這樣週期性地進行。可以說，這是一個負反饋機制，使得服務器保持較好的利用率。
在加權輪叫調度算法中，當服務器的權值爲零，已建立的連接會繼續得到該服務器的服務，而新的連接不會分配到該服務器。系統管理員可以將一臺服務器的權值設置爲零，使得該服務器安靜下來，當已有的連接都結束後，他可以將該服務器切出，對其進行維護。維護工作對系統
都是不可少的，比如硬件升級和軟件更新等，零權值使得服務器安靜的功能很主要。所以，在動態反饋負載均衡機制中我們要保證該功能，當服務器的權值爲零時，我們不對服務器的權值進行調整。
3.3. 綜合負載
在計算綜合負載時，我們主要使用兩大類負載信息：輸入指標和服務器指標。輸入指標是在調度器上收集到的，而服務器指標是在服務器上的各種負載信息。我們用綜合負載來反映服務器當前的比較確切負載情況，對於不同的應用，會有不同的負載情況，這裏我們引入各個負載信
息的係數，來表示各個負載信息在綜合負載中輕重。系統管理員根據不同應用的需求，調整各個負載信息的係數。另外，系統管理員設置收集負載信息的時間間隔。
輸入指標主要是在單位時間內服務器收到新連接數與平均連接數的比例，它是在調度器上收集到的，所以這個指標是對服務器負載情況的一個估計值。在調度器上有各個服務器收到連接數的計數器，對於服務器Si，可以得到分別在時間T1和T2時的計數器值Ci1和Ci2，計算出在時間
間隔T2-T1內服務器Si收到新連接數Ni = Ci2 - Ci1。這樣，得到一組服務器在時間間隔T2-T1內服務器Si收到新連接數{Ni}，服務器Si的輸入指標INPUTi爲其新連接數與n臺服務器收到平均連接數的比值，其公式爲
服務器指標主要記錄服務器各種負載信息，如服務器當前CPU負載LOADi、服務器當前磁盤使用情況Di、當前內存利用情況Mi和當前進程數目Pi。有兩種方法可以獲得這些信息；一是在所有的服務器上運行着SNMP（Simple Network Management Protocol）服務進程，而在調度器
上的Monitor Daemon通過SNMP向各個服務器查詢獲得這些信息；二是在服務器上實現和運行收集信息的Agent，由Agent定時地向Monitor Daemon報告負載信息。若服務器在設定的時間間隔內沒有響應，Monitor Daemon認爲服務器是不可達的，將服務器在調度器中的權值設置爲零，不會
有新的連接再被分配到該服務器；若在下一次服務器有響應，再對服務器的權值進行調整。再對這些數據進行處理，使其落在[0, ∞)的區間內，1表示負載正好，大於1表示服務器超載，小於1表示服務器處於低負載狀態。獲得調整後的數據有DISKi、MEMORYi和PROCESSi。
另一個重要的服務器指標是服務器所提供服務的響應時間，它能比較好地反映服務器上請求等待隊列的長度和請求的處理時間。調度器上的Monitor Daemon作爲客戶訪問服務器所提供的服務，測得其響應時間。例如，測試從WEB服務器取一個HTML頁面的響應延時，Monitor Daemo
n只要發送一個“GET /”請求到每個服務器，然後記錄響應時間。若服務器在設定的時間間隔內沒有響應，Monitor Daemon認爲服務器是不可達的，將服務器在調度器中的權值設置爲零。同樣，我們對響應時間進行如上調整，得到RESPONSEi。
這裏，我們引入一組可以動態調整的係數Ri來表示各個負載參數的重要程度，其中ΣRi = 1。綜合負載可以通過以下公式計算出：
例如，在WEB服務器集羣中，我們採用以下係數{0.1, 0.3, 0.1, 0.1, 0.1, 0.3}，認爲服務器的CPU負載和請求響應時間較其他參數重要一些。若當前的係數Ri不能很好地反映應用的負載，系統管理員可以對係數不斷地修正，直到找到貼近當前應用的一組係數。
另外，關於查詢時間間隔的設置，雖然很短的間隔可以更確切地反映各個服務器的負載，但是很頻繁地查詢（如1秒鐘幾次）會給調度器和服務器帶來一定的負載，如頻繁執行的Monitor Daemon在調度器會有一定的開銷，同樣頻繁地查詢服務器指標會服務器帶來一定的開銷。所以
，這裏要有個折衷（Tradeoff），我們一般建議將時間間隔設置在5到20秒之間。
3.4. 權值計算
當服務器投入集羣系統中使用時，系統管理員對服務器都設定一個初始權值DEFAULT_WEIGHTi，在內核的IPVS調度中也先使用這個權值。然後，隨着服務器負載的變化，對權值進行調整。爲了避免權值變成一個很大的值，我們對權值的範圍作一個限制[DEFAULT_WEIGHTi, SCALE*DE
FAULT_WEIGHTi]，SCALE是可以調整的，它的缺省值爲10。
Monitor Daemon週期性地運行，若DEFAULT_WEIGHTi不爲零，則查詢該服務器的各負載參數，並計算出綜合負載值AGGREGATE_LOADi。我們引入以下權值計算公式，根據服務器的綜合負載值調整其權值。
在公式中，0.95是我們想要達到的系統利用率，A是一個可調整的係數（缺省值爲5）。當綜合負載值爲0.95時，服務器權值不變；當綜合負載值大於0.95時，權值變小；當綜合負載值小於0.95時，權值變大。若新權值大於SCALE*DEFAULT_WEIGHTi，我們將新權值設爲SCALE*DEFAULT
_WEIGHTi。若新權值與當前權值的差異超過設定的閥值，則將新權值設置到內核中的IPVS調度參數中，否則避免打斷IPVS調度的開銷。我們可以看出這是一個負反饋公式，會使得權值調整到一個穩定點，如系統達到理想利用率時，權值是不變的。
在實際使用中，若發現所有服務器的權值都小於他們的DEFAULT_WEIGHT，則說明整個服務器集羣處於超載狀態，這時需要加入新的服務器結點到集羣中來處理部分負載；反之，若所有服務器的權值都接近於SCALE*DEFAULT_WEIGHT，則說明當前系統的負載都比較輕。
3.5. 一個實現例子
我們在RedHat集羣管理工具Piranha[6]中實現了一個簡單的動態反饋負載均衡算法。在綜合負載上，它只考慮服務器的CPU負載（Load Average），使用以下公式進行權值調整：
服務器權值調整區間爲[DEFAULT_WEIGHTi, 10*DEFAULT_WEIGHTi]，A爲DEFAULT_WEIGHTi /2，而權值調整的閥值爲DEFAULT_WEIGHTi /4。1是所想要達到的系統利用率。Piranha每隔20秒查詢各臺服務器的CPU負載，進行權值計算和調整。
4. 小結
本文主要講述了IP虛擬服務器在內核中實現的八種連接調度算法：
·輪叫調度（Round-Robin Scheduling）
·加權輪叫調度（Weighted Round-Robin Scheduling）
·最小連接調度（Least-Connection Scheduling）
·加權最小連接調度（Weighted Least-Connection Scheduling）
·基於局部性的最少鏈接（Locality-Based Least Connections Scheduling）
·帶複製的基於局部性最少鏈接（Locality-Based Least Connections with Replication Scheduling）
·目標地址散列調度（Destination Hashing Scheduling）
·源地址散列調度（Source Hashing Scheduling）
因爲請求的服務時間差異較大，內核中的連接調度算法容易使得服務器運行出現傾斜。爲此，給出了一個動態反饋負載均衡算法，結合內核中的加權連接調度算法，根據動態反饋回來的負載信息來調整服務器的權值，來調整服務器間處理請求數的比例，從而避免服務器間的負載不
平衡。動態反饋負載算法可以較好地避免服務器的傾斜，提高系統的資源使用效率，從而提高系統的吞吐率。
[目錄]
安裝配置
這篇文檔將解釋怎樣建立和管理可提供高質量的web和ftp服務的lvs(linux虛擬服務器)集羣。
-------------------------------------------------------------------------------
目錄
-------------------------------------------------------------------------------
簡介
一個lvs集羣的組件
lvs集羣的背景
硬件/網絡的要求
lvs路由的必要條件
集羣節點內部連接的必要條件
安裝軟件
配置一個lvs集羣
例子---建立一個5節點的集羣
[目錄]
簡介
linux虛擬服務器集羣是一個被特別配置的，可提供高性能web和ftp服務的服務器的集合。在下面的圖表中闡述了lvs集羣是怎樣工作的。到達一個lvs集羣的服務請求被尋址到一個虛擬的服務器上。一個公開廣告的，完整網域名稱與一個浮動的ip地址相關聯，這種浮動ip地址能遷
移到不同的節點。
Figure 1. LVS Cluster Interactions
_/\__/\_
| |
/ Internet \
\_ _ _ _/
\/ \/ \/
|
|
Virtual Server IP/FQDN
|------------------------------------------|
|eth0 |eth0
------|----- -------|-----
| Primary | | Backup |
| Node | | Node | LVS
| | | | routers
------|----- -------|-----
|eth1 |eth1
|-------|------------|-----------------|---|
| | |
| | |
| | |
|----|----| |----|----| |----|----|
| Web/FTP | | Web/FTP | | Web/FTP | real
| Node#1 | | Node#2 | ... | Node#n | servers
|_________| |_________| |_________|
一個lvs集羣由一個或兩個路由節點和很多數量的web/ftp服務器(底部)組成。我們把lvs路由節點稱作lvs 路由，而將web/ftp服務器的彙集稱作真實服務器。真實服務器通過內部網絡相連。lvs 路由同時相連着內部網絡和公共網絡。對於把lvs 路由與內部網絡和公共網絡連接
起來的適配器(圖中的eth0和eth1)可以是任何的設備，但是每個路由上的設備必須是相同的。
在同一時刻，僅有一個路由是激活的。激活的路由扮演的角色是將虛擬服務器上的服務請求重定向到真實服務器。重定向基於四種負載平衡算法規則中的一種(如表一)。激活的路由通過三種被支持方式中的一種(如圖二)，動態的監視真實服務器的健康情況和每個服務器的工作量。
如果有一個真實服務器無效了，在工作的router將停止向這臺服務器發送任務直到服務器恢復正常運轉。
lvs 路由定期通過公共網互相交換“我活着的”心臟跳動信息。當備份的節點在與其在一段時間間隔內沒有接收到心臟跳動信息，它將啓動failover以取代激活的路由。在failover過程中，備份路由將接管失敗的路由的浮動ip地址(在集羣配置文件中指示)，利用arp(地址解析協
議)欺騙技術，開始宣佈自己爲失敗節點ip包尋址的目的地。當失敗的節點恢復服務時，它將承擔熱備份這個角色。
當前，lvs集羣支持一個路由選擇的方式，net address translation(nat)(將來，tunneling和direct routing將被加入。)。下面的圖表闡述了一個nat虛擬服務器是怎樣工作的。
Figure 2. An LVS Cluster Implemented with NAT Routing
_/\__/\_
| |
/ Internet \
\_ _ _ _/
\/ \/ \/
|
|
|------------------------------------------| public
| network
eth0 | virtual server IP address
--------------------
| active router |
| |
--------------------
eth1 | NAT router IP address
|
|-------|-------------------------|--------| private
| | network
| |
| |
|----|----------| |-----------|---|
| real server#1 | | real server#2 |
| | | | ...
|_______________| |_______________|
客戶端的服務請求到達一個虛擬服務器的ip地址。這是個公共廣告地址，它被網站管理員與一個完整網域名稱相關聯(例如，lvs.agax.com)。在敘述中只看到了一個虛擬服務器地址，但是也可有多個。一個獨立的虛擬服務器地址包含了三個部分： 一個協議(tcp或udp)，一個ip地
址和端口號。
虛擬服務器的地址的ip部分是浮動的地址。他們也許是一個通過lvs路由連接到公共網絡的設備的別名(例如，eth0:1)，或者是每個ip地址與一個單獨的設備相聯繫。nat路由ip地址也是個浮動ip地址，每個在內部網絡中的真實服務器使用這個ip地址爲默認路由，與活動的路由通信
。對於虛擬服務器的地址，nat路由ip地址可以是連接虛擬服務器到真實服務器網絡的一個設備的別名(例如，eth1:1)，或者也可與一個獨立的設備相關聯。
虛擬服務器和nat尋址只可在被激活的路由上纔可運行。因此，如果激活狀態下的路由失敗了，通過接管浮動ip地址，備份路由便可運行虛擬服務器和nat尋址。如圖二所示的拓撲學原理，虛擬服務器尋址在eth0設備上運行，而nat路由尋址在eth1上運行。
核心中的ipvs表映射所有內部網絡中從虛擬服務器地址到真實服務器地址的請求。例如，在一個虛擬服務器1.2.3.1上，一個tcp請求被尋址到80端口也許被按指定路線發送到真實服務器192.168.1.2的80端口。在ipvs表中，對任務實際映射到哪個真實服務器上是基於使用某個負載
平衡規則。表一描述了被支持的負載平衡方式。
Table 1. Load-balancing Methods
名稱 描述
Round robin 將工作平均的分配到服務器
Least-connections 向較少連接的服務器分配較多的工作
(IPVS 表存儲了所有的活動的連接。)
Weighted round robin 向較大容量的服務器分配較多的工作。
容量通過用戶指定的砝碼來說明，
可以根據裝載信息動態的向上或向下調整。
Weighted least-connections 考慮它們的容量向較少連接的服務器分配較多的工作。
容量通過用戶指定的砝碼來說明，
可以根據裝載信息動態的向上或向下調整。
當真實服務器處理一個請求時，它將包返回到活動的路由，包中真實服務器的地址也被虛擬服務器的地址所代替。在這種規則下，對於客戶的請求，內部網絡中的真實服務器被僞裝起來。
[目錄]
組件
下面介紹一個lvs集羣的組件。
pulse
這是控制啓動其他守護進程的過程所需的。正常情況下它是在系統啓動時，在lvs路由上通過/etc/rc.d/init.d/pulse腳本啓動。通過pulse，提供一種簡單的心跳檢測，非活動的lvs路由決定活動的路由是否健康，是否需要啓動failover。
lvs
lvs守護進程在lvs路由上運行。它讀入配置文件，調用ipvsadm來建立和維護ipvs路由選擇表。
nanny
nanny將監視在活動的lvs路由上運行的守護進程。通過這個守護進程，活動的路由決定每個真實服務器是否健康，同時獲得服務器的工作量。它是一個被每個虛擬服務器使用的，獨立的在每個真實服務器上運行的進程。
/etc/lvs.cf
只是lvs集羣的配置文件。直接或間接的，所有的守護進程都從這個文件中獲得它們的配置信息。
piranha
這是一個圖形化的監視，配置和管理lvs集羣的工具。通常情況下，你將用這個工具來維護/etc/lvs.cf，重新啓動運行的守護進程，監視一個lvs集羣。
ipvsadm
這個工具用來更新核心中的ipvs路由選擇表。lvs守護進程通過調用ipvsadm向ipvs路由選擇表添加，改變或刪除項目來建立和管理一個lvs集羣。
[目錄]
背景
lvs集羣的背景
redhat lvs集羣是基於linux社團直接的貢獻，要不然就是linux社團工程使它的成分更富於靈感，更豐富。
lvs集羣主要是源於wensong zhang的linux虛擬服務器核心選擇規則(請看[url]http://www.linuxvirtualserver.org[/url])。當前redhat lvs支持的功能：
建立虛擬的服務器：公共網絡中的服務請求到達的地址，採用浮動ip地址。
虛擬服務器上的服務請求到真實服務器上的路由選擇。
負載平衡(看錶一)。
包轉發中的網絡地址翻譯。
lvs的創新被redhat lvs集羣所支持，它以很多的技術爲基礎，包括網絡地址的翻譯(nat)，ip僞裝，端口轉發。對於一般性的討論和相關howto的索引以及有關的主題，請看[url]http://www.linas.org/linux/load.html[/url]
[目錄]
硬件/網絡的要求
硬件/網絡的要求
一個lvs集羣由一個或兩個lvs路由，一些提供web和ftp服務的真實服務器組成。下面描述了連接和硬件的要求。
lvs路由
一個基本的lvs路由的要求是一個linux服務器。這臺機器要有兩個網絡適配器，一個與公共網絡連接而另一個與真實服務器的內部網絡連接。
如果要有failover功能，你需要有第二個linux服務器來作爲備份lvs路由。這臺機器也需要兩塊適配器來連接公共網絡和有真實服務器的內部網絡。兩個lvs路由中的適配器設備必須相匹配。因此，如果主lvs路由設備eth0和eth1分別與公共網和內部網相連，在備份lvs路由中的相
同設備也要分別與公共網和內部網連接。注意，備份lvs路由是個純熱候補機器。
真實服務器
lvs路由連接的內部網包括一定數量的web/ftp服務器主機。尋址到虛擬服務器上的工作被重定向到真實的服務器，這些服務器可以是各種各樣的，運行任何操作系統或是web服務器的計算機平臺。
在配置過程中，你對每個真實服務器的砝碼進行賦值。這是一個反映每個服務器處理能力的，與其它服務器相關聯在一起的整數(以內存，處理器速度，處理器個數，等等爲基礎)。它們是成比例的(2/1，20/10，200/100)，這很有效。例如，分配的砝碼是2000的服務器表示它的計
算能力是砝碼爲1000的服務器的兩倍。通過兩個有效的任務計劃規則(表一所示),以裝載信息爲基礎來分配砝碼，從而動態的調節砝碼。你應該準備制定一個準確的砝碼。
[目錄]
路由的必要條件
lvs路由的必要條件
lvs路由要求redhat linux6.1或更高的版本。在lvs路由上,packet-forwarding,packet defragmenting和ip masquerading必須是激活的。
激活packet-forwarding和defragmenting，確定/etc/sysconf/network中由這兩行：
FORWARD_IPV4=yes
DEFRAG_IPV4=yes
這些行將使/etc/rc.d/rc.sysinit在路由啓動時執行：
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/ip_always_defrag
激活ip masquerading，用這個命令：
ipchains -A forward -j MASQ -s n.n.n.n/type -d 0.0.0.0/0
其中：
n.n.n.n是內部子網的真實服務器的連接地址。
類型是8.16.24.32，他們表示地址的類型和掩碼： netmask | type | Subnet
~~~~~~~~~~~~~~~~|~~~~~~|~~~~~~~~~~~~~~~
255.0.0.0 | 8 | Class A
255.255.0.0 | 16 | Class B
255.255.255.0 | 24 | Class C
255.255.255.255 | 32 | Point-to-point
你也許要將ipchains命令加入到init腳本中去(例如，/etc/rc.d/rc.local)，這樣在lvs路由系統啓動時masquerading將被配置好。
ipchains是一個在覈心的tcp棧中設定的，用來產生和管理防火牆規則的工具。masquerading使用這些規則的一個小的部分，它允許機器通過內部網絡的ip與外面的網絡通信。使用ipchains對系統的安全有很大的影響。如果你對系統安全有興趣,請閱讀ipchains howto。([url]http://w[/url]
ww.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html).
[目錄]
節點內部連接的必要條件
在配置過程中，你選擇的工具集(rsh或ssh)將被用於在lvs路由中對/etc/lvs.cf
配置文件進行同步。選擇的工具必須在lvs路由中被激活，如此這樣每個路由上的root纔可在沒有管理者介入的情況下登陸到另外的路由上去。
並且在配置過程中，你也要選擇工具(uptime,ruptime,或rup)在活動的路由上用來監視真實服務器上的工作量。在真實服務器上激活這些被選中的工具。如果不能做到這點(例如，你的一個真實服務器是windows/nt web服務器)，集羣將仍然提供高性能的服務。然而，weighted r
ound robin 和weighted least-connections(表一介紹的)運算規則將受到影響。換句話說，因爲裝載的信息將不再有效，用戶分配的砝碼將靜態的被應用而不是動態的基於服務器工作量來調整。
表二描述了在通常情況下，你要在源主機和目標主機上做什麼來激活這些工具。要了解詳細的情況，請看man文件。注意，用rsh和ssh，root必須能在網絡中登陸。爲了在redhat linux系統中激活遠程登陸，從文件/etc/pam.d/login中移去下面這一行：
auth required /lib/security/pam_security.so
這是個安全漏洞，雖然很小。確信你的lvs節點有一個合適的防火牆，這樣可以允許值得信賴的節點登陸。
rsh
在目標主機上的根目錄下創建一個.rhosts文件，其屬性爲600，註明源 主機和用戶(例如，foo.host1.com root)。
ssh
獲得並安裝工具，由於法律原因沒有在國際的linux版本發行。在源主機和目標主機上禁止通過所有其它的方式遠程登陸，使用./ssh/authorized_keys建立基於rsa的認證，然後啓動sshd。
uptime
如上所示的方法，在每一個真實服務器上激活rsh或是ssh。
ruptime
設置在啓動時，每一個lvs路由和真實服務器上啓動rwhod。
rup
設置在啓動時，每一個真實服務器啓動rpc.rstatd。
[目錄]
安裝軟件
安裝軟件
lvs集羣的軟件包含三個發行的rpm軟件包：
piranha(程序)
piranha-gui(圖形界面的配置工具)
piranha-docs(文檔) 你可用這命令從6.1的光盤中安裝這些軟件包：
#rpm -Uvh /mnt/cdrom/RedHat/RPMS/piranha*.rpm
因爲你的硬件平臺的緣故，獲得這些軟件包合理的升級，請訪問redhat的網站[url]http://www.redhat.com/corp/support/errata/rh61-errata-updates.html[/url]
[目錄]
配置
配置一個lvs集羣
你可以從lvs路由通過編輯配置文件和啓動或重新啓動pulse守護進程，來安裝和維護lvs集羣。特別的幾個步驟是：
在主路由上，編輯配置文件/etc/lvs.cf。
拷貝編輯好的配置文件到備份路由上。
首先在主路由上啓動(或重啓)pulse守護進程，然後是備份路由。
你可用你喜歡的編輯器編輯配置文件，從shell中執行這幾步。在shell中的啓動重啓和停止的命令是：
/etc/rc.d/init.d/pulse start
/etc/rc.d/init.d/pulse restart
/etc/rc.d/init.d/pulse stop
當需要時，pulse守護進程啓動或重啓其他的lvs集羣守護進程，它們的配置文件信息是直接或間接的從當前的配置文件中獲得的。
如果你停止pulse(爲了關閉集羣)，首先要停止在備份路由上的pulse。這將阻止有可能備份路由代替激活的路由。
作爲一種選擇，你可用piranha來建立，監視和管理你的lvs集羣。可在它的窗口中設置或是改變/etc/lvs.cf中的一些行，這裏還有啓動，停止和重啓集羣的按鈕。使用piranha的要求是你的lvs路由必須配置好了x window系統。使用piranha的好處是它可同步主路由和備份路由上
的配置文件，你可在激活的路由上執行所有的管理任務執行。
下一章將描述lvs集羣的配置文件。如果你要手工配置這些文件，請閱讀這一章。如果你選擇使用piranha，請看 the section called Using the Piranha Configuration Tool.
編輯配置文件
/etc/lvs.cf文件有三個部分。全局部分，在表三中描述，建立lvs路由和特殊的網絡和心臟跳動檢測參數。這有一組集羣的參數。預設虛擬服務器一部分，在表四中描述，定義虛擬服務器的地址，建立虛擬服務器和真實服務器之間的關聯，還有特別的任務計劃參數。對每個被定義
的虛擬服務器都有一組獨立的參數。預設真實服務器一部分在表五中描述，定義從每個虛擬服務器到真實服務器的路由選擇。對每個虛擬服務器有一組參數。
Table 3. Setting Global Parameters
參數 描述
primary =
輸入通過連接主lvs路由到公共網絡的適配器的ip地址。
backup = backup=
輸入通過連接備份lvs路由到公共網絡的適配器的ip地址。
heartbeat_port =
輸入在主路由和備份路由上使用心臟跳動檢測的端口號。
keepalive =
輸入心臟跳動檢測時間間隔是多少秒。
deadtime =
輸入在等待幾秒後宣佈無響應路由死亡並且啓動failover
rsh_command = [rsh|ssh]
輸入熟悉的命令以同步主路由和備份路由的配置文件。重點：在表二中講述，你必須在主路由和備份路由上激活被選擇的命令。
network = [nat|direct|tunnel]
現在只有網絡地址翻譯被支持。
nat_router =
輸入浮動ip地址和nat路由設備。這個ip地址必須是每個真實服務器和活動lvs路由通信的默認路由。連接lvs路由到內部網絡上的真實服務器的設備是ip地址的別名(例如，eth1:1)。在兩個lvs路由上的設備必須是相同的(例如，eth1)。
Table 4. Setting Per-Virtual-Server Parameters
參數 描述
name
輸入一個唯一定義的虛擬服務器名字
address =
輸入虛擬服務器的ip地址：一個與全稱域名相關聯的浮動ip地址
active = [0|1]
激活(1)或屏蔽(0)這個ip地址
load_monitor = [uptime|ruptime|rup]
選擇在活動路由上用於監視真實服務器工作量的工具(默認是uptime)。重點：如表二中所述，除非你在真實服務器上激活選好的命令，使用動態載入信息的運行規則，將被應用於靜態的砝碼上，而不是通過載入信息來調整砝碼。如果你選擇默認方式(uptime)，這個你爲了"rsh_com
mand"而指定的工具，在登陸到真實服務器上時使用。在真實服務器端，這個工具必須被激活。
timeout =
輸入在真實服務器被確定死亡而移出路由表之前的一個失效時間(默認是10秒)
reentry =
輸入一個以恢復的真實服務器被重新加入到路由表中之前的持續正常的秒數(默認是180秒)。
port = [http/80|ftp/21]
輸入在虛擬服務器上的監聽端口：http用80(默認)或ftp用21端口。或是你也可輸入數字。
scheduler = [wlc|lc|wrr|rr]
選擇從虛擬服務器上到真實服務器，分配任務的運行規則(默認是wlc)選項在表一中描述。
Table 5. Setting Per-Real-Server Parameters
參數 描述
name
輸入唯一的真實服務器名字
address =
輸入真實服務器在內部網絡中的ip地址
active = [0|1]
激活(1)或是屏蔽(0)真實服務器
weight =
輸入一個指定這臺服務器的處理能力的整數(默認是1)，它與其它真實服務器相關聯。
使用piranha配置工具
啓動piranha的方法時，成爲root用戶然後打入piranha &。當你這樣做了後，它的主窗口將被打開。窗口由四個標籤：
控制/監視--第一個標籤。用於start/stop/restart集羣守護進程和監視運行狀態。看 the section called Controls/Monitoring Tab.
Global Settings --
用於設定主lvs路由和nat路由的ip地址。請看 the section called Global Settings Tab.
Redundancy --
設定備份路由的地址和心臟跳動檢測的參數。請看 the section called Redundancy Tab.
Virtual Servers --
用於設定服務器地址，建立服務器地址和真實的web/ftp服務器主機之間的路由選擇。請看 the section called Virtual Servers.
piranha窗口有一些這樣的按鈕:
OK -- 應用改變同時退出窗口。
Apply -- 應用改變但不退出窗口。
Close -- 不應用改變而退出窗口。
Controls/Monitoring Tab
區域/按鈕 描述
Start/Stop
當集羣守護進程還沒有運行時，這個按鈕標記爲開始：點擊它來啓動集羣。當集羣守護進程沒有運行時，這個按鈕標記爲停止：點擊它停止集羣守護進程。
Add pulse daemon to this runlevel
選擇在這個運行級中，在系統啓動時啓動pulse。
Update information now
點擊來顯示當前核心路由表的信息。
Auto-update
選擇在特定的時間間隔內自動顯示核心路由表信息。
Global Settings Tab
區域/按鈕 描述
Primary LVS server IP
包含了lvs主路由的公共ip地址
NAT Router IP
包含了與連接虛擬服務器網絡到真實服務器網絡的網絡適配器相關聯的浮動ip地址。這個地址被用作真實服務器與虛擬服務器通信的網關。如果這個節點失敗，其地址將被lvs備份路由節點所繼承。
NAT Router Device
與nat路由ip地址相聯繫的設備的名字。這個通過地址別名來實現。例如，nat路由的ip可以爲物理設備eth1化名爲eth1:1。
Sync tool
選擇用來同步主路由和備份路由的工具。你選的工具必須激活，這樣lvs路由纔可相互登陸而不用輸入密碼。一般的過程請看錶二 。
Redundancy Tab
區域/按鈕 描述
Enable redundant server
選擇激活failover。
Redundant LVS server
IP 包含備份路由的公共ip。
Heartbeat interval (seconds)
包含了兩次心臟跳動檢測之間的秒數：備份lvs節點檢測主lvs節點看是否還活着的時間間隔。
Assume dead after (seconds)
如果時間用完了主lvs節點還無響應，備份路由將啓動failover。在failover過程中，備份路由接管所有的在主lvs路由上處理的虛擬服務器的ip，無條件廣播arps，通知它的mac地址作爲尋址到主路由包的目標地址。
Heartbeat port
輸入在主路由和備份路由中用於心跳檢測的端口。
Virtual Servers
屏幕顯示一排當前被定義的虛擬服務器的信息。點擊一排信息來選擇它。在屏幕右邊的按鈕是應用當前選擇的虛擬服務器。點擊刪除是移去選擇的虛擬服務器。
區域/按鈕 描述
Status
顯示激活或屏蔽。點擊屏蔽來關閉一個激活的虛擬服務器。點擊激活來啓動一個選擇的虛擬服務器。改變狀態後，你必須要重啓pulse守護進程來使改變生效。要這樣做的話，到controls/monitoring tab，點擊停止按鈕(它的名字變爲了啓動)，而後點擊啓動。
Name
包含一個唯一定義的虛擬服務器名。
Port
包含監聽到來的服務請求的端口。
Protocol
當前只有tcp被支持。
Add/Edit a Virtual Server
點擊添加按鈕來創建一個新的未被定義的虛擬服務器。點擊編輯按鈕(或是雙擊這排信息)來定義或修改一個虛擬服務器。點擊真實服務器標籤來觀看或是修改被選好的與真實服務器相關聯的虛擬服務器。
區域/按鈕 描述
Name
輸入對這個虛擬服務器唯一定義的名字
Application
點擊選擇http或是ftp
Port
輸入監聽到來的服務請求的端口
Address
輸入服務請求到達的浮動ip地址。這個服務請求到達的地址已和一個全稱的域名相關聯。
Device
一個連接lvs路由到公共網絡，其浮動ip地址通過ip別名相關聯的適配器設備的名字(例如，eht0:1)。如果活動路由失敗，在這期間虛擬服務器地址和端口將轉到在備份路由上的對應設備上，從而備份路由成爲活動路由。
Re-entry Time
輸入一個以恢復的真實服務器被重新加入到路由表中之前的持續正常的秒數(默認是180秒)。
Service timeout
輸入一個以秒爲單位的時間，在這段時間裏真實服務器必須響應一個重定向請求。如果主機超過了這個時間，它將被宣佈爲死亡並從集羣中移除。
每個兩秒鐘在活動路由上運行的nanny進程發送一個心臟跳動檢測(必要的ping連接)到每個真實服務器。如果成功了，服務連接(必要的一個telnet連接)將被送到一個特定的服務端口。如果nanny收到從真實服務器返回的任何響應，真實服務器和提供的服務被推定爲活着。如果無響
應服務超時超過了有效秒數，那麼這個真實服務器將被推定爲死亡並被一除出路由表。但是nanny通過每兩秒鐘發送一次心跳檢測繼續監視着服務器和它提供的服務。如果，在一次成功的ping以後，一個被移出去的服務器保持"re-entery time"時間的存活，它將被重新加入到核心路由表中
去。
Load monitoring tool
選擇用於決定在真實服務器上工作量的工具(uptime,ru,或ruptime)。在表二的表格中描述了激活這些工具的一般過程。
Scheduling
選擇從虛擬服務器到真實服務器上的請求的路由選擇規則。在表以中描述了選項。
Real Servers
屏幕顯示了每個當前被定義的真實服務器的一排信息。點擊這一排信息來選定它。屏幕右邊的按鈕是應用當前選擇的一排。點擊刪除來移去一個被選擇的真實服務器。
區域/按鈕 描述
Status
顯示激活或屏蔽。點擊屏蔽來關閉一個激活的虛擬服務器。點擊激活來啓動一個選擇的虛擬服務器。改變狀態後，你必須要重啓pulse守護進程來使改變生效。要這樣做的話，到controls/monitoring tab，點擊停止按鈕(它的名字變爲了啓動)，而後點擊啓動。
Name
顯示服務器在集羣中的名字。
Address
顯示服務器的ip地址。
Add/Edit a Real Server
點擊添加按鈕來創建一個新的未被定義的真實服務器。點擊編輯按鈕(或是雙擊這排信息)來定義或修改一個真實服務器。
區域/按鈕 描述
Name
輸入一個描述名字。
Address
輸入一個才內部網絡中的真實服務器的ip地址。
Weight
輸入一個指定這臺服務器的處理能力的整數，它與其它真實服務器相關聯。
[目錄]
例子
例子---建立一個5節點的集羣
這一節將一步步地介紹怎樣建立一個由兩個lvs路由和三個web/ftp服務器的集羣。首先，收集信息然後照着接下來一節說明的一樣來建立五個系統。然後是從shell方式對這個例子加以補充(在 the section called Implementing the Example from the Shell中解釋)或
是啓動一個圖形界面的配置工具(在 the section called Implementing the Example with Piranha說明) 。
圖三顯示了在你裝完lvs路由和真實服務器後將出現的網絡。所有顯示的網絡地址是爲了闡述得更明白。
Figure 3. Layout of the Example Network
|-------|------------------------------------------|---------| Public network
|eth0=1.2.3.2 |eth0=1.2.3.3
|eth0:1=1.2.3.1 (vs1) |
------|----- -------|-----
| active | | backup |
| router | | router |
| | | |
------|----- -------|-----
|eth1=192.168.1.1 |eth1=192.168.1.2
|eth1:1=192.168.1.254 (NAT router) |
|-------|-|------------------|-----------------|---|----------| Private network
|eth0=192.168.1.3 |eth0=192.168.1.4 |eth0=192.168.1.5
| | |
|---------| |---------| |---------|
| rs1 | | rs2 | | rs3 |
|_________| |_________| |_________|
初步設置
從網絡管理員那獲得虛擬服務器的ip地址。在我們的例子中將是1.2.3.1。在lvs集羣中的服務請求將被尋址到一個和這個地址相關聯的全稱域名上。
定位五個服務器和指定它們的角色：1個主lvs路由，1個備份路由，3個真實服務器。lvs路由必須裝上了linux系統，運行red hat 6.1或更高。真實服務器可以是任何平臺，運行任何操作系統和web服務器。
3-7步建立lvs路由。
在每個lvs路由上，裝有兩個以太網卡，eth0和eth1。在eth0上建立一個公共ip界面和一個內部ip界面。公共界面的設備(eth0)是用於心臟跳動檢測的設備。虛擬服務器的地址是這個設備的別名。
Primary node Backup node
eth0 1.2.3.2 1.2.3.3
eth1 192.168.1.1 192.168.1.2
爲路由上連接活動路由到內部網絡的設備(eth1)制定一個ip地址(192.168.1.254)。這個浮動ip地址將在路由設備上化名爲eth1:1，同時將成爲每個真實服務器與活動路由通信的默認路由和內部網絡的網關。
在每個lvs路由上：
激活package forwarding。在系統啓動時執行，確信文件/etc/sysconf/newwork包含了這以行forward_ipv4=yes。激活package forwarding而不用重啓，登陸爲root輸入下面命令：
echo "1" > /proc/sys/net/ipv4/ip_forward
激活packet defragmenting。在系統啓動時便執行，確信文件/etc/sysconf/network包含這一行defrag_piv4=yes。激活package defragmenting而不用重啓，登陸爲root輸入下面的命令：
echo "1" > /proc/sys/net/ipv4/ip_always_defrag
僞裝內部網絡。輸入下面這條命令到/etc/rc.d/rc.local：
ipchains -A forward -j MASQ -s 192.168.1.0/24 -d 0.0.0.0
決定是否使用類似於rsh或ssh進行lvs集羣文件同步。驗證你的選擇是否安裝，這樣lvs路由纔可登陸到其他的路由上，而不用管理者介入。在這個例子中，我們選擇rsh。
在每個lvs路由上，驗證lvs集羣軟件是否裝好。
8-11步是建立真實服務器。
在每個真實服務器上，裝有一個以太網卡，eth0。照第3步在同一個內部子網絡中建立一個ip地址，爲每個服務器分配一個砝碼，這是一個反映每個服務器處理能力的，與其它服務器相關聯在一起的整數。在這個例子中，rs1有兩倍於rs2和rs3的處理能力(兩個處理器)
rs1 rs2 rs3
eth0 192.168.1.3 192.168.1.4 192.168.1.5
weight 2000 1000 1000
在每個真實服務器上驗證在第四步中註明的地址是它與活動路由通信的默認路由。
決定用哪個程序(uptime,ruptime,rup)在活動路由上運行，用來監視真實服務器上的工作量。如果選擇uptime，每個lvs路由必須在無管理員介入的情況下與每個真實服務器連接，在第6步中使用你選擇的類似的工具。得到一般的激活指令請看錶二。如果你選擇的工具不能被激活(
例如，其中一個真實服務器是一個nt系統)，使用動態裝載信息的計劃規則仍將工作，但是用戶分配的砝碼將靜態的被應用而不是動態的基於服務器工作量來調整。
驗證每個真實服務器上安裝和配置了http服務。注意：真實服務器必須監聽與虛擬服務器對應的同一個端口(如例中的80)。
驗證(例中用telnet或ping)每個真實服務器可到達公共網絡上的主機。如果一個在內部網絡上的真實服務器不可達到，這預示着服務器與活動路由間的通信失敗了。看8和9步。
確定運行參數。對於這裏的一些參數，你也許需要測試一定的時間來獲得一個恰當的值。在這個例子中，我們用了列表中的值。
取值 參數描述
1050
主路由和備份路由心跳檢測的監聽端口。
2
心跳檢測的時間間隔秒數 。
10
宣佈無響應路由死亡並且啓動failover的等待秒數。
10
無響應真實服務器被確定死亡而移出路由表的等待秒數 。
180
當一個真實服務器被移出路由表後開始又有了響應，在被重新加入到路由表的等待秒秒數。
wlc
使用weight least-connections負載平衡規則(考慮其動態調整的砝碼，分配較多的工作給不忙的服務器)。對選項的描述請看錶一。
http
應用程序。可選項有ftp。
80
虛擬服務器上的端口數。在虛擬服務器上的監聽端口，在真實服務器上也是同樣的。
現在我麼準備補充一個例子。你可向下一節中的例子一樣在shell下工作。或者你也可象例( the section called Implementing the Example with Piranha.)中的用圖形界面的配置工具。
補充一個shell下配置的例子
用你喜歡的編輯器，打開/etc/lvs.cf文件，設置如下所示的值。 右邊的數字是在 the section called Preliminary Setup 中討論配置的每步的鏈接。
# Global section
primary = 1.2.3.2 3
backup = 1.2.3.3 3
keepalive = 2 13
deadtime = 10 13
heartbeat_port = 1050 13
rsh_command = rsh 6
network = nat
nat_router = 192.168.1.254 eth1:1 4
# Per-virtual-server section
virtual server vs1 { 8
address = 1.2.3.1 1
active = 1
load_monitor = ruptime 10
timeout = 10 13
reentry = 180 13
port = 80 13
scheduler = wlc 13
# Per-real-server section
server rs1 { 8
address = 192.168.1.3 8
active = 1
weight = 2000 8
}
server rs2 { 8
address = 192.168.1.4 8
active = 1
weight = 1000 8
}
server rs3 { 8
address = 192.168.1.5 8
active = 1
weight = 1000 8
}
}
拷貝編輯好的配置文件到備份路由上。
在主路由上，用這個命令啓動pulse守護進程：
/etc/rc.d/init.d/pulse start
在備份路由上啓動pulse守護進程。
補充一個用piranha的例子
在主路由上，登陸爲root，打入piranha &啓動圖形配置工具。
點擊global settings標籤輸入下面的值：
Field Enter: See Step:
Primary LVS server IP 1.2.3.2 3
NAT Router IP 192.168.1.254 4
NAT Router Device eth1:1 4
Sync tool rsh 6
點擊redundancy標籤輸入下面的值：
Field Enter: See Step:
Enable Redundant server (select)
Redundant LVS server IP 1.2.3.3 3
Heartbeat interval 2 13
Assume dead after 10 13
Heartbeat port 1050 13
點擊virtual servers標籤。在標籤上，點擊add,然後是edit，輸入下面
的值：
Field Enter: See Step:
Name vs1
Application http 13
Port 80 13
Address 1.2.3.1 1
Device eth0:1 3
Re-entry time 180 13
Service timeout 10 13
Load monitoring tool ruptime 10
Scheduling weighted least-connections 13
點擊real servers標籤。在標籤上，點擊add,然後是edit，輸入下面的值：
Field Enter: See Step:
Name rs1 8
Address 192.168.1.3 8
Weight 2000 8
在rs2和rs3上重複第5步。對於他們來說，輸入砝碼爲1000，這表示了rs1的運算能力是rs2和rs3的兩倍。
點擊close回到real servers標籤。在這裏，選擇每一個真實服務器點擊activate來激活它。
點擊close回到virtual servers標籤。在這裏，選擇每一個虛擬服務器點擊activate來激活它。
點擊controls/monitoring標籤：
點擊start按鈕(名字改變爲stop)。
如果你選中"add pulse daemon to this runlevel"集羣將在系統啓動時啓動，在piranha啓動時，上面的按鈕通常將被標爲stop。
登陸到備份路游泳這條命令啓動pulse：
/etc/rc.d/init.d/pulse start
如果你正確的輸入了上面所示的值，piranha將在配置文件最後產生一個如下結構的信息，這些將在虛擬服務器和它的真實服務器上使用。
network = nat
nat_router = 192.168.1.254 eth1:1
virtual vs1 {
address = 1.2.3.1 eth0:1
active = 1
scheduler = wlc
load_monitor = ruptime
timeout = 5
server rs1 {
address = 192.168.1.3
active = 1
weight = 2000
}
server rs2 {
address = 192.168.1.4
active = 1
weight = 1000
}
server rs3 {
address = 192.168.1.5
active = 1
weight = 1000
}
}
[目錄]
簡單實例
通過Linux LVS，實現WWW，Telnet服務的負載平衡。這裏實現Telnet集羣服務僅爲了測試上的方便。
LVS有三種負載平衡方式，NAT（Network Address Translation），DR（Direct Routing），IP Tunneling。其中，最爲常用的是DR方式，因此這裏只說明DR(Direct Routing)方式的LVS負載平衡。
網絡拓撲結構。
爲測試方便，4臺機器處於同一網段內，通過一交換機或者集線器相連。實際的應用中，最好能夠將虛擬服務器vs1和真實服務器rs1, rs2置於於不同的網段上，即提高了性能，也加強了整個集羣系統的安全性。
服務器的軟硬件配置
首先說明，雖然本文的測試環境中用的是3臺相同配置的服務器，但LVS並不要求集羣中的服務器規格劃一，相反，可以根據服務器的不同配置和負載情況，調整負載分配策略，充分利用集羣環境中的每一臺服務器。
這3臺服務器中，vs1作爲虛擬服務器（即負載平衡服務器），負責將用戶的訪問請求轉發到集羣內部的rs1,rs2，然後由rs1,rs2分別處理。
client爲客戶端測試機器，可以爲任意操作系統。
4臺服務器的操作系統和網絡配置分別爲：
vs1: RedHat 6.2, Kernel 2.2.19
vs1: eth0 192.168.0.1
vs1: eth0:101 192.168.0.101
rs1: RedHat 6.2, Kernel 2.2.14
rs1: eth0 192.168.0.3
rs1: dummy0 192.168.0.101
rs2: RedHat 6.2, Kernel 2.2.14
rs2: eth0 192.168.0.4
rs2: dummy0 192.168.0.101
client: Windows 2000
client: eth0 192.168.0.200
其中，192.168.0.101是允許用戶訪問的IP。
虛擬服務器的集羣配置
大部分的集羣配置工作都在虛擬服務器vs1上面，需要下面的幾個步驟：
重新編譯內核。
首先，下載最新的Linux內核，版本號爲2.2.19，下載地址爲：[url]http://www.kernel.org/[/url]，解壓縮後置於/usr/src/linux目錄下。
其次需要下載LVS的內核補丁，地址爲：[url]http://www.linuxvirtualserver.org/software/ipvs-1.0.6-2.2.19.tar.gz[/url]。這裏注意，如果你用的Linux內核不是2.2.19版本的，請下載相應版本的LVS內核補丁。將ipvs-1.0.6-2.2.19.tar.gz解壓縮後置於/usr/src/linux目錄下。
然後，對內核打補丁，如下操作：
[root@vs2 /root]# cd /usr/src/linux
[root@vs2 linux]# patch -p1 < ipvs-1.0.6-2.2.19/ipvs-1.0.6-2.2.19.patch
下面就是重新配置和編譯Linux的內核。特別注意以下選項：
1 Code maturity level options--->
* [*]Prompt for development and/or incomplete code/drivers
2 Networking部分：
[*] Kernel/User netlink socket
[*] Routing messages
<*> Netlink device emulation
* [*] Network firewalls
[*] Socket Filtering
<*> Unix domain sockets
* [*] TCP/IP networking
[*] IP: multicasting
[*] IP: advanced router
[ ] IP: policy routing
[ ] IP: equal cost multipath
[ ] IP: use TOS value as routing key
[ ] IP: verbose route monitoring
[ ] IP: large routing tables
[ ] IP: kernel level autoconfiguration
* [*] IP: firewalling
[ ] IP: firewall packet netlink device
* [*] IP: transparent proxy support
* [*] IP: masquerading
--- Protocol-specific masquerading support will be built as modules.
* [*] IP: ICMP masquerading
--- Protocol-specific masquerading support will be built as modules.
* [*] IP: masquerading special modules support
* <M> IP: ipautofw masq support (EXPERIMENTAL)(NEW)
* <M> IP: ipportfw masq support (EXPERIMENTAL)(NEW)
* <M> IP: ip fwmark masq-forwarding support (EXPERIMENTAL)(NEW)
* [*] IP: masquerading virtual server support (EXPERIMENTAL)(NEW)
[*] IP Virtual Server debugging (NEW) <--最好選擇此項，以便觀察LVS的調試信息
* (12) IP masquerading VS table size (the Nth power of 2) (NEW)
* <M> IPVS: round-robin scheduling (NEW)
* <M> IPVS: weighted round-robin scheduling (NEW)
* <M> IPVS: least-connection scheduling (NEW)
* <M> IPVS: weighted least-connection scheduling (NEW)
* <M> IPVS: locality-based least-connection scheduling (NEW)
* <M> IPVS: locality-based least-connection with replication scheduling (NEW)
* [*] IP: optimize as router not host
* <M> IP: tunneling
<M> IP: GRE tunnels over IP
[*] IP: broadcast GRE over IP
[*] IP: multicast routing
[*] IP: PIM-SM version 1 support
[*] IP: PIM-SM version 2 support
* [*] IP: aliasing support
[ ] IP: ARP daemon support (EXPERIMENTAL)
* [*] IP: TCP syncookie support (not enabled per default)
--- (it is safe to leave these untouched)
< > IP: Reverse ARP
[*] IP: Allow large windows (not recommended if <16Mb of memory)
< > The IPv6 protocol (EXPERIMENTAL)
上面，帶*號的爲必選項。
然後就是常規的編譯內核過程，不再贅述，請參考編譯 Linux 教程
在這裏要注意一點：如果你使用的是RedHat自帶的內核或者從RedHat下載的內核版本，已經預先打好了LVS的補丁。這可以通過查看/usr/src/linux/net/目錄下有沒有幾個ipvs開頭的文件來判斷：如果有，則說明已經打過補丁。
編寫LVS配置文件，實例中的配置文件如下： #lvs_dr.conf (C) Joseph Mack [email protected]
LVS_TYPE=VS_DR
INITIAL_STATE=on
VIP=eth0:101 192.168.0.101 255.255.255.0 192.168.0.0
DIRECTOR_INSIDEIP=eth0 192.168.0.1 192.168.0.0 255.255.255.0 192.168.0.255
SERVICE=t telnet rr rs1:telnet rs2:telnet
SERVICE=t www rr rs1:www rs2:www
SERVER_VIP_DEVICE=dummy0
SERVER_NET_DEVICE=eth0
#----------end lvs_dr.conf------------------------------------
將該文件置於/etc/lvs目錄下。
使用LVS的配置腳本產生lvs.conf文件。該配置腳本可以從[url]http://www.linuxvirtualserver.org/Joseph.Mack/configure-lvs_0.8.tar.gz[/url] 單獨下載，在ipvs-1.0.6-2.2.19.tar.gz包中也有包含。
腳本configure的使用方法：
[root@vs2 lvs]# configure lvs.conf
這樣會產生幾個配置文件，這裏我們只使用其中的rc.lvs_dr文件。
修改/etc/rc.d/init.d/rc.local，增加如下幾行：
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/ip_always_defrag
# 顯示最多調試信息
echo 10 > /proc/sys/net/ipv4/vs/debug_level
配置NFS服務。這一步僅僅是爲了方便管理，不是必須的步驟。
假設配置文件lvs.conf文件放在/etc/lvs目錄下，則/etc/exports文件的內容爲：
/etc/lvs ro(rs1,rs2)
然後使用exportfs命令輸出這個目錄:
[root@vs2 lvs]# exportfs
如果遇到什麼麻煩，可以嘗試：
[root@vs2 lvs]# /etc/rc.d/init.d/nfs restart
[root@vs2 lvs]# exportfs
這樣，各個real server可以通過NFS獲得rc.lvs_dr文件，方便了集羣的配置:你每次修改lvs.conf中的配置選項，都可以即可反映在rs1,rs2的相應目錄裏。
修改/etc/syslogd.conf，增加如下一行： kern.* /var/log/kernel_log
這樣，LVS的一些調試信息就會寫入/var/log/kernel_log文件中.
real server的配置
real server的配置相對簡單，主要是是以下幾點：
配置telnet和WWW服務。telnet服務沒有需要特別注意的事項，但是對於www服務，需要修改httpd.conf文件，使得apache在虛擬服務器的ip地址上監聽，如下所示：
Listen 192.168.0.101:80
關閉real server上dummy0的arp請求響應能力。這是必須的，具體原因請參見ARP problem in LVS/TUN and LVS/DR（[url]http://www.linuxvirtualserver.org/arp.html[/url]）。關閉dummy0的arp響應的方式有多種，比較簡單地方法是，修改/etc/rc.d/rc.local文件，增加如下幾行
： echo 1 > /proc/sys/net/ipv4/conf/all/hidden
ifconfig dummy0 up
ifconfig dummy0 192.168.0.101 netmask 255.255.255.0 broadcast 192.168.0.0 up
echo 1 > /proc/sys/net/ipv4/conf/dummy0/hidden
再次修改/etc/rc.d/rc.local，增加如下一行：（可以和步驟2合併）
echo 1 > /proc/sys/net/ipv4/ip_forward
四 LVS的測試
好了，經過了上面的配置步驟，現在可以測試LVS了，步驟如下：
分別在vs1，rs1，rs2上運行/etc/lvs/rc.lvs_dr。注意，rs1,rs2上面的/etc/lvs目錄是vs2輸出的。如果您的NFS配置沒有成功，也可以把vs1上的/etc/lvs/rc.lvs_dr複製到rs1,rs2上，然後分別運行。
確保rs1,rs2上面的apache已經啓動並且允許telnet。
然後從client運行telnet 192.168.0.101，如果登錄後看到如下輸出就說明集羣已經開始工作了:（假設以guest用戶身份登錄）
[guest@rs1 guest]$-----------說明已經登錄到服務器rs1上。
再開啓一個telnet窗口，登錄後會發現系統提示變爲：
[guest@rs2 guest]$-----------說明已經登錄到服務器rs2上。
然後在vs2上運行如下命令：
[root@vs2 /root]ipvsadm
運行結果應該爲：
IP Virtual Server version 1.0.6 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.101:telnet rr
-> rs2:telnet Route 1 1 0
-> rs1:telnet Route 1 1 0
TCP 192.168.0.101:www rr
-> rs2:www Route 1 0 0
-> rs1:www Route 1 0 0
至此已經驗證telnet的LVS正常。
然後測試一下WWW是否正常：用你的瀏覽器查看">[url]http://192.168.0.101/[/url]是否有什麼變化？爲了更明確的區別響應來自那個real server，可以在rs1,rs2上面分別放置如下的測試頁面(test.html)：
<BODY>
我是real server #1 or #2
</BODY>
</HTML>
然後刷新幾次頁面（[url]http://192.168.0.101/test.html[/url]），如果你看到“我是real server #1”和“我是real server #2”交替出現，說明www的LVS系統已經正常工作了。
但是由於Internet Explore 或者Netscape本身的緩存機制，你也許總是隻能看到其中的一個。不過通過ipvsadm還是可以看出，頁面請求已經分配到兩個real server上了，如下所示：
IP Virtual Server version 1.0.6 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.101:telnet rr
-> rs2:telnet Route 1 0 0
-> rs1:telnet Route 1 0 0
TCP 192.168.0.101:www rr
-> rs2:www Route 1 0 5
-> rs1:www Route 1 0 4
或者，可以採用linux的lynx作爲測試客戶端，效果更好一些。如下運行命令：
[root@client /root]while true; do lynx -dump [url]http://10.64.1.56/test.html;[/url] sleep 1; done
這樣，每隔1秒鐘“我是realserver #1”和“我是realserver #2”就交替出現一次，清楚地表明響應分別來自兩個不同的real server。
五調試技巧
如果您的運氣不好，在配置LVS的過程中也許會遇到一些困難，下面的技巧或許有幫助：
首先確定網絡硬件沒有問題，尤其是網線，ping工具就足夠了。
使用netstat查看端口的活動情況。
使用tcpdump查看數據包的流動情況。
查看/var/log/kernel_log文件。