LVS工做原理前端
負載調度器(Load Balancer),是整個集羣堆外面的前端機,負責將客戶的請求發送到一組服務器上執行,而客戶任務服務是來自一個IP地址(虛擬IP)是的。
服務器組(Server Arrary),是一組真正執行客戶請求的服務器(RealServer),可執行的服務有Web、Mail、Ftp等。
共享存儲(Share Storage),它爲服務器組提供一個共享的存儲區,這樣很容易使得服務器組擁有相同的內容,提供相同的服務。算法
LVS特色:數據庫
經過LVS提供的負載均衡技術和Linux操做系統實現一個高性能、高可用的服務器羣集,它具備良好可靠性、可擴展性和可操做性。從而以低廉的成本實現最優的服務性能。後端
LVS的主要特色有如下幾個方面:服務器
高併發鏈接:LVS基於內核網絡層面工做,有超強的承載能力和併發處理能力。單臺LVS負載均衡器,可支持上萬併發鏈接。穩定性強:是工做在網絡4層之上僅做分發之用,這個特色也決定了它在負載均衡軟件裏的性能最強,穩定性最好,對內存和cpu資源消耗極低。
成本低廉:硬件負載均衡器少則十幾萬,多則幾十萬上百萬,LVS只需一臺服務器和就能免費部署使用,性價比極高。
配置簡單:LVS配置很是簡單,僅需幾行命令便可完成配置,也可寫成腳本進行管理。
支持多種算法:支持多種論調算法,可根據業務場景靈活調配進行使用
支持多種工做模型:可根據業務場景,使用不一樣的工做模式來解決生產環境請求處理問題。
應用範圍廣:由於LVS工做在4層,因此它幾乎能夠對全部應用作負載均衡,包括http、數據庫、DNS、ftp服務等等
缺點:工做在4層,不支持7層規則修改,機制過於龐大,不適合小規模應用。
軟件自己不支持正則處理,不能作動靜分離網絡
1)IP負載均衡與負載調度算法併發
IP負載均衡技術
負載均衡技術有不少實現方案,有基於DNS域名輪流解析的方法、有基於客戶端調度訪問的方法、有基於應用層系統負載的調度方法,還有基於IP地址的調度方法,在這些負載調度
算法中,執行效率最高的是IP負載均衡技術。
LVS的IP負載均衡技術是經過IPVS模塊來實現的,IPVS是LVS集羣系統的核心軟件,它的主要做用是:安裝在Director Server上,同時在Director Server上虛擬出一個IP地址,用戶
必須經過這個虛擬的IP地址訪問服務。這個虛擬IP通常稱爲LVS的VIP,即Virtual IP。訪問的請求首先通過VIP到達負載調度器,而後由負載調度器從Real Server列表中選取一個服
務節點響應用戶的請求。
當用戶的請求到達負載調度器後,調度器如何將請求發送到提供服務的Real Server節點,而Real Server節點如何返回數據給用戶,是IPVS實現的重點技術,IPVS實現負載均衡機制
有三種,分別是NAT、TUN和DR、fullnat負載均衡
VS/NAT(Virtual Server via Network Address Translation,網絡地址翻轉技術實現虛擬服務器),當請求到來時,Director Server上處理的程序將數據報文中的目標地址(VIP)改爲具體的某臺Real Server,端口也改爲Real Server的端口,而後把報文發給Real Server。Real Server處理完數據後,須要返回給Director Server,而後Director Server將數據包中的源地址和源端口改爲VIP的地址和端口,最後把數據發送出去。由此能夠看出,用戶的請求和返回都要通過Director Server,若是數據過多,則Director Server 將不堪負重。tcp
VS/TUN(Virtual Server via IP Tunneling,IP隧道技術實現虛擬服務器) ,它跟VS/NAT基本同樣,但Real Server是直接返回數據給客戶端,不須要通過Director Server,這樣大大下降了Director Server的壓力。ide
VS/DR(Virtual Server via Direct Routing,直接路由技術實現虛擬服務器),它經過改寫請求報文的MAC地址,將請求發送到Real Server,而Real Server 將相應直接返回給客戶,免去了VS/TUN中的IP隧道開銷。這種是以上三種模式中性能最高最好的,但必需要求Director Server與Real Server都有一塊網卡鏈接在同一物理網段上。
三種工做模式的優缺點:
vs/NAT
優勢:集羣的物理服務器可使用任何支持TCP/IP操做系統,物理服務器能夠分配Internte的保留私有地址,只有Director Server須要一個合法的IP地址。
缺點:擴展性不足。當服Real Server增加到>=20臺時間,Director Server將成爲整個系統的瓶頸,由於全部的請求包和應答包都須要通過Director Server。
VS/TUN
優勢:Director Server只負責將請求包分發給物理服務器,而物理服務器將應該報直接發給用戶,因此Director Server處理巨大的請求包,這種模式一臺Director Server能爲超過100臺的服務器服務器服務,Director Server基本不成爲系統的瓶頸。 很是適合Internet(如Web,Webservice等)負載,由於通常它們的請求包很小,但應答包比較大。
缺點:這種方式須要全部服務器支持IP Tunneling(IP Encapsulation)協議。
VS/DR
優勢:和VS/TUN同樣,Director Server只負責分發請求, 應答包經過單獨的路由方法返回給客戶端。與VS/TUN相比,VS/DR不要隧道支持,由於可使用大多數的操做系統做爲物理服務器。
缺點:要求Director Server網卡必須與物理網卡在一個物理段上。
LVS的調度算法
LVS的調度算法分爲靜態與動態兩類。
1.靜態算法(4種):只根據算法進行調度 而不考慮後端服務器的實際鏈接狀況和負載狀況
①.RR:輪叫調度(Round Robin)
調度器經過」輪叫」調度算法將外部請求按順序輪流分配到集羣中的真實服務器上,它均等地對待每一臺服務器,而無論服務器上實際的鏈接數和系統負載。
②.WRR:加權輪叫(Weight RR)
調度器經過「加權輪叫」調度算法根據真實服務器的不一樣處理能力來調度訪問請求。這樣能夠保證處理能力強的服務器處理更多的訪問流量。調度器能夠自動問詢真實服務器的負載狀況,並動態地調整其權值。
③.DH:目標地址散列調度(Destination Hash )
根據請求的目標IP地址,做爲散列鍵(HashKey)從靜態分配的散列表找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,不然返回空。
④.SH:源地址 hash(Source Hash)
源地址散列」調度算法根據請求的源IP地址,做爲散列鍵(HashKey)從靜態分配的散列表找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,不然返回空。
2.動態算法(6種):前端的調度器會根據後端真實服務器的實際鏈接狀況來分配請求
①.LC:最少連接(Least Connections)
調度器經過」最少鏈接」調度算法動態地將網絡請求調度到已創建的連接數最少的服務器上。若是集羣系統的真實服務器具備相近的系統性能,採用」最小鏈接」調度算法能夠較好地均衡負載。
②.WLC:加權最少鏈接(默認採用的就是這種)(Weighted Least Connections)
在集羣系統中的服務器性能差別較大的狀況下,調度器採用「加權最少連接」調度算法優化負載均衡性能,具備較高權值的服務器將承受較大比例的活動鏈接負載。調度器能夠自動問詢真實服務器的負載狀況,並動態地調整其權值。
③.SED:最短延遲調度(Shortest Expected Delay )
在WLC基礎上改進,Overhead = (ACTIVE+1)*256/加權,再也不考慮非活動狀態,把當前處於活動狀態的數目+1來實現,數目最小的,接受下次請求,+1的目的是爲了考慮加權的時候,非活動鏈接過多缺陷:當權限過大的時候,會倒置空閒服務器一直處於無鏈接狀態。
④.NQ永不排隊/最少隊列調度(Never Queue Scheduling NQ)
無需隊列。若是有臺 realserver的鏈接數=0就直接分配過去,不須要再進行sed運算,保證不會有一個主機很空間。在SED基礎上不管+幾,第二次必定給下一個,保證不會有一個主機不會很空閒着,不考慮非活動鏈接,才用NQ,SED要考慮活動狀態鏈接,對於DNS的UDP不須要考慮非活動鏈接,而httpd的處於保持狀態的服務就須要考慮非活動鏈接給服務器的壓力。
⑤.LBLC:基於局部性的最少連接(locality-Based Least Connections)
基於局部性的最少連接」調度算法是針對目標IP地址的負載均衡,目前主要用於Cache集羣系統。該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器,若該服務器是可用的且沒有超載,將請求發送到該服務器;若服務器不存在,或者該服務器超載且有服務器處於一半的工做負載,則用「最少連接」的原則選出一個可用的服務器,將請求發送到該服務器。
⑥. LBLCR:帶複製的基於局部性最少鏈接(Locality-Based Least Connections with Replication)
帶複製的基於局部性最少連接」調度算法也是針對目標IP地址的負載均衡,目前主要用於Cache集羣系統。它與LBLC算法的不一樣之處是它要維護從一個目標IP地址到一組服務器的映射,而LBLC算法維護從一個目標IP地址到一臺服務器的映射。該算法根據請求的目標IP地址找出該目標IP地址對應的服務器組,按」最小鏈接」原則從服務器組中選出一臺服務器,若服務器沒有超載,將請求發送到該服務器;若服務器超載,則按「最小鏈接」原則從這個集羣中選出一臺服務器,將該服務器加入到服務器組中,將請求發送到該服務器。同時,當該服務器組有一段時間沒有被修改,將最忙的服務器從服務器組中刪除,以下降複製的程度。
##################################################################################################
健康檢查和失敗切換是keepalived的兩大核心功能。所謂的健康檢查,就是採用tcp三次握手,icmp請求,http請求,udp echo請求等方式對負載均衡器後面的實際的服務器(一般是承載真實業務的服務器)進行保活;而失敗切換主要是應用於配置了主備模式的負載均衡器,利用VRRP維持主備負載均衡器的心跳,當主負載均衡器出現問題時,由備負載均衡器承載對應的業務,從而在最大限度上減小流量損失,並提供服務的穩定性。
keepalived工做原理
keepalived主要有三個模塊,分別是core、check和vrrp。core模塊爲keepalived的核心,負責主進程的啓動、維護以及全局配置文件的加載和解析。check負責健康檢查,包括常見的各類檢查方式。vrrp模塊是來實現VRRP協議的。
Keepalived對服務器運行狀態和故障隔離的工做原理:
Keepalived起初是爲LVS設計的,專門用來監控集羣系統中各個服務節點的狀態,工做在TCP/IP參考模型的三層、四層、五層(物理層,鏈路層):
網絡層(3):Keepalived經過ICMP協議向服務器集羣中的每個節點發送一個ICMP數據包(有點相似與Ping的功能),若是某個節點沒有返回響應數據包,那麼認爲該節點發生了故障,Keepalived將報告這個節點失效,並從服務器集羣中剔除故障節點。
傳輸層(4):Keepalived在傳輸層裏利用了TCP協議的端口鏈接和掃描技術來判斷集羣節點的端口是否正常,好比對於常見的WEB服務器80端口。或者SSH服務22端口,Keepalived一旦在傳輸層探測到這些端口號沒有數據響應和數據返回,就認爲這些端口發生異常,而後強制將這些端口所對應的節點從服務器集羣中剔除掉。
應用層(5):,Keepalived的運行方式也更加全面化和複雜化,用戶能夠經過自定義Keepalived工做方式,例如:能夠經過編寫程序或者腳原本運行Keepalived,而Keepalived將根據用戶的設定參數檢測各類程序或者服務是否容許正常,若是Keepalived的檢測結果和用戶設定的不一致時,Keepalived將把對應的服務器從服務器集羣中剔除。
後來Keepalived又加入了VRRP的功能,VRRP(VritrualRouterRedundancyProtocol,虛擬路由冗餘協議)
虛擬路由冗餘協議,能夠認爲是實現路由器高可用的協議,即將N臺提供相同功能的路由器組成一個路由器組,這個組裏面有一個master和多個backup,master上面有一個對外提供服務的vip(該路由器所在局域網內其餘機器的默認路由爲該vip),master會發組播,當backup收不到vrrp包時就認爲master宕掉了,這時就須要根據VRRP的優先級來選舉一個backup當master。這樣的話就能夠保證路由器的高可用了。
VRRP使用選舉機制來肯定路由器的狀態,優先級選舉: 1.VRRP組中IP擁有者。若是虛擬IP地址與VRRP組中的某臺VRRP路由器IP地址相同,則此路由器爲IP地址擁有者,這臺路由器將被定位主路由器。 2.比較優先級。若是沒有IP地址擁有者,則比較路由器的優先級,優先級的範圍是0~255,優先級大的做爲主路由器 3.比較IP地址。在沒有Ip地址擁有者和優先級相同的狀況下,IP地址大的做爲主路由器。