Linux服務器集羣系統

時間 2019-11-13

原文原文鏈接

Linux服務器集羣系統(一) LVS項目介紹

本文介紹了Linux服務器集羣系統――LVS（Linux Virtual Server）項目的產生背景和目標，並描述了LVS服務器集羣框架及目前提供的軟件，列舉LVS集羣系統的特色和一些實際應用，最後，本文談論了LVS項目的開發進展和開發感觸。

背景

當今計算機技術已進入以網絡爲中心的計算時期。因爲客戶/服務器模型的簡單性、易管理性和易維護性，客戶/服務器計算模式在網上被大量採用。在九十年代中期，萬維網（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）
   在集羣系統上，容易開發應用程序。

Linux Virtual Server項目

針對高可伸縮、高可用網絡服務的需求，咱們給出了基於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虛擬服務器軟件IPVS

在調度器的實現技術中，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負載均衡技術，它們的大體原理以下（咱們將在其餘章節對其工做原理進行詳細描述），

1. Virtual Server via Network Address Translation（VS/NAT）
   經過網絡地址轉換，調度器重寫請求報文的目標地址，根據預設的調度算法，將請求分派給後端的真實服務器；真實服務器的響應報文經過調度器時，報文的源地址被重寫，再返回給客戶，完成整個負載調度過程。
2. Virtual Server via IP Tunneling（VS/TUN）
   採用NAT技術時，因爲請求和響應報文都必須通過調度器地址重寫，當客戶請求愈來愈多時，調度器的處理能力將成爲瓶頸。爲了解決這個問題，調度器把請求報文經過IP隧道轉發至真實服務器，而真實服務器將響應直接返回給客戶，因此調度器只處理請求報文。因爲通常網絡服務應答比請求報文大許多，採用 VS/TUN技術後，集羣系統的最大吞吐量能夠提升10倍。
3. Virtual Server via Direct Routing（VS/DR）
   VS/DR經過改寫請求報文的MAC地址，將請求發送到真實服務器，而真實服務器將響應直接返回給客戶。同VS/TUN技術同樣，VS/DR技術可極大地提升集羣系統的伸縮性。這種方法沒有IP隧道的開銷，對集羣中的真實服務器也沒有必須支持IP隧道協議的要求，可是要求調度器與真實服務器都有一塊網卡連在同一物理網段上。

針對不一樣的網絡服務需求和服務器配置，IPVS調度器實現了以下八種負載調度算法：

1. 輪叫（Round Robin）
   調度器經過"輪叫"調度算法將外部請求按順序輪流分配到集羣中的真實服務器上，它均等地對待每一臺服務器，而無論服務器上實際的鏈接數和系統負載。
2. 加權輪叫（Weighted Round Robin）
   調度器經過"加權輪叫"調度算法根據真實服務器的不一樣處理能力來調度訪問請求。這樣能夠保證處理能力強的服務器處理更多的訪問流量。調度器能夠自動問詢真實服務器的負載狀況，並動態地調整其權值。
3. 最少連接（Least Connections）
   調度器經過"最少鏈接"調度算法動態地將網絡請求調度到已創建的連接數最少的服務器上。若是集羣系統的真實服務器具備相近的系統性能，採用"最小鏈接"調度算法能夠較好地均衡負載。
4. 加權最少連接（Weighted Least Connections）
   在集羣系統中的服務器性能差別較大的狀況下，調度器採用"加權最少連接"調度算法優化負載均衡性能，具備較高權值的服務器將承受較大比例的活動鏈接負載。調度器能夠自動問詢真實服務器的負載狀況，並動態地調整其權值。
5. 基於局部性的最少連接（Locality-Based Least Connections）
   "基於局部性的最少連接" 調度算法是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於一半的工做負載，則用"最少連接"的原則選出一個可用的服務器，將請求發送到該服務器。
6. 帶複製的基於局部性最少連接（Locality-Based Least Connections with Replication） "帶複製的基於局部性最少連接"調度算法也是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。它與LBLC算法的不一樣之處是它要維護從一個目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。該算法根據請求的目標IP地址找出該目標IP地址對應的服務器組，按"最小鏈接"原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器，若服務器超載；則按"最小鏈接"原則從這個集羣中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以下降複製的程度。
7. 目標地址散列（Destination Hashing）
   "目標地址散列"調度算法根據請求的目標IP地址，做爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空。
8. 源地址散列（Source Hashing）
   "源地址散列"調度算法根據請求的源IP地址，做爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空。

內核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已經能對HTTP請求進行基於內容的調度，但它還不很成熟，在其調度算法和各類協議的功能支持等方面，有大量的工做需要作。

