LVS的三種工作模式：

• VS/NAT模式（Network address translation）
• VS/TUN模式（tunneling）
• DR模式（Direct routing）

參考文章：http://www.linuxvirtualserver.org/zh/lvs3.html

** NAT模式-網絡地址轉換 ** * Virtualserver via Network address translation(VS/NAT)*

這個是通過網絡地址轉換的方法來實現調度的。首先調度器(LB)接收到客戶的請求數據包時（請求的目的IP為VIP），根據調度算法決定將請求發送給哪個后端的真實服務器（RS）。然后調度就把客戶端發送的請求數據包的目標IP地址及端口改成后端真實服務器的IP地址（RIP）,這樣真實服務器（RS）就能夠接收到客戶的請求數據包了。真實服務器響應完請求后，查看默認路由（NAT模式下我們需要把RS的默認路由設置為LB服務器。）把響應后的數據包發送給LB,LB再接收到響應包后，把包的源地址改成虛擬地址（VIP）然后發送回給客戶端。

原理簡述：

1. 客戶端請求數據，目標IP為VIP
2. 請求數據到達LB服務器，LB根據調度算法將目的地址修改為RIP地址及對應端口（此RIP地址是根據調度算法得出的。）并在連接HASH表中記錄下這個連接。
3. 數據包從LB服務器到達RS服務器webserver，然后webserver進行響應。Webserver的網關必須是LB，然后將數據返回給LB服務器。
4. 收到RS的返回后的數據，根據連接HASH表修改源地址VIP&目標地址CIP，及對應端口80.然后數據就從LB出發到達客戶端。
5. 客戶端收到的就只能看到VIP\DIP信息。

NAT模式優缺點：

1. NAT技術將請求的報文和響應的報文都需要通過LB進行地址改寫，因此網站訪問量比較大的時候LB負載均衡調度器有比較大的瓶頸，一般要求最多之能10-20臺節點
2. 只需要在LB上配置一個公網IP地址就可以了。
3. 每臺內部的節點服務器的網關地址必須是調度器LB的內網地址。
4. NAT模式支持對IP地址和端口進行轉換。即用戶請求的端口和真實服務器的端口可以不一致。

TUN模式 virtual server via ip tunneling

采用NAT模式時，由于請求和響應的報文必須通過調度器地址重寫，當客戶請求越來越多時，調度器處理能力將成為瓶頸。為了解決這個問題，調度器把請求的報文通過IP隧道轉發到真實的服務器。真實的服務器將響應處理后的數據直接返回給客戶端。這樣調度器就只處理請求入站報文，由于一般網絡服務應答數據比請求報文大很多，采用VS/TUN模式后，集群系統的最大吞吐量可以提高10倍。
VS/TUN和NAT模式不同的是，它在LB和RS之間的傳輸不用改寫IP地址。而是把客戶請求包封裝在一個IP tunnel里面，然后發送給RS節點服務器，節點服務器接收到之后解開IP tunnel后，進行響應處理。并且直接把包通過自己的外網地址發送給客戶不用經過LB服務器。

原理簡述：

1. 客戶請求數據包，目標地址VIP發送到LB上。
2. LB接收到客戶請求包，進行IP Tunnel封裝。即在原有的包頭加上IP Tunnel的包頭。然后發送出去。
3. RS節點服務器根據IP Tunnel包頭信息（此時就有一種邏輯上的隱形隧道，只有LB和RS之間懂）收到請求包，然后解開IP Tunnel包頭信息，得到客戶的請求包并進行響應處理。
4. 響應處理完畢之后，RS服務器使用自己的出公網的線路，將這個響應數據包發送給客戶端。源IP地址還是VIP地址。（RS節點服務器需要在本地回環接口配置VIP）

DR模式（直接路由模式） Virtual server via direct routing (vs/dr)

DR模式是通過改寫請求報文的目標MAC地址，將請求發給真實服務器的，而真實服務器響應后的處理結果直接返回給客戶端用戶。同TUN模式一樣，DR模式可以極大的提高集群系統的伸縮性。而且DR模式沒有IP隧道的開銷，對集群中的真實服務器也沒有必要必須支持IP隧道協議的要求。但是要求調度器LB與真實服務器RS都有一塊網卡連接到同一物理網段上，必須在同一個局域網環境。
DR模式是互聯網使用比較多的一種模式。

DR模式原理過程簡述：
VS/DR模式的連接調度和管理與NAT和TUN中的一樣，它的報文轉發方法和前兩種不同。DR模式將報文直接路由給目標真實服務器。在DR模式中，調度器根據各個真實服務器的負載情況，連接數多少等，動態地選擇一臺服務器，不修改目標IP地址和目標端口，也不封裝IP報文，而是將請求報文的數據幀的目標MAC地址改為真實服務器的MAC地址。然后再將修改的數據幀在服務器組的局域網上發送。因為數據幀的MAC地址是真實服務器的MAC地址，并且又在同一個局域網。那么根據局域網的通訊原理，真實服務器是一定能夠收到由LB發出的數據包。真實服務器接收到請求數據包的時候，解開IP包頭查看到的目標IP是VIP。（此時只有自己的IP符合目標IP才會接收進來，所以我們需要在本地的回環接口上面配置VIP。另：由于網絡接口都會進行ARP廣播響應，但集群的其他機器都有這個VIP的lo接口，都響應就會沖突。所以我們需要把真實服務器的lo接口的ARP響應關閉掉。）然后真實服務器做成請求響應，之后根據自己的路由信息將這個響應數據包發送回給客戶，并且源IP地址還是VIP。

