LVS 三種負載均衡方式比較

1、什麼是LVS？

首先簡單介紹一下LVS (Linux Virtual Server)到底是什麼東西，其實它是一種叢集(Cluster)技術，採用IP負載均衡技術和基於內容請求分發技術。排程器具有很好的吞吐率，將請求均衡地轉移到不同的伺服器上執行，且排程器自動遮蔽掉伺服器的故障，從而將一組伺服器構成一個高效能的、高可用的虛擬伺服器。整個伺服器叢集的結構對客戶是透明的，而且無需修改客戶端和伺服器端的程式。

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

群採用三層結構，其體系結構如圖所示：

LVS叢集的體系結構

2、LVS主要組成部分為：

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

伺服器池（server pool/ Realserver），是一組真正執行客戶請求的伺服器，執行的服務一般有WEB、MAIL、FTP和DNS等。

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

3、LVS負載均衡方式:

◆Virtual Server via Network Address Translation NAT（VS/NAT）

VS/NAT是一種最簡單的方式，所有的RealServer只需要將自己的閘道器指向Director即可。客戶端可以是任意作業系統，但此方式下，一個Director能夠帶動的RealServer比較有限。在VS/NAT的方式下，Director也可以兼為一臺RealServer。VS/NAT的體系結構如圖所示。

VS/NAT的體系結構

◆Virtual Server via IP Tunneling(VS/TUN)

IP隧道（IP tunneling）是將一個IP報文封裝在另一個IP報文的技術，這可以使得目標為一個IP地址的資料包文能被封裝和轉發到另一個IP地址。IP隧道技術亦稱為IP封裝技術（IP encapsulation）。IP隧道主要用於移動主機和虛擬私有網路（Virtual Private Network），在其中隧道都是靜態建立的，隧道一端有一個IP地址，另一端也有唯一的IP地址。

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

VS/TUN的體系結構

VS/TUN的工作流程：

◆Virtual Server via Direct Routing(VS/DR)

VS/DR方式是通過改寫請求報文中的MAC地址部分來實現的。Director和RealServer必需在物理上有一個網路卡通過不間斷的區域網相連。 RealServer上繫結的VIP配置在各自Non-ARP的網路裝置上(如lo或tunl),Director的VIP地址對外可見，而RealServer的VIP對外是不可見的。RealServer的地址即可以是內部地址，也可以是真實地址。

VS/DR的體系結構

VS/DR的工作流程

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

VS/DR的工作流程

4、三種負載均衡方式比較：

◆Virtual Server via NAT

VS/NAT 的優點是伺服器可以執行任何支援TCP/IP的作業系統，它只需要一個IP地址配置在排程器上，伺服器組可以用私有的IP地址。缺點是它的伸縮能力有限，當伺服器結點數目升到20時，排程器本身有可能成為系統的新瓶頸，因為在VS/NAT中請求和響應報文都需要通過負載排程器。我們在Pentium166 處理器的主機上測得重寫報文的平均延時為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負載均衡技術的優缺點歸納以下表：

	VS/NAT	VS/TUN	VS/DR
伺服器作業系統	任意	支援隧道	多數（支援Non-arp）
伺服器網路	私有網路	區域網/廣域網	區域網
伺服器數目（100M網路）	10~20	100	大於100
伺服器閘道器	負載均衡器	自己的路由	自己的路由
效率	一般	高	最高

注：以上三種方法所能支援最大伺服器數目的估計是假設排程器使用100M網路卡，排程器的硬體配置與後端伺服器的硬體配置相同，而且是對一般Web服務。使 用更高的硬體配置（如千兆網路卡和更快的處理器）作為排程器，排程器所能排程的伺服器數量會相應增加。當應用不同時，伺服器的數目也會相應地改變。所以，以上資料估計主要是為三種方法的伸縮性進行量化比較。

5、lvs的負載排程演算法 在核心中的連線排程演算法上，IPVS已實現了以下八種排程演算法：

◆一 輪叫排程（Round­Robin Schedul ing ）

輪叫排程（Round Robin Scheduling）演算法就是以輪叫的方式依次將請求排程不同的伺服器，即每次排程執行i=(i+1)mod n，並選出第i臺伺服器。演算法的優點是其簡潔性，它無需記錄當前所有連線的狀態，所以它是一種無狀態排程。

◆二 加權輪叫排程（Weighted Round­Robin Scheduling ）