雖然應用層交換處理複雜，它的伸縮性有限，但應用層交換帶來如下好處：

* 相同頁面的請求被髮送到同一服務器，能夠提升單臺服務器的Cache命中率。
* 一些研究[5]代表WEB訪問流中存在局部性。Layer-7交換能夠充分利用訪問的局部性，將相同類型的請求發送到同一臺服務器，使得每臺服務器收到的請求具備更好的類似性，可進一步提升單臺服務器的Cache命中率。
* 後端服務器可運行不一樣類型的服務，如文檔服務，圖片服務，CGI服務和數據庫服務等。

LVS集羣的特色

LVS集羣的特色能夠歸結以下：

1. 功能
   有實現三種IP負載均衡技術和八種鏈接調度算法的IPVS軟件。在IPVS內部實現上，採用了高效的Hash函數和垃圾回收機制，能正確處理所調度報文相關的ICMP消息（有些商品化的系統反而不能）。虛擬服務的設置數目沒有限制，每一個虛擬服務有本身的服務器集。它支持持久的虛擬服務（如HTTP Cookie和HTTPS等須要該功能的支持），並提供詳盡的統計數據，如鏈接的處理速率和報文的流量等。針對大規模拒絕服務（Deny of Service）攻擊，實現了三種防衛策略。
   有基於內容請求分發的應用層交換軟件KTCPVS，它也是在Linux內核中實現。有相關的集羣管理軟件對資源進行監測，能及時將故障屏蔽，實現系統的高可用性。主、從調度器能週期性地進行狀態同步，從而實現更高的可用性。
2. 適用性
   後端服務器可運行任何支持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服務。
3. 性能
   LVS服務器集羣系統具備良好的伸縮性，可支持幾百萬個併發鏈接。配置100M網卡，採用VS/TUN或VS/DR調度技術，集羣系統的吞吐量可高達1Gbits/s；如配置千兆網卡，則系統的最大吞吐量可接近10Gbits/s。
4. 可靠性
   LVS服務器集羣軟件已經在不少大型的、關鍵性的站點獲得很好的應用，因此它的可靠性在真實應用獲得很好的證明。有不少調度器運行一年多，未做一次重啓動。
5. 軟件許可證
   LVS集羣軟件是按GPL（GNU Public License）許可證發行的自由軟件，這意味着你能夠獲得軟件的源代碼，有權對其進行修改，但必須保證你的修改也是以GPL方式發行。

LVS集羣的應用

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 項目於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項目感興趣，請訪問Linux Vritual Server項目的主頁（ http://www.LinuxVirtualServer.org/或者 http://www.linux-vs.org/），你能夠得到最新的 LVS 源代碼和有關運行軟件，及最新的文檔資料。

分享到：

分享0 收藏0 支持0 反對0

回覆

使用道具舉報 php

騎虎

你們網大學一年級html

積分: 862
帖子: 161
精華: 11
經驗: 584 點
威望: 0 點
金幣: 458

2樓

發表於 2008-10-22 14:42:47 | 只看該做者

Linux服務器集羣系統(二) LVS集羣的體系結構

本文主要介紹了LVS集羣的體系結構。先給出LVS集羣的通用體系結構，並討論了其的設計原則和相應的特色；最後將LVS集羣應用於創建可伸縮的Web、Media、Cache和Mail等網絡服務。

引言

在過去的十幾年中，Internet從幾個研究機構相連爲信息共享的網絡發展成爲擁有大量應用和服務的全球性網絡，它正成爲人們生活中不可缺乏的一部分。雖然Internet發展速度很快，但建設和維護大型網絡服務依然是一項挑戰性的任務，由於系統必須是高性能的、高可靠的，尤爲當訪問負載不斷增加時，系統必須能被擴展來知足不斷增加的性能需求。因爲缺乏創建可伸縮網絡服務的框架和設計方法，這意味着只有擁有很是出色工程和管理人才的機構才能創建和維護大型的網絡服務。

針對這種情形，本文先給出LVS集羣的通用體系結構，並討論了其的設計原則和相應的特色；最後將LVS集羣應用於創建可伸縮的Web、Media、Cache和Mail等網絡服務。

