lvs它是一種集群(Cluster)技術，采用IP負載均衡技術和基於內容請求分發技術。調度器具有很好的吞吐率，將請求均衡地轉移到不同的服務器上執行，且調度器自動屏蔽掉服務器的故障，從而將一組服務器構成一個高性能的、高可用的虛擬服務器。整個服務器集群的結構對客戶是透明的，而且無需修改客戶端和服務器端的程序。

二、實現方式：

1） NAT模式：

原理：就是把客戶端發來的數據包的IP頭的目的地址，在負載均衡器上換成其中一臺真機服務器的IP地址，並發至此真機服務器來處理,真機服務器處理完成後把數據交給經過負載 均衡器,負載均衡器再把數據包的原IP地址改為自己的IP，將目的地址改為客戶端IP地址即可?期間,無論是進來的流量,還是出去的流量,都必須經過負載 均衡器?

優點：集群中的物理服務器可以使用任何支持TCP/IP操作系統，只有負載均衡器需要一個合法的IP地址。

缺點：擴展性有限。當服務器節點（普通PC服務器）增長過多時,負載均衡器將成為整個系統的瓶頸，因為所有的請求包和應答包的流向都經過負載均衡器。當服務器節點過多時，大量的數據包都交匯在負載均衡器那，速度就會變慢！

2）IP隧道模式（VS-TUN）

原理：首先要知道，互聯網上的大多Internet服務的請求包很短小，而應答包通常很大。那麽隧道模式就是，把客戶端發來的數據包，封裝一個新的IP頭 標記(僅目的IP)發給真機服務器,真機服務器收到後,先把數據包的頭解開,還原數據包,處理後,直接返回給客戶端,不需要再經過負載均衡器?註意,由於真機度武器需要對負 載均衡器發過來的數據包進行還原,所以說必須支持IPTUNNEL協議?所以,在真機服務器的內核中,必須編譯支持IPTUNNEL這個選項

優點：負載均衡器只負責將請求包分發給後端節點服務器，而真機服務器將應答包直接發給用戶。所以，減少了負載均衡器的大量數據流動，負載均衡器不再是系統的瓶頸，就能處理很巨大的請求量，這種方式，一臺負載均衡器能夠為很多真機服務器進行分發。而且跑在公網上就能進行不同地域的分發。

缺點：隧道模式的真機服務器節點需要合法IP，這種方式需要所有的服務器支持”IP Tunneling”(IP Encapsulation)協議，服務器可能只局限在部分Linux系統上。

3）直接路由模式

原理：負載均衡器和RS都使用同一個IP對外服務?但只有DR對ARP請求進行響應,所有RS對本身這個IP的ARP請求保持靜默?也就是說,網關會把對 這個服務IP的請求全部定向給DR,而DR收到數據包後根據調度算法,找出對應的RS,把目的MAC地址改為RS的MAC（因為IP一致）並將請求分發給 這臺RS?這時RS收到這個數據包,處理完成之後，由於IP一致，可以直接將數據返給客戶，則等於直接從客戶端收到這個數據包無異,處理後直接返回給客戶 端?由於負載均衡器要對二層包頭進行改換,所以負載均衡器和RS之間必須在一個廣播域,也可以簡單的理解為在同一臺交換機上?

優點：和TUN（隧道模式）一樣，負載均衡器也只是分發請求，應答包通過單獨的路由方法返回給客戶端。與VS-TUN相比，VS-DR這種實現方式不需要隧道結構，因此可以使用大多數操作系統做為物理服務器。

缺點：要求負載均衡器的網卡必須與物理網卡在一個物理段上。

調度算法

LVS 的負載調度算法 在內核中的連接調度算法上,IPVS 已實現了以下八種調度算法

1、 輪調調度(Round-Robin Scheduling )
（1）輪叫的方式依次將請求調度不同的服務器
（2）算法的優點是其簡潔性,它無需記錄當前所有連接的狀態,所以它是一種無狀態調度。

