當今計算機技術已進入以網絡爲中心的計算時期。由於客戶/服務器模型的簡單性、易管理性和易維護性，客戶/服務器計算模式在網上被大量採用。在九十年代中 期，萬維網（World Wide Web）的出現以其簡單操作方式將圖文並茂的網上信息帶給普通大衆，Web也正在從一種內容發送機製成爲一種服務平臺，大量的服務和應用（如新聞服務、網 上銀行、電子商務等）都是圍繞着Web進行。這促進Internet用戶劇烈增長和Internet流量爆炸式地增長，圖1顯示了1995至2000年與 Internet連接主機數的變化情況[1]，可見增長趨勢較以往更迅猛。
圖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億頁面[5]。一些網絡服務也收到鉅額的流量， 如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），整個系統實現是經濟的、易支付的。
  |
|
對稱多處理（Symmetric Multi-Processor，簡稱SMP）是由多個對稱的處理器、和通過總線共享的內存和I/O部件所組成的計算機系統。SMP是一種低並行度的結構，是我們通常所說的"緊耦合多處理系統"，它的可擴展能力有限，但SMP的優點是單一系統映像（Single System Image），有共享的內存和I/O，易編程。
由於SMP的可擴展能力有限，SMP服務器顯然不能滿足高可伸縮、高可用網絡服務中的負載處理能力不斷增長需求。隨着負載不斷增長，會導致服務器不斷地升 級。這種服務器升級有下列不足：一是升級過程繁瑣，機器切換會使服務暫時中斷，並造成原有計算資源的浪費；二是越往高端的服務器，所花費的代價越大；三是 SMP服務器是單一故障點（Single Point of Failure），一旦該服務器或應用軟件失效，會導致整個服務的中斷。
通過高性能網絡或局域網互聯的服務器集羣正成爲實現高可伸縮的、高可用網絡服務的有效結構。這種鬆耦合結構的服務器集羣系統有下列優點：
-
性能
網絡服務的工作負載通常是大量相互獨立的任務，通過一組服務器分而治之，可以獲得很高的整體性能。 -
性能/價格比
組成集羣系統的PC服務器或RISC服務器和標準網絡設備因爲大規模生產降低成本，價格低，具有最高的性能/價格比。若整體性能隨着結點數的增長而接近線性增加，該系統的性能/價格比接近於PC服務器。所以，這種鬆耦合結構比緊耦合的多處理器系統具有更好的性能/價格比。 -
可伸縮性
集羣系統中的結點數目可以增長到幾千個，乃至上萬個，其伸縮性遠超過單臺超級計算機。 -
高可用性
在硬件和軟件上都有冗餘，通過檢測軟硬件的故障，將故障屏蔽，由存活結點提供服務，可實現高可用性。
當然，用服務器集羣系統實現可伸縮網絡服務也存在很多挑戰性的工作：
-
透明性（Transparency）
如何高效地使得由多個獨立計算機組成的鬆藕合的集羣系統構成一個虛擬服務器；客戶端應用程序與集羣系統交互時，就像與一臺高性能、高可用的服務器交互一樣，客戶端無須作任何修改。部分服務器的切入和切出不會中斷服務，這對用戶也是透明的。 -
性能（Performance）
性能要接近線性加速，這需要設計很好的軟硬件的體系結構，消除系統可能存在的瓶頸。將負載較均衡地調度到各臺服務器上。 -
高可用性（Availability）
需要設計和實現很好的系統資源和故障的監測和處理系統。當發現一個模塊失敗時，要這模塊上提供的服務遷移到其他模塊上。在理想狀況下，這種遷移是即時的、自動的。 -
可管理性（Manageability）
要使集羣系統變得易管理，就像管理一個單一映像系統一樣。在理想狀況下，軟硬件模塊的插入能做到即插即用（Plug & Play）。 -
可編程性（Programmability）
在集羣系統上，容易開發應用程序。
|
|
針對高可伸縮、高可用網絡服務的需求，我們給出了基於IP層和基於內容請求分發的負載平衡調度解決方法，並在Linux內核中實現了這些方法，將一組服務器構成一個實現可伸縮的、高可用網絡服務的虛擬服務器。
虛擬服務器的體系結構如圖2所示，一組服務器通過高速的局域網或者地理分佈的廣域網相互連接，在它們的前端有一個負載調度器（Load Balancer）。負載調度器能無縫地將網絡請求調度到真實服務器上，從而使得服務器集羣的結構對客戶是透明的，客戶訪問集羣系統提供的網絡服務就像訪 問一臺高性能、高可用的服務器一樣。客戶程序不受服務器集羣的影響不需作任何修改。系統的伸縮性通過在服務機羣中透明地加入和刪除一個節點來達到，通過檢 測節點或服務進程故障和正確地重置系統達到高可用性。由於我們的負載調度技術是在Linux內核中實現的，我們稱之爲Linux虛擬服務器（Linux Virtual Server）。
圖2：虛擬服務器的結構
在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框架實現高可伸縮的、高可用的Web、Cache、Mail和Media等網絡服務；在此基礎上，可以開 發支持龐大用戶數的、高可伸縮的、高可用的電子商務應用。
圖3：Linux虛擬服務器框架
在 調度器的實現技術中，IP負載均衡技術是效率最高的。在已有的IP負載均衡技術中有通過網絡地址轉換（Network Address Translation）將一組服務器構成一個高性能的、高可用的虛擬服務器，我們稱之爲VS/NAT技術（Virtual Server via Network Address Translation），大多數商品化的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）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
在基於IP負載調度技術中，當一個TCP連接的初始SYN報文到達時，調度器就選擇一臺服務器，將報文轉發給它。此後通過查發報文的IP和TCP報文頭地 址，保證此連接的後繼報文被轉發到該服務器。這樣，IPVS無法檢查到請求的內容再選擇服務器，這就要求後端服務器組提供相同的服務，不管請求被髮送到哪 一臺服務器，返回結果都是一樣的。但是，在有些應用中後端服務器功能不一，有的提供HTML文檔，有的提供圖片，有的提供CGI，這就需要基於內容的調度 (Content-Based Scheduling)。
由於用戶空間TCP Gateway的開銷太大，我們提出在操作系統的內核中實現Layer-7交換方法，來避免用戶空間與核心空間的切換和內存複製的開銷。在Linux操作系統的內核中，我們實現了Layer-7交換，稱之爲KTCPVS（Kernel TCP Virtual Server）。目前，KTCPVS已經能對HTTP請求進行基於內容的調度，但它還不很成熟，在其調度算法和各種協議的功能支持等方面，有大量的工作需要做。
雖然應用層交換處理複雜，它的伸縮性有限，但應用層交換帶來以下好處：
- 相同頁面的請求被髮送到同一服務器，可以提高單臺服務器的Cache命中率。
- 一些研究[5]表明WEB訪問流中存在局部性。Layer-7交換可以充分利用訪問的局部性，將相同類型的請求發送到同一臺服務器，使得每臺服務器收到的請求具有更好的相似性，可進一步提高單臺服務器的Cache命中率。
- 後端服務器可運行不同類型的服務，如文檔服務，圖片服務，CGI服務和數據庫服務等。
|
|
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協議：
無需對客戶機和服務器作任何修改，可適用大多數Internet服務。協議 內 容 TCP HTTP，FTP，PROXY，SMTP，POP3，IMAP4，DNS，LDAP，HTTPS，SSMTP等 UDP DNS，NTP，ICP，視頻、音頻流播放協議等 -
性能
LVS服務器集羣系統具有良好的伸縮性，可支持幾百萬個併發連接。配置100M網卡，採用VS/TUN或VS/DR調度技術，集羣系統的吞吐量可高達1Gbits/s；如配置千兆網卡，則系統的最大吞吐量可接近10Gbits/s。 -
可靠性
LVS服務器集羣軟件已經在很多大型的、關鍵性的站點得到很好的應用，所以它的可靠性在真實應用得到很好的證實。有很多調度器運行一年多，未作一次重啓動。 -
軟件許可證
LVS集羣軟件是按GPL（GNU Public License）許可證發行的自由軟件，這意味着你可以得到軟件的源代碼，有權對其進行修改，但必須保證你的修改也是以GPL方式發行。
|
|
LVS項目從成立到現在爲止，受到不少關注，LVS集羣系統已被應用於很多重負載的站點，就我所知該系統已在美、英、德、澳等國的幾十個站點上正式使用。
我們沒有上百臺機器和高速的網絡來實際測試LVS的終極性能，所以舉LVS的應用實例來說明LVS的高性能和穩定性。我們所知的一些大型LVS應用實例如下：
-
英國國家JANET Cache Service（wwwcache.ja.net）是爲英國150所以上的大學提供Web Cache服務。他們用28個結點的LVS集羣代替了原有現50多臺相互獨立的Cache服務器，用他們的話說現在速度就跟夏天一樣，因爲夏天是放假期間沒有很多人使用網絡。
-
Linux的門戶站點（www.linux.com）用LVS將很多臺VA Linux SMP服務器組成高性能的WEB服務，已使用將近一年。
-
SourceForge（sourceforge.net）是在全球範圍內爲開發源碼項目提供WEB、FTP、Mailing List和CVS等服務，他們也使用LVS將負載調度到十幾臺機器上。
-
世界上最大的PC製造商之一採用了兩個LVS集羣系統，一個在美洲，一個在歐洲，用於網上直銷系統。
-
以RealPlayer提供音頻視頻服務而聞名的Real公司（www.real.com）使用由20臺服務器組成的LVS集羣，爲其全球用戶提供音頻視頻服務。在2000年3月時，整個集羣系統已收到平均每秒20,000個連接的請求流。
-
NetWalk（www.netwalk.com）用多臺服務器構造LVS系統，提供1024個虛擬服務，其中本項目的一個美國鏡像站點（www.us.linuxvirtualserver.org）。
-
RedHat（www.redhat.com）從其6.1發行版起已包含LVS代碼，他們開發了一個LVS集羣管理工具叫Piranha，用於控制LVS集羣，並提供了一個圖形化的配置界面。
-
VA Linux（www.valinux.com）向客戶提供基於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
http://marc.theaimsgroup.com/?1=linux-virtual-server&m=95385809030794&w=2
"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
http://marc.theaimsgroup.com/?1=linux-virtual-server&m=95385694529750&w=2
|
|
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項目感興趣，請訪問Linux Vritual Server項目的主頁（ http://www.LinuxVirtualServer.org/或者http://www.linux-vs.org/），你可以獲得最新的
LVS 源代碼和有關運行軟件，及最新的文檔資料。
如果你在使用LVS 的過程中遇到困難，請訂閱我們的郵件列表 [email protected]，提問、解答或者發表你的高見。
[1] Information Navigators, Internet Growth Charts, http://navigators.com/stats.html
[3] Lucent Technologies. Web ProForum tutorial: DWDM. October 1999,http://www.webproforum.com/acrobat/dwdm.pdf
[4] Lucent Technologies. Lucent Technologies announces record-breaking 320-channel optical networking system. April 2000, http://www.lucent.com/press-/0400/000417.nsb.html
[5] Yahoo! Inc., The Yahoo! Directory and Web Services, http://www.yahoo.com/
[6] Dell Inc. http://www.dell.com/
在過去的十幾年中，Internet從幾個研究機構相連爲信息共享的網絡發展成爲擁有大量應用和服務的全球性網絡，它正成爲人們生活中不可缺少的一部分。 雖然Internet發展速度很快，但建設和維護大型網絡服務依然是一項挑戰性的任務，因爲系統必須是高性能的、高可靠的，尤其當訪問負載不斷增長時，系 統必須能被擴展來滿足不斷增長的性能需求。由於缺少建立可伸縮網絡服務的框架和設計方法，這意味着只有擁有非常出色工程和管理人才的機構才能建立和維護大 型的網絡服務。
針對這種情形，本文先給出LVS集羣的通用體系結構，並討論了其的設計原則和相應的特點；最後將LVS集羣應用於建立可伸縮的Web、Media、Cache和Mail等網絡服務。
|
|
LVS集羣採用IP負載均衡技術和基於內容請求分發技術。調度器具有很好的吞吐率，將請求均衡地轉移到不同的服務器上執行，且調度器自動屏蔽掉服務器的故 障，從而將一組服務器構成一個高性能的、高可用的虛擬服務器。整個服務器集羣的結構對客戶是透明的，而且無需修改客戶端和服務器端的程序。
圖1：LVS集羣的體系結構
爲此，在設計時需要考慮系統的透明性、可伸縮性、高可用性和易管理性。一般來說，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）協議和身份認證後，才能進行系統監測，並進行系統的配置和管理。
層 次的體系結構可以使得層與層之間相互獨立，每一個層次提供不同的功能，在一個層次可以重用不同的已有軟件。例如，調度器層提供了負載平衡、可伸縮性和高可 用性等，在服務器層可以運行不同的網絡服務，如Web、Cache、Mail和Media等，來提供不同的可伸縮網絡服務。明確的功能劃分和清晰的層次結 構使得系統容易建設，以後整個系統容易維護，而且系統的性能容易被擴展。
共 享存儲如分佈式文件系統在這個LVS集羣系統是可選項。當網絡服務需要有相同的內容，共享存儲是很好的選擇，否則每臺服務器需要將相同的內容複製到本地硬 盤上。當系統存儲的內容越多，這種無共享結構（Shared-nothing Structure）的代價越大，因爲每臺服務器需要一樣大的存儲空間，任何的更新需要涉及到每臺服務器，系統的維護代價會非常高。
共 享存儲爲服務器組提供統一的存儲空間，這使得系統的內容維護工作比較輕鬆，如Webmaster只需要更新共享存儲中的頁面，對所有的服務器都有效。分佈 式文件系統提供良好的伸縮性和可用性，當分佈式文件系統的存儲空間增加時，所有服務器的存儲空間也隨之增大。對於大多數Internet服務來說，它們都 是讀密集型（Read-intensive）的應用，分佈式文件系統在每臺服務器使用本地硬盤作Cache（如2Gbytes的空間），可以使得訪問分佈 式文件系統本地的速度接近於訪問本地硬盤。
此外，存儲硬件技術的發展也促使從無共享的集羣向共享存儲的集羣遷移。存儲區域 網（Storage Area Networks）技術解決了集羣的每個結點可以直接連接/共享一個龐大的硬盤陣列，硬件廠商也提供多種硬盤共享技術，如光纖通道（Fiber Channel）、共享SCSI（Shared SCSI）。InfiniBand是一個通用的高性能I/O規範，使得存儲區域網中以更低的延時傳輸I/O消息和集羣通訊消息，並且提供很好的伸縮性。 InfiniBand得到絕大多數的大廠商的支持，如Compaq、Dell、Hewlett-Packard、IBM、Intel、Microsoft 和SUN Microsystems等，它正在成爲一個業界的標準。這些技術的發展使得共享存儲變得容易，規模生產也會使得成本逐步降低。
集羣系統的特點是它在軟硬件上都有冗餘。系統的高可用性可以通過檢測節點或服務進程故障和正確地重置系統來實現，使得系統收到的請求能被存活的結點處理。
通 常，我們在調度器上有資源監測進程來時刻監視各個服務器結點的健康狀況。當服務器對ICMP ping不可達時或者探測她的網絡服務在指定的時間沒有響應時，資源監測進程通知操作系統內核將該服務器從調度列表中刪除或者失效。這樣，新的服務請求就 不會被調度到壞的結點。資源監測進程能通過電子郵件或傳呼機向管理員報告故障。一旦監測進程到服務器恢復工作，通知調度器將其加入調度列表進行調度。另 外，通過系統提供的管理程序，管理員可發命令隨時可以將新機器加入服務來提高系統的處理性能，也可以將已有的服務器切出服務，以便對服務器進行系統維護。
現 在前端的調度器有可能成爲系統的單一失效點（Single Point of Failure）。一般來說，調度器的可靠性較高，因爲調度器上運行的程序較少而且大部分程序早已經遍歷過，但我們不能排除硬件老化、網絡線路或者人爲誤 操作等主要故障。爲了避免調度器失效而導致整個系統不能工作，我們需要設立一個從調度器作爲主調度器的備份。兩個心跳（Heartbeat）進程[6]分 別在主、從調度器上運行，它們通過串口線和UDP等心跳線來相互定時地彙報各自的健康狀況。當從調度器不能聽得主調度器的心跳時，從調度器通過ARP欺騙 （Gratuitous ARP）來接管集羣對外的Virtual IP Address，同時接管主調度器的工作來提供負載調度服務。當主調度器恢復時，這裏有兩種方法，一是主調度器自動變成從調度器，二是從調度器釋放 Virtual IP Address，主調度器收回Virtual IP Address並提供負載調度服務。這裏，多條心跳線可以使得因心跳線故障導致誤判（即從調度器認爲主調度器已經失效，其實主調度器還在正常工作）的概論 降到最低。
通常，當主調度器失效時，主調度器上所有已建立連接的狀態信息將丟失，已有的連接會中斷。客戶需要向重新連接， 從調度器纔會將新連接調度到各個服務器上，這對客戶會造成一定的不便。爲此，IPVS調度器在Linux 內核中實現一種高效狀態同步機制，將主調度器的狀態信息及時地同步到從調度器。當從調度器接管時，絕大部分已建立的連接會持續下去。
|
|
基 於LVS的Web集羣的體系結構如圖2所示：第一層是負載調度器，一般採用IP負載均衡技術，可以使得整個系統有較高的吞吐率；第二層是Web服務器池， 在每個結點上可以分別運行HTTP服務或HTTPS服務、或者兩者都運行；第三層是共享存儲，它可以是數據庫，可以是網絡文件系統或分佈式文件系統，或者 是三者的混合。集羣中各結點是通過高速網絡相連接的。
圖2：基於LVS的Web集羣
對 於動態頁面（如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地 址的不同連接會被髮送到集羣中同一個服務器結點，可以很好地解決客戶連接的相關性問題。
|
|
基 於LVS的媒體集羣的體系結構如圖3所示：第一層是負載調度器，一般採用IP負載均衡技術，可以使得整個系統有較高的吞吐率；第二層是Web服務器池，在 每個結點上可以運行相應的媒體服務；第三層是共享存儲，通過網絡文件系統/分佈式文件系統存儲媒體節目。集羣中各結點是通過高速網絡相連接。
圖3：基於LVS的媒體集羣
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]。
|
|
有 效的網絡Cache系統可以大大地減少網絡流量、降低響應延時以及服務器的負載。但是，若Cache服務器超載而不能及時地處理請求，反而會增加響應延 時。所以，Cache服務的可伸縮性很重要，當系統負載不斷增長時，整個系統能被擴展來提高Cache服務的處理能力。尤其，在主幹網上的Cache服務 可能需要幾個Gbps的吞吐率，單臺服務器（例如SUN目前最高端的Enterprise 10000服務器）遠不能達到這個吞吐率。可見，通過PC服務器集羣實現可伸縮Cache服務是很有效的方法，也是性能價格比最高的方法。
基 於LVS的Cache集羣的體系結構如圖4所示：第一層是負載調度器，一般採用IP負載均衡技術，可以使得整個系統有較高的吞吐率；第二層是Cache服 務器池，一般Cache服務器放置在接近主幹Internet連接處，它們可以分佈在不同的網絡中。調度器可以有多個，放在離客戶接近的地方。
圖4：基於LVS的Cache集羣
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），提高整個系統的資源利用率。
|
|
隨 着Internet用戶不斷增長，很多ISP面臨他們郵件服務器超載的問題。當郵件服務器不能容納更多的用戶帳號時，有些ISP買更高檔的服務器來代替原 有的，將原有服務器的信息（如用戶郵件）遷移到新服務器是很繁瑣的工作，會造成服務的中斷；有些ISP設置新的服務器和新的郵件域名，新的郵件用戶放置在 新的服務器上，如上海電信現在用不同的郵件服務器public1.sta.net.cn、public2.sta.net.cn到 public9.sta.net.cn放置用戶的郵件帳號，這樣靜態地將用戶分割到不同的服務器上，會造成郵件服務器負載不平衡，系統的資源利用率低，對 用戶來說郵件的地址比較難記。
圖5：基於LVS的可伸縮郵件集羣
可 以利用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 Protocol 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就可以）。當郵件用 戶不斷增長時，只要在集羣中增加服務器結點和存儲結點。用戶信息的集中存儲使得用戶管理變得容易，且集羣系統有利於提高資源利用率。
|
|
本 文給出LVS集羣的通用體系結構，並討論了它的設計原則和相應的特點；最後將LVS集羣應用於建立可伸縮的Web、Media、Cache和Mail網絡 服務，並指出了系統架設時應注意的要點。我們將在後續的文章中詳細解釋LVS集羣的技術、實現和應用。 
- J.H. Howard. An Overview of the Andrew File System. In Proceedings of the USENIX Winter Technical Conference, Dallas, TX, USA, February 1998.
- Kenneth W. Preslan, Andrew P. Barry, Jonathan E. Brassow, Grant M. Erickson, Erling Nygaard, Christopher J. Sabol, Steven R. Soltis, David C. Teigland, and Matthew T. O'Keefe. A 64-bit, Shared Disk File System for Linux. In Proceeding of 16th IEEE Mass Storage Systems Symposium, San Diego, CA, USA. March 15-18, 1999.
- Global File System Website. http://www.globalfilesystem.org.
- Coda File System Website. http://www.coda.cs.cmu.edu.
- InterMezzo File System Website. http://www.inter-mezzo.org.
- Alan Robertson, et al. Linux High Availability Project. http://www.linux-ha.org.
- Jerry Glomph Black. LVS testimonials from Real Networks. March 2000.http://marc.theaimsgroup.com/?l=linux-virtual-server&m=95385809030794&w=2
LVS集羣中的IP負載均衡技術
在前面文章中，講 述了可伸縮網絡服務的幾種結構，它們都需要一個前端的負載調度器（或者多個進行主從備份）。我們先分析實現虛擬網絡服務的主要技術，指出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協議。下面簡述當前用服務器集羣實現高可伸縮、高可用網絡服務的幾種負載調度方法，並列舉幾個在這方面有代表性的研究項目。
|
|
在網絡服務中，一端是客戶程序，另一端是服務程序，在中間可能有代理程序。由此看來，可以在不同的層次上實現多臺服務器的負載均衡。用集羣解決網絡服務性能問題的現有方法主要分爲以下四類。
NCSA的可伸縮的WEB服務器系統就是最早基於RR-DNS（Round-Robin Domain Name System）的原型系統[1,2]。它的結構和工作流程如下圖所示：
圖1：基於RR-DNS的可伸縮WEB服務器
(注：本圖來自文獻【9】)
有 一組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(Time To Live)值，過了這一段時間，域名服務器將這個映射從緩衝中淘汰。當用戶請求，它會再向上一級域名服器提交請求並進行重新影射。這就涉及到如何設置這個 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[3]是Berkeley做的另一種基於客戶端的解決方法。服務提供一個Java Applet在客戶方瀏覽器中運行，Applet向各個服務器發請求來收集服務器的負載等信息，再根據這些信息將客戶的請求發到相應的服務器。高可用性也 在Applet中實現，當服務器沒有響應時，Applet向另一個服務器轉發請求。這種方法的透明性不好，Applet向各服務器查詢來收集信息會增加額 外的網絡流量，不具有普遍的適用性。
多 臺服務器通過高速的互聯網絡連接成一個集羣系統，在前端有一個基於應用層的負載調度器。當用戶訪問請求到達調度器時，請求會提交給作負載均衡調度的應用程 序，分析請求，根據各個服務器的負載情況，選出一臺服務器，重寫請求並向選出的服務器訪問，取得結果後，再返回給用戶。
應 用層負載均衡調度的典型代表有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等應用，都需要重寫調度器。
用 戶通過虛擬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需要所有的服務器有相同的配置，如網卡速度和處理能力。
|
|
由 於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相連 接的。這些服務器提供相同的網絡服務、相同的內容，即不管請求被髮送到哪一臺服務器，執行結果是一樣的。服務的內容可以複製到每臺服務器的本地硬盤上，可 以通過網絡文件系統（如NFS）共享，也可以通過一個分佈式文件系統來提供。
圖2：VS/NAT的體系結構
客 戶通過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上提供的服務，而服務器集羣的結構對用戶是透明的。對改寫後的報文，應用增量調整Checksum的算法調整TCP Checksum的值，避免了掃描整個報文來計算Checksum的開銷。
在 一些網絡服務中，它們將IP地址或者端口號在報文的數據中傳送，若我們只對報文頭的IP地址和端口號作轉換，這樣就會出現不一致性，服務會中斷。所以，針 對這些服務，需要編寫相應的應用模塊來轉換報文數據中的IP地址或者端口號。我們所知道有這個問題的網絡服務有FTP、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，如圖3所示：
圖3：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.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處理的。
|
|
在 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隧道設備上。
圖4：VS/TUN的體系結構
VS/TUN 的工作流程如圖5所示：它的連接調度和管理與VS/NAT中的一樣，只是它的報文轉發方法不同。調度器根據各個服務器的負載情況，動態地選擇一臺服務器， 將請求報文封裝在另一個IP報文中，再將封裝後的IP報文轉發給選出的服務器；服務器收到報文後，先將報文解封獲得原來目標地址爲VIP的報文，服務器發 現VIP地址被配置在本地的IP隧道設備上，所以就處理這個請求，然後根據路由表將響應報文直接返回給客戶。
圖5：VS/TUN的工作流程
在這裏需要指出，根據缺省的TCP/IP協議棧處理，請求報文的目標地址爲VIP，響應報文的源地址肯定也爲VIP，所以響應報文不需要作任何修改，可以直接返回給客戶，客戶認爲得到正常的服務，而不會知道究竟是哪一臺服務器處理的。
圖6：半連接的TCP有限狀態機
|
|
跟 VS/TUN方法相同，VS/DR利用大多數Internet服務的非對稱特點，負載調度器中只負責調度請求，而服務器直接將響應返回給客戶，可以極大地 提高整個集羣系統的吞吐量。該方法與IBM的NetDispatcher產品中使用的方法類似（其中服務器上的IP地址配置方法是相似的），但IBM的 NetDispatcher是非常昂貴的商品化產品，我們也不知道它內部所使用的機制，其中有些是IBM的專利。
VS/DR 的體系結構如圖7所示：調度器和服務器組都必須在物理上有一個網卡通過不分斷的局域網相連，如通過高速的交換機或者HUB相連。VIP地址爲調度器和服務 器組共享，調度器配置的VIP地址是對外可見的，用於接收虛擬服務的請求報文；所有的服務器把VIP地址配置在各自的Non-ARP網絡設備上，它對外面 是不可見的，只是用於處理目標地址爲VIP的網絡請求。
圖7：VS/DR的體系結構
VS/DR 的工作流程如圖8所示：它的連接調度和管理與VS/NAT和VS/TUN中的一樣，它的報文轉發方法又有不同，將報文直接路由給目標服務器。在VS/DR 中，調度器根據各個服務器的負載情況，動態地選擇一臺服務器，不修改也不封裝IP報文，而是將數據幀的MAC地址改爲選出服務器的MAC地址，再將修改後 的數據幀在與服務器組的局域網上發送。因爲數據幀的MAC地址是選出的服務器，所以服務器肯定可以收到這個數據幀，從中可以獲得該IP報文。當服務器發現 報文的目標地址VIP是在本地的網絡設備上，服務器處理這個報文，然後根據路由表將響應報文直接返回給客戶。
圖8：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服務。使用更 高的硬件配置（如千兆網卡和更快的處理器）作爲調度器，調度器所能調度的服務器數量會相應增加。當應用不同時，服務器的數目也會相應地改變。所以，以上數 據估計主要是爲三種方法的伸縮性進行量化比較。
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地址或者端口號。這會帶來實現的工作量，同時應用模塊檢查報文的開銷會降低系統的吞吐率。
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端口上。
|
|
本文主要講述了LVS集羣中的三種IP負載均衡技術。在分析網絡地址轉換方法（VS/NAT）的缺點和網絡服務的非對稱性的基礎上，我們給出了通過IP隧道實現虛擬服務器的方法VS/TUN，和通過直接路由實現虛擬服務器的方法VS/DR，極大地提高了系統的伸縮性。
- Eric Dean Katz, Michelle Butler, and Robert McGrath, "A Scalable HTTP Server: The NCSA Prototype", Computer Networks and ISDN Systems, pp155-163, 1994.
- Thomas T. Kwan, Robert E. McGrath, and Daniel A. Reed, "NCSA's World Wide Web Server: Design and Performance", IEEE Computer, pp68-74, November 1995.
- C. Yoshikawa, B. Chun, P. Eastham, A. Vahdat, T. Anderson, and D. Culler. Using Smart Clients to Build Scalable Services. In Proceedings of the 1997 USENIX Technical Conference, January 1997.
- Zeus Technology, Inc. Zeus Load Balancer v1.1 User Guide. http://www.zeus.com/
- Ralf S.Engelschall. Load Balancing Your Web Site: Practical Approaches for Distributing HTTP Traffic. Web Techniques Magazine, Volume 3, Issue 5, http://www.webtechniques.com, May 1998.
- Eric Anderson, Dave Patterson, and Eric Brewer, "The Magicrouter: an Application of Fast Packet Interposing", http://www.cs.berkeley.edu/~eanders-/magicrouter/, May, 1996.
- D. Dias, W. Kish, R. Mukherjee, and R. Tewari. A Scalable and Highly Available Server. In Proceeding of COMPCON 1996, IEEE-CS Press, Santa Clara, CA, USA, Febuary 1996, pp. 85-92.
- Guerney D.H. Hunt, German S. Goldszmidt, Richard P. King, and Rajat Mukherjee. Network Dispatcher: a connection router for scalable Internet services. In Proceedings of the 7th International WWW Conference, Brisbane, Australia, April 1998.
- Microsoft Corporation. Microsoft Windows NT Load Balancing Service.http://www.micorsoft.com/ntserver/NTServerEnterprise/exec/feature/WLBS/.
LVS集羣的負載調度
在上一篇文章中，我們主要講述了LVS集羣中實現的三種IP負載均衡技術，它們主要解決系統的可伸縮性和透明性問題，如何通過負載調度器將請求高效地分發 到不同的服務器執行，使得由多臺獨立計算機組成的集羣系統成爲一臺虛擬服務器；客戶端應用程序與集羣系統交互時，就像與一臺高性能的服務器交互一樣。
本 文將主要講述在負載調度器上的負載調度策略和算法，如何將請求流調度到各臺服務器，使得各臺服務器儘可能地保持負載均衡。文章主要由兩個部分組成。第一部 分描述IP負載均衡軟件IPVS在內核中所實現的各種連接調度算法；第二部分給出一個動態反饋負載均衡算法（Dynamic-feedback load balancing），它結合內核中的加權連接調度算法，根據動態反饋回來的負載信息來調整服務器的權值，來進一步避免服務器間的負載不平衡。
在 下面描述中，我們稱客戶的socket和服務器的socket之間的數據通訊爲連接，無論它們是使用TCP還是UDP協議。對於UDP數據報文的調 度，IPVS調度器也會爲之建立調度記錄並設置超時值（如5分鐘）；在設定的時間內，來自同一地址（IP地址和端口）的UDP數據包會被調度到同一臺服務 器。
|
|
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）
下面，我們先介紹這八種連接調度算法的工作原理和算法流程，會在以後的文章中描述怎麼用它們。
輪叫調度（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的輪叫調度優越很多。
加 權輪叫調度（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，所有的新連接都會被丟掉。加權輪叫調度也無需記錄當前所有連接的狀態，所以它也是一種無狀態調度。
最 小連接調度（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的TIME_WAIT一般爲2分鐘，此時連接還佔用服務器的資源，所以會出現這樣情 形，性能高的服務器已處理所收到的連接，連接處於TIME_WAIT狀態，而性能低的服務器已經忙於處理所收到的連接，還不斷地收到新的連接請求。
加 權最小連接調度（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;
|
基 於局部性的最少鏈接調度（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小時。
帶 複製的基於局部性最少鏈接調度（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地址對應的服務器組；按“最小連接”原則從該服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服 務器；若服務器超載；則按“最小連接”原則從整個集羣中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時 間沒有被修改，將最忙的服務器從服務器組中刪除，以降低複製的程度。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小時。
目標地址散列調度（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
|
源 地址散列調度（Source Hashing Scheduling）算法正好與目標地址散列調度算法相反，它根據請求的源IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。它採用的散列函數與目標地址散列調度算法 的相同。它的算法流程與目標地址散列調度算法的基本相似，除了將請求的目標IP地址換成請求的源IP地址，所以這裏不一一敘述。
在實際應用中，源地址散列調度和目標地址散列調度可以結合使用在防火牆集羣中，它們可以保證整個系統的唯一出入口。
|
|
動 態反饋負載均衡算法考慮服務器的實時負載和響應情況，不斷調整服務器間處理請求的比例，來避免有些服務器超載時依然收到大量請求，從而提高整個系統的吞吐 率。圖1顯示了該算法的工作環境，在負載調度器上運行Monitor Daemon進程，Monitor Daemon來監視和收集各個服務器的負載信息。Monitor Daemon可根據多個負載信息算出一個綜合負載值。Monitor Daemon將各個服務器的綜合負載值和當前權值算出一組新的權值，若新權值和當前權值的差值大於設定的閥值，Monitor Daemon將該服務器的權值設置到內核中的IPVS調度中，而在內核中連接調度一般採用加權輪叫調度算法或者加權最小連接調度算法。
圖1：動態反饋負載均衡算法的工作環境
當 客戶通過TCP連接訪問網絡訪問時，服務所需的時間和所要消耗的計算資源是千差萬別的，它依賴於很多因素。例如，它依賴於請求的服務類型、當前網絡帶寬的 情況、以及當前服務器資源利用的情況。一些負載比較重的請求需要進行計算密集的查詢、數據庫訪問、很長響應數據流；而負載比較輕的請求往往只需要讀一個 HTML頁面或者進行很簡單的計算。
請求處理時間的千差萬別可能會導致服務器利用的傾斜（Skew），即服務器間的負載不 平衡。例如，有一個WEB頁面有A、B、C和D文件，其中D是大圖像文件，瀏覽器需要建立四個連接來取這些文件。當多個用戶通過瀏覽器同時訪問該頁面時， 最極端的情況是所有D文件的請求被髮到同一臺服務器。所以說，有可能存在這樣情況，有些服務器已經超負荷運行，而其他服務器基本是閒置着。同時，有些服務 器已經忙不過來，有很長的請求隊列，還不斷地收到新的請求。反過來說，這會導致客戶長時間的等待，覺得系統的服務質量差。
3.1.1. 簡單連接調度
簡單連接調度可能會使得服務器傾斜的發生。在上面的例子中，若採用輪叫調度算法，且集羣中正好有四臺服務器，必有一臺服務器總是收到D文件的請求。這種調度策略會導致整個系統資源的低利用率，因爲有些資源被用盡導致客戶的長時間等待，而其他資源空閒着。
3.1.2. 實際TCP/IP流量的特徵
文 獻[1]說明網絡流量是呈波浪型發生的，在一段較長時間的小流量後，會有一段大流量的訪問，然後是小流量，這樣跟波浪一樣週期性地發生。文獻 [2,3,4,5]揭示在WAN和LAN上網絡流量存在自相似的特徵，在WEB訪問流也存在自相似性。這就需要一個動態反饋機制，利用服務器組的狀態來應 對訪問流的自相似性。
TCP/IP流量的特徵通俗地說是有許多短事務和一些長事務組成，而長事務的工作量在整個工作量佔有較高的比例。所以，我們要設計一種負載均衡算法，來避免長事務的請求總被分配到一些機器上，而是儘可能將帶有毛刺（Burst）的分佈分割成相對較均勻的分佈。
我 們提出基於動態反饋負載均衡機制，來控制新連接的分配，從而控制各個服務器的負載。例如，在IPVS調度器的內核中使用加權輪叫調度（Weighted Round-Robin Scheduling）算法來調度新的請求連接；在負載調度器的用戶空間中運行Monitor Daemon。Monitor Daemon定時地監視和收集各個服務器的負載信息，根據多個負載信息算出一個綜合負載值。Monitor Daemon將各個服務器的綜合負載值和當前權值算出一組新的權值。當綜合負載值表示服務器比較忙時，新算出的權值會比其當前權值要小，這樣新分配到該服 務器的請求數就會少一些。當綜合負載值表示服務器處於低利用率時，新算出的權值會比其當前權值要大，來增加新分配到該服務器的請求數。若新權值和當前權值 的差值大於設定的閥值，Monitor Daemon將該服務器的權值設置到內核中的IPVS調度中。過了一定的時間間隔（如2秒鐘），Monitor Daemon再查詢各個服務器的情況，並相應調整服務器的權值；這樣週期性地進行。可以說，這是一個負反饋機制，使得服務器保持較好的利用率。
在 加權輪叫調度算法中，當服務器的權值爲零，已建立的連接會繼續得到該服務器的服務，而新的連接不會分配到該服務器。系統管理員可以將一臺服務器的權值設置 爲零，使得該服務器安靜下來，當已有的連接都結束後，他可以將該服務器切出，對其進行維護。維護工作對系統都是不可少的，比如硬件升級和軟件更新等，零權 值使得服務器安靜的功能很主要。所以，在動態反饋負載均衡機制中我們要保證該功能，當服務器的權值爲零時，我們不對服務器的權值進行調整。
在 計算綜合負載時，我們主要使用兩大類負載信息：輸入指標和服務器指標。輸入指標是在調度器上收集到的，而服務器指標是在服務器上的各種負載信息。我們用綜 合負載來反映服務器當前的比較確切負載情況，對於不同的應用，會有不同的負載情況，這裏我們引入各個負載信息的係數，來表示各個負載信息在綜合負載中輕 重。系統管理員根據不同應用的需求，調整各個負載信息的係數。另外，系統管理員設置收集負載信息的時間間隔。
輸入指標主要 是在單位時間內服務器收到新連接數與平均連接數的比例，它是在調度器上收集到的，所以這個指標是對服務器負載情況的一個估計值。在調度器上有各個服務器收 到連接數的計數器，對於服務器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 Daemon只要發送一個“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秒之間。
當 服務器投入集羣系統中使用時，系統管理員對服務器都設定一個初始權值DEFAULT_WEIGHTi，在內核的IPVS調度中也先使用這個權值。然後，隨 着服務器負載的變化，對權值進行調整。爲了避免權值變成一個很大的值，我們對權值的範圍作一個限制[DEFAULT_WEIGHTi, SCALE*DEFAULT_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，則說明當前系統的負載都比較輕。
我們在RedHat集羣管理工具Piranha[6]中實現了一個簡單的動態反饋負載均衡算法。在綜合負載上，它只考慮服務器的CPU負載（Load Average），使用以下公式進行權值調整：
服 務器權值調整區間爲[DEFAULT_WEIGHTi, 10*DEFAULT_WEIGHTi]，A爲DEFAULT_WEIGHTi /2，而權值調整的閥值爲DEFAULT_WEIGHTi /4。1是所想要達到的系統利用率。Piranha每隔20秒查詢各臺服務器的CPU負載，進行權值計算和調整。
|
|
本文主要講述了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）
因 爲請求的服務時間差異較大，內核中的連接調度算法容易使得服務器運行出現傾斜。爲此，給出了一個動態反饋負載均衡算法，結合內核中的加權連接調度算法，根 據動態反饋回來的負載信息來調整服務器的權值，來調整服務器間處理請求數的比例，從而避免服務器間的負載不平衡。動態反饋負載算法可以較好地避免服務器的 傾斜，提高系統的資源使用效率，從而提高系統的吞吐率。
- William Stalling, Viewpoint: Self-similarity upsets data traffic assumptions, IEEE Spectrum, January 1997.
- Kihong Park, Gitae Kim, Mark Crovella, "On the Effect of Traffic Self-similarity on Network Performance", In Proceedings of the 1997 SPIE International Conference on Performance and Control of Network Systems, 1997.
- Nicolas D. Georganas, Self-Similar ("Fractal") Traffic in ATM Networks, In Proceedings of the 2nd International Workshop on Advanced Teleservices and High-Speed Communications Architectures (IWACA'94), pages 1-7, Heidelberg, Germany, September 1994.
- Mark Crovella and Azer Besavros, Explaining World Wide Web Traffic Self-Similarity. Technical report, Boston University, October 1995, TR-95-015.
- Bruce A. Mah. An Empirical Model of HTTP Network Traffic. In Proceedings of INFOCOM 97, Kobe, Japan, April 1997.
- Red Hat High Availability Server Project, http://ha.redhat.com/
- The Linux Virtual Server Project, http://www.LinuxVirtualServer.org/
|
章文嵩博士，開放源碼及Linux內核的開發者，著名的Linux集羣項目－－LVS(Linux Virtual Server)的創始人和主要開發人員。他目前工作於國家並行與分佈式處理重點實驗室，主要從事集羣技術、操作系統、對象存儲與數據庫的研究。他一直在自由軟件的開發上花費大量時間，並以此爲樂。 |