LVS集羣的通用體系結構

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）進程分別在主、從調度器上運行，它們經過串口線和UDP等心跳線來相互定時地彙報各自的健康情況。當從調度器不能聽得主調度器的心跳時，從調度器經過ARP欺騙（Gratuitous ARP）來接管集羣對外的Virtual IP Address，同時接管主調度器的工做來提供負載調度服務。當主調度器恢復時，這裏有兩種方法，一是主調度器自動變成從調度器，二是從調度器釋放 Virtual IP Address，主調度器收回Virtual IP Address並提供負載調度服務。這裏，多條心跳線可使得因心跳線故障致使誤判（即從調度器認爲主調度器已經失效，其實主調度器還在正常工做）的概論降到最低。

一般，當主調度器失效時，主調度器上全部已創建鏈接的狀態信息將丟失，已有的鏈接會中斷。客戶須要向從新鏈接，從調度器纔會將新鏈接調度到各個服務器上，這對客戶會形成必定的不便。爲此，IPVS調度器在Linux 內核中實現一種高效狀態同步機制，將主調度器的狀態信息及時地同步到從調度器。當從調度器接管時，絕大部分已創建的鏈接會持續下去。

可伸縮Web服務

基於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擊敗全部他們嘗試過的商品化負載均衡產品。

可伸縮Cache服務

有效的網絡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、POP三、 IMAP4和HTTP/HTTPS請求流負載較均衡地分發到各郵件服務器上，從上面各服務的處理流程來看，無論請求被髮送到哪一臺郵件服務器處理，其結果是同樣的。這裏，將SMTP、POP三、IMAP4和HTTP/HTTPS運行在各個郵件服務器上進行集中調度，有利於提升整個系統的資源利用率。

系統中可能的瓶頸是LDAP服務器，對LDAP服務中B+樹的參數進行優化，再結合高端的服務器，能夠得到較高的性能。若分佈式文件系統沒有多個存儲結點間的負載均衡機制，則須要相應的郵件遷移機制來避免郵件訪問的傾斜。

這樣，這個集羣系統對用戶來講就像一個高性能、高可靠的郵件服務器（例如上海電信只要用一個郵件域名public.sta.net.cn就能夠）。當郵件用戶不斷增加時，只要在集羣中增長服務器結點和存儲結點。用戶信息的集中存儲使得用戶管理變得容易，且集羣系統有利於提升資源利用率。

小結

本文給出LVS集羣的通用體系結構，並討論了它的設計原則和相應的特色；最後將LVS集羣應用於創建可伸縮的Web、Media、Cache和Mail網絡服務，並指出了系統架設時應注意的要點。咱們將在後續的文章中詳細解釋LVS集羣的技術、實現和應用。

回覆

使用道具舉報前端

騎虎

你們網大學一年級node

積分: 862
帖子: 161
精華: 11
經驗: 584 點
威望: 0 點
金幣: 458

3樓

發表於 2008-10-22 14:51:33 | 只看該做者

Linux服務器集羣系統(三) LVS集羣的體系結構

本文在分析服務器集羣實現虛擬網絡服務的相關技術上，詳細描述了LVS集羣中實現的三種IP負載均衡技術（VS/NAT、VS/TUN和VS/DR）的工做原理，以及它們的優缺點。

前言

在前面文章中，講述了可伸縮網絡服務的幾種結構，它們都須要一個前端的負載調度器（或者多個進行主從備份）。咱們先分析實現虛擬網絡服務的主要技術，指出 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協議。下面簡述當前用服務器集羣實現高可伸縮、高可用網絡服務的幾種負載調度方法，並列舉幾個在這方面有表明性的研究項目。

實現虛擬服務的相關方法

在網絡服務中，一端是客戶程序，另外一端是服務程序，在中間可能有代理程序。由此看來，能夠在不一樣的層次上實現多臺服務器的負載均衡。用集羣解決網絡服務性能問題的現有方法主要分爲如下四類。

基於RR-DNS的解決方法

NCSA的可伸縮的WEB服務器系統就是最先基於RR-DNS（Round-Robin Domain Name System）的原型系統[1,2]。它的結構和工做流程以下圖所示：

圖1：基於RR-DNS的可伸縮WEB服務器

有一組WEB服務器，他們經過分佈式文件系統AFS(Andrew File System)來共享全部的HTML文檔。這組服務器擁有相同的域名（如www.ncsa.uiuc.edu），當用戶按照這個域名訪問時, RR-DNS服務器會把域名輪流解析到這組服務器的不一樣IP地址，從而將訪問負載分到各臺服務器上。

