一、簡介

        LVS(Linux Virtual Server) 是Unix-like系統中的一個虛擬伺服器，LVS在Unix-like系統中是作為一個前端(Director)存在的,又稱為排程器，它本身不提供任何的服務，只是將通過網際網路進來的請求接受後再轉發給後臺執行的真正的伺服器(RealServer)進行處理，然後響應給客戶端。LVS有兩個重要的元件：一個是IPVS，一個是IPVSADM。ipvs是LVS的核心元件，它本身只是一個框架，類似於iptables，工作於核心空間中。ipvsadm 是用來定義LVS的轉發規則的，工作於使用者空間中。

二、IPVS的四種轉發模式

        根據負載均衡器轉發客戶端請求以及RS返回響應機制的不同，將IPVS的轉發模式分為四種：NAT，DR，FULLNAT， TUNNEL

1、DR模式（Direct Routing）

        DR模式下，客戶端的請求包到達負載均衡器的虛擬服務IP埠後，負載均衡器不會改寫請求包的IP和埠，但是會改寫請求包的MAC地址為後端RS的MAC地址，然後將資料包轉發；真實伺服器處理請求後，響應包直接回給客戶端，不再經過負載均衡器。所以DR模式的轉發效率是最高的，特別適合下行流量較大的業務場景，比如請求視訊等大檔案。

DR模式的特點：

        資料包在LB轉發過程中，源/目的IP埠都不會變化

        LB只是將資料包的MAC地址改寫為RS的MAC地址，然後轉發給相應的RS。每臺RS上都必須在環回網絡卡上繫結LB的虛擬服務IP因為LB轉發時並不會改寫資料包的目的IP，所以RS收到的資料包的目的IP仍是LB的虛擬服務IP。為了保證RS能夠正確處理該資料包，而不是丟棄，必須在RS的環回網絡卡上繫結LB的虛擬服務IP。這樣RS會認為這個虛擬服務IP是自己的IP，自己是能夠處理這個資料包的。否則RS會直接丟棄該資料包！RS上的業務程序必須監聽在環回網絡卡的虛擬服務IP上，且埠必須和LB上的虛擬服務埠一致，因為LB不會改寫資料包的目的埠，所以RS服務的監聽埠必須和虛擬服務埠一致，否則RS會直接拒絕該資料包。RS處理完請求後，響應直接回給客戶端，不再經過LB。因為RS收到的請求資料包的源IP是客戶端的IP，所以理所當然RS的響應會直接回給客戶端，而不會再經過LB。這時候要求RS和客戶端之間的網路是可達的。

LB和RS須位於同一個子網，因為LB在轉發過程中需要改寫資料包的MAC為RS的MAC地址，所以要能夠查詢到RS的MAC。而要獲取到RS的MAC，則需要保證二者位於一個子網，否則LB只能獲取到RS閘道器的MAC地址。

2. NAT模式（Network Address Translation）

        NAT模式下，請求包和響應包都需要經過LB處理。當客戶端的請求到達虛擬服務後，LB會對請求包做目的地址轉（DNAT），將請求包的目的IP改寫為RS的IP。當收到RS的響應後，LB會對響應包做源地址轉換（SNAT），將響應包的源IP改寫為LB的IP。

