一、LVS介紹

在本部分，我們將介紹Linux伺服器叢集系統——LVS（Linux Virtual Server）專案的產生背景和目標，並描述LVS伺服器叢集框架及目前提供的軟體，列舉LVS叢集系統的特點和一些實際應用。

1、背景

當今計算機技術已進入以網路為中心的計算時期。由於客戶/伺服器模型的簡單性、易管理性和易維護性，客戶/伺服器計算模式在網上被大量採用。同時，Internet的飛速發展給網路頻寬和伺服器帶來巨大的挑戰。

因此，對於大型網站的構建，其對於用硬體和軟體方法實現高可伸縮性、高可用網路服務的需求不斷增長，這種需求可以歸結為以下幾點：

• 可伸縮性（Scalability）：當服務的負載增長時，系統能被擴充套件來滿足需求，且不降低服務質量。

• 高可用性（Availability）：儘管部分硬體和軟體會發生故障，整個系統的服務必須是7*24小時可用的。

• 可管理性（Manageability）：整個系統可能在物理上很大，但應該容易管理。

• 價格有效性（Cost-Effectiveness）：整個系統實現是經濟的、易支付的。

2、伺服器叢集系統

由於SMP的可擴充套件能力有限，SMP伺服器顯然不能滿足高可伸縮、高可用網路服務中的負載處理能力不斷增長需求。隨著負載不斷增長，會導致伺服器不斷地升級。這種伺服器升級有下列不足：一是升級過程繁瑣，機器切換會使服務暫時中斷，並造成原有計算資源的浪費；二是越往高階的伺服器，所花費的代價越大；三是 SMP伺服器是單一故障點（Single Point of Failure），一旦該伺服器或應用軟體失效，會導致整個服務的中斷。

通過高效能網路或區域網互聯的伺服器叢集正成為實現高可伸縮的、高可用網路服務的有效結構。這種鬆耦合結構的伺服器叢集系統有下列優點：

• 效能
  網路服務的工作負載通常是大量相互獨立的任務，通過一組伺服器分而治之，可以獲得很高的整體效能。

• 價效比
  組成叢集系統的PC伺服器或RISC伺服器和標準網路裝置因為大規模生產降低成本，價格低，具有最高的效能/價格比。若整體效能隨著結點數的增長而接近線性增加，該系統的效能/價格比接近於PC伺服器。所以，這種鬆耦合結構比緊耦合的多處理器系統具有更好的效能/價格比。

• 可伸縮性
  叢集系統中的結點數目可以增長到幾千個，乃至上萬個，其伸縮性遠超過單臺超級計算機。

• 高可用性
  在硬體和軟體上都有冗餘，通過檢測軟硬體的故障，將故障遮蔽，由存活結點提供服務，可實現高可用性。

當然，用伺服器叢集系統實現可伸縮網路服務也存在很多挑戰性的工作：

• 透明性（Transparency）
  如何高效地使得由多個獨立計算機組成的鬆藕合的叢集系統構成一個虛擬伺服器；客戶端應用程式與叢集系統互動時，就像與一臺高效能、高可用的伺服器互動一樣，客戶端無須作任何修改。部分伺服器的切入和切出不會中斷服務，這對使用者也是透明的。

• 效能（Performance）
  效能要接近線性加速，這需要設計很好的軟硬體的體系結構，消除系統可能存在的瓶頸。將負載較均衡地排程到各臺伺服器上。

• 高可用性（Availability）
  需要設計和實現很好的系統資源和故障的監測和處理系統。當發現一個模組失敗時，要這模組上提供的服務遷移到其他模組上。在理想狀況下，這種遷移是即時的、自動的。

• 可管理性（Manageability）
  要使叢集系統變得易管理，就像管理一個單一映像系統一樣。在理想狀況下，軟硬體模組的插入能做到即插即用（Plug & Play）。

• 可程式設計性（Programmability）
  在叢集系統上，容易開發應用程式。

3、LVS專案

針對高可伸縮、高可用網路服務的需求，我們給出了基於IP層和基於內容請求分發的負載平衡排程解決方法，並在Linux核心中實現了這些方法，將一組伺服器構成一個實現可伸縮的、高可用網路服務的虛擬伺服器。

虛擬伺服器的體系結構如下圖所示：

