一. 集群的概念
服務器集群簡稱集群是一種服務器系統,它通過一組松散集成的服務器軟件和/或硬件連接起來高度緊密地協作完成計算工作。在某種意義上,他們可以被看作是一臺服務器。
集群系統中的單個服務器通常稱為節點,通常通過局域網連接,但也有其它的可能連接方式。集群服務器通常用來改進單個服務器的計算速度和/或可靠性。一般情況下集群
服務器比單個服務器,比如工作站或超級服務器性能價格比要高得多。集群就是一組獨立的服務器,通過網絡連接組合成一個組合來共同完一個任務。
說的直白點,集群就是一組相互獨立的服務器,通過高速的網絡組成一個服務器系統,每個集群節點都是運行其自己進程的一個獨立服務器。對網絡用戶來講,網站后
端就是一個單一的系統,協同起來向用戶提供系統資源,系統服務。
二. 為什么要使用集群
1) 集群的特點
– 高性能performance
一些需要很強的運算處理能力比如天氣預報,核試驗等。這就不是幾臺服務器能夠搞定的。這需要上千臺一起來完成這個工作的。
– 價格有效性
通常一套系統集群架構,只需要幾臺或數十臺服務器主機即可,與動則上百萬的專用超級服務器具有更高的性價比。
– 可伸縮性
當服務器負載壓力增長的時候,系統能夠擴展來滿足需求,且不降低服務質量。
– 高可用性
盡管部分硬件和軟件發生故障,整個系統的服務必須是7*24小時運行的。
2) 集群的優勢
– 透明性
如果一部分服務器宕機了業務不受影響,一般耦合度沒有那么高,依賴關系沒有那么高。比如NFS服務器宕機了其他就掛載不了了,這樣依賴性太強。
– 高性能
訪問量增加,能夠輕松擴展。
– 可管理性
整個系統可能在物理上很大,但很容易管理。
– 可編程性
在集群系統上,容易開發應用程序,門戶網站會要求這個。
3) 集群分類及不同分類的特點
計算機集群架構按照功能和結構一般分成以下幾類:
– 負載均衡集群(Loadbalancingclusters)簡稱LBC
– 高可用性集群(High-availabilityclusters)簡稱HAC
– 高性能計算集群(High-perfomanceclusters)簡稱HPC
– 網格計算(Gridcomputing)
就集群分類而言, 網絡上面一般認為是有三個,負載均衡和高可用集群式我們互聯網行業常用的集群架構。
1) 負載均衡集群
負載均衡集群為企業提供了更為實用,性價比更高的系統架構解決方案。負載均衡集群把很多客戶集中訪問的請求負載壓力可能盡可能平均的分攤到計算機集群中處理。
客戶請求負載通常包括應用程度處理負載和網絡流量負載。這樣的系統非常適合向使用同一組應用程序為大量用戶提供服務。每個節點都可以承擔一定的訪問請求負載壓力,
并且可以實現訪問請求在各節點之間動態分配,以實現負載均衡。
負載均衡運行時,一般通過一個或多個前端負載均衡器將客戶訪問請求分發到后端一組服務器上,從而達到整個系統的高性能和高可用性。這樣集群有時也被稱為服務器群。
一般高可用性集群和負載均衡集群會使用類似的技術,或同時具有高可用性與負載均衡的特點。
負載均衡集群的作用:
a)分擔訪問流量(負載均衡)
b)保持業務的連續性(高可用)
2) 高可用性集群
一般是指當集群中的任意一個節點失效的情況下,節點上的所有任務自動轉移到其他正常的節點上,并且此過程不影響整個集群的運行,不影響業務的提供。類似是集群中運行著兩個或兩個以上的一樣的節點,當某個主節點出現故障的時候,那么其他作為從 節點的節點就會接替主節點上面的任務。從節點可以接管主節點的資源(IP地址,架構身份等),此時用戶不會發現提供服務的對象從主節點轉移到從節點。
高可用性集群的作用:當一臺機器宕機另一臺進行接管。比較常用的高可用集群開源軟件有:keepalive,heardbeat。
3) 高性能計算集群
高性能計算集群采用將計算任務分配到集群的不同計算節點兒提高計算能力,因而主要應用在科學計算領域。比較流行的HPC采用Linux操作系統和其它一些免費軟件來完成并行運算。這一集群配置通常被稱為Beowulf集群。這類集群通常運行特定的程序以發揮HPCcluster的并行能力。這類程序一般應用特定的運行庫, 比如專為科學計算設計的MPI庫。HPC集群特別適合于在計算中各計算節點之間發生大量數據通訊的計算作業,比如一個節點的中間結果或影響到其它節點計算結果的情況。
三. 負載均衡集群介紹
負載均衡集群是 Load Balance 集群, 是一種將網絡上的訪問流量分布于各個節點,以降低服務器壓力,更好的向客戶端提供服務的一種方式。
負載均衡集群的作用:提供一種廉價、有效、透明的方法,來擴展網絡設備和服務器的負載帶寬、增加吞吐量,加強網絡數據處理能力、提高網絡的靈活性和可用性。簡單來說,也就是:
1) 把單臺計算機無法承受的大規模的并發訪問或數據流量分擔到多臺節點設備上分別處理,減少用戶等待響應的時間,提升用戶體驗。
2) 單個重負載的運算分擔到多臺節點設備上做并行處理,每個節點設備處理結束后,將結果匯總,返回給用戶,系統處理能力得到大幅度提高。
3) 7*24小時的服務保證,任意一個或多個設備節點設備宕機,不能影響到業務。在負載均衡集群中,所有計算機節點都應該提供相同的服務,集群負載均衡獲取所有對該服務的如站請求。
常用的負載均衡分為:
1) 開源軟件負載均衡: Nginx, LVS, Haproxy (Nginx和Haproxy通常做七層負載均衡, LVS做四層負載均衡. 但是Nginx也可以通過stream模塊做四層負載均衡, Haproxy也可以做四層負載均衡 ) ;
2) 商業的硬件負載均衡: 設備F5、Netscale ;
簡單理解一下軟件負載均衡:
1) 所謂分層的負載均衡,都是以網絡的模型來說的。四層就是基于IP和端口的負載均衡,七層就是基于URL等應用信息的負載均衡。所以簡單的說四層負載均衡就是通過IP和端口接收請求再分發至真實的服務器,七層是通過URL或主機名接收請求,然后分發至真實的服務器。
2) .而七層的實現也是在四層的基礎上是實現的,沒有四層就不可能有七層。在第七層上可以做許多事情,比如可以根據七層的瀏覽器類別區分是手機還是PC,將WEB服務器分為2組,手機登陸專門的移動端網站。
3) 對客戶端來說,客戶端好像是訪問的同一臺主機。其實為了有更好的用戶體驗,從智能DNS入手,根據客戶端IP來源將域名解析到距離客戶端最近的一臺服務器或者訪問最快速的一臺服務器,但這些內容客戶端都是感覺不到的,客戶端感覺到的只能是訪問網站很快。
四. LVS負載均衡集群說明
1) LVS是什么?
LVS是linux virtual server的簡寫linux虛擬服務器,是一個虛擬的服務器集群系統,可以在unix/linux平臺下實現負載均衡集群功能。該項目在1998年5月由章文嵩博士組織成立。LVS是一種集群(Cluster)技術,采用IP負載均衡技術和基于內容請求分發技術。調度器具有很好的吞吐率,將請求均衡地轉移到不同的服務器上執行,且調度器自動屏蔽掉服務器
的故障,從而將一組服務器構成一個高性能的、高可用的虛擬服務器。整個服務器集群的結構對客戶是透明的,而且無需修改客戶端和服務器端的程序。
LVS集群采用IP負載均衡技術和基于內容請求分發技術。調度器具有很好的吞吐率,將請求均衡地轉移到不同的服務器上執行,且調度器自動屏蔽掉服 務器的故障,從而將一組服務器構成一個高性能的、高可用的虛擬服務器。整個服務器集群的結構對客戶是透明的,而且無需修改客戶端和服務器端的程序。
LVS在設計時需要考慮系統的透明性、可伸縮性、高可用性和易管理性。一般來說,LVS集群采用三層結構,其體系結構如圖所示:
負載均衡的原理很簡單,就是當客戶端發起請求時,請求直接發給Director Server(調度器),這時會根據設定的調度算法,將請求按照算法的規定智能的分發到真正的后臺服務器。以達到將壓力均攤。但是我們知道,http的連接時無狀態的,假設這樣一個場景,我登錄某寶買東西,當我看上某款商品時,我將它加入購物車,但是我刷新了一下頁面,這時由于負載均衡的原因,調度器又選了新的一臺服務器為我提供服務,我剛才的購物車內容全都不見了,這樣就會有十分差的用戶體驗。所以就還需要一個存儲共享,這樣就保證了用戶請求的數據是一樣的。所以LVS負載均衡分為三層架構(也就是LVS負載均衡主要組成部分):
第一層:負載調度器(load balancer/ Director),它是整個集群的總代理,它在有兩個網卡,一個網卡面對訪問網站的客戶端,一個網??面對整個集群的內部。負責將客戶端的請求發送到一組服務器上執行,而客戶也認為服務是來自這臺主的。舉個生動的例子,集群是個公司,負載調度器就是在外接攬生意,將接攬到的生意分發給后臺的真正干活的真正的主機們。當然需要將活按照一定的算法分發下去,讓大家都公平的干活。
第二層:服務器池(server pool/ Realserver),是一組真正執行客戶請求的服務器,可以當做WEB服務器。就是上面例子中的小員工。
第三層:共享存儲(shared storage),它為服務器池提供一個共享的存儲區,這樣很容易使得服務器池擁有相同的內容,提供相同的服務。一個公司得有一個后臺賬目吧,這才能協調。不然客戶把錢付給了A,而換B接待客戶,因為沒有相同的賬目。B說客戶沒付錢,那這樣就不是客戶體驗度的問題了。
2) LVS負載均衡集群特點
2.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(下面會詳細介紹);
負載調度算法
負載調度器是根據各個服務器的負載情況,動態地選擇一臺Real Server響應用戶請求,那么動態選擇是如何實現呢,其實也就是我們這里要說的負載調度算法,根據不同的網絡服務需求和服務器配置,IPVS實現了如下八種負載調度算法:rr、wrr、Wlc、Dh、SH、Lc、Lblc(下面會詳細介紹);
2.2) 高可用性
LVS是一個基于內核級別的應用軟件,因此具有很高的處理性能,后端服務器可運行任何支持TCP/IP的操作系統,包括Linux,各種Unix(如FreeBSD、Sun Solaris、HP Unix等),Mac/OS和Windows NT/2000等。負載調度器能夠支持絕大多數的TCP和UDP協議.
2.3) 性能
LVS服務器集群系統具有良好的伸縮性,可支持幾百萬個并發連接。用LVS構架的負載均衡集群系統具有優秀的處理能力,每個服務節點的故障不會影響整個系統的正常使用,同時又實現負載的合理均衡,使應用具有超高負荷的服務能力,可支持上百萬個并發連接請求。如配置百兆網卡,采用VS/TUN或VS/DR調度技術,整個集群系統的吞吐量可高達1Gbits/s;如配置千兆網卡,則系統的最大吞吐量可接近10Gbits/s。
2.4)高可靠性
LVS負載均衡集群軟件已經在企業、學校等行業得到了很好的普及應用,國內外很多大型的、關鍵性的web站點也都采用了LVS集群軟件,所以它的可靠性在實踐中得到了很好的證實。有很多以LVS做的負載均衡系統,運行很長時間,從未做過重新啟動。這些都說明了LVS的高穩定性和高可靠性。
2.5) 適用環境
LVS對前端Director Server目前僅支持Linux和FreeBSD系統,但是支持大多數的TCP和UDP協議,支持TCP協議的應用有:HTTP,HTTPS ,FTP,SMTP,,POP3,IMAP4,PROXY,LDAP,SSMTP等等。支持UDP協議的應用有:DNS,NTP,ICP,視頻、音頻流播放協議等。LVS對Real Server的操作系統沒有任何限制,Real Server可運行在任何支持TCP/IP的操作系統上,包括Linux,各種Unix(如FreeBSD、Sun Solaris、HP Unix等),Mac/OS和Windows等。
2.6) 開源軟件(軟件許可證)
LVS集群軟件是按GPL(GNU Public License)許可證發行的自由軟件,因此,使用者可以得到軟件的源代碼,并且可以根據自己的需要進行各種修改,但是修改必須是以GPL方式發行。
3) LVS體系結構
LVS集群負載均衡器接受服務的所有入展客戶端的請求,然后根據調度算法決定哪個集群節點來處理回復客戶端的請求。LVS虛擬服務器的體系如下圖所示,一組服務器通過高速的局域網或者地理分布的廣域網相互連接,在這組服務器之前有一個負載調度器(load balance)。負載調度器負責將客戶的請求調度到真實服務器上。這樣這組服務器集群的結構對用戶來說就是透明的。客戶訪問集群系統就如只是訪問一臺高性能,高可用的服務器一樣。客戶程序不受服務器集群的影響,不做任何修改。
就比如說:我們去飯店吃飯點菜,客戶只要跟服務員點菜就行。并不需要知道具體他們是怎么分配工作的,所以他們內部對于我們來說是透明的。此時這個服務員就會按照一定的規則把他手上的活,分配到其他人員上去。這個服務員就是負載均衡器(LB)而后面這些真正做事的就是服務器集群。
LVS結構圖如下:
LVS基本工作過程
客戶請發送向負載均衡服務器發送請求。負載均衡器接受客戶的請求,然后先是根據LVS的調度算法(8種)來決定要將這個請求發送給哪個節點服務器。然后依據自己的工作模式(3種)來看應該如何把這些客戶的請求如何發送給節點服務器,節點服務器又應該如何來把響應數據包發回給客戶端。
LVS組成
lvs分為兩個部分,分別是內核模塊和lvs的管理工具。目前來說,CentOS6及其以上的內核版本已經包括了ipvs的相關模塊了。
從上面可知, 內核支持的ipvs模塊, 上圖中的rr,wrr,lc,wlc,lblc等等都是lvs中調度器的調度算法,根據不同的調度算法可以更好的分配服務,實現負載均衡。而ipvs(ip virtual server):一段代碼工作在內核空間,實現調度。
上圖是ipvsadm (即LVS客戶端管理工具), 主要負責為ipvs內核框架編寫規則,定義誰是集群服務,而誰是后端真實的服務器(Real Server)。
4) LVS的實現原理
lvs的原理其實就是利用了Iptables的功能。了解防火墻的都知道四表五鏈。防火墻不僅僅有放火的功能還有轉發,地址偽裝,限流等等功能。
1) 首先,客戶端向調度器(Director Server)發起一個請求,調度器將這個請求發送至內核
2) PREROUTING鏈首先會接收到用戶請求,判斷目標IP確定是本機IP,將數據包發往INPUT鏈。
3) 當請求達到INPUT鏈上,調度器判斷報文中的目標端口來確定這個訪問是不是要訪問集群服務(因為還有可能只是ssh想單純的遠程登錄主機這個主機),如果是訪問的集群服務,那么就會強制修改這個包的目標IP
4) POSTROUTING鏈接收數據包后發現目標IP地址剛好是自己的后端服務器,那么此時通過選路,將數據包最終發送給后端的服務器
5) LVS的工作原理
LVS 的工作模式分為4中分別是 NAT,DR,TUN,FULL-NAT。其中做個比較,由于工作原理的關系的,NAT的配置最為簡單,但是NAT對調度器的壓力太大了,導致其效率最低,DR和TUN的工作原理差不多,但是DR中,所有主機必須處于同一個物理環境中,而在TUN中,所有主機可以分布在不同的位置,服務器一個在紐約,一個在深圳。最多應用的是FULL-NAT。
其中的專業術語
DS:Director Server。指的是前端負載均衡器。
RS:Real Server。后端真實的工作服務器。
VIP:向外部直接面向用戶請求,作為用戶請求的目標的IP地址。
DIP:Director Server IP,主要用于和內部主機通訊的IP地址。
RIP:Real Server IP,后端服務器的IP地址。
CIP:Client IP,訪問客戶端的IP地址。
下面介紹LVS常用的三種負載均衡模式
1)NAT模式-網絡地址轉換 Virtualserver via Network address translation(VS/NAT)
這個是通過網絡地址轉換的方法來實現調度的。首先調度器(LB)接收到客戶的請求數據包時(請求的目的IP為VIP),根據調度算法決定將請求發送給哪個后端的真實服務器(RS)。然后調度就把客戶端發送的請求數據包的目標IP地址及端口改成后端真實服務器的IP地址(RIP),這樣真實服務器(RS)就能夠接收到客戶的請求數據包了。真實服務器響應完請求后,查看默認路由(NAT模式下我們需要把RS的默認路由設置為LB服務器。)把響應后的數據包發送給LB,LB再接收到響應包后,把包的源地址改成虛擬地址(VIP)然后發送回給客戶端。
VS/NAT是一種最簡單的方式,所有的RealServer只需要將自己的網關指向Director即可。客戶端可以是任意操作系統,但此方式下,一個Director能夠帶動的RealServer比較有限。在VS/NAT的方式下,Director也可以兼為一臺RealServer。VS/NAT的體系結構如圖所示。
NAT工作模式下,調度過程IP包詳細圖:
NAT模式的以上原理圖簡述:
1) 客戶端請求數據,目標IP為VIP
2) 請求數據到達LB服務器,LB根據調度算法將目的地址修改為RIP地址及對應端口(此RIP地址是根據調度算法得出的。)并在連接HASH表中記錄下這個連接。
3) 數據包從LB服務器到達RS服務器webserver,然后webserver進行響應。Webserver的網關必須是LB,然后將數據返回給LB服務器。
4) 收到RS的返回后的數據,根據連接HASH表修改源地址VIP&目標地址CIP,及對應端口80.然后數據就從LB出發到達客戶端。
5) 客戶端收到的就只能看到VIPDIP信息。
NAT模式優缺點:
1) NAT技術將請求的報文和響應的報文都需要通過LB進行地址改寫,因此網站訪問量比較大的時候LB負載均衡調度器有比較大的瓶頸,一般要求最多之能10-20臺節點。
2) 只需要在LB上配置一個公網IP地址就可以了。
3) 每臺內部的節點服務器的網關地址必須是調度器LB的內網地址。
4) NAT模式支持對IP地址和端口進行轉換。即用戶請求的端口和真實服務器的端口可以不一致。
再看下面的NAT模式圖
客戶發出請求,發送請求給鏈接調度器的VIP,調度器將請求報文中的目標Ip地址改為RIP。這樣服務器RealServer將請求的內容發給調度器,調度器再將報文中的源IP地址改為VIP;
1) 當用戶請求到達Director Server,此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP,目標IP為VIP;
2) PREROUTING檢查發現數據包的目標IP是本機,將數據包送至INPUT鏈;
3) IPVS比對數據包請求的服務是否為集群服務,若是,修改數據包的目標IP地址為后端服務器IP,然后將數據包發至POSTROUTING鏈。 此時報文的源IP為CIP,目標IP為RIP
4) POSTROUTING鏈通過選路,將數據包發送給Real Server;
5) Real Server比對發現目標為自己的IP,開始構建響應報文發回給Director Server。 此時報文的源IP為RIP,目標IP為CIP;
6) Director Server在響應客戶端前,此時會將源IP地址修改為自己的VIP地址,然后響應給客戶端。 此時報文的源IP為VIP,目標IP為CIP;
NAT模式特點和注意事項:
1) 很好配置,原理簡單易懂;
2) 由于調度器的工作量太大,很容易成為整個集群系統的瓶頸;
3) RS應該使用私有地址;
4) RS的網關的必須指向DIP;
5) RIP和DIP必須在同一網段內;
6) 請求和響應的報文都得經過Director;在高負載場景中,Director很可能成為系統性能瓶頸;
7) 支持端口映射;
8) RS可以使用任意支持集群服務的OS;
2)TUN模式-IP隧道模式 Virtual Server via IP Tunneling(VS/TUN)
IP隧道(IP tunneling)是將一個IP報文封裝在另一個IP報文的技術,這可以使得目標為一個IP地址的數據報文能被封裝和轉發到另一個IP地址。IP隧道技術亦稱為IP封裝技術(IP encapsulation)。
IP隧道主要用于移動主機和虛擬私有網絡(Virtual Private Network),在其中隧道都是靜態建立的,隧道一端有一??IP地址,另一端也有唯一的IP地址。它的連接調度和管理與VS/NAT中的一樣,只是它的報文轉發方法不同。調度器根據各個服務器的負載情況,動態地選擇一臺服務器,將請求報文封裝在另一個IP報文中,再將封裝后的IP報文轉發給選出的服務器; 服務器收到報文后,先將報文解封獲得原來目標地址為 VIP 的報文,服務器發現VIP地址被配置在本地的IP隧道設備上,所以就處理這個請求,然后根據路由表將響應報文直接返回給客戶。
采用NAT模式時,由于請求和響應的報文必須通過調度器地址重寫,當客戶請求越來越多時,調度器處理能力將成為瓶頸。為了解決這個問題,調度器把請求的報文通過IP隧道轉發到真實的服務器。真實的服務器將響應處理后的數據直接返回給客戶端。這樣調度器就只處理請求入站報文,由于一般網絡服務應答數據比請求報文大很多,采用VS/TUN模式后,集群系統的最大吞吐量可以提高10倍。
VS/TUN的工作原理流程圖如下所示,它和NAT模式不同的是,它在LB和RS之間的傳輸不用改寫IP地址。而是把客戶請求包封裝在一個IP tunnel里面,然后發送給RS節點服務器,節點服務器接收到之后解開IP tunnel后,進行響應處理。并且直接把包通過自己的外網地址發送給客戶不用經過LB服務器。
TUN模式下的以上原理圖過程簡述:
1)客戶請求數據包,目標地址VIP發送到LB上;
2)LB接收到客戶請求包,進行IP Tunnel封裝。即在原有的包頭加上IP Tunnel的包頭。然后發送出去;
3)RS節點機器根據IP Tunnel包頭信息 (此時就又一種邏輯上的隱形隧道,只有LB和RS之間懂)收到請求包,然后解開IP Tunnel包頭信息,得到客戶的請求包并進行響應處理。
4)響應處理完畢之后,RS服務器使用自己的出公網的線路,將這個響應數據包發送給客戶端。源IP地址還是VIP地址。(RS節點服務器需要在本地回環接口配置VIP);
其實TUN模式和下面的DR模式差不多,但是比DR多了一個隧道技術以支持realserver不在同一個物理環境中。就是realserver一個在北京,一個工作在上海。在原有的IP報文外再次封裝多一層IP首部,內部IP首部(源地址為CIP,目標IIP為VIP),外層IP首部(源地址為DIP,目標IP為RIP. 再看下面的TUN模式圖:
1) 當用戶請求到達Director Server,此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP,目標IP為VIP 。
2) PREROUTING檢查發現數據包的目標IP是本機,將數據包送至INPUT鏈;
3) IPVS比對數據包請求的服務是否為集群服務,若是,在請求報文的首部再次封裝一層IP報文,封裝源IP為為DIP,目標IP為RIP。然后發至POSTROUTING鏈。 此時源IP為DIP,目標IP為RIP;
4) POSTROUTING鏈根據最新封裝的IP報文,將數據包發至RS(因為在外層封裝多了一層IP首部,所以可以理解為此時通過隧道傳輸)。 此時源IP為DIP,目標IP為RIP;
5) RS接收到報文后發現是自己的IP地址,就將報文接收下來,拆除掉最外層的IP后,會發現里面還有一層IP首部,而且目標是自己的lo接口VIP,那么此時RS開始處理此請求,處理完成之后,通過lo接口送給eth0網卡,然后向外傳遞。 此時的源IP地址為VIP,目標IP為CIP;
6) 響應報文最終送達至客戶端;
LVS-TUN (ip隧道) 模式特點和注意事項
1) RIP、VIP、DIP全是公網地址
2) RS的網關不會也不可能指向DIP
3) 不支持端口映射
4) RS的系統必須支持隧道
3)DR模式-直接路由模式 Virtual Server via Direct Routing(VS/DR)
DR模式也就是用直接路由技術實現虛擬服務器。它的連接調度和管理與VS/NAT和VS/TUN中的一樣,但它的報文轉發方法又有不同,VS/DR通過改寫請求報文的MAC地址,將請求發送到Real Server,而Real Server將響應直接返回給客戶,免去了VS/TUN中的IP隧道開銷。這種方式是三種負載調度機制中性能最高最好的,但是必須要求Director Server與Real Server都有一塊網卡連在同一物理網段上。
Director和RealServer必需在物理上有一個網卡通過不間斷的局域網相連。 RealServer上綁定的VIP配置在各自Non-ARP的網絡設備上(如lo或tunl),Director的VIP地址對外可見,而RealServer的VIP對外是不可見的。RealServer的地址即可以是內部地址,也可以是真實地址。
DR模式是通過改寫請求報文的目標MAC地址,將請求發給真實服務器的,而真實服務器響應后的處理結果直接返回給客戶端用戶。同TUN模式一樣,DR模式可以極大的提高集群系統的伸縮性。而且DR模式沒有IP隧道的開銷,對集群中的真實服務器也沒有必要必須支持IP隧道協議的要求。但是要求調度器LB與真實服務器RS都有一塊網卡連接到同一物理網段上,必須在同一個局域網環境。
DR模式是互聯網使用比較多的一種模式,DR模式原理圖如下:
DR模式以上原理過程簡述:
VS/DR模式的工作流程圖如上圖所示,它的連接調度和管理與NAT和TUN中的一樣,它的報文轉發方法和前兩種不同。DR模式將報文直接路由給目標真實服務器。在DR模式中,調度器根據各個真實服務器的負載情況,連接數多少等,動態地選擇一臺服務器,不修改目標IP地址和目標端口,也不封裝IP報文,而是將請求報文的數據幀的目標MAC地址改為真實服務器的MAC地址。然后再將修改的數據幀在服務器組的局域網上發送。因為數據幀的MAC地址是真實服務器的MAC地址,并且又在同一個局域網。那么根據局域網的通訊原理,真實復位是一定能夠收到由LB發出的數據包。真實服務器接收到請求數據包的時候,解開IP包頭查看到的目標IP是VIP。(此時只有自己的IP符合目標IP才會接收進來,所以我們需要在本地的回環借口上面配置VIP。
另外: 由于網絡接口都會進行ARP廣播響應,但集群的其他機器都有這個VIP的lo接口,都響應就會沖突。所以我們需要把真實服務器的lo接口的ARP響應關閉掉。)然后真實服務器做成請求響應,之后根據自己的路由信息將這個響應數據包發送回給客戶,并且源IP地址還是VIP。
其實整個DR模式都是停留在第二層的數據鏈路層, 直接修改MAC。實現報文的轉發。再看下面的DR模式圖:
1) 當用戶請求到達Director Server,此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP,目標IP為VIP;
2) PREROUTING檢查發現數據包的目標IP是本機,將數據包送至INPUT鏈;
3) IPVS比對數據包請求的服務是否為集群服務,若是,將請求報文中的源MAC地址修改為DIP的MAC地址,將目標MAC地址修改RIP的MAC地址,然后將數據包發至POSTROUTING鏈。 此時的源IP和目的IP均未修改,僅修改了源MAC地址為DIP的MAC地址,目標MAC地址為RIP的MAC地址;
4) 由于DS和RS在同一個網絡中,所以是通過二層來傳輸。POSTROUTING鏈檢查目標MAC地址為RIP的MAC地址,那么此時數據包將會發至Real Server;
5) 響應報文最終送達至客戶端;
LVS-DR模式特點和注意事項
1) 在前端路由器做靜態地址路由綁定,將對于VIP的地址僅路由到Director Server
2) arptables:在arp的層次上實現在ARP解析時做防火墻規則,過濾RS響應ARP請求。修改RS上內核參數(arp_ignore和arp_announce)將RS上的VIP配置在網卡接口的別名上,并限制其不能響應對VIP地址解析請求。
3) RS可以使用私有地址;但也可以使用公網地址,此時可以直接通過互聯網連入RS以實現配置、監控等;
4) RS的網關一定不能指向DIP;
5) RS跟Dirctory要在同一物理網絡內(不能由路由器分隔);
6) 請求報文經過Directory,但響應報文一定不經過Director
7) 不支持端口映射;
8) RS可以使用大多數的操作系統;
DR模式小結:
1)通過在調度器LB上修改數據包的目的MAC地址實現轉發。注意源地址仍然是CIP,目的地址仍然是VIP地址。
2)請求的報文經過調度器,而RS響應處理后的報文無需經過調度器LB,因此并發訪問量大時使用效率很高(和NAT模式比)
3)因為DR模式是通過MAC地址改寫機制實現轉發,因此所有RS節點和調度器LB只能在一個局域網里面
4)RS主機需要綁定VIP地址在LO接口上(防止IP沖突),并且需要配置ARP機制。
5)RS節點的默認網關不需要配置成LB,而是直接配置為上級路由的網關,能讓RS直接出網就可以。
6)由于DR模式的調度器僅做MAC地址的改寫,所以調度器LB就不能改寫目標端口,那么RS服務器就得使用和VIP相同的端口提供服務。
三種負載均衡方式簡單比較:
1)NAT模式-網絡地址轉換
VS/NAT 的優點是服務器可以運行任何支持TCP/IP的操作系統,它只需要一個IP地址配置在調度器上,服務器組可以用私有的IP地址。缺點是它的伸縮能力有限,當服務器結點數目升到20時,調度器本身有可能成為系統的新瓶頸,因為在VS/NAT中請求和響應報文都需要通過負載調度器。如果負載調度器成為系統新的瓶頸,可以有三種方法解決這個問題:混合方法、VS/TUN和 VS/DR。在DNS混合集群系統中,有若干個VS/NAT負調度器,每個負載調度器帶自己的服務器集群,同時這些負載調度器又通過RR-DNS組成簡單的域名。但VS/TUN和VS/DR是提高系統吞吐量的更好方法。對于那些將IP地址或者端口號在報文數據中傳送的網絡服務,需要編寫相應的應用模塊來轉換報文數據中的IP地址或者端口號。這會帶來實現的工作量,同時應用模塊檢查報文的開銷會降低系統的吞吐率。
2)TUN模式-IP隧道模式
在TUN 的集群系統中,負載調度器只將請求調度到不同的后端服務器,后端服務器將應答的數據直接返回給用戶。這樣負載調度器就可以處理大量的請求,它甚至可以調度百臺以上的服務器(同等規模的服務器),而它不會成為系統的瓶頸。即使負載調度器只有100Mbps的全雙工網卡,整個系統的最大吞吐量可超過 1Gbps。所以,VS/TUN可以極大地增加負載調度器調度的服務器數量。VS/TUN調度器可以調度上百臺服務器,而它本身不會成為系統的瓶頸,可以用來構建高性能的超級服務器。VS/TUN技術對服務器有要求,即所有的服務器必須支持”IP Tunneling”或者”IP Encapsulation”協議。目前,VS/TUN的后端服務器主要運行Linux操作系統,我們沒對其他操作系統進行測試。因為”IP Tunneling”正成為各個操作系統的標準協議,所以VS/TUN應該會適用運行其他操作系統的后端服務器。
3)DR模式
跟VS/TUN方法一樣,VS/DR調度器只處理客戶到服務器端的連接,響應數據可以直接從獨立的網絡路由返回給客戶。這可以極大地提高LVS集群系統的伸縮性。跟VS/TUN相比,這種方法沒有IP隧道的開銷,但是要求負載調度器與實際服務器都有一塊網卡連在同一物理網段上,服務器網絡設備(或者設備別名)不作ARP響應,或者能將報文重定向(Redirect)到本地的Socket端口上。
6) LVS負載均衡調度算法
VS的調度算法決定了如何在集群節點之間分布工作負荷。當director調度器收到來自客戶端訪問VIP的上的集群服務的入站請求時,director調度器必須決定哪個集群節點應該
處理請求。
Director調度器用的調度方法基本分為兩類 (如下所列, LVS總共有10種調度算法, 常用的也就四種調度算法, 下面會說到):
靜態調度算法:rr,wrr,dh,sh
動態調度算法:wlc,lc,lblc,lblcr, sed, nq