LVS 相關理論知識

標籤：lvs 相關理論知識

LVS 介紹

LVS 是Linux Virtual Server 的簡寫，即linux虛擬伺服器，是一個虛擬伺服器叢集系統，可以在UNIX/LINUX平台下實現的負載平衡叢集功能，該項目在1998年5月由章文嵩博士組織成立，是中國國內最早出現的自然軟體之一。

官網：http://www.linuxvirtualserver.org/zh/

Linux虛擬伺服器，我們使用該軟體配置lvs時候，不能直接配置核心中的ipvs，而是需要使用ipvs的管理工具進行管理，當然，也可以通過keepalived等軟體直接管理ipvs，而不是通過ipvsadm來管理ipvs

ipvs的管理工具ipvsadm管理ipvs

LVS：

1.實現調度的工具IPVS

2.管理工具ipvsadm

3.keepalived實現管理及高可用

名稱解析

虛擬IP地址VIP           VIP為Director用於向用戶端電腦提供服務的IP地址（向外提供服務的IP）

Virtual ip Address

真實IP地址 RIP         在叢集下面節點使用的IP地址，物理伺服器IP地址。

Real Server Ip Address

Director的IP地址 DIP  Director用於串連外網的IP地址，物理網卡地址，是負載平衡伺服器上的IP

Director IP Address 

用戶端主機IP地址用戶端電腦請求叢集伺服器的IP地址，用做發送叢集的請求的源IP地址

Client IP Address 

LVS叢集內部的節點稱為只是伺服器RS，也叫叢集節點。

#######################################################

IP虛擬伺服器軟體IPVS

在調度器的實現技術中，IP負載平衡技術是效率最高的。在已有的IP負載平衡技術中有通過網路位址轉譯（Network Address Translation）將一組伺服器構成一個高效能的、高可用的虛擬伺服器，我們稱之為VS/NAT技術（Virtual Server via Network Address Translation），大多數商品化的IP負載平衡調度器產品都是使用此方法，如Cisco的LocalDirector、F5的Big/IP和 Alteon的ACEDirector。在分析VS/NAT的缺點和網路服務的非對稱性的基礎上，我們提出通過IP隧道實現虛擬伺服器的方法VS/TUN （Virtual Server via IP Tunneling），和通過直接路由實現虛擬伺服器的方法VS/DR（Virtual Server via Direct Routing），它們可以極大地提高系統的伸縮性。所以，IPVS軟體實現了這三種IP負載平衡技術，它們的大致原理如下，

###################################################

Virtual Server via Network Address Translation（VS/NAT）

通過網路位址轉譯，調度器重寫請求報文的目標地址，根據預設的調度演算法，將請求指派給後端的真實伺服器；真實伺服器的響應報文通過調度器時，報文的源地址被重寫，再返回給客戶，完成整個負載調度過程。

Virtual Server via IP Tunneling（VS/TUN）

採用NAT技術時，由於請求和響應報文都必須經過調度器地址修正，當客戶請求越來越多時，調度器的處理能力將成為瓶頸。為瞭解決這個問題，調度器把請求報 文通過IP隧道轉寄至真實伺服器，而真實伺服器將響應直接返回給客戶，所以調度器只處理請求報文。由於一般網路服務應答比請求報文大許多，採用 VS/TUN技術後，叢集系統的最大輸送量可以提高10倍。

Virtual Server via Direct Routing（VS/DR）

VS/DR通過改寫請求報文的MAC地址，將請求發送到真實伺服器，而真實伺服器將響應直接返回給客戶。同VS/TUN技術一樣，VS/DR技術可極大地 提高叢集系統的伸縮性。這種方法沒有IP隧道的開銷，對叢集中的真實伺服器也沒有必須支援IP隧道協議的要求，但是要求調度器與真實伺服器都有一塊網卡連 在同一物理網段上

##################################################################################

##################################################################################

NAT 模式

1、NAT技術將請求的報文DNAT和響應報文SNAT，通過調度器地址修正然後轉寄給內部的伺服器，報文返回時再改寫成原來的使用者請求地址。

2、只需要在調度器LB上配置WAN公網IP即可，調度器也要有私人LAN IP和內部RS節點通訊

3、每台內部RS節點的網關地址，必須要配置成調度器LB的私人LAN內物理網卡地址LDIP,這樣才能確保資料報文返回時仍舊經過調度器LB        重點

4、由於請求與響應的資料報文必須經過調度器LB，因此網站訪問量大時，調度器LB有較大的瓶頸，一般要求最多10-20台RS節點

5、NAT模式支援對IP及連接埠的轉換，即使用者請求10.0.0.1:80,可以通過調度器轉換到RS節點的172.16.0.1:8080(DR和TUN模式不具備這樣的功能)

6、所以的NAT內部RS節點只需要配置使用LAN IP即可

7、由於資料包來回都需要經過調度器，因此，要開啟核心轉寄net.ipv4.ip.forward=1,當然也包括iptables防火牆的forward功能，（DR和TUN模式不需要）

##################################################################################

FULLNAT 模式

1、請求到調度器的時候，不僅僅把目標的ip修改，還把源的ip也修改。連接埠是否發生改變根據實質情況，如果需要改連接埠，它也可以修改

##################################################################################

##################################################################################

DR模式

1、通過在調度器LB上修改資料包的目的MAC地址實現轉寄，注意，源IP地址仍是CIP,目的IP仍是VIP

2、請求的報文經過調度器，而RS響應處理後的報文無需經過調度器LB，因此，並發訪問量大時使用效率很高（和NAT模式對比）