一組伺服器通過高速的區域網或者地理分佈的廣域網相互連線，在它們的前端有一個負載排程器（Load Balancer）。負載排程器能無縫地將網路請求排程到真實伺服器上，從而使得伺服器叢集的結構對客戶是透明的，客戶訪問叢集系統提供的網路服務就像訪問一臺高效能、高可用的伺服器一樣。客戶程式不受伺服器叢集的影響不需做任何修改。系統的伸縮性通過在服務機群中透明地加入和刪除一個節點來達到，通過檢測節點或服務程式故障和正確地重置系統達到高可用性。由於我們的負載排程技術是在Linux核心中實現的，我們稱之為Linux虛擬伺服器（Linux Virtual Server）。

Linux Virtual Server專案的目標 ：使用叢集技術和Linux作業系統實現一個高效能、高可用的伺服器，它具有很好的可伸縮性（Scalability）、可靠性（Reliability）和可管理性（Manageability）。

目前，LVS專案已提供了一個實現可伸縮網路服務的Linux Virtual Server框架，如下圖所示。

在LVS框架中，提供了含有三種IP負載均衡技術的IP虛擬伺服器軟體IPVS、基於內容請求分發的核心Layer-7交換機KTCPVS和叢集管理軟體。可以利用LVS框架實現高可伸縮的、高可用的Web、Cache、Mail和Media等網路服務；在此基礎上，可以開發支援龐大使用者數的、高可伸縮的、高可用的電子商務應用。

3.1 IP虛擬伺服器軟體IPVS

在排程器的實現技術中，IP負載均衡技術是效率最高的。

3.1.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），它們可以極大地提高系統的伸縮性。

所以，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隧道協議的要求，但是要求排程器與真實伺服器都有一塊網路卡連在同一物理網段上。

3.1.2 負載排程演算法

針對不同的網路服務需求和伺服器配置，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 核心七層交換機KTCPVS

在基於IP負載排程技術中，當一個TCP連線的初始SYN報文到達時，排程器就選擇一臺伺服器，將報文轉發給它。此後通過查發報文的IP和TCP報文頭地址，保證此連線的後繼報文被轉發到該伺服器。這樣，IPVS無法檢查到請求的內容再選擇伺服器，這就要求後端伺服器組提供相同的服務，不管請求被髮送到哪 一臺伺服器，返回結果都是一樣的。

但是，在有些應用中，後端伺服器功能不一，有的提供HTML文件，有的提供圖片，有的提供CGI，這就需要基於內容的排程（Content-Based Schduling）。

由於使用者空間TCP Gateway的開銷太大，我們提出在作業系統的核心中實現七層交換方法，來避免使用者空間與核心空間的切換和記憶體複製的開銷。在Linux作業系統的核心中，我們實現了七層交換，稱之為KTCPVS（Kernel TCP Virtual Server）。目前，KTCPVS已經能對HTTP請求進行基於內容的排程。

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

• 相同頁面的請求被髮送到同一伺服器，可以提高單臺伺服器的Cache命中率。
• 七層交換可以充分利用訪問的區域性性，將相同型別的請求傳送到同一臺伺服器，使得每臺伺服器收到的請求具有更好的相似性，可進一步提高單臺伺服器的Cache命中率。
• 後端伺服器可執行不同型別的服務，如文件服務，圖片服務，CGI服務和資料庫服務等。

3.3 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協議，無需對客戶機和伺服器作任何修改，可適用大多數Internet服務。

• 效能

LVS伺服器叢集系統具有良好的伸縮性，可支援幾百萬個併發連線。配置100M網路卡，採用VS/TUN或VS/DR排程技術，叢集系統的吞吐量可高達1Gbits/s；如配置千兆網路卡，則系統的最大吞吐量可接近10Gbits/s。

• 可靠性

LVS伺服器叢集軟體已經在很多大型的、關鍵性的站點得到很好的應用，所以它的可靠性在真實應用得到很好的證實。有很多排程器執行一年多，未作一次重啟動。

• 軟體許可證

LVS叢集軟體是按GPL（GNU Public License）許可證發行的自由軟體，這意味著你可以得到軟體的原始碼，有權對其進行修改，但必須保證你的修改也是以GPL方式發行。

二、LVS叢集的體系結構

1、LVS叢集的通用體系結構

