lvs的多種模式和排程詳細講解
一.簡介
LVS是Linux Virtual Server的簡稱，也就是Linux虛擬伺服器, 是一個由章文嵩博士發起的自由軟體專案，目前已經是Linux標準核心的一部分，但在Linux2.4核心以前，使用LVS時必須要重新編譯核心以支援LVS功能模組。
類似於iptables的架構，在核心中有一段程式碼用於實時監聽資料包來源的請求，當資料包到達埠時做一次重定向。這一系列的工作必須在核心中實現。在核心中實現資料包請求處理的程式碼叫做ipvs。ipvs僅僅提供了功能框架，還需要自己手動定義是資料對哪個服務的請求，而這種定義需要通過寫規則來實現，寫規則的工具就稱為ipvsadm。
通過Lvs提供的負載均衡技術來實現一個高效能、高可用的伺服器叢集。Lvs對使用者的請求進行分發，這個請求可以是網頁、郵件、視訊、DNS等等。
名詞：
- VIP（Virtual IP）：Director用來向客戶端提供服務的IP地址，因為需要做冗餘，就需要2臺Lvs虛擬一個共用的VIP，也是對外開放的外網ip。
- RIP（Real IP）：叢集節點（後臺真正提供服務的伺服器）所使用的IP地址
- DIP（Director's IP）：Director用來和RIP 進行聯絡的地址
- CIP（Client computer's ）：公網IP，客戶端用來訪問服務的ip。
二.結構
使用LVS架設的伺服器集群系統有三個部分組成：最前端的負載均衡層，用Load Balancer表示，中間的伺服器群組層，用Server Array表示，最底端的資料共享儲存層，用Shared Storage表示。在使用者看來，所有的內部應用都是透明的，使用者只是在使用一個虛擬伺服器提供的高效能服務。
Load Balancer層：
位於整個集群系統的最前端，有一臺或者多臺負載排程器（Director Server）組成，它的作用主要是類似於一個路由器，根據設定通過路由表將使用者的請求分發給後端的應用伺服器上，它本身並不對請求有任何解讀和處理。同時，還要安裝對應用伺服器的監控模組Ldirectord，此模組用於監測應用伺服器的健康狀況。在不可用時把它從LVS路由表中剔除，恢復時重新加入。
Server Array層：
由一組實際執行應用服務的機器組成，Real Server可以是WEB伺服器、MAIL伺服器、FTP伺服器、DNS伺服器、視訊伺服器中的一個或者多個。
Shared Storage層：
是為所有Real Server提供共享儲存空間和內容一致性的儲存區域，在物理上，一般有磁碟陣列裝置組成，為了提供內容的一致性，一般可以通過NFS網路檔案系統共享資料，但是NFS在繁忙的業務系統中，效能並不是很好，此時可以採用叢集檔案系統，例如Red hat的GFS檔案系統，oracle提供的OCFS2檔案系統等。
三.負載均衡
簡介
LVS的IP負載均衡技術是通過IPVS模組來實現的，IPVS是LVS集群系統的核心軟體，它的主要作用是：安裝在Director Server上，同時在Director Server上虛擬出一個IP地址，使用者必須通過這個虛擬的IP地址訪問服務。這個虛擬IP一般稱為LVS的VIP，即Virtual IP。
訪問的請求首先經過VIP到達負載排程器，然後由負載排程器從Real Server列表中選取一個服務節點響應使用者的請求。當用戶的請求到達負載排程器後，排程器如何將請求傳送到提供服務的Real Server節點，而Real Server節點如何返回資料給使用者，有如下三種方式。
NAT（Network Address Translation）
步驟：
NAT是一種外網和內網地址對映的技術，網路資料報的進出都要經過LVS的處理。LVS需要作為RS（真實伺服器）的閘道器。當包到達LVS時，從後端應用伺服器選擇一個，做目標地址轉換（DNAT），將目標IP改為RS的IP。Lvs就相當於一個路由器一樣，做基本的路由轉發。
RS接收到包以後，彷彿是客戶端直接發給它的一樣。RS處理完後，將包傳送給客戶端，這時RS的包通過閘道器（LVS）中轉，LVS會做源地址轉換（SNAT），將包的源地址改為VIP，這樣，這個包對客戶端看起來就彷彿是LVS直接返回給它的。客戶端無法感知到後端RS的存在。
資料包地址轉換過程：
S:CIP D:VIP -> Director -> S:CIP D:RIP -> Real Server -> S:RIP D:CIP -> Director -> S:VIP D:CIP
特點：
在NAT方式下Lvs要對使用者請求和響應報文做地址轉換，當用戶請求越來越多時，排程器的處理能力將成為瓶頸。
需要Lvs和RS在一個區域網，Lvs做RS的閘道器。
隱藏真實迴應的ip。
支援埠對映。
後臺的Real Server可以使用任何作業系統。
TUN（IP Tunneling）
步驟：
TUN也就是IP隧道技術實現虛擬伺服器，它將排程器收到的IP資料包封裝在一個新的IP資料包中，轉交給RS，然後RS的返回資料會直接返回給使用者。
ip隧道是一個將ip報文封裝到另一個ip報文的技術，將客戶請求包封裝在一個ip tunnel裡面，然後發給RS節點伺服器。這時候這個包的源ip就是Lvs的，目的ip是RS伺服器的。
RS收到請求後解開裡面的ip tunnel層，進行響應處理。並且直接把包通過自己的外網地址傳送給客戶，不用經過LVS。
資料包地址轉換過程：
DIP -> VIP 基於隧道來傳輸，在資料包外層額外封裝了S:DIP D :RIP 的地址。
特點：
因為經過封裝，所以RS一定不能是私有地址，可以異地容災。
Lvs只處理使用者的報文請求而不用傳送迴應，這樣會提高一定的效率，但要維持ip隧道會降低一些效率。
直接將資料包返回給客戶端，所以RS預設閘道器不能是DIP，必須是公網上某個路由器的地址。
需要RS的系統支援隧道。
不支援埠對映。
無法隱藏真實迴應的ip。
DR（Direct Routing）
步驟：
DR模式下，LVS只需要將網路幀的MAC地址修改為某一臺RS的MAC，該包就會被轉發到相應的RS處理，此時的源IP和目標IP都沒變，LVS只是做了一下移花接木。RS收到LVS轉發來的包時，鏈路層發現MAC是自己的，到上面的網路層，發現IP(虛擬的)也是自己的，於是這個包被合法地接受，RS感知不到前面有LVS的存在。而當RS返回響應時，只要直接向源IP（即使用者的IP）返回即可，不再經過LVS。
資料包地址轉換過程：
S:CIP D:VIP -> Director -> S:CIP D:RIP -> Real Server -> S:VIP D:CIP
特點：
因為只改寫進來的網路包的mac地址，不管理出去的，也沒有ip隧道，所以效能最好。
不需要和Lvs在一個網段，但需要RS有一塊網絡卡和Lvs連線在同一物理網段上。
無法隱藏ip地址。
不支援埠對映。
RS不能將閘道器指向DIP。
直接將資料包返回給客戶端，所以Real Server預設閘道器不能是DIP，必須是公網上某個路由器的地址；
RIP 為公網地址，管理員可以遠端連線Real Server來檢視工作狀態；
一旦Director 宕機，可以通過修改DNS記錄將A記錄指向RIP 繼續向外提供服務；
四.負載排程
簡介
在Lvs進行負載均衡選擇後端RS（真實伺服器）的時候，可以根據策略進行動態選擇。當前有十種負載均衡演算法。
固定排程演算法
按照某種既定的演算法，不考慮實時的連線數予以分配。
輪詢排程（Round Robin）
輪詢排程會按順序挨個將請求分配到後端叢集中，而不管RS的負載和效能情況。如果有A,B,C三臺RS，那會按順序轉發到A,B,C上面，第四個請求就又發到A上面了。
加權輪詢（Weighted Round Robin）
“加權輪詢”排程演算法是根據RS的不同處理能力來排程訪問請求。可以對每臺RS設定不同的排程權值。對於效能相對較好的RS可以設定較高的權值，而對於處理能力較弱的RS可以設定較低的權值，這樣保證了處理能力強的伺服器處理更多的訪問流量。充分合理的利用了伺服器資源。同時，排程器還可以自動查詢RS的負載情況，並動態地調整其權值。
目標地址雜湊（Destination Hashing）
來自於同一個IP地址的請求都被重定向到同一臺Real Server上（保證目標地址不變）。
先根據請求的目標IP地址，作為雜湊鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且並未超載，將請求傳送到該伺服器，否則返回空。
源地址雜湊（Source Hashing）
Director必須確保響應的資料包必須通過請求資料包所經過的路由器或者防火牆（保證原地址不變）。
先根據請求的源IP地址，作為雜湊鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且並未超載，將請求傳送到該伺服器，否則返回空。它採用的雜湊函式與目標地址雜湊排程演算法的相同，它的演算法流程與目標地址雜湊排程演算法的基本相似。
使用SH演算法，SH演算法在核心中會自動維護一個雜湊表，此雜湊表中用每一個請求的源IP地址經過雜湊計算得出的值作為鍵，把請求所到達的RS的地址作為值。在後面的請求中，每一個請求會先經過此雜湊表，如果請求在此雜湊表中有鍵值，那麼直接定向至特定Real Server，如沒有，則會新生成一個鍵值，以便後續請求的定向。但是此種方法在時間的記錄上比較模糊（依據TCP的連線時長計算），而且其是演算法本身，所以無法與演算法分離，並不是特別理想的方法。
動態排程演算法
通過檢查伺服器上當前連線的活動狀態來重新決定下一步排程方式該如何實現。
最少連結（Least Connections）
“最少連線”排程演算法動態地將網路請求排程到已建立的連結數最少的伺服器上。如果集群系統的真實伺服器具有相近的系統性能，採用“最小連線”排程演算法可以較好地均衡負載。
演算法：連線數=活動連線數*256+非活動連線數
加權最少連結（Weighted Least Connections）
在最少連線的基礎上給每臺Real Server分配一個權重。
“加權最少連結”是“最少連線排程”的超集，每個服務節點可以用相應的權值表示其處理能力，而系統管理員可以動態的設定相應的權值，預設權值為1，加權最小連線排程在分配新連線請求時儘可能使服務節點的已建立連線數和其權值成正比。
演算法：連線數=（活動連線數*256+非活動連線數）÷權重
基於區域性性的最少連結（Locality-Based Least Connections）
針對請求報文的目標IP地址的負載均衡排程，簡稱LBLC。目前主要用於Cache集群系統，因為在Cache叢集客戶請求報文的目標IP地址是變化的。
這裡假設任何後端伺服器都可以處理任一請求，演算法的設計目標是在伺服器的負載基本平衡情況下，將相同目標IP地址的請求排程到同一臺伺服器，來提高各臺伺服器的訪問區域性性和Cache命中率，從而提升整個集群系統的處理能力。
先根據請求的目標IP地址找出該目標IP地址最近使用的伺服器，若該伺服器是可用的且沒有超載，將請求傳送到該伺服器；若伺服器不存在，或者該伺服器超載且有伺服器處於一半的工作負載，則使用'最少連線'的原則選出一個可用的伺服器，將請求傳送到伺服器。
帶複製的基於區域性性最少連結（Locality-Based Least Connections with Replication）
也是針對目標IP地址的負載均衡，目前主要用於Cache集群系統，它與LBLC不同之處是它要維護從一個目標IP地址到一組伺服器的對映，而LBLC演算法維護從一個目標IP地址到一臺伺服器的對映。
按'最小連線'原則從該伺服器組中選出一臺伺服器，若伺服器沒有超載，將請求傳送到該伺服器；若伺服器超載，則按'最小連線'原則從整個叢集中選出一臺伺服器，將該伺服器加入到這個伺服器組中，將請求傳送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除，以降低複製的程度
最短的期望的延遲（Shortest Expected Delay）
不再考慮非活動連線數
基於加權最少連結演算法，舉個例子，ABC三臺伺服器的權重分別為1、2、3 ，那麼如果使用加權最少連結的話一個新請求進入時它可能會分給ABC中的任意一個。
演算法：連線數=(活動連線數+1) *256 ÷權重
最少佇列排程（Never Queue）
對SED的改進，當新請求過來的時候不僅要取決於SED演算法所得到的值，還要取決於Real Server上是否有活動連線。
五.特點
優點：
- 抗負載能力強、是工作在網路4層之上僅作分發之用，沒有流量的產生，這個特點也決定了它在負載均衡軟體裡的效能最強的，對記憶體和cpu資源消耗比較低。
- 工作穩定，因為其本身抗負載能力很強，自身有完整的雙機熱備方案。
- 無流量，LVS只分發請求，而流量並不從它本身出去，這點保證了均衡器IO的效能不會受到大流量的影響。
- 工作在四層，可以對所有應用進行負載均衡，包括Web、資料庫等
缺點：
- 軟體本身不支援正則表示式處理，不能做動靜分離
- 如果是網站應用比較龐大，配置和測試就會很複雜，需要很長時間。
- 對網路依賴比較大，需要穩定的網路環境