??? LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務(wù)器，是一個虛擬的服務(wù)器集群系統(tǒng)。本項目在1998年5月由章文嵩博士成立，是中國國內(nèi)最早出現(xiàn)的自由軟件項目之一。

LVS為了在不同場景中使用而提供了4種實現(xiàn)模型: 分別為
??? NAT???????? -m?
??? DR????????? -g?
??? Tunnel????? -i?
??? FULLNAT???? -b?
???
LVS的用到幾個IP縮寫
??? CIP: 用戶的IP
??? VIP: LVS虛擬的IP，用于用戶訪問
??? DIP: LVS Director調(diào)度器自已的IP
??? RID: Real server 的IP
??? LIP: LVS Director調(diào)度器指定的local address，FULLNAT模式下專用的

NAT模型工作流程
??? 1、客戶端請求VIP(Virtual IP Address)
??? 2、Director接受到請求, 根據(jù)連接調(diào)度算法從一組真實服務(wù)器中選出一臺服務(wù)器, 將報文的目標(biāo)地址VIP(Virtual IP Address)改寫成選定服務(wù)器的地址，報文的目標(biāo)端口改寫成選定服務(wù)器的相應(yīng)端口，最后將修改后的報文發(fā)送給選出的服務(wù)器。
??? 3、調(diào)度器在連接Hash 表中記錄這個連接，當(dāng)這個連接的下一個報文到達(dá)時，從連接Hash表中可以得?到原選定服務(wù)器的地址和端口，進(jìn)行同樣的改寫操作，并將報文傳給原選定的服務(wù) 器。當(dāng)來自真實服務(wù)器的響應(yīng)報文經(jīng)過調(diào)度器時，調(diào)度器將報文的源地址和源端口改為Virtual IP Address和相應(yīng)的端口，再把報文發(fā)給用戶

??? 不同的報文會使得連接處于不同的狀態(tài)，不同的狀態(tài)有不同的超時值。在TCP 連接中，根據(jù)標(biāo)準(zhǔn)的TCP有限狀態(tài)機進(jìn)行狀態(tài)遷移；在UDP中，只設(shè)置一個UDP狀態(tài)。
不同狀態(tài)的超時值是可以設(shè)置的，在缺省情況下：
??? SYN狀態(tài)的超 時為1分鐘
??? ESTABLISHED狀態(tài)的超時為15分鐘
??? FIN狀態(tài)的超時為1分鐘
??? UDP狀態(tài)的超時為5分鐘
??? 當(dāng)連接終止或超時，調(diào)度器將這個連接從 連接Hash表中刪除。

實現(xiàn)NAT模型有幾點需要注意的:
??? 1、RS和Director可以不在同一IP網(wǎng)段中
??? 2、可以實現(xiàn)端口映射
??? 3、請求報文和響應(yīng)報文都必須經(jīng)過Director
???
??? 在一些網(wǎng)絡(luò)服務(wù)中，它們將IP地址或者端口號在報文的數(shù)據(jù)中傳送，若只對報文頭的IP地址和端口號作轉(zhuǎn)換，這樣就會出現(xiàn)不一致性，服務(wù)會中斷。 所以，針對這些服務(wù)，需要編寫相應(yīng)的應(yīng)用模塊來轉(zhuǎn)換報文數(shù)據(jù)中的IP地址或者端口號?，F(xiàn)已經(jīng)知道有這個問題的網(wǎng)絡(luò)服務(wù)有FTP、IRC、H.323、 CUSeeMe、Real Audio、Real Video、Vxtreme/Vosiac、VDOLive、VIVOActive、True Speech、RSTP、PPTP、StreamWorks、NTT AudioLink、NTT SoftwareVision、Yamaha MIDPlug、iChat Pager、Quake和Diablo。