LVS叢集採用IP負載均衡技術和基於內容請求分發技術。排程器具有良好的吞吐率，將請求均衡地轉移到不同的伺服器上執行，且排程器自動遮蔽掉伺服器故障，從而將一組伺服器構成一個高效能的、高可用的虛擬伺服器。整個伺服器叢集的結構對客戶是透明的，而且無需修改客戶端和伺服器端的程式。

為此，在設計時需要考慮系統的透明性、可伸縮性、高可用性和易管理性。

一般來說，LVS叢集採用三層結構，如上圖所示。三層結構的主要組成部分為：

• 負載排程器（Load Balancer）：它是整個叢集對外面的前端機，負責將客戶的請求傳送到一組伺服器上執行，而客戶認為服務是來自一個IP地址（我們可稱之為虛擬IP地址）上的。

• 伺服器池（Server Pool）：它是一組真正執行客戶請求的伺服器，執行的服務有WEB/Mail/FTP/DNS等等。

• 共享儲存（Shared Storage）：它為伺服器池提供了一個共享的儲存區，這樣很容易使得伺服器池擁有相同的內容，提供相同的服務。

排程器是伺服器叢集系統的唯一入口點（Single Entry Point），它可以採用IP負載均衡技術、基於內容請求分發技術或者兩者相結合。在IP負載均衡技術中，需要伺服器池擁有相同的內容提供相同的服務。當客戶請求到達時，排程器只根據伺服器負載情況和設定的排程演算法從伺服器池中選出一個伺服器，將該請求轉發到選出的伺服器，並記錄這個排程；當這個請求的其他報文到達，也會被轉發到前面選出的伺服器。在基於內容請求分發技術中，伺服器可以提供不同的服務，當客戶請求到達時，排程器可根據請求的內容選擇伺服器執行請求。因為所有的操作都是在Linux作業系統核心空間中將完成的，它的排程開銷很小，所以它具有很高的吞吐率。

伺服器池的節點數目是可變的。當整個系統收到的負載超過目前所有節點的處理能力時，可以在伺服器池中增加伺服器來滿足不斷增長的請求負載。對大多數網路服務來說，請求間不存在很強的相關性，請求可以在不同的節點上並行執行，所以整個系統的效能基本上可以隨著伺服器池的節點數目增加而線性增長。

共享儲存通常是資料庫、網路檔案系統或者分散式檔案系統。伺服器節點需要動態更新的資料一般儲存在資料庫系統中，同時資料庫會保證併發訪問時資料的一致性。靜態的資料可以儲存在網路檔案系統（如NFS/CIFS）中，但網路檔案系統的伸縮能力有限。對於規模較大的叢集系統，可以考慮用分散式檔案系統。分散式檔案系統可為各伺服器提供共享的儲存區，它們訪問分散式檔案系統就像訪問本地檔案系統一樣，同時分散式檔案系統可提供良好的伸縮性和可用性。此外，當不同伺服器上的應用程式同時讀寫訪問分散式檔案系統上同一資源時，應用程式的訪問衝突需要消解才能使得資源處於一致狀態。這需要一個分散式鎖管理器（Distributed Lock Manager），它可能是分散式檔案系統內部提供的，也可能是外部的。開發者在寫應用程式時，可以使用分散式鎖管理器來保證應用程式在不同節點上併發訪問的一致性。

負載排程器、伺服器池和共享儲存系統通過高速網路相連線，如Gigabit網路等。使用高速的網路，主要為避免當系統規模擴大時網際網路絡成為整個系統的瓶頸。

1.1 為什麼使用層次的體系結構

層次的體系結構可以使得層與層之間相互獨立，每一個層次提供不同的功能，在一個層次可以重用不同的已有軟體。例如，排程器層提供了負載平衡、可伸縮性和高可用性等，在伺服器層可以執行不同的網路服務，如Web、Cache、Mail和Media等，來提供不同的可伸縮網路服務。明確的功能劃分和清晰的層次結構使得系統容易建設，以後整個系統容易維護，而且系統的效能容易被擴充套件。

1.2 為什麼使用共享儲存

共享儲存如分散式檔案系統在這個LVS叢集系統是可選項。當網路服務需要有相同的內容，共享儲存是很好的選擇，否則每臺伺服器需要將相同的內容複製到本地硬碟上。當系統儲存的內容越多，這種無共享結構（Shared-nothing Structure）的代價越大，因為每臺伺服器需要一樣大的儲存空間，任何的更新需要涉及到每臺伺服器，系統的維護代價會非常高。

