LVS四種負載均衡類型，十種調度方法
Load balancer / director 負載調度器
RS / real server 真實服務器
VIP客戶端訪問的虛擬集羣ip
RIP集羣所提供的應用程序的真實ip
DIP調度器的真實地址
一．四種負載均衡類型
1.DR直連
（1）首先，客戶端CIP的請求發送給LVS調度器的VIP。
（2）LVS調度器收到客戶端的請求包後，會選擇一臺real server,將數據包的MAC地址改成選擇的Real Server的MAC地址，並通過交換機（數據鏈路層）發送給RS服務器（因爲MAC地址是rs服務器，所以，rs可以接收到該數據報。）注意：此時數據包的目的及源ip地址沒有發生任何改變。
（3）A.RS的數據鏈路層收到發送來的數據報文請求後，會從鏈路層往上傳給IP層，此時IP層需要驗證請求的目標IP地址。因爲包的目標IP（即VIP）並不是像常規數據報那樣爲RS的本地IP，而僅僅目的MAC地址是RS的。所以，在RS上需要綁定一個VIP，這樣包的目標ip就沒有發生變化。而且這個vip是隱藏的，不會響應arp解析。
B.RS處理數據包完成後，直接將應答返回給客戶端，此時的源ip爲vip，目標爲cip，回覆這個過程不經過調度器
2.Tun隧道
（1）客戶端發送請求到調度器的vip；
（2）調度器根據調度算法選擇一臺real server 進行轉發，這個時候的源ip爲cip，目標ip爲vip，如果直接轉發，目標ip就爲rip了，所以需要在vip到rip這個過程進行隧道封裝，封裝兩個ip首部，轉發的報文源cip目標vip，但是還會在ip首部再添加一個ip首部，目標地址是rip，這個過程要求支持隧道協議。
（3）當real server接受到數據包之後，由於ip首部的目標ip是自己，就會拆開封裝，還有一個首部內容爲cip請求自己的vip，就會響應這個請求給cip。（響應報文的源ip爲vip，目標ip爲cip）
3.Nat
（1）客戶端訪問集羣的vip，請求web服務。（請求報文：源cip，目標vip）；
（2）調度器收到請求，會修改目標ip爲rip，並且將請求根據相應的調度算法發往後端web服務器（請求報文：源cip，目標rip）
（3）Web服務器收到請求，發現目標ip是自己，並且也提供相應的服務，就會響應這個請求報文，並且發送給調度器。（相應報文：源rip，目標cip）
（4）調度器收到web服務器的相應報文，會根據相應的機制判斷出用戶的目標ip是vip，這時會修改源ip爲vip發送給客戶端響應。（源vip，目標cip）
4.Fullnat
（1）客戶端發送請求給調度器。（源cip，目標vip）
（2）Vip經過調度算法，講請求發送給real server。（源dip，目標rip）
（3）Real server 接收到請求後，發現源地址是dip，則對dip進行響應。（源rip，目標dip）
（4）調度器收到real server 的響應後，會修改數據報的源地址爲vip，目標地址爲cip進行響應。
十種調度算法：
LVS的調度算法
LVS的調度方法分爲兩種，一種是靜態方法，一種是動態方法：
靜態方法：僅根據算法本身實現調度；實現起點公平，不管服務器當前處理多少請求，分配的數量一致；
動態方法：根據算法及後端RS當前的負載狀況實現調度；不管以前分了多少，只看分配的結果是不是公平；
一，靜態調度算法（4種）
（1）rr : round robin :輪叫,輪詢
每一次把來自用戶的請求輪流分配給內部中的服務器，從1開始，直到N(內部服務器個數)，然後重新開始循環。算法的優點是其簡潔性，它無需記錄當前所有連接的狀態，所以它是一種無狀態調度。缺點：是不考慮每臺服務器的處理能力。
(2)wrr: weight round robin :加權輪詢(以權重之間的比例實現在各主機之間進行調度)
由於每臺服務器的配置、安裝的業務應用等不同，其處理能力會不一樣。所以，我們根據服務器的不同處理能力，給每個服務器分配不同的權值，使其能夠接受相應權值數的服務請求。
(3)sh : source hashing : 源地址hash實現會話綁定sessionaffinity
將同一客戶端的請求發給同一個real server,源地址散列調度算法正好與目標地址散列調度算法相反，它根據請求的源IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的並且沒有超負荷，將請求發送到該服務器，否則返回空。它採用的散列函數與目標地址散列調度算法的相同。它的算法流程與目標地址散列調度算法的基本相似，除了將請求的目標IP地址換成請求的源IP地址。
(4)dh : destination hashing : 目標地址hash
將同樣的請求發送給同一個server,一般用於緩存服務器，簡單的說，LB集羣后面又加了一層，在LB與realserver之間加了一層緩存服務器，當一個客戶端請求一個頁面時,LB發給cache1,當第二個客戶端請求同樣的頁面時，LB還是發給cache1,這就是我們所說的，將同樣的請求發給同一個server,來提高緩存的命中率。
動態調度算法（6種）:
(1)lc :leash-connection 最少連接
把新的連接請求分配到當前連接數最小的服務器，最小連接調度是一種動態調度短算法，它通過服務器當前所活躍的連接數來估計服務器的負載均衡，調度器需要記錄各個服務器已建立連接的數目，當一個請求被調度到某臺服務器，其連接數加1，當連接中止或超時，其連接數減一，在系統實現時，我們也引入當服務器的權值爲0時，表示該服務器不可用而不被調度。此算法忽略了服務器的性能問題，有的服務器性能好，有的服務器性能差，通過加權重來區分性能，所以有了下面算法wlc。
簡單算法：active*256+inactive (誰的小，挑誰)
(2)wlc :加權最少連接
加權最小連接調度算法是最小連接調度的超集，各個服務器用相應的權值表示其處理性能。服務器的缺省權值爲1，系統管理員可以動態地設置服務器的權限，加權最小連接調度在調度新連接時儘可能使服務器的已建立連接數和其權值成比例。由於服務器的性能不同，我們給性能相對好的服務器，加大權重，即會接收到更多的請求。
簡單算法：（active*256+inactive）/weight（誰的小，挑誰）
(3)sed :最少期望延遲
說明：不考慮非活動連接，誰的權重大，我們優先選擇權重大的服務器來接收請求，但會出現問題，就是權重比較大的服務器會很忙，但權重相對較小的服務器很閒，甚至會接收不到請求，所以便有了下面的算法nq。
基於wlc算法，簡單算法：（active+1)*256/weight （誰的小選誰）
(4).nq :never queue 永不排隊
說明：在上面我們說明了，由於某臺服務器的權重較小，比較空閒，甚至接收不到請求，而權重大的服務器會很忙，所此算法是sed改進，就是說不管你的權重多大都會被分配到請求。簡單說，無需隊列，如果有臺real server的連接數爲0就直接分配過去，不需要在進行sed運算。
(5).LBLC :基於局部性的最少連接
說明：基於局部性的最少連接算法是針對請求報文的目標IP地址的負載均衡調度，主要用於Cache集羣系統，因爲Cache集羣中客戶請求報文的目標IP地址是變化的，這裏假設任何後端服務器都可以處理任何請求，算法的設計目標在服務器的負載基本平衡的情況下，將相同的目標IP地址的請求調度到同一個臺服務器，來提高服務器的訪問局部性和主存Cache命中率，從而調整整個集羣系統的處理能力。
(6).LBLCR :基於局部性的帶複製功能的最少連接
說明：基於局部性的帶複製功能的最少連接調度算法也是針對目標IP地址的負載均衡，該算法根據請求的目標IP地址找出該目標IP地 址對應的服務器組，按“最小連接”原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載，則按“最小連接”原則從這個集羣中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除， 以降低複製的程度。
注：LVS默認調度算法是 wlc 。