DR模型工作流程
??? 1、客戶端請求VIP
??? 2、Director接收到請求報文,不修改也不封裝IP報文,而是將數(shù)據(jù)幀的MAC地址改為選出服務(wù)器的 MAC地址，再將修改后的數(shù)據(jù)幀在與服務(wù)器組的局域網(wǎng)上發(fā)送。因為數(shù)據(jù)幀的MAC地址是選出的服務(wù)器，所以交換機會將數(shù)據(jù)幀發(fā)送給選出的服務(wù)器，服務(wù)器從中可以獲得該IP報文。
??? 3、RIP接收到DIP發(fā)過來的報文后,發(fā)現(xiàn)報文的目標(biāo)地址VIP是在本地的網(wǎng)絡(luò)設(shè)備上,服務(wù)器處理這個報文，然后根據(jù)路由表將響應(yīng)報文直接返回給客戶。

因為VIP分別存在于Director和RS,造成IP沖突，解決方法：
??? 1、網(wǎng)絡(luò)設(shè)備中設(shè)置VIP地址和DIrector的MAC地址進(jìn)行綁定
??? 2、Linux系統(tǒng)中有一個軟件可以實現(xiàn)對ARP廣播進(jìn)行過濾, arptables
??? 3、可以修改內(nèi)核參數(shù)來實現(xiàn), arp_ignore, arp_announce

實現(xiàn)DR模型需要注意的:
??? 1、RS和Director必須要在同一個二層網(wǎng)段中，中間沒有隔有路由器(MAC地址無法穿越三層設(shè)備)
??? 2、請求報文必須經(jīng)過Director, 但是響應(yīng)報文一定不能通過Director
??? 3、不能實現(xiàn)端口映射

三種IP負(fù)載均衡技術(shù)的優(yōu)缺點歸納在下表中：
??????????????????? VS/NAT????????? VS/TUN????????? VS/DR
Server????????????? any???????????? Tunneling?????? Non-arp device
server network????? private???????? LAN/WAN???????? LAN
server number?????? low (10~20)???? High (100)????? High (100)
server gateway????? load balancer?? own router????? Own router

以上三種方法所能支持最大服務(wù)器數(shù)目的估計是假設(shè)調(diào)度器使用100M網(wǎng)卡，調(diào)度器的硬件配置與后端服務(wù)器的硬件配置相同，而且是對一般Web服 務(wù)。使用更高的硬件配置（如千兆網(wǎng)卡和更快的處理器）作為調(diào)度器，調(diào)度器所能調(diào)度的服務(wù)器數(shù)量會相應(yīng)增加。當(dāng)應(yīng)用不同時，服務(wù)器的數(shù)目也會相應(yīng)地改變。所 以，以上數(shù)據(jù)估計主要是為三種方法的伸縮性進(jìn)行量化比較。
???

FULLNAT工作流程
??? 1、引入LIP(local address)，可以配置多個，也可以使用DIP
??? 2、客戶端請求VIP
??? 3、Director接受到請求,根據(jù)調(diào)度算法得出轉(zhuǎn)發(fā)的RS, 將CIP修改為LIP, VIP修改為對應(yīng)RIP, 轉(zhuǎn)發(fā)給RS
??? 4、RS接受到請求后, 響應(yīng)請求給LIP, Director將響應(yīng)報文RIP改為VIP, LIP改為CIP, 響應(yīng)給用戶
???
實現(xiàn)FULLNAT模型需要注意的:
??? 1、請求報文和響應(yīng)報都要通過Director
??? 2、RIP接收到的請求報文的源地址為LIP,目標(biāo)地址為RIP
??? 3、支持端口映射
??? 4、為了保證應(yīng)用透明性，通過tcp option傳遞client ip給RealServer(TOA).要RS讀取數(shù)據(jù)包中的tcp option來記錄client ip
??? 5、和NAT比，正常轉(zhuǎn)發(fā)性能下降<10%

LVS的調(diào)度算法

??? IPVS在內(nèi)核中的負(fù)載均衡調(diào)度是以連接為粒度的。在HTTP協(xié)議（非持久）中，每個對象從WEB服務(wù)器上獲取都需要建立一個TCP連接，同一用戶 的不同請求會被調(diào)度到不同的服務(wù)器上，所以這種細(xì)粒度的調(diào)度在一定程度上可以避免單個用戶訪問的突發(fā)性引起服務(wù)器間的負(fù)載不平衡。