共享儲存為伺服器組提供統一的儲存空間，這使得系統的內容維護工作比較輕鬆，如Webmaster只需要更新共享儲存中的頁面，對所有的伺服器都有效。分散式檔案系統提供良好的伸縮性和可用性，當分散式檔案系統的儲存空間增加時，所有伺服器的儲存空間也隨之增大。對於大多數 Internet服務來說，它們都是讀密集型（Read-intensive）的應用，分散式檔案系統在每臺伺服器使用本地硬碟作Cache（如 2Gbytes的空間），可以使得訪問分散式檔案系統本地的速度接近於訪問本地硬碟。

1.3 高可用性

叢集系統的特點是它在軟硬體上都有冗餘。系統的高可用性可以通過檢測節點或服務程式故障和正確地重置系統來實現，使得系統收到的請求能被存活的伺服器節點處理。

通常，我們在排程器上有資源監測程式來時刻監視各個伺服器節點的健康狀況。當伺服器對ICMP ping不可達時或者探測到它的網路服務在指定的時間沒有響應時，資源監測程式就會通知作業系統核心將該伺服器從排程列表中刪除或者失效。這樣，新的服務請求就不會被排程到壞的節點。資源監測程式能通過電子郵件或傳呼機向管理員報告故障。一旦監測程式監測到伺服器恢復工作，其通知排程器將該伺服器節點重新加入排程列表進行排程。另外，通過系統提供的管理程式，管理員可發命令隨時可以將新機器加入服務來提高系統的處理效能，也可以將已有的伺服器移出服務，以便對伺服器進行系統維護。

現在前端的排程器有可能成為系統的單一失效點（Single Point of Failure）。一般來說，排程器的可靠性較高，因為排程器上執行的程式較少而且大部分程式早已經遍歷過，但我們不能排除硬體老化、網路線路或者人為誤操作等主要故障。為了避免排程器失效而導致整個系統不能工作，我們需要設立一個從排程器作為主排程器的備份。兩個心跳（Heartbeat）程式分別在主、從排程器上執行，它們通過串列埠線和UDP等心跳線來相互定時地彙報各自的健康狀況。當從排程器不能聽得主排程器的心跳時，從排程器通過ARP欺騙 （Gratuitous ARP）來接管叢集對外的Virtual IP Address，同時接管主排程器的工作來提供負載排程服務。當主排程器恢復時，這裡有兩種方法，一是主排程器自動變成從排程器，二是從排程器釋放Virtual IP Address，主排程器收回Virtual IP Address並提供負載排程服務。這裡，多條心跳線可以使得因心跳線故障導致誤判（即從排程器認為主排程器已經失效，其實主排程器還在正常工作）的概率降到最低。

通常，當主排程器失效時，主排程器上所有已建立連線的狀態資訊將丟失，已有的連線會中斷。客戶需要向重新連線，從排程器才會將新連線排程到各個伺服器上，這對客戶會造成一定的不便。為此，IPVS排程器在Linux核心中實現一種高效狀態同步機制，將主排程器的狀態資訊及時地同步到從排程器。當從排程器接管時，絕大部分已建立的連線會持續下去。

2、可伸縮Web服務

基於LVS的Web叢集的體系結構如下圖所示。

第一層是負載排程器，一般採用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地 址的不同連線會被髮送到叢集中同一個伺服器結點，可以很好地解決客戶連線的相關性問題。

3、可伸縮Cache服務

有效的網路Cache系統可以大大地減少網路流量、降低響應延時以及伺服器的負載。但是，若Cache伺服器超載而不能及時地處理請求，反而會增加響應延時。所以，Cache服務的可伸縮性很重要，當系統負載不斷增長時，整個系統能被擴充套件來提高Cache服務的處理能力。尤其，在主幹網上的 Cache服務可能需要幾個Gbps的吞吐率，單臺伺服器（例如SUN目前最高階的Enterprise 10000伺服器）遠不能達到這個吞吐率。可見，通過PC伺服器叢集實現可伸縮Cache服務是很有效的方法，也是效能價格比最高的方法。

基於LVS的Cache叢集的體系結構如下所示。

第一層是負載排程器，一般採用IP負載均衡技術，可以使得整個系統有較高的吞吐率；

第二層是Cache伺服器池，一般Cache伺服器放置在接近主幹Internet連線處，它們可以分佈在不同的網路中。

排程器可以有多個，放在離客戶接近的地方。