2、加權輪叫調度(Weighted Round-Robin Scheduling )
（1）解決服務器間性能不一的情況,
（2）按權值的高低和輪叫方式分配請求到各服務器。權值高的服務器先收到的連接,權值高的服 務器比權值低的服務器處理更多的連接,相同權值的服務器處理相同數目的連接數。

3、最小連接調度(Least-Connection Scheduling )
（1）把新的連接請求分配到當前連接數最小的服務器。
（2）一種動態調度算法,它通過服務器當前所活躍的連接數來估計服
務 器的負載情況。調度器需要記錄各個服務器已建立連接的數目,當一個請求被調度到某臺服務器,其連接數加 1;當連接中止或超時,其連接數減一。

4、加權最小連接調度(Weighted Least-Connection Scheduling)

（1）最小連接調度的超集,各個服務器用相應的權值表示其處理性能。
（2）服務器的缺省權值為1,系統管理員可以動態地設置服務器的權 值。
（3）加權最小連接調度在調度新連接時盡可能使服務器的已建立連接數和其權值成比例。

5、基於局部性的最少鏈接(Locality-Based Least Connections Scheduling )
（1）簡稱LBLC算法，針對請求報文的目標 IP 地址的負載均衡調度,目前主要用於 Cache 集群系統,因為在 Cache 集群中 客戶請求報文的目標 IP 地址是變化的。
（2）假設任何後端服務器都可以處理任一請求,算法的設計目標是在服務器的負載基本平衡情況下,將相同目標IP地址的請求調度到同一臺服務器,來提高各臺服務器的訪問局部性和主存 Cache 命中率,從而整個集群系統的處理能力。
（3）LBLC調度算法先根據請求的目標IP地址找出該目標IP地址最近使用的服務器,若該服務器是可用的且沒有超載,將請求發送到該服務器;若服務器不 存在,或者該服務器超載且有服務器處於其一半的工作負載,則用 “ 最少鏈接 ” 的原則選出一個可用的服務器,將請求發送到該服務器。

6、帶復制的基於局部性最少鏈接(Locality-Based Least Connections with Replication Scheduling)
（1）簡稱 LBLCR算法，也是針對目標 IP 地址的負載均衡,目前主要用於 Cache集群系統。它與 LBLC 算法的不同之處是它要維護從一個目標 IP 地址到一組服務器的映射。
（2）LBLCR 算法先根據請求的目標 IP 地址找出該目標 IP 地址對應的服務器組;按 “ 最小連接 ” 原則從該服務器組中選出一臺服務器,若服務器沒有超載,將請求發送到該服務器;若服務器超載;則按 “ 最小連接 ” 原則從整個集群中選出一臺服務器,將該服務器加入到服務器組中,將請求發送到該服務器。同時,當該服務器組有一段時間沒有被修改,將最忙的服 務器從服務器組中刪除,以降低復制的程度。

7、目標地址散列調度(Destination Hashing Scheduling）
（1）針對目標 IP 地址的負載均衡,但它是一種靜態映射算法,通過一個散列(Hash)函數將一個目標 IP 地址映射到一臺服務器。
（2）目標地址散列調度算法先根據請求的目標 IP 地址,作為散列鍵(Hash Key)從靜態分配的散列表找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,否則返回空。

8、源地址散列調度(Source Hashing Scheduling)
（1）源地址散列調度(Source Hashing Scheduling)算法正好與目標地址散列調度算法相反

（2）它根據請求的源 IP 地址,作為散列鍵(Hash Key)從靜態分配的散列表找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,否則返回空。
（3）它采用的散列函數與目標地址散列調度算法 的相同。它的算法流程與目標地址散列調度算法的基本相似,除了將請求的目標 IP 地址換成請求的源 IP 地址。
（4）在實際應用中,源地址散列調度和目標地址散列調度可以結合使用在防火墻集群中,它們可以保證整個系統的唯一出入口。

lvs負載調度原理和方式