lvs集群學習筆記之原理
lvs集群學習筆記之原理
集群 負載均衡 lvs 原理
什么是集群
集群（Cluster）：計算機集合為解決某個特定問題組合起來形成的單個系統(tǒng) 。
分為：
LB（Load Banlancing）：負載均衡 HA（High Availability）：高可用。提高服務可用性，避免出現單點故障 HP（High Performance）：高性能 分布式存儲與運算
什么是負載均衡
在現實情況中當我們遇到了單臺服務器性能不足的時候，這時我們有兩種提升方案：
Scale Up：向上擴展、垂直擴展、縱向擴展；用性能好的主機替代性能差的主機，性價比差； Scale Out: 向外擴展、水平擴展，即以新增服務器和現有服務器組成集群來應對性能不足的問題
在以上兩種解決方案中我們一般選擇向外擴展 因為：
向上擴展所付出的代價和得到性能的提升不成正比, 大多時候提升服務器一倍的性能需要花費三倍的價格 向外擴展也有很多問題, 例如：如何協調兩臺服務器提供一服務,用戶在兩臺服務器進行輪調時如何保存其的session信息
負載均衡或者負載均衡集群的作用就是將：
**向外擴張的服務器群組組成一個負載均衡集群，前端通過負載均衡調度器來對用戶請求通過調度算法合理分發(fā)到后端服務器中, 來達到負載均衡的目的.**
負載均衡解決方案
硬件解決方案： F5公司： BIG-IP Citrix公司： Netscaler A10公司： A10 Array Redware 軟件解決方案： 四層: LVS 七層: HAproxy, Nginx, Varnish....
lvs簡介
LVS(Linux Virtual Server)是目前阿里巴巴首席科學家章文嵩博士在大學期間的一款開源的負載均衡軟件, 可實現四層的負載均衡。 首先解釋下下文中出現的各種術語： Director: 負載均衡調度器, 負責在前端接受用戶請求根據特定的算法轉發(fā)到后端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事先定義，就會將請求報文直接截取下根據其特定的模型修改請求報文, 再轉發(fā)到POSTROUTING鏈上送出TCP/IP協議棧
其報文流經過程如下：
1.當客戶端的請求到達負載均衡器的內核空間時，首先會到達PREROUTING鏈。 2.當內核發(fā)現請求數據包的目的地址是本機時，將數據包送往INPUT鏈。 3.LVS由用戶空間的ipvsadm和內核空間的IPVS組成，ipvsadm用來定義規(guī)則，IPVS利用ipvsadm定義 的規(guī)則工作，IPVS工作在INPUT鏈上,當數據包到達INPUT鏈時，首先會被IPVS檢查，如果數據包里 面的目的地址及端口沒有在規(guī)則里面，那么這條數據包將被放行至用戶空間。 4.如果數據包里面的目的地址及端口在規(guī)則里面，那么這條數據報文將被修改目的地址為事先定義 好的后端服務器，并送往POSTROUTING鏈。 5.最后經由POSTROUTING鏈發(fā)往后端服務器。
lvs特點
lvs具有以下特點： 1、ipvs工作于netfilter框架上。 2、 規(guī)則： 簡單來說就是把ip加端口定義為ipvs集群服務，ipvs會為此請求定義一個或多個后端服務 目標地址未必會改，但是報文會被強行轉發(fā)給后端的服務器。 3、ipvs組件： ipvsadm（用戶空間，用來編寫規(guī)則） + ipvs（內核空間） 4、ipvs工作在第四層： （1）四層交換、四層路由。 做第四層轉發(fā)。（osi模型中的網絡層） （2）只能基于ip和port轉發(fā)，無法在應用層，session級別轉發(fā) （3） 不用到達應用層空間，就能轉發(fā) 即工作在第四層不能進行7層負載均衡，但基于4層可以不要管上層協議進行負載均衡，只要支持 tcp或udp就行。 5、 lvs 性能很好，但是由于只第四層，不能到用戶空間，因此不能進行更加精細的控制。 在精細控制方面，haproxy和Ngnix可以更好的實現。 6、lvs通常作為總入口，更精細化的切割可能使用，haproxy或者Nginx實現
lvs實現方式
lvs的實現方法為實現模型和負載均衡調度算法 實現模型為： 1、NAT 2、DR 3、TUN 4、FULLNAT 負載均衡調度算法分為兩種：靜態(tài)和動態(tài) 靜態(tài)： RR WRR SH DH 動態(tài)： LC WLC SED NQ LBLC LBLCR 這些后文會一一介紹。
lvs實現方式之nat模型
如圖實現過程如下：
1、客戶端將請求發(fā)往前端的負載均衡器，請求報文源地址是CIP(客戶端IP),后面統(tǒng)稱為CIP)，目標地址為VIP(負載均衡器前端地址，后面統(tǒng)稱為VIP)。2、負載均衡器收到報文后，發(fā)現請求的是在規(guī)則里面存在的地址，那么它將客戶端請求報文的目標地址改為了后端服務器的RIP地址并將報文根據算法發(fā)送出去。 3、報文送到Real Server后，由于報文的目標地址是自己，所以會響應該請求，并將響應報文返還給LVS。 4、然后lvs將此報文的源地址修改為本機并發(fā)送給客戶端。注意：在NAT模式中，Real Server的網關必須指向LVS，否則報文無法送達客戶端。 5、 NAT模型其實就是一個多路的DNAT,客戶端對VIP進行請求,Director通過事先指定好的調度算法計算出應該轉發(fā)到哪臺RS上, 并修改請求報文的目標地址為RIP,通過DIP送往RS. 當RS響應客戶端報文給CIP,經過Director時,Director又會修改源地址為VIP并將響應報文發(fā)給客戶端. 這段過程對于用戶來說是透明的.
關于nat模型有幾點需要注意： 1、RS和Director必須要在同一個IP網段中 2、RS的網關必須指向DIP 3、可以實現端口映射 4、請求報文和響應報文都會經過Director 5、RS可以是任意操作系統(tǒng) 6、DIP和RIP只能是內網IP
lvs實現方式之dr
如圖過程如下： 1、客戶端將請求發(fā)往前端的負載均衡器，請求報文源地址是CIP，目標地址為VIP。 2、負載均衡器收到報文后，發(fā)現請求的是在規(guī)則里面存在的地址，那么它將客戶端請求報文的源MAC地址改為自己DIP的MAC地址，目標MAC改為了RIP的MAC地址，并將此包發(fā)送給RS。 3、RS發(fā)現請求報文中的目的MAC是自己，就會將次報文接收下來，處理完請求報文后，將響應報文通過lo接口送給eth0網卡直接發(fā)送給客戶端。注意：需要設置lo接口的VIP不能響應本地網絡內的arp請求。 DR模型是一個較為復雜的模型. DR模型比較詭異, 因為VIP在Director和每一個RS上都存在, 客戶端對VIP(Director)請求時,Director接收到請求會將請求報文的源MAC地址和目標MAC地址修改為本機DIP所在網卡的MAC地址和指定的RS的RIP所在網卡的MAC地址, RS接收到請求報文后直接對CIP發(fā)出響應報文, 而不需要通過Director
實現DR模型有一個最為關鍵的問題,大家都知道Linux主機配置一個IP地址會向本網絡進行廣播來通告其他主機或網絡設備IP地址對應的MAC地址,那么VIP分別存在于Director和RS,IP不就沖突了么,我們該如何解決這個問題？
事實上LVS并不能幫助我們解決這個麻煩的問題:
我們有很多種方法可以解決上面的問題:
1、網絡設備中設置VIP地址和DIrector的MAC地址進行綁定
2、Linux系統(tǒng)中有一個軟件可以實現對ARP廣播進行過濾, arptables
3、可以修改內核參數來實現, arp_ignore, arp_announce
實現DR模型需要注意的:
1、RS和Director可以不在同一IP網段中, 但是一定要在同一物理網絡中
2、請求報文必須經過Director, 但是響應報文一定不能通過Director
3、RS的網關不能是Director
4、不能實現端口映射
5、RS可以是大部分操作系統(tǒng)
6、DIP和RIP可以是公網地址
lvs實現方式之tun
如圖tun工作流程如下： 1、客戶端將請求發(fā)往前端的負載均衡器，請求報文源地址是CIP，目標地址為VIP。 2、負載均衡器收到報文后，發(fā)現請求的是在規(guī)則里面存在的地址，那么它將在客戶端請求報文的首部再封裝一層IP報文,將源地址改為DIP，目標地址改為RIP,并將此包發(fā)送給RS。 3、RS收到請求報文后，會首先拆開第一層封裝,然后發(fā)現里面還有一層IP首部的目標地址是自己lo接口上的VIP，所以會處理次請求報文，并將響應報文通過lo接口送給eth0網卡直接發(fā)送給客戶端。注意：需要設置lo接口的VIP不能在共網上出現。 tun模型原理如下： TUN模型通過隧道的方式在公網中實現請求報文的轉發(fā),客戶端請求VIP(Director),Director不修改 請求報文的源IP和目標IP,而是在IP首部前附加DIP和對應RIP的地址并轉發(fā)到RIP上,RS收到請求報 文, 本地的接口上也有VIP, 遂直接響應報文給CIP。
需要注意的要點是： 1、RIP,DIP,VIP都是公網地址 2、RS的網關不能指向DIP 3、請求報文必須通過Director, 響應報文一定不能經過Director 4、不支持端口映射 5、RS的操作系統(tǒng)必須支持隧道功能
lvs實現方式之FULLNAT
FULLNAT實現原理: FULLNAT是近幾年才出現的,客戶端請求VIP(Director),Director修改請求報文的源地址(DIP)和目標地址(RIP)并轉發(fā)給RS, FULLNAT模型一般是Director和RS處在復雜的內網環(huán)境中的實現。 實現FULLNAT模型需要注意的: 1、VIP是公網地址, DIP和RIP是內網地址, 但是無需在同一網絡中 2、請求報文需要經過Director, 響應報文也要通過Director 3、RIP接收到的請求報文的源地址為DIP,目標地址為RIP 4、支持端口映射 5、RS可以是任意的操作系統(tǒng)
lvs之算法
lvs到底是根據什么來將請求負載均衡到real server上去的呢？
事實上lvs支持10中算法來決定如何將用戶請求調度到real server上去。
調度算法分為兩種：靜態(tài)算法和動態(tài)算法。
靜態(tài)調度算法: 根據算法本身進行調度, 不考慮RS的狀態(tài)
動態(tài)調度算法: 根據算法和RS的實時負載進行調度
靜態(tài)算法
①.RR：輪詢調度（Round Robin） 調度器通過”輪叫”調度算法將外部請求按順序輪流分配到集群中的真實服務器上，它均等地對待每一臺服務器，而不管服務器上實際的連接數和系統(tǒng)負載? ②.WRR：加權輪詢（Weight RR） 調度器通過“加權輪叫”調度算法根據真實服務器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的服務器處理更多的訪問流量。調度器可以自動問詢真實服務器的負載情況,并動態(tài)地調整其權值。 ③.DH：目標地址散列調度（Destination Hash ） 根據請求的目標IP地址，作為散列鍵(HashKey)從靜態(tài)分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發(fā)送到該服務器，否則返回空。 ④.SH：源地址 hash（Source Hash） 源地址散列”調度算法根據請求的源IP地址，作為散列鍵(HashKey)從靜態(tài)分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發(fā)送到該服務器，否則返回空?
動態(tài)算法
①.LC：最少鏈接（Least Connections） 調度器通過”最少連接”調度算法動態(tài)地將網絡請求調度到已建立的鏈接數最少的服務器上。如果集群系統(tǒng)的真實服務器具有相近的系統(tǒng)性能，采用”最小連接”調度算法可以較好地均衡負載。 ②.WLC：加權最少連接(默認采用的就是這種)（Weighted Least Connections） 在集群系統(tǒng)中的服務器性能差異較大的情況下，調度器采用“加權最少鏈接”調度算法優(yōu)化負載均衡性能，具有較高權值的服務器將承受較大比例的活動連接負載?調度器可以自動問詢真實服務器的負載情況,并動態(tài)地調整其權值。 ③.SED：最短延遲調度（Shortest Expected Delay ） 在WLC基礎上改進，Overhead = （ACTIVE+1）*256/加權，不再考慮非活動狀態(tài)，把當前處于活動狀態(tài)的數目+1來實現，數目最小的，接受下次請求，+1的目的是為了考慮加權的時候，非活動連接過多缺陷：當權限過大的時候，會倒置空閑服務器一直處于無連接狀態(tài)。 ④.NQ永不排隊/最少隊列調度（Never Queue Scheduling NQ） 無需隊列。如果有臺 realserver的連接數＝0就直接分配過去，不需要再進行sed運算，保證不會有一個主機很空間。在SED基礎上無論+幾，第二次一定給下一個，保證不會有一個主機不會很空閑著，不考慮非活動連接，才用NQ，SED要考慮活動狀態(tài)連接，對于DNS的UDP不需要考慮非活動連接，而httpd的處于保持狀態(tài)的服務就需要考慮非活動連接給服務器的壓力。 ⑤.LBLC：基于局部性的最少鏈接（locality-Based Least Connections） 基于局部性的最少鏈接”調度算法是針對目標IP地址的負載均衡，目前主要用于Cache集群系統(tǒng)?該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發(fā)送到該服務器;若服務器不存在，或者該服務器超載且有服務器處于一半的工作負載，則用“最少鏈接”的原則選出一個可用的服務器，將請求發(fā)送到該服務器? ⑥. LBLCR：帶復制的基于局部性最少連接（Locality-Based Least Connections with Replication） 帶復制的基于局部性最少鏈接”調度算法也是針對目標IP地址的負載均衡，目前主要用于Cache集群系統(tǒng)?它與LBLC算法的不同之處是它要維護從一個目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射?該算法根據請求的目標IP地址找出該目標IP地址對應的服務器組，按”最小連接”原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發(fā)送到該服務器；若服務器超載，則按“最小連接”原則從這個集群中選出一臺服務器，將該服務器加入到服務器組中，將請求發(fā)送到該服務器?同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低復制的程度。