IPVS負載排程器一般使用IP隧道方法（即VS/TUN方法），來架構Cache叢集系統，因為Cache伺服器可能被放置不同的地方（例如在接近主幹Internet連線處），而排程器與Cache伺服器池可能不在同一個物理網路中。採用VS/TUN方法，排程器只排程Web Cache請求，而Cache伺服器將響應資料直接返回給客戶。在請求物件不能在本地命中的情況下，Cache伺服器要向源伺服器發請求，將結果取回，最後將結果返回給客戶。

三、IP負載均衡技術

1、實現虛擬服務的相關方法

在網路服務中，一端是客戶程式，另一端是服務程式，在中間可能有代理程式。由此看來，可以在不同層次上實現多臺伺服器的負載均衡。用叢集解決網路服務效能問題的現有方法主要有以下四類：

1.1 基於RR-DNS的解決方法

伺服器組擁有相同的域名（如www.jjj.com），當使用者按照該域名訪問時，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”按鈕，也無濟於事。

1.2 基於客戶端的解決方法

基於客戶端的解決方法需要每個客戶程式都有一定的伺服器叢集的知識，進而把以負載均衡的方式將請求發到不同的伺服器。例如，Netscape Navigator瀏覽器訪問Netscape的主頁時，它會隨機地從一百多臺伺服器中挑選第N臺，最後將請求送往wwwN.netscape.com。

1.3 基於應用層負載均衡排程的解決方法

多臺伺服器通過高速的網際網路絡連線成一個叢集系統，在前端有一個基於應用層的負載排程器。當使用者訪問請求到達排程器時，請求會提交給用作負載均衡排程的應用程式，分析請求，根據各個伺服器的負載情況，選出一臺伺服器，重寫請求並向選出的伺服器訪問，取得結果後，再返回給使用者。

基於應用層負載均衡排程的多伺服器解決方法也存在一些問題。

第一，系統處理開銷特別大，致使系統的伸縮性有限。同時，需要兩次TCP連線，一次是從使用者到排程器，另一次是從排程器到真實伺服器，同時需要對請求進行分析和重寫。

第二，基於應用層的負載均衡排程器對於不同的應用，需要寫不同的排程器。

1.4 基於IP層負載均衡排程的解決方法

使用者通過虛擬IP地址（Virtual IP Address）訪問服務時，訪問請求的報文會到達負載排程器，由它進行負載均衡排程，從一組真實伺服器選出一個，將報文的目標地址Virtual IP Address改寫成選定伺服器的地址，報文的目標埠改寫成選定伺服器的相應埠，最後將報文傳送給選定的伺服器。真實伺服器的回應報文經過負載排程器時，將報文的源地址和源埠改為Virtual IP Address和相應的埠，再把報文發給使用者。

2、通過NAT實現虛擬伺服器（VS/NAT）

客戶通過Virtual IP Address（虛擬服務的IP地址）訪問網路服務時，請求報文到達排程器，排程器根據連線排程演算法從一組真實伺服器中選出一臺伺服器，將報文的目標地址 Virtual IP Address改寫成選定伺服器的地址，報文的目標埠改寫成選定伺服器的相應埠，最後將修改後的報文傳送給選出的伺服器。

同時，排程器在連線Hash 表中記錄這個連線，當這個連線的下一個報文到達時，從連線Hash表中可以得到原選定伺服器的地址和埠，進行同樣的改寫操作，並將報文傳給原選定的伺服器。當來自真實伺服器的響應報文經過排程器時，排程器將報文的源地址和源埠改為Virtual IP Address和相應的埠，再把報文發給使用者。

3、通過IP隧道實現虛擬伺服器（VS/TUN）

在VS/NAT 的叢集系統中，請求和響應的資料包文都需要通過負載排程器，當真實伺服器的數目在10臺和20臺之間時，負載排程器將成為整個叢集系統的新瓶頸。大多數 Internet服務都有這樣的特點：請求報文較短而響應報文往往包含大量的資料。如果能將請求和響應分開處理，即在負載排程器中只負責排程請求而響應直接返回給客戶，將極大地提高整個叢集系統的吞吐量。

我們利用IP隧道技術將請求報文封裝轉發給後端伺服器，響應報文能從後端伺服器直接返回給客戶。但在這裡，後端伺服器有一組而非一個，所以我們不可能靜態地建立一一對應的隧道，而是動態地選擇一臺伺服器，將請求報文封裝和轉發給選出的伺服器。這樣，我們可以利用IP隧道的原理將一組伺服器上的網路服務組成在一個IP地址上的虛擬網路服務。