??? RR：Round Robin, 輪詢 將用戶請求輪詢到各個RS上
??? WRR: Weighted Round Robin, 加權(quán)輪輪詢, 根據(jù)每一臺RS的權(quán)重將用戶請求輪詢分發(fā)到各個RS上
??? SH: Source Hash, 源地址哈希， 將同一客戶端的請求轉(zhuǎn)發(fā)到同一個RS上
??? DH: Destination Hash, 將同一類型的請求轉(zhuǎn)發(fā)到同一個RS上

??? LC：least connections, 最小連接. 公式: Active*256+Inactive
??? WLC：Weighted Least Connections, 加權(quán)最小連接. 公式: (Active*256+Inactive)/Weighted
??? SED：Shortest Expection Delay, 最短延遲預(yù)期. 公式: (Active+1)*256/Weighted
??? NQ：Never Queue, 永不排隊, 對sed算法的改進(jìn)
??? LBLC：Locality-Based Least-Connections, 基于局部的最少鏈接, 即為動態(tài)的dh算法
??? LBLCR：locality-based least-connections replication, 帶復(fù)制功能的lblc

Hash表
??? LVS的調(diào)優(yōu)建議將hash table的值設(shè)置為不低于并發(fā)連接數(shù)。例如，并發(fā)連接數(shù)為200，Persistent時間為200S，那么hash桶的個數(shù)應(yīng)設(shè)置為盡可能接近200x200=40000，2的15次方為32768就可以了。當(dāng)ip_vs_conn_tab_bits=20 時，哈希表的的大小（條目）為 pow(2,20)，即 1048576，對于64位系統(tǒng)，IPVS占用大概16M內(nèi)存，可以通過demsg看到：IPVS: Connection hash table configured (size=1048576, memory=16384Kbytes)。對于現(xiàn)在的服務(wù)器來說，這樣的內(nèi)存占用不是問題。所以直接設(shè)置為20即可。

??? 關(guān)于最大“連接數(shù)限制”：這里的hash桶的個數(shù)，并不是LVS最大連接數(shù)限制。LVS使用哈希鏈表解決“哈希沖突”，當(dāng)連接數(shù)大于這個值時，必然會出現(xiàn)哈稀沖突，會（稍微）降低性能，但是并不對在功能上對LVS造成影響。

??? 關(guān)于連接占用內(nèi)存：
每條記錄用一個ip_vs_conn結(jié)構(gòu)表示，這個結(jié)構(gòu)使用了Linux里面的典型數(shù)據(jù)結(jié)構(gòu)struct list_head構(gòu)造雙向鏈表，使得所有的記錄以鏈表形式鏈接起來。
* struct ip_vs_conn 里面的其他元素就是每個連接的具體信息，在32位系統(tǒng)上為128字節(jié),64位系統(tǒng)上為192字節(jié) 。
* struct list_head 在32位系統(tǒng)上為8字節(jié)，在64位系統(tǒng)上為16字節(jié)。
??? 所以，hash表里面的每條記錄(每個連接)，在32位系統(tǒng)上占據(jù)136字節(jié)內(nèi)存，在64位系統(tǒng)上占用208字節(jié)。

調(diào)整 ip_vs_conn_tab_bits的方法

ipvsadm?-l

如果顯示IP Virtual Server version 1.2.1 (size=4096),則ip_vs conn_tab_bits為默認(rèn)的12

在/etc/modprobe.d/目錄下添加文件ip_vs.conf，內(nèi)容為：

options?ip_vs?conn_tab_bits=20modprobe?-r?ip_vs modprobe?ip_vs

重新查看
IP Virtual Server version 1.2.1 (size=1048576)

假如沒有變化，則需要重新調(diào)內(nèi)核整編譯選項，重新編譯內(nèi)核。

參考：
http://zh.linuxvirtualserver.org/node/2580
http://zh.linuxvirtualserver.org/files/LVS%E6%89%8B%E5%86%8C%E4%B8%AD%E6%96%87%E5%8A%A0%E7%9B%AE%E5%BD%95%E7%89%88.doc

轉(zhuǎn)載于:https://blog.51cto.com/1step/1763704

總結(jié)

以上是生活随笔為你收集整理的LVS总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。