3、因為DR模式是通過MAC地址的改寫機制實現的轉寄，因此，所以的RS節點和調度器LB只能在一個區域網路中（小缺點）

4、需要注意RS節點的VIP是綁定在lo介面上（lo：vip、lo1：vip）。以及ARP抑制問題，

5、強調：RS節點的預設閘道不需要是調度器LB的DIP，而直接是IDC機房分配的上級路由IP（這是RS帶有外網IP地址情況），理論上講，只要RS可以出網即可，不是必須要配置外網IP

6、由於DR模式的調度器僅僅進行了目的MAC地址的改寫，因此調度器LB無法改變請求報文的目的連接埠（和NAT模式的區別）

7、當前，調度器LB支援幾乎所有UNIX.LINUX系統，但是目前不支援window系統，但是真實伺服器RS可以是windows系統。

8、總的來說DR模式效率很高，但是配置也比較麻煩，因此，並發量不是特別大的公司，可以用haproxy/nginx取代，這符合營運的原則，簡單、易用、高效，在日PV在2千萬一些並發在1萬一下都可以考慮用haproxy、nginx或者LVS的NAT 模式

9、直接對外的訪問業務，例如：Web服務節點RS節點。RS最好有公網IP地址，如果不直接對外服務，例如：MySQL，儲存系統的RS節點，最好只用內部IP地址

##################################################################################

##################################################################################

TUN模式

1、負載平衡器通過該把請求報文通過IP隧道（ipip隧道）的方式（請求的報文不經過源目的地址的修改（包括MAC），而是直接封裝成另外一個報文）

 轉寄到真實的伺服器，而真實的伺服器將響應處理後直接返回給用戶端使用者

2、由於真實伺服器將響應後的報文直接返迴轉發給用戶端使用者，因此最好RS有一個外網IP地址，這樣效率才能更高，理論上，只要能出網即可，無需外網IP地址也可以

3、由於調度器LB只處理如站請求的報文，因此，此叢集系統的輸送量可以提供10倍以上，但是隧道模式也會帶來一定的系統開銷，TUN模式適合LAN/WAM.

4、TUN模式的LAN環境轉寄不如DR模式效率高，而且還要考慮系統對IP隧道的支援問題，

5、所有的RS伺服器要綁定VIP，抑制ARP轉寄，配置複製

6、LAN環境一般採用DR模式，WAN環境可以用TUN模式，但是當前在WAN環境下，請求轉寄更多的被haproxy、nginx、DNS調度等代理取代，要麼DNS調度，底層資料還可以同步

7、直接對外的訪問業務，例如：web服務做RS節點，最好用公網IP地址。不直接對外的業務.例如MySQL，儲存系統RS節點，最好用內部IP地址

##################################################################################

##################################################################################

調度演算法：

針對不同的網路服務需求和服 務器配置，IPVS調度器實現了如下八種負載調度演算法：

輪叫（Round Robin）

調度器通過"輪叫"調度演算法將外部請求按順序輪流分配到叢集中的真實伺服器上，它均等地對待每一台伺服器，而不管伺服器上實際的串連數和系統負載。

加權輪叫（Weighted Round Robin）

調度器通過"加權輪叫"調度演算法根據真實伺服器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的伺服器處理更多的訪問流量。調度器可以自動問詢真實伺服器的負載情況，並動態地調整其權值。

最少連結（Least Connections）

調度器通過"最少串連"調度演算法動態地將網路請求調度到已建立的連結數最少的伺服器上。如果叢集系統的真實伺服器具有相近的系統效能，採用"最小串連"調度演算法可以較好地均衡負載。

加權最少連結（Weighted Least Connections）

在叢集系統中的伺服器效能差異較大的情況下，調度器採用"加權最少連結"調度演算法最佳化負載平衡效能，具有較高權值的伺服器將承受較大比例的活動串連負載。調度器可以自動問詢真實伺服器的負載情況，並動態地調整其權值。

基於局部性的最少連結（Locality-Based Least Connections）

"基於局部性的最少連結" 調度演算法是針對目標IP地址的負載平衡，目前主要用於Cache叢集系統。該演算法根據請求的目標IP地址找出該目標IP地址最近使用的伺服器，若該伺服器 是可用的且沒有超載，將請求發送到該伺服器；若伺服器不存在，或者該伺服器超載且有伺服器處於一半的工作負載，則用"最少連結"的原則選出一個可用的服務 器，將請求發送到該伺服器。

帶複製的基於局部性最少連結（Locality-Based Least Connections with Replication）

"帶複製的基於局部性最少連結"調度演算法也是針對目標IP地址的負載平衡，目前主要用於Cache叢集系統。它與LBLC演算法的不同之處是它要維護從一個 目標IP地址到一組伺服器的映射，而LBLC演算法維護從一個目標IP地址到一台伺服器的映射。該演算法根據請求的目標IP地址找出該目標IP地址對應的服務 器組，按"最小串連"原則從伺服器組中選出一台伺服器，若伺服器沒有超載，將請求發送到該伺服器，若伺服器超載；則按"最小串連"原則從這個叢集中選出一 台伺服器，將該伺服器加入到伺服器組中，將請求發送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除，以降低複製的 程度。

目標地址散列（Destination Hashing）

"目標地址散列"調度演算法根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。

源地址散列（Source Hashing）

"源地址散列"調度演算法根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。

##################################################################################

##################################################################################

本文出自 “奮鬥吧” 部落格，請務必保留此出處http://lvnian.blog.51cto.com/7155281/1701986

LVS 相關理論知識