簡介
LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集群系統。本項目在1998年5月由章文嵩博士成立，是中國國內最早出現的自由軟件項目之一。
LVS是四層負載均衡，也就是說建立在OSI模型的第四層——傳輸層之上，傳輸層上有我們熟悉的TCP/UDP，LVS支持TCP/UDP的負載均衡
一 什么是負載均衡?
當單臺服務器性能不足時我們有兩種對其進行擴展的方式, 分別是向上擴展和向外擴展
向上擴展:
向上擴展意思是提升服務器的硬件性能來應對性能不足的問題
向外擴展：
向外擴展意思是新增服務器和現有服務器組成集群來應對性能不足的問題
在這兩種解決方案中, 我們一般情況下都選擇向外擴展
因為向上擴展所付出的代價和得到性能的提升不成正比, 大多時候提升服務器一倍的性能需要花費三倍的價格
向外擴展也有很多問題, 例如：如何協調兩臺服務器提供一服務, 用戶在兩臺服務器進行輪調時如何保存其的session信息….
我們可以將向外擴展數臺服務器組成一個負載均衡集群, 前端通過負載均衡調度器來對用戶請求通過調度算法合理分發到后端服務器中, 來達到負載均衡的目的.
負載均衡有軟件和硬件的實現方式
硬件：F5 BIG IP, NetScaler
軟件:
傳輸層: LVS
應用層: HAproxy, Nginx, Varnish, Perlbal….
二 LVS架構
為了更好地理解LVS, 先解釋一下相應的術語:
Director: 負載均衡調度器, 負責在前端接受用戶請求根據特定的算法轉發到后端Real Server
Real Server: 后端提供服務的服務器
VIP: Director接受用戶請求的IP地址
DIP: Director和Real Server聯系的IP地址
RIP: Real Server的IP地址
CIP: Client IP, 客戶端的IP地址
LVS其實由兩個組件組成, 在用戶空間的ipvsadm和內核空間的ipvs, ipvs工作在INPUT鏈上, 如果有請求報文被ipvs事先定義，就會將請求報文直接截取下根據其特定的模型修改請求報文, 再轉發到POSTROUTING鏈上送出TCP/IP協議棧
1.當客戶端的請求到達負載均衡器的內核空間時，首先會到達PREROUTING鏈。
2.當內核發現請求數據包的目的地址是本機時，將數據包送往INPUT鏈。
3.LVS由用戶空間的ipvsadm和內核空間的IPVS組成，ipvsadm用來定義規則，IPVS利用ipvsadm定義的規則工作，IPVS工作在INPUT鏈上,當數據包到達INPUT鏈時，首先會被IPVS檢查，如果數據包里面的目的地址及端口沒有在規則里面，那么這條數據包將被放行至用戶空間。
4.如果數據包里面的目的地址及端口在規則里面，那么這條數據報文將被修改目的地址為事先定義好的后端服務器，并送往POSTROUTING鏈。
5.最后經由POSTROUTING鏈發往后端服務器。
三 LVS 工作模型
LVS為了在不同場景中使用而提供了4種實現模型: 分別為NAT, DR, TUN, FULLNAT.
1. NAT模型實現原理
a) 客戶端將請求發往前端的負載均衡器，請求報文源地址是CIP，目標地址為VIP(負載均衡器前端地址)。
b) 負載均衡器收到報文后，發現請求的是在規則里面存在的地址，那么它將客戶端請求報文的目標地址改為了后端服務器的RIP地址并將報文根據算法發送出去。
c) 報文送到Real Server后，由于報文的目標地址是自己，所以會響應該請求，并將響應報文返還給LVS。
d) 然后lvs將此報文的源地址修改vip地址并發送給客戶端。
實現NAT模型有幾點需要注意的:
(1) RS應該和DIP應該使用私網地址，且RS的網關要指向DIP；
(2) 請求和響應報文都要經由director轉發；極高負載的場景中，director可能會成為系統瓶頸；
(3) 支持端口映射；
(4) RS可以使用任意OS；
(5) RS的RIP和Director的DIP必須在同一IP網絡；
2. DR模型實現原理
a) 客戶端將請求發往前端的負載均衡器，請求報文源地址是CIP，目標地址為VIP。
b) 負載均衡器收到報文后，發現請求的是在規則里面存在的地址，那么它將客戶端請求報文的源MAC地址改為自己DIP的MAC地址，目標MAC改為了RIP的MAC地址，并將此包發送給RS。
c) RS發現請求報文中的目的MAC是自己，就會將次報文接收下來，處理完請求報文后，將響應報文通過lo接口送給eth0網卡直接發送給客戶端。注意：需要設置lo接口的VIP不能響應本地網絡內的arp請求。
實現DR模型有一個最為關鍵的問題, 大家都知道Linux主機配置一個IP地址會向本網絡進行廣播來通告其他主機或網絡設備IP地址對應的MAC地址, 那么VIP分別存在于Director和RS, IP不就沖突了么, 我們該如何解決這個問題？
事實上LVS并不能幫助我們解決這個麻煩的問題:
我們有多種方法可以解決上面的問題:
(1) 網絡設備中設置VIP地址和DIrector的MAC地址進行綁定
(2) Linux系統中有一個軟件可以實現對ARP廣播進行過濾, arptables
(3) 可以修改內核參數來實現, arp_ignore, arp_announce
實現DR模型需要注意的:
(1) 保證前端路由器將目標IP為VIP的請求報文發送給director;
(2) RS的RIP可以使用私有地址；但也可以使用公網地址；
(3) RS跟Director必須在同一物理網絡中；
(4) 請求報文經由Director調度，但響應報文一定不能經由Director；
(5) 不支持端口映射；
(6) RS可以大多數OS；
(7) RS的網關不能指向DIP；
3. TUN模型實現原理
TUN模型通過隧道的方式在公網中實現請求報文的轉發, 客戶端請求VIP(Director), Director不修改請求報文的源IP和目標IP, 而是在IP首部前附加DIP和對應RIP的地址并轉發到RIP上, RS收到請求報文, 本地的接口上也有VIP, 遂直接響應報文給CIP
TUN的工作流程:
a) 客戶端將請求發往前端的負載均衡器，請求報文源地址是CIP，目標地址為VIP。
b) 負載均衡器收到報文后，發現請求的是在規則里面存在的地址，那么它將在客戶端請求報文的首部再封裝一層IP報文,將源地址改為DIP，目標地址改為RIP,并將此包發送給RS。
c) RS收到請求報文后，會首先拆開第一層封裝,然后發現里面還有一層IP首部的目標地址是自己lo接口上的VIP，所以會處理請求報文，并將響應報文通過lo接口送給eth0網卡直接發送給客戶端。
實現TUN模型需要注意的:
(1) RIP, DIP, VIP全得是公網地址；
(2) RS的網關的不能指向DIP；
(3) 請求報文必須經由director調度，但響應報文必須不能經由director；
(4) 不支持端口映射；
(5) RS的OS必須支持隧道功能；
4. FULLNAT.模型實現原理
FULLNAT是近幾年才出現的, 客戶端請求VIP(Director), Director修改請求報文的源地址(DIP)和目標地址(RIP)并轉發給RS, FULLNAT模型一般是Director和RS處在復雜的內網環境中的實現
FULLNAT工作流程:
a) 客戶端請求VIP
b) Director接受到請求, 通過調度算法得出轉發的RS, 將源地址修改為DIP, 目標地址修改為對應RIP, 轉發給RS
c) RS接受到請求后, 響應請求給DIP, DIP將響應報文源地址改為VIP, 目標地址改為CIP, 響應給CIP
實現FULLNAT模型需要注意的:
(1) VIP是公網地址；RIP和DIP是私網地址，二者無須在同一網絡中；
(2) RS接收到的請求報文的源地址為DIP，因此要響應給DIP；
(3) 請求報文和響應報文都必須經由Director;
(4) 支持端口映射機制；
(5) RS可以使用任意OS；
四 LVS的調度算法
1. 靜態調度算法(4種)：
1) RR：Round Robin, 輪詢 將用戶請求輪詢到各個RS上
2) WRR: Weighted Round Robin, 加權輪輪詢, 根據每一臺RS的權重將用戶請求輪詢分發到各個RS上
3) SH: Source Hash, 源地址哈希， 將同一客戶端的請求轉發到同一個RS上
4) DH: Destination Hash, 將同一類型的請求轉發到同一個RS上
2. 動態調度算法(6種):
1) LC：least connections, 根據最少連接數調度. 公式: Active*256+Inactive
2) WLC：Weighted Least Connections, 加權最少連接數調度. 公式: (Active*256+Inactive)/Weighted
3) SED：Shortest Expection Delay, 最短延遲預期. 公式: (Active+1)*256/Weighted
4) NQ：Never Queue, 永不排隊, 對SED算法的改進
5) LBLC：Locality-Based Least-Connections, 基于局部的最少鏈接, 即為動態的dh算法
6) LBLCR：locality-based least-connections replication, 帶復制功能的lblc
原創文章，作者：liangkai，如若轉載，請注明出處：http://www.www58058.com/62669
