LVS專題: LVS的工作模型和調度算法介紹
LVS專題: LVS的工作模型和調度算法介紹
靜態調度算法(4種)
動態調度算法(6種):
NAT實現原理:
DR實現原理:
TUN實現原理：
FULLNAT實現原理:
前言
什麼是負載均衡?
什麼是LVS?
LVS的架構:
LVS的實現模型:
LVS的調度算法
總結
前言
本文大概介紹一下LVS的工作方式和實現的模型以及調度算法,流程圖方面只上了兩張圖, 如果有需要LVS各工作模式的流程圖請看張小凡:LVS原理詳解
什麼是負載均衡?
當單臺服務器性能不足時我們有兩種對其進行擴展的方式, 分別是向上擴展和向外擴展 向上擴展:
向上擴展意思是提升服務器的硬件性能來應對性能不足的問題
向外擴展：
向外擴展意思是新增服務器和現有服務器組成集羣來應對性能不足的問題
在這兩種解決方案中, 我們一般情況下都選擇向外擴展,
因爲向上擴展所付出的代價和得到性能的提升不成正比, 大多時候提升服務器一倍的性能需要花費三倍的價格
向外擴展也有很多問題, 例如：如何協調兩臺服務器提供一服務, 用戶在兩臺服務器進行輪調時如何保存其的session信息….
我們可以將向外擴展數臺服務器組成一個負載均衡集羣, 前端通過負載均衡調度器來對用戶請求通過調度算法合理分發到後端服務器中, 來達到負載均衡的目的.
負載均衡有軟件和硬件的實現方式
硬件：F5 BIG IP, NetScaler
軟件:
四層: LVS
七層: HAproxy, Nginx, Varnish....
什麼是LVS?
LVS(Linux Virtual Server)是目前阿里巴巴首席科學家章文嵩博士在大學期間的一款開源的負載均衡軟件, 可實現四層的負載均衡。
爲了更好地理解LVS, 我們解釋一下相應的術語:
Director: 負載均衡調度器, 負責在前端接受用戶請求根據特定的算法轉發到後端Real Server
Real Server: 後端提供服務的服務器
VIP: Director接受用戶請求的IP地址
DIP: Director和Real Server聯繫的IP地址
RIP: Real Server的IP地址
CIP: Client IP, 客戶端的IP地址
LVS的架構:
LVS其實由兩個組件組成, 在用戶空間的ipvsadm和內核空間的ipvs, ipvs工作在INPUT鏈上, 如果有請求報文被ipvs事先定義，就會將請求報文直接截取下根據其特定的模型修改請求報文, 再轉發到POSTROUTING鏈上送出TCP/IP協議棧
其實ipvs提供了一個API, 即使我們不使用ipvsadm這個命令行工具, 也可以使用其他工具對其規則進行定義.
LVS的實現模型:
LVS爲了在不同場景中使用而提供了4種實現模型: 分別爲
NAT, DR, TUN, FULLNAT. 我們分別對其進行介紹:
NAT實現原理:
NAT模型其實就是一個多路的DNAT, 客戶端對VIP進行請求, Director通過事先指定好的調度算法計算出應該轉發到哪臺RS上, 並修改請求報文的目標地址爲RIP,通過DIP送往RS. 當RS響應客戶端報文給CIP, 經過Director時, Director又會修改源地址爲VIP並將響應報文發給客戶端. 這段過程對於用戶來說是透明的.
NAT模型工作流程
1、客戶端請求VIP
2、Director接受到請求, 根據調度算法得出該轉發的RS, 將請求報文的目標IP地址修改成對應RS的IP地址並轉發
3、RS接收並響應請求給CIP, 經過Director時, 源地址被修改成VIP地址
實現NAT模型有幾點需要注意的:
1、RS和Director必須要在同一個IP網段中
2、RS的網關必須指向DIP
3、可以實現端口映射
4、請求報文和響應報文都會經過Director
5、RS可以是任意操作系統
6、DIP和RIP只能是內網IP
DR實現原理:
DR模型是一個較爲複雜的模型. DR模型比較詭異, 因爲VIP在Director和每一個RS上都存在, 客戶端對VIP(Director)請求時, Director接收到請求, 會將請求報文的源MAC地址和目標MAC地址修改爲本機DIP所在網卡的MAC地址和指定的RS的RIP所在網卡的MAC地址, RS接收到請求報文後直接對CIP發出響應報文, 而不需要通過Director
DR模型工作流程
1、客戶端請求VIP
2、Director接收到請求報文, 修改請求報文的源MAC地址和目標MAC地址, 使用DIP所在網卡發送給調度算法得出的RIP
3、RIP接收到DIP發過來的報文後, 發現本機的確有VIP, 遂響應報文給CIP
可能很多朋友還聽不明白, 所以我們提供了LVS-DR WORK_FLOW便於大家理解
實現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、RS和Director可以不在同一IP網段中, 但是一定要在同一物理網絡中
2、請求報文必須經過Director, 但是響應報文一定不能通過Director
3、RS的網關不能是Director
4、不能實現端口映射
5、RS可以是大部分操作系統
6、DIP和RIP可以是公網地址
TUN實現原理：
TUN模型通過隧道的方式在公網中實現請求報文的轉發, 客戶端請求VIP(Director), Director不修改請求報文的源IP和目標IP, 而是在IP首部前附加DIP和對應RIP的地址並轉發到RIP上, RS收到請求報文, 本地的接口上也有VIP, 遂直接響應報文給CIP
TUN的工作流程
1、客戶端請求VIP
2、Director接收到請求, 通過調度算法得出轉發的RS,將請求報文的IP首部外附加DIP和對應RS的IP地址，發給對應RS
3、RS接收到請求, 發現本機的確有VIP地址, 遂響應報文給CIP
實現TUN模型需要注意的:
1、RIP,DIP,VIP都是公網地址
2、RS的網關不能指向DIP
3、請求報文必須通過Director, 響應報文一定不能經過Director
4、不支持端口映射
5、RS的操作系統必須支持隧道功能
FULLNAT實現原理:
FULLNAT是近幾年纔出現的, 客戶端請求VIP(Director), Director修改請求報文的源地址(DIP)和目標地址(RIP)並轉發給RS, FULLNAT模型一般是Director和RS處在複雜的內網環境中的實現
FULLNAT工作流程
1、客戶端請求VIP
2、Director接受到請求, 通過調度算法得出轉發的RS, 將源地址修改爲DIP, 目標地址修改爲對應RIP, 轉發給RS
3、RS接受到請求後, 響應請求給DIP, DIP將響應報文源地址改爲VIP, 目標地址改爲CIP, 響應給CIP
實現FULLNAT模型需要注意的:
1、VIP是公網地址, DIP和RIP是內網地址, 但是無需在同一網絡中
2、請求報文需要經過Director, 響應報文也要通過Director
3、RIP接收到的請求報文的源地址爲DIP,目標地址爲RIP
4、支持端口映射
5、RS可以是任意的操作系統
LVS的調度算法
lvs主要功能將用戶請求轉發到後端的服務器, 但是Director根據什麼來轉發到哪個RS上呢？事實上LVS支持10種調度算法計算該將用戶請求調度到哪一臺RS上.
調度算法分爲兩種: 靜態和動態
靜態調度算法: 根據算法本身進行調度, 不考慮RS的狀態
動態調度算法: 根據算法和RS的實時負載進行調度
靜態調度算法(4種)
RR：Round Robin, 輪詢 將用戶請求輪詢到各個RS上
WRR: Weighted Round Robin, 加權輪輪詢, 根據每一臺RS的權重將用戶請求輪詢分發到各個RS上
SH: Source Hash, 源地址哈希， 將同一客戶端的請求轉發到同一個RS上
DH: Destination Hash, 將同一類型的請求轉發到同一個RS上
動態調度算法(6種):
LC：least connections, 最小連接. 公式: Active*256+Inactive
WLC：Weighted Least Connections, 加權最小連接. 公式: (Active*256+Inactive)/Weighted
SED：Shortest Expection Delay, 最短延遲預期. 公式: (Active+1)*256/Weighted
NQ：Never Queue, 永不排隊, 對sed算法的改進
LBLC：Locality-Based Least-Connections, 基於局部的最少鏈接, 即爲動態的dh算法
LBLCR：locality-based least-connections replication, 帶複製功能的lblc
本文出自 “The AnyISalIn blog” 博客，請務必保留此出處http://anyisalin.blog.51cto.com/10917514/1760562