VS/TUN的體系結構如下圖所示，各個伺服器將VIP地址配置在自己的IP隧道裝置上。

VS/TUN的工作流程如下：

排程器根據各個伺服器的負載情況，動態地選擇一臺伺服器， 將請求報文封裝在另一個IP報文中，再將封裝後的IP報文轉發給選出的伺服器；伺服器收到報文後，先將報文解封獲得原來目標地址為VIP的報文，伺服器發現VIP地址被配置在本地的IP隧道裝置上，所以就處理這個請求，然後根據路由表將響應報文直接返回給客戶。

4、通過直接路由實現虛擬伺服器（VS/DR）

跟VS/TUN方法相同，VS/DR利用大多數Internet服務的非對稱特點，負載排程器中只負責排程請求，而伺服器直接將響應返回給客戶，可以極大地提高整個叢集系統的吞吐量。

VS/DR的體系結構如下圖所示：

排程器和伺服器組都必須在物理上有一個網路卡通過不分斷的區域網相連，如通過高速的交換機或者HUB相連。VIP地址為排程器和伺服器組共享，排程器配置的VIP地址是對外可見的，用於接收虛擬服務的請求報文；所有的伺服器把VIP地址配置在各自的Non-ARP網路裝置上，它對外面是不可見的，只是用於處理目標地址為VIP的網路請求。

VS/DR的工作流程如下：

在VS/DR 中，排程器根據各個伺服器的負載情況，動態地選擇一臺伺服器，不修改也不封裝IP報文，而是將資料幀的MAC地址改為選出伺服器的MAC地址，再將修改後的資料幀在與伺服器組的區域網上傳送。因為資料幀的MAC地址是選出的伺服器，所以伺服器肯定可以收到這個資料幀，從中可以獲得該IP報文。當伺服器發現報文的目標地址VIP是在本地的網路裝置上，伺服器處理這個報文，然後根據路由表將響應報文直接返回給客戶。

5、三種方法的優缺點比較

三種IP負載均衡技術的優缺點歸納在下表中：

6、小結

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

四、LVS叢集的負載排程

在本部分，我們將主要講述在負載排程器上的負載排程策略和演算法，如何將請求流排程到各臺伺服器，使得各臺伺服器儘可能地保持負載均衡。

主要由兩個部分組成。第一部分描述IP負載均衡軟體IPVS在核心中所實現的各種連線排程演算法；第二部分給出一個動態反饋負載均衡演算法（Dynamic-feedback load balancing），它結合核心中的加權連線排程演算法，根據動態反饋回來的負載資訊來調整伺服器的權值，來進一步避免伺服器間的負載不平衡。

1、核心中的連線排程演算法

在核心中的連線排程演算法上，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）

下面，我們先介紹這八種連線排程演算法的工作原理和演算法流程，會在以後的文章中描述怎麼用它們。

1.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的輪詢排程優越很多。

1.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初始化為-1，cw初始化為零。

while (true) {
  i = (i + 1) mod n;
if (i == 0) {
     cw = cw - gcd(S);
     if (cw <= 0) {
       cw = max(S);
       if (cw == 0)
         return NULL;
     }
  }
  if (W(Si) >= cw)
    return Si;
}

例如，有三個伺服器A、B和C分別有權值4、3和2，則在一個排程週期內(mod sum(W(Si)))排程式列為AABABCABC。加權輪詢排程演算法還是比較簡單和高效。當請求的服務時間變化很大，單獨的加權輪詢排程演算法依然會導致伺服器間的負載不平衡。

從上面的演算法流程中，我們可以看出當伺服器的權值為零時，該伺服器不被被排程；當所有伺服器的權值為零，即對於任意i有W(Si)=0，則沒有任何伺服器可用，演算法返回NULL，所有的新連線都會被丟掉。加權輪詢排程也無需記錄當前所有連線的狀態，所以它也是一種無狀態排程。

1.3 最少連線排程

最少連線排程（Least-Connection Scheduling）演算法是把新的連線請求分配到當前連線數最小的伺服器。