加權輪叫排程 （Weighted Round­Robin Scheduling）演算法可以解決伺服器間效能不一的情況，它用相應的權值表示伺服器的處理效能，伺服器的預設權值為1。假設伺服器A的權值為1，B的權值為2，則表示伺服器B的處理效能是A的兩倍。加權輪叫排程演算法是按權值的高 低和輪叫方式分配請求到各伺服器。權值高的伺服器先收到的連線，權值高的服 務器比權值低的伺服器處理更多的連線，相同權值的伺服器處理相同數目的連線數。

◆三 最小連線排程（Least­Connect ion Schedul ing ）

最小連線排程（Least­ Connect ion Scheduling）演算法是把新的連線請求分配到當前連線數最小的伺服器。最小連線排程是一種動態排程演算法，它通過伺服器當前所活躍的連線數來估計伺服器的負載情況。排程器需要記錄各個伺服器已建立連線的數目，當一個請求被排程到某臺伺服器，其連線數加1；當連線中止或超時，其連線數減一。

◆四 加權最小連線排程（Weighted Least­Connectio n Scheduling）

加權最小連線調 度（Weighted Least­Connectio n Scheduling）演算法是最小連線排程的超集，各個伺服器用相應的權值表示其處理效能。伺服器的預設權值為1，系統管理員可以動態地設定伺服器的權值。加權最小連線排程在排程新連線時儘可能使伺服器的已建立連線數和其權值成比例。

◆五 基於區域性性的最少連結（Locality­Based Least Connections Schedulin g ）

基於區域性性的最少連結排程（Locality­Based Least Connections Scheduling，以下簡稱為LBLC）演算法是針對請求報文的目標IP地址的負載均衡排程，目前主要用於Cache叢集系統，因為在Cache叢集中客戶請求報文的目標IP地址是變化的。這裡假設任何後端伺服器都可以處理任一請求，演算法的設計目標是在伺服器的負載基本平衡情況下，將相同目標IP地址的請求排程到同一臺伺服器，來提高各臺伺服器的訪問區域性性和主存Cache命中率，從而整個叢集系統的處理能力。LBLC排程演算法先根據請求的目標IP 地址 找出該目標IP地址最近使用的伺服器，若該伺服器是可用的且沒有超載，將請求傳送到該伺服器；若伺服器不存在，或者該伺服器超載且有伺服器處於其一半的工 作負載，則用“最少連結”的原則選出一個可用的伺服器，將請求傳送到該伺服器。

◆六 帶複製的基於區域性性最少連結（Locality­Based Least Connectio ns with Replication Scheduling）

帶複製的基於區域性性最少連結排程（Locality­Based Least Connectio ns 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地址對應的伺服器組；按“最小連線”原則從該伺服器組中選出一臺伺服器，若伺服器沒有超載，將請求傳送到該伺服器；若伺服器超載；則按“最小連線”原則從整個叢集中選出一臺伺服器，將該伺服器加入到伺服器組中，將請求傳送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，將最忙的服 務器從伺服器組中刪除，以降低複製的程度。

◆七 目標地址雜湊排程（Destinat ion Hashing Scheduling ）

目標地址雜湊排程 （Destinat ion Hashing Scheduling）演算法也是針對目標IP地址的負載均衡，但它是一種靜態對映演算法，通過一個雜湊（Hash）函式將一個目標IP地址對映到一臺伺服器。目標地址雜湊排程演算法先根據請求的目標IP地址，作為雜湊鍵（Hash Key）從靜態分配的雜湊表找出對應的伺服器，若該伺服器是可用的且未超載，將請求傳送到該伺服器，否則返回空。

◆八 源地址雜湊排程（Source Hashing Scheduling）

源地址雜湊排程（Source Hashing Scheduling）演算法正好與目標地址雜湊排程演算法相反，它根據請求的源IP地址，作為雜湊鍵（Hash Key）從靜態分配的雜湊表找出對應的伺服器，若該伺服器是可用的且未超載，將請求傳送到該伺服器，否則返回空。它採用的雜湊函式與目標地址雜湊排程演算法 的相同。它的演算法流程與目標地址雜湊排程演算法的基本相似，除了將請求的目標IP地址換成請求的源IP 地址，所以這裡不一一敘述。在實際應用中，源地址雜湊 排程和目標地址雜湊排程可以結合使用在防火牆叢集中，它們可以保證整個系統的唯一出入口。