DR模式小結：

1. 通過在調度器LB上修改數據包的目的MAC地址實現轉發。注意源地址仍然是CIP，目的地址仍然是VIP地址。
2. 請求的報文經過調度器，而RS響應處理后的報文無需經過調度器LB，因此并發訪問量大時使用效率很高（和NAT模式比）
3. 因為DR模式是通過MAC地址改寫機制實現轉發，因此所有RS節點和調度器LB只能在一個局域網里面
4. RS主機需要綁定VIP地址在LO接口上，并且需要配置ARP抑制。
5. RS節點的默認網關不需要配置成LB，而是直接配置為上級路由的網關，能讓RS直接出網就可以。
6. 由于DR模式的調度器僅做MAC地址的改寫，所以調度器LB就不能改寫目標端口，那么RS服務器就得使用和VIP相同的端口提供服務。

LVS調度算法

參考文章：http://www.linuxvirtualserver.org/zh/lvs4.html
Lvs的調度算法決定了如何在集群節點之間分布工作負荷。當director調度器收到來自客戶端訪問VIP的上的集群服務的入站請求時，director調度器必須決定哪個集群節點應該處理請求。Director調度器用的調度方法基本分為兩類：
固定調度算法：rr，wrr，dh，sh
動態調度算法：wlc，lc，lblc，lblcr

算法說明

RR（Round Robin Scheduling)

輪詢算法，它將請求依次分配給不同的rs節點，也就是RS節點中均攤分配。這種算法簡單，但只適合于RS節點處理性能差不多的情況

WRR（Weighted Round-Robin Scheduling）

加權輪詢調度，它將依據不同RS的權值分配任務。權值較高的RS將優先獲得任務，并且分配到的連接數將比權值低的RS更多。相同權值的RS得到相同數目的連接數。

WLC（Weighted Least-Connection Scheduling）

加權最小連接數調度，假設各臺RS的全職依次為Wi，當前tcp連接數依次為Ti，依次去Ti/Wi為最小的RS作為下一個分配的RS

DH（Destination Hashing Scheduling）

目的地址哈希調度以目的地址為關鍵字查找一個靜態hash表來獲得需要的RS

SH（Source Hashing Scheduling）

源地址哈希調度以源地址為關鍵字查找一個靜態hash表來獲得需要的RS

LC（Least-Connection Scheduling）

最小連接數調度,IPVS表存儲了所有活動的連接。LB會比較將連接請求發送到當前連接最少的RS.

LBLC（Locality-Based Least Connections Scheduling）

基于地址的最小連接數調度：將來自同一個目的地址的請求分配給同一臺RS，此時這臺服務器是尚未滿負荷的。否則就將這個請求分配給連接數最小的RS，并以它作為下一次分配的首先考慮。

LBLCR（Locality-Based Least Connections with Replication Scheduling）

帶復制的基于局部性最少鏈接調度算法也是針對目標IP地址的負載均衡。LBLCR算法先根據請求的目標IP地址找出該目標IP地址對應的服務器組；按“最小連接”原則從該服務器組中選出一臺服務器，若服務器沒有超載， 將請求發送到該服務器；若服務器超載；則按“最小連接”原則從整個集群中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該 服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低復制的程度。

LVS調度算法的生產環境選型：

1. 一般的網絡服務，如http，mail，mysql等常用的LVS調度算法為：

• 基本輪詢調度RR
• 加權最小連接調度WLC
• 加權輪詢調度WRR

2. 基于局部性的最小連接LBLC和帶復制的給予局部性最小連接LBLCR主要適用于web cache和DB cache
3. 源地址散列調度SH和目標地址散列調度DH可以結合使用在防火墻集群中，可以保證整個系統的出入口唯一。
   實際適用中這些算法的適用范圍很多，工作中最好參考內核中的連接調度算法的實現原理，然后根據具體的業務需求合理的選型。

參考文章：http://atong.blog.51cto.com/2393905/1351362

LVS+keepalived實現負載均衡&高可用

部署成功后的另一些問題

1. 當我們的RS節點出現問題，LB如何知道。如果不知道是會把會話連接接續轉發到RS上面。
2. 如果LB出現故障，那么整個網絡就出現故障。

針對上面的1問題，我們就需要一種RS節點健康檢查機制。定時的去檢測RS是否正常，如果出現不正常那么就把這個RS從VIP服務里面刪除掉。如果恢復正常了，就再把RS添加進來。針對2問題，我們可以另外再架設一臺LB服務器，作為備LB服務器。那么當主LB出現故障，備LB服務器就會啟動接管主LB服務器的工作，接管它的資源（IP地址，在網絡中的角色身份等）

LVS/Nginx/HAProxy負載均衡器的對比分析