這種方法帶來幾個問題。第一，域名服務器是一個分佈式系統，是按照必定的層次結構組織的。當用戶就域名解析請求提交給本地的域名服務器，它會因不能直接解析而向上一級域名服務器提交，上一級域名服務器再依次向上提交，直到RR-DNS域名服器把這個域名解析到其中一臺服務器的IP地址。可見，從用戶到 RR-DNS間存在多臺域名服器，而它們都會緩衝已解析的名字到IP地址的映射,這會致使該域名服器組下全部用戶都會訪問同一WEB服務器，出現不一樣 WEB服務器間嚴重的負載不平衡。爲了保證在域名服務器中域名到IP地址的映射不被長久緩衝，RR-DNS在域名到IP地址的映射上設置一個 TTL(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鏈接，一次是從用戶到調度器，另外一次是從調度器到真實服務器；須要對請求進行分析和重寫。這些處理都須要不小的CPU、內存和網絡等資源開銷，且處理時間長。所構成系統的性能不能接近線性增長的，通常服務器組增至3或4臺時，調度器自己可能會成爲新的瓶頸。因此，這種基於應用層負載均衡調度的方法的伸縮性極其有限。第二，基於應用層的負載均衡調度器對於不一樣的應用，須要寫不一樣的調度器。以上幾個系統都是基於HTTP協議，若對於FTP、Mail、 POP3等應用，都須要重寫調度器。

基於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須要全部的服務器有相同的配置，如網卡速度和處理能力。

經過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相鏈接的。這些服務器提供相同的網絡服務、相同的內容，即無論請求被髮送到哪一臺服務器，執行結果是同樣的。服務的內容能夠複製到每臺服務器的本地硬盤上，能夠經過網絡文件系統（如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.32三、 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處理的。

經過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隧道設備上。

圖4：VS/TUN的體系結構

VS/TUN 的工做流程如圖5所示：它的鏈接調度和管理與VS/NAT中的同樣，只是它的報文轉發方法不一樣。調度器根據各個服務器的負載狀況，動態地選擇一臺服務器，將請求報文封裝在另外一個IP報文中，再將封裝後的IP報文轉發給選出的服務器；服務器收到報文後，先將報文解封得到原來目標地址爲VIP的報文，服務器發現VIP地址被配置在本地的IP隧道設備上，因此就處理這個請求，而後根據路由表將響應報文直接返回給客戶。

圖5：VS/TUN的工做流程

在這裏須要指出，根據缺省的TCP/IP協議棧處理，請求報文的目標地址爲VIP，響應報文的源地址確定也爲VIP，因此響應報文不須要做任何修改，能夠直接返回給客戶，客戶認爲獲得正常的服務，而不會知道到底是哪一臺服務器處理的。

圖6：半鏈接的TCP有限狀態機

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

跟 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服務。使用更高的硬件配置（如千兆網卡和更快的處理器）做爲調度器，調度器所能調度的服務器數量會相應增長。當應用不一樣時，服務器的數目也會相應地改變。因此，以上數據估計主要是爲三種方法的伸縮性進行量化比較。

Virtual Server via NAT

VS/NAT 的優勢是服務器能夠運行任何支持TCP/IP的操做系統，它只須要一個IP地址配置在調度器上，服務器組能夠用私有的IP地址。缺點是它的伸縮能力有限，當服務器結點數目升到20時，調度器自己有可能成爲系統的新瓶頸，由於在VS/NAT中請求和響應報文都須要經過負載調度器。咱們在Pentium 166 處理器的主機上測得重寫報文的平均延時爲60us，性能更高的處理器上延時會短一些。假設TCP報文的平均長度爲536 Bytes，則調度器的最大吞吐量爲8.93 MBytes/s. 咱們再假設每臺服務器的吞吐量爲800KBytes/s，這樣一個調度器能夠帶動10臺服務器。（注：這是很早之前測得的數據）

基於VS/NAT的的集羣系統能夠適合許多服務器的性能要求。若是負載調度器成爲系統新的瓶頸，能夠有三種方法解決這個問題：混合方法、VS/TUN和 VS /DR。在DNS混合集羣系統中，有若干個VS/NAT負載調度器，每一個負載調度器帶本身的服務器集羣，同時這些負載調度器又經過RR-DNS組成簡單的域名。但VS/TUN和VS/DR是提升系統吞吐量的更好方法。

對於那些將IP地址或者端口號在報文數據中傳送的網絡服務，須要編寫相應的應用模塊來轉換報文數據中的IP地址或者端口號。這會帶來實現的工做量，同時應用模塊檢查報文的開銷會下降系統的吞吐率。

Virtual Server via IP Tunneling

在 VS/TUN的集羣系統中，負載調度器只將請求調度到不一樣的後端服務器，後端服務器將應答的數據直接返回給用戶。這樣，負載調度器就能夠處理大量的請求，它甚至能夠調度百臺以上的服務器（同等規模的服務器），而它不會成爲系統的瓶頸。即便負載調度器只有100Mbps的全雙工網卡，整個系統的最大吞吐量可超過1Gbps。因此，VS/TUN能夠極大地增長負載調度器調度的服務器數量。VS/TUN調度器能夠調度上百臺服務器，而它自己不會成爲系統的瓶頸，能夠用來構建高性能的超級服務器。

VS/TUN技術對服務器有要求，即全部的服務器必須支持「IP Tunneling」或者「IP Encapsulation」協議。目前，VS/TUN的後端服務器主要運行Linux操做系統，咱們沒對其餘操做系統進行測試。由於「IP Tunneling」正成爲各個操做系統的標準協議，因此VS/TUN應該會適用運行其餘操做系統的後端服務器。

Virtual Server via Direct Routing

跟VS/TUN方法同樣，VS/DR調度器只處理客戶到服務器端的鏈接，響應數據能夠直接從獨立的網絡路由返回給客戶。這能夠極大地提升LVS集羣系統的伸縮性。

跟VS/TUN相比，這種方法沒有IP隧道的開銷，可是要求負載調度器與實際服務器都有一塊網卡連在同一物理網段上，服務器網絡設備（或者設備別名）不做ARP響應，或者能將報文重定向（Redirect）到本地的Socket端口上。

小結

本文主要講述了LVS集羣中的三種IP負載均衡技術。在分析網絡地址轉換方法（VS/NAT）的缺點和網絡服務的非對稱性的基礎上，咱們給出了經過IP隧道實現虛擬服務器的方法VS/TUN，和經過直接路由實現虛擬服務器的方法VS/DR，極大地提升了系統的伸縮性。

回覆

使用道具舉報 linux

騎虎

你們網大學一年級算法

積分: 862
帖子: 161
精華: 11
經驗: 584 點
威望: 0 點
金幣: 458

4樓

發表於 2008-10-22 15:03:06 | 只看該做者

Linux服務器集羣系統(四) LVS集羣的負載調度

本文主要講述了LVS集羣的IP負載均衡軟件IPVS在內核中實現的各類鏈接調度算法。針對請求的服務時間變化很大，給出一個動態反饋負載均衡算法，它結合內核中的加權鏈接調度算法，根據動態反饋回來的負載信息來調整服務器的權值，來進一步避免服務器間的負載不平衡。

前言

在上一篇文章中，咱們主要講述了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分別有權值四、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調度中，而在內核中鏈接調度通常採用加權輪叫調度算法或者加權最小鏈接調度算法。

動態反饋負載均衡算法的工做環境

鏈接調度

當客戶經過TCP鏈接訪問網絡訪問時，服務所需的時間和所要消耗的計算資源是千差萬別的，它依賴於不少因素。例如，它依賴於請求的服務類型、當前網絡帶寬的狀況、以及當前服務器資源利用的狀況。一些負載比較重的請求須要進行計算密集的查詢、數據庫訪問、很長響應數據流；而負載比較輕的請求每每只須要讀一個 HTML頁面或者進行很簡單的計算。

請求處理時間的千差萬別可能會致使服務器利用的傾斜（Skew），即服務器間的負載不平衡。例如，有一個WEB頁面有A、B、C和D文件，其中D是大圖像文件，瀏覽器須要創建四個鏈接來取這些文件。當多個用戶經過瀏覽器同時訪問該頁面時，最極端的狀況是全部D文件的請求被髮到同一臺服務器。因此說，有可能存在這樣狀況，有些服務器已經超負荷運行，而其餘服務器基本是閒置着。同時，有些服務器已經忙不過來，有很長的請求隊列，還不斷地收到新的請求。反過來說，這會致使客戶長時間的等待，以爲系統的服務質量差。

簡單鏈接調度

簡單鏈接調度可能會使得服務器傾斜的發生。在上面的例子中，若採用輪叫調度算法，且集羣中正好有四臺服務器，必有一臺服務器老是收到D文件的請求。這種調度策略會致使整個系統資源的低利用率，由於有些資源被用盡致使客戶的長時間等待，而其餘資源空閒着。

實際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）由於請求的服務時間差別較大，內核中的鏈接調度算法容易使得服務器運行出現傾斜。爲此，給出了一個動態反饋負載均衡算法，結合內核中的加權鏈接調度算法，根據動態反饋回來的負載信息來調整服務器的權值，來調整服務器間處理請求數的比例，從而避免服務器間的負載不平衡。動態反饋負載算法能夠較好地避免服務器的傾斜，提升系統的資源使用效率，從而提升系統的吞吐率。