最少連線排程是一種動態排程演算法，它通過伺服器當前所活躍的連線數來估計伺服器的負載情況。排程器需要記錄各個伺服器已建立連線的數目，當一個請求被排程到某臺伺服器，其連線數加1；當連線中止或超時，其連線數減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狀態，而效能低的伺服器已經忙於處理所收到的連線，還不斷地收到新的連線請求。

1.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;

1.5 基於區域性性的最少連線排程

基於區域性性的最少連線排程（Locality-Based Least Connections Scheduling，以下簡稱為LBLC）演算法是針對請求報文的目標IP地址的負載均衡排程，目前主要用於Cache叢集系統，因為在Cache叢集中客戶請求報文的目標IP地址是變化的。這裡假設任何後端伺服器都可以處理任一請求，演算法的設計目標是在伺服器的負載基本平衡情況下，將相同目標IP地址的請求排程到同一臺伺服器，來提高各臺伺服器的訪問區域性性和主存Cache命中率，從而整個叢集系統的處理能力。

LBLC排程演算法先根據請求的目標IP地址找出該目標IP地址最近使用的伺服器，若該伺服器是可用的且沒有超載，將請求傳送到該伺服器；若伺服器不存在，或者該伺服器超載且有伺服器處於其一半的工作負載，則用“最少連線”的原則選出一個可用的伺服器，將請求傳送到該伺服器。

該演算法的詳細流程如下：

假設有一組伺服器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小時。

1.6 帶複製的基於區域性性最少連線排程

帶複製的基於區域性性最少連線排程（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排程演算法的流程如下：

假設有一組伺服器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小時。

1.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函式如下：

static inline unsigned hashkey(unsigned int dest_ip)
{
    return (dest_ip* 2654435761UL) & HASH_TAB_MASK;
}

其中，2654435761UL是2到2^32 (4294967296)間接近於黃金分割的素數，

1.8 源地址雜湊排程

源地址雜湊排程（Source Hashing Scheduling）演算法正好與目標地址雜湊排程演算法相反，它根據請求的源IP地址，作為雜湊鍵（Hash Key）從靜態分配的雜湊表找出對應的伺服器，若該伺服器是可用的且未超載，將請求傳送到該伺服器，否則返回空。它採用的雜湊函式與目標地址雜湊排程演算法 的相同。它的演算法流程與目標地址雜湊排程演算法的基本相似，除了將請求的目標IP地址換成請求的源IP地址，所以這裡不一一敘述。

在實際應用中，源地址雜湊排程和目標地址雜湊排程可以結合使用在防火牆叢集中，它們可以保證整個系統的唯一出入口。

2、動態反饋負載均衡演算法

我們提出基於動態反饋負載均衡機制，來控制新連線的分配，從而控制各個伺服器的負載。例如，在IPVS排程器的核心中使用加權輪詢排程 （Weighted Round-Robin Scheduling）演算法來排程新的請求連線；在負載排程器的使用者空間中執行Monitor Daemon。Monitor Daemon定時地監視和收集各個伺服器的負載資訊，根據多個負載資訊算出一個綜合負載值。Monitor Daemon將各個伺服器的綜合負載值和當前權值算出一組新的權值。當綜合負載值表示伺服器比較忙時，新算出的權值會比其當前權值要小，這樣新分配到該伺服器的請求數就會少一些。當綜合負載值表示伺服器處於低利用率時，新算出的權值會比其當前權值要大，來增加新分配到該伺服器的請求數。若新權值和當前權值的差值大於設定的閾值，Monitor Daemon將該伺服器的權值設定到核心中的IPVS排程中。過了一定的時間間隔（如2秒鐘），Monitor Daemon再查詢各個伺服器的情況，並相應調整伺服器的權值；這樣週期性地進行。可以說，這是一個負反饋機制，使得伺服器保持較好的利用率。

在加權輪詢排程演算法中，當伺服器的權值為零，已建立的連線會繼續得到該伺服器的服務，而新的連線不會分配到該伺服器。系統管理員可以將一臺伺服器的權值設定為零，使得該伺服器安靜下來，當已有的連線都結束後，他可以將該伺服器切出，對其進行維護。維護工作對系統都是不可少的，比如硬體升級和軟體更新等，零權值使得伺服器安靜的功能很主要。所以，在動態反饋負載均衡機制中我們要保證該功能，當伺服器的權值為零時，我們不對伺服器的權值進行調整。

五、總結

在本文，我們主要對LVS技術進行了原理級的介紹。