NAT模式的特點：

        LB會修改資料包的地址對於請求包，會進行DNAT；對於響應包，會進行SNAT。

        LB會透傳客戶端IP到RS（DR模式也會透傳），雖然LB在轉發過程中做了NAT轉換，但是因為只是做了部分地址轉發，所以RS收到的請求包裡是能看到客戶端IP的。需要將RS的預設閘道器地址配置為LB的浮動IP地址，因為RS收到的請求包源IP是客戶端的IP，為了保證響應包在返回時能走到LB上面，所以需要將RS的預設閘道器地址配置為LB的虛擬服務IP地址。當然，如果客戶端的IP是固定的，也可以在RS上新增明細路由指向LB的虛擬服務IP，不用改預設閘道器。LB和RS須位於同一個子網，並且客戶端不能和LB/RS位於同一子網，因為需要將RS的預設閘道器配置為LB的虛擬服務IP地址，所以需要保證LB和RS位於同一子網。又因為需要保證RS的響應包能走回到LB上，則客戶端不能和RS位於同一子網。否則RS直接就能獲取到客戶端的MAC，響應包就直接回給客戶端了，不會走閘道器，也就走不到LB上面了。這時候由於沒有LB做SNAT，客戶端收到的響應包源IP是RS的IP，而客戶端的請求包目的IP是LB的虛擬服務IP，這時候客戶端無法識別響應包，會直接丟棄。

效果演示，將排程器的兩塊網絡卡配置成不在同一個網段的IP地址，RS1和RS2的IP地址為同一網段

（1）設計規劃圖:

（2）配置各個虛擬機器的IP地址

（3）配置Director虛擬主機

（4）在RS1、RS2開啟http服務

（5）指定RS1、RS2的閘道器

（6）效果監測

3 、FULLNAT模式

        FULLNAT模式下，LB會對請求包和響應包都做SNAT+DNAT。

FULLNAT模式的特點：

        LB完全作為一個代理伺服器，FULLNAT下，客戶端感知不到RS，RS也感知不到客戶端，它們都只能看到LB。此種模式和七層負載均衡有點相似，只不過不會去解析應用層協議，而是在TCP層將訊息轉發

LB和RS對於組網結構沒有要求，不同於NAT和DR要求LB和RS位於一個子網，FULLNAT對於組網結構沒有要求。只需要保證客戶端和LB、LB和RS之間網路互通即可。

4、TUNNEL模式

TUNNEL模型的特點：

        RS伺服器與前端的LB可以在不同的網路中，RIP一定不能是私有IP，前端的LB只處理客戶端的請求，然後將請求轉發RS，由後臺的RS直接響應客戶端，不再經過LB,此種模型也不支援埠對映,RS只能使用哪些支援IP隧道的作業系統。

三、IPVS支援的排程演算法

        對於後端的RS叢集，LB是如何決策應該把訊息排程到哪個RS節點呢？這是由負載均衡排程演算法決定的。IPVS常用的排程演算法有：

1、輪詢（Round Robin）

        LB認為叢集內每臺RS都是相同的，會輪流進行排程分發。從資料統計上看，RR模式是排程最均衡的。

2、加權輪詢（Weighted Round Robin）

        LB會根據RS上配置的權重，將訊息按權重比分發到不同的RS上。可以給效能更好的RS節點配置更高的權重，提升叢集整體的效能。

3、最小連線數（Least Connections）

        LB會根據和叢集內每臺RS的連線數統計情況，將訊息排程到連線數最少的RS節點上。在長連線業務場景下，LC演算法對於系統整體負載均衡的情況較好；但是在短連線業務場景下，由於連線會迅速釋放，可能會導致訊息每次都排程到同一個RS節點，造成嚴重的負載不均衡。

4、加權最小連線數（Weighted Least Connections）

        預設排程方法

5、源地址雜湊（Source  Hash）

        實現session sticky，源IP地址hash；將來自於同一個IP地址的請求始終發往第一次挑中的RS，從而實現會話繫結

6、從不排隊排程方法(Never Queue)

        第一輪均勻分配，後續SED

7、基於本地的最少連線 (Locale-Based LC) 

        動態的DH演算法，使用場景，根據負載狀態實現正向代理

8、帶複製的基於本地的最少連線 (LBLC with Replicated)

        帶複製功能的LBLC，解決LBLC負載不均衡問題，從負載重的複製到負載輕的RS

9、目的地址雜湊 (Destination Hash)

        第一次輪詢，排程至RS，後續將發往同一個目標地址的請求始終轉發至，第一次挑中的RS，典型使用場景是正向代理快取場景中的負載均衡