四層and七層負載均衡

来源:https://www.cnblogs.com/licker/archive/2018/08/04/9419506.html
-Advertisement-
Play Games

四層負載/七層負載 在常規運維工作中,經常會運用到負載均衡服務。負載均衡分為四層負載和七層負載,那麼這兩者之間有什麼不同? 廢話不多說,詳解如下: 1. 什麼是負載均衡 1)負載均衡(Load Balance)建立在現有網路結構之上,它提供了一種廉價有效透明的方法擴展網路設備和伺服器的帶寬、增加吞吐 ...


四層負載/七層負載

 在常規運維工作中,經常會運用到負載均衡服務。負載均衡分為四層負載和七層負載,那麼這兩者之間有什麼不同?

廢話不多說,詳解如下:

1.    什麼是負載均衡

1)負載均衡(Load Balance)建立在現有網路結構之上,它提供了一種廉價有效透明的方法擴展網路設備和伺服器的帶寬、增加吞吐量、加強網路數據處理能力、提高網路的靈活性和可用性。負載均衡有兩方面的含義:首先,大量的併發訪問或數據流量分擔到多台節點設備上分別處理,減少用戶等待響應的時間;其次,單個重負載的運算分擔到多台節點設備上做並行處理,每個節點設備處理結束後,將結果彙總,返回給用戶,系統處理能力得到大幅度提高。
2)簡單來說就是:其一是將大量的併發處理轉發給後端多個節點處理,減少工作響應時間;其二是將單個繁重的工作轉發給後端多個節點處理,處理完再返回給負載均衡中心,再返回給用戶。目前負載均衡技術大多數是用於提高諸如在Web伺服器、FTP伺服器和其它關鍵任務伺服器上的Internet伺服器程式的可用性和可伸縮性。

2.    負載均衡分類

1)二層負載均衡(mac)
根據OSI模型分的二層負載,一般是用虛擬mac地址方式,外部對虛擬MAC地址請求,負載均衡接收後分配後端實際的MAC地址響應)
2)三層負載均衡(ip)
一般採用虛擬IP地址方式,外部對虛擬的ip地址請求,負載均衡接收後分配後端實際的IP地址響應)
3)四層負載均衡(tcp)
在三次負載均衡的基礎上,用ip+port接收請求,再轉發到對應的機器。
4)七層負載均衡(http)
根據虛擬的url或IP,主機名接收請求,再轉向相應的處理伺服器)。

我們運維中最常見的四層和七層負載均衡,這裡重點說下這兩種負載均衡。
1)四層的負載均衡就是基於IP+埠的負載均衡:在三層負載均衡的基礎上,通過發佈三層的IP地址(VIP),然後加四層的埠號,來決定哪些流量需要做負載均衡,對需要處理的流量進行NAT處理,轉發至後臺伺服器,並記錄下這個TCP或者UDP的流量是由哪台伺服器處理的,後續這個連接的所有流量都同樣轉發到同一臺伺服器處理。
對應的負載均衡器稱為四層交換機(L4 switch),主要分析IP層及TCP/UDP層,實現四層負載均衡。此種負載均衡器不理解應用協議(如HTTP/FTP/MySQL等等)。
實現四層負載均衡的軟體有:
F5:硬體負載均衡器,功能很好,但是成本很高。
lvs:重量級的四層負載軟體
nginx:輕量級的四層負載軟體,帶緩存功能,正則表達式較靈活
haproxy:模擬四層轉發,較靈活
2)七層的負載均衡就是基於虛擬的URL或主機IP的負載均衡:在四層負載均衡的基礎上(沒有四層是絕對不可能有七層的),再考慮應用層的特征,比如同一個Web伺服器的負載均衡,除了根據VIP加80埠辨別是否需要處理的流量,還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。舉個例子,如果你的Web伺服器分成兩組,一組是中文語言的,一組是英文語言的,那麼七層負載均衡就可以當用戶來訪問你的功能變數名稱時,自動辨別用戶語言,然後選擇對應的語言伺服器組進行負載均衡處理。
對應的負載均衡器稱為七層交換機(L7 switch),除了支持四層負載均衡以外,還有分析應用層的信息,如HTTP協議URI或Cookie信息,實現七層負載均衡。此種負載均衡器能理解應用協議。
實現七層負載均衡的軟體有:
haproxy:天生負載均衡技能,全面支持七層代理,會話保持,標記,路徑轉移;
nginx:只在http協議和mail協議上功能比較好,性能與haproxy差不多;
apache:功能較差
Mysql proxy:功能尚可。

總的來說,一般是lvs做4層負載;nginx做7層負載;haproxy比較靈活,4層和7層負載均衡都能做

3.    兩者之間的區別

1)         從技術原理上分析

      所謂四層負載均衡,也就是主要通過報文中的目標地址和埠,再加上負載均衡設備設置的伺服器選擇方式,決定最終選擇的內部伺服器。
      以常見的TCP為例,負載均衡設備在接收到第一個來自客戶端的SYN 請求時,即通過上述方式選擇一個最佳的伺服器,並對報文中目標IP地址進行修改(改為後端伺服器IP),直接轉發給該伺服器。TCP的連接建立,即三次握手是客戶端和伺服器直接建立的,負載均衡設備只是起到一個類似路由器的轉發動作。在某些部署情況下,為保證伺服器回包可以正確返回給負載均衡設備,在轉發報文的同時可能還會對報文原來的源地址進行修改。

 

      所謂七層負載均衡,也稱為“內容交換”,也就是主要通過報文中的真正有意義的應用層內容,再加上負載均衡設備設置的伺服器選擇方式,決定最終選擇的內部伺服器。
      以常見的TCP為例,負載均衡設備如果要根據真正的應用層內容再選擇伺服器,只能先代理最終的伺服器和客戶端建立連接(三次握手)後,才可能接受到客戶端發送的真正應用層內容的報文,然後再根據該報文中的特定欄位,再加上負載均衡設備設置的伺服器選擇方式,決定最終選擇的內部伺服器。負載均衡設備在這種情況下,更類似於一個代理伺服器。負載均衡和前端的客戶端以及後端的伺服器會分別建立TCP連接。所以從這個技術原理上來看,七層負載均衡明顯的對負載均衡設備的要求更高,處理七層的能力也必然會低於四層模式的部署方式。

 

 

簡單來說,二者之間的區別
 七層負載均衡基本都是基於http協議的,適用於web伺服器的負載均衡。(nginx)
-  四層負載均衡主要是基於tcp協議報文,可以做任何基於tcp/ip協議的軟體的負載均衡。(haproxy、LVS)
-  兩者主要區別在於利用的報文所在的層面是不同的,各有各的好處。
 七層應用負載的好處,是使得整個網路更”智能化“。例如訪問一個網站的用戶流量,可以通過七層的方式,將對圖片類的請求轉發到特定的圖片伺服器並可以使用緩存技術;將對文字類的請求可以轉發到特定的文字伺服器並可以使用壓縮技術。當然這隻是七層應用的一個小案例,從技術原理上,這種方式可以對客戶端的請求和伺服器的響應進行任意意義上的修改,極大的提升了應用系統在網路層的靈活性。很多在後臺,例如Nginx或者Apache上部署的功能可以前移到負載均衡設備上,例如客戶請求中的Header重寫,伺服器響應中的關鍵字過濾或者內容插入等功能。
 四層負載均衡主要是較為靈活,可以作為多種軟體的負載均衡器。

舉個例子形象的說明:四層負載均衡就像銀行的自助排號機,每一個達到銀行的客戶根據排號機的順序,選擇對應的視窗接受服務;而七層負載均衡像銀行大堂經理,先確認客戶需要辦理的業務,再安排排號。這樣辦理理財、存取款等業務的客戶,會根據銀行內部資源得到統一協調處理,加快客戶業務辦理流程。

 

總結:從上面的對比看來四層負載與七層負載最大的區別就是效率與功能的區別。四層負載架構設計比較簡單,無需解析具體的消息內容,在網路吞吐量及處理能力上會相對比較高,而七層負載均衡的優勢則體現在功能多,控制靈活強大。在具體業務架構設計時,使用七層負載或者四層負載還得根據具體的情況綜合考慮。

=====================================================================
負載均衡時的數據流都經過負載均衡器,如何解決負載均衡器成為瓶頸的問題?
通過修改tcp報文的源地址和目的地址,使從web伺服器中返回的數據直接返回到客戶端,這是七層負載均衡無法做到的,因為tcp三次握手建立在客戶端與負載均衡伺服器之間,http協議基於tcp協議,建立好tcp鏈接後才傳送http報文,收到http報文說明負載均衡器和客戶端已經建立了tcp連接,而web伺服器和客戶端的tcp鏈接都沒建立,怎麼回傳數據給客戶端呢。以上的辦法會出現問題:所有集群里的主機都是內網ip,無法跟外界聯繫。
解決方案1
如果能買到那麼多外網Ip地址來用,然後在tcp鏈接要建立時負載均衡給真正的web伺服器,讓客戶端和伺服器建立tcp鏈接
解決方案2
引用一句話:電腦所有的問題都可以通過建立一層虛擬層解決。
可以通過將所有伺服器主機ip虛擬化成負載均衡伺服器的ip,這樣伺服器集群的所有主機都可以訪問外界網路,因為ip地址(網路層,三層)都是相同,所以只能通過第二層來分辨數據流向,修改數據鏈路層(二層)目的主機的MAC地址,使請求發到web伺服器上,然後才真正建立起tcp連接,然後web伺服器因為可以聯網,所以可以直接返回數據給客戶端

2)         從應用場景的需求上分析

     七層應用負載的好處,是使得整個網路更"智能化"。可以參考這篇:http應用優化和加速說明-負載均衡,就可以基本上瞭解這種方式的優勢所在。例如訪問一個網站的用戶流量,可以通過七層的方式,將對圖片類的請求轉發到特定的圖片伺服器並可以使用緩存技術;將對文字類的請求可以轉發到特定的文字伺服器並可以使用壓縮技術。當然這隻是七層應用的一個小案例,從技術原理上,這種方式可以對客戶端的請求和伺服器的響應進行任意意義上的修改,極大的提升了應用系統在網路層的靈活性。很多在後臺,例如Nginx或者Apache上部署的功能可以前移到負載均衡設備上,例如客戶請求中的Header重寫,伺服器響應中的關鍵字過濾或者內容插入等功能。
     另外一個常常被提到功能就是安全性。網路中最常見的SYN Flood攻擊,即黑客控制眾多源客戶端,使用虛假IP地址對同一目標發送SYN攻擊,通常這種攻擊會大量發送SYN報文,耗盡伺服器上的相關資源,以達到Denial of Service(DoS)的目的。從技術原理上也可以看出,四層模式下這些SYN攻擊都會被轉發到後端的伺服器上;而七層模式下這些SYN攻擊自然在負載均衡設備上就截止,不會影響後臺伺服器的正常運營。另外負載均衡設備可以在七層層面設定多種策略,過濾特定報文,例如SQL Injection等應用層面的特定攻擊手段,從應用層面進一步提高系統整體安全。
     現在的7層負載均衡,主要還是著重於應用HTTP協議,所以其應用範圍主要是眾多的網站或者內部信息平臺等基於B/S開發的系統。 4層負載均衡則對應其他TCP應用,例如基於C/S開發的ERP等系統。

3)七層應用需要考慮的問題

1.是否真的必要。七層應用的確可以提高流量智能化,同時必不可免的帶來設備配置複雜,負載均衡壓力增高以及故障排查上的複雜性等問題。在設計系統時需要考慮四層七層同時應用的混雜情況。
2.是否真的可以提高安全性。例如SYN Flood攻擊,七層模式的確將這些流量從伺服器屏蔽,但負載均衡設備本身要有強大的抗DDoS能力,否則即使伺服器正常而作為中樞調度的負載均衡設備故障也會導致整個應用的崩潰。
3.是否有足夠的靈活度。七層應用的優勢是可以讓整個應用的流量智能化,但是負載均衡設備需要提供完善的七層功能,滿足客戶根據不同情況的基於應用的調度。最簡單的一個考核就是能否取代後臺Nginx或者Apache等伺服器上的調度功能。能夠提供一個七層應用開發介面的負載均衡設備,可以讓客戶根據需求任意設定功能,才真正有可能提供強大的靈活性和智能性。

4)總體對比

1.智能性
七層負載均衡由於具備OIS七層的所有功能,所以在處理用戶需求上能更加靈活,從理論上講,七層模型能對用戶的所有跟服務端的請求進行修改。例如對文件header添加信息,根據不同的文件類型進行分類轉發。四層模型僅支持基於網路層的需求轉發,不能修改用戶請求的內容。
2.安全性
七層負載均衡由於具有OSI模型的全部功能,能更容易抵禦來自網路的攻擊;四層模型從原理上講,會直接將用戶的請求轉發給後端節點,無法直接抵禦網路攻擊。
3.複雜度
四層模型一般比較簡單的架構,容易管理,容易定位問題;七層模型架構比較複雜,通常也需要考慮結合四層模型的混用情況,出現問題定位比較複雜。
4.效率比
四層模型基於更底層的設置,通常效率更高,但應用範圍有限;七層模型需要更多的資源損耗,在理論上講比四層模型有更強的功能,現在的實現更多是基於http應用。

4.    負載均衡技術方案說明

目前有許多不同的負載均衡技術用以滿足不同的應用需求,下麵從負載均衡所採用的設備對象(軟/硬體負載均衡),應用的OSI網路層次(網路層次上的負載均衡),及應用的地理結構(本地/全局負載均衡)等來分類。
1)軟/硬體負載均衡
     軟體負載均衡解決方案是指在一臺或多台伺服器相應的操作系統上安裝一個或多個附加軟體來實現負載均衡,如DNS Load Balance,CheckPoint Firewall-1 ConnectControl,Keepalive+ipvs等,它的優點是基於特定環境,配置簡單,使用靈活,成本低廉,可以滿足一般的負載均衡需求。軟體解決方案缺點也較多,因為每台伺服器上安裝額外的軟體運行會消耗系統不定量的資源,越是功能強大的模塊,消耗得越多,所以當連接請求特別大的時候,軟體本身會成為伺服器工作成敗的一個關鍵;軟體可擴展性並不是很好,受到操作系統的限制;由於操作系統本身的Bug,往往會引起安全問題。
     硬體負載均衡解決方案是直接在伺服器和外部網路間安裝負載均衡設備,這種設備通常是一個獨立於系統的硬體,我們稱之為負載均衡器。由於專門的設備完成專門的任務,獨立於操作系統,整體性能得到大量提高,加上多樣化的負載均衡策略,智能化的流量管理,可達到最佳的負載均衡需求。負載均衡器有多種多樣的形式,除了作為獨立意義上的負載均衡器外,有些負載均衡器集成在交換設備中,置於伺服器與Internet鏈接之間,有些則以兩塊網路適配器將這一功能集成到PC中,一塊連接到Internet上,一塊連接到後端伺服器群的內部網路上。
     軟體負載均衡與硬體負載均衡的對比:
     軟體負載均衡的優點是需求環境明確,配置簡單,操作靈活,成本低廉,效率不高,能滿足普通的企業需求;缺點是依賴於系統,增加資源開銷;軟體的優劣決定環境的性能;系統的安全,軟體的穩定性均會影響到整個環境的安全。
     硬體負載均衡優點是獨立於系統,整體性能大量提升,在功能、性能上優於軟體方式;智能的流量管理,多種策略可選,能達到最佳的負載均衡效果;缺點是價格昂貴。
2)本地/全局負載均衡
     負載均衡從其應用的地理結構上分為本地負載均衡(Local Load Balance)和全局負載均衡(Global Load Balance,也叫地域負載均衡),本地負載均衡是指對本地的伺服器群做負載均衡,全局負載均衡是指對分別放置在不同的地理位置、有不同網路結構的伺服器群間作負載均衡。
     本地負載均衡能有效地解決數據流量過大、網路負荷過重的問題,並且不需花費昂貴開支購置性能卓越的伺服器,充分利用現有設備,避免伺服器單點故障造成數據流量的損失。其有靈活多樣的均衡策略把數據流量合理地分配給伺服器群內的伺服器共同負擔。即使是再給現有伺服器擴充升級,也只是簡單地增加一個新的伺服器到服務群中,而不需改變現有網路結構、停止現有的服務。 
     全局負載均衡主要用於在一個多區域擁有自己伺服器的站點,為了使全球用戶只以一個IP地址或功能變數名稱就能訪問到離自己最近的伺服器,從而獲得最快的訪問速度,也可用於子公司分散站點分佈廣的大公司通過Intranet(企業內部互聯網)來達到資源統一合理分配的目的。
3)網路層次上的負載均衡
     針對網路上負載過重的不同瓶頸所在,從網路的不同層次入手,我們可以採用相應的負載均衡技術來解決現有問題。 
隨著帶寬增加,數據流量不斷增大,網路核心部分的數據介面將面臨瓶頸問題,原有的單一線路將很難滿足需求,而且線路的升級又過於昂貴甚至難以實現,這時就可以考慮採用鏈路聚合(Trunking)技術。
     鏈路聚合技術(第二層負載均衡)將多條物理鏈路當作一條單一的聚合邏輯鏈路使用,網路數據流量由聚合邏輯鏈路中所有物理鏈路共同承擔,由此在邏輯上增大了鏈路的容量,使其能滿足帶寬增加的需求。
     現代負載均衡技術通常操作於網路的第四層或第七層。第四層負載均衡將一個Internet上合法註冊的IP地址映射為多個內部伺服器的IP地址,對每次 TCP連接請求動態使用其中一個內部IP地址,達到負載均衡的目的。在第四層交換機中,此種均衡技術得到廣泛的應用,一個目標地址是伺服器群VIP(虛擬 IP,Virtual IP address)連接請求的數據包流經交換機,交換機根據源端和目的IP地址、TCP或UDP埠號和一定的負載均衡策略,在伺服器IP和VIP間進行映射,選取伺服器群中最好的伺服器來處理連接請求。

七層負載均衡控制應用層服務的內容,提供了一種對訪問流量的高層控制方式,適合對HTTP伺服器群的應用。第七層負載均衡技術通過檢查流經的HTTP報頭,根據報頭內的信息來執行負載均衡任務。
七層負載均衡優點表現在如下幾個方面: 
1)通過對HTTP報頭的檢查,可以檢測出HTTP400、500和600系列的錯誤信息,因而能透明地將連接請求重新定向到另一臺伺服器,避免應用層故障。
2)可根據流經的數據類型(如判斷數據包是圖像文件、壓縮文件或多媒體文件格式等),把數據流量引向相應內容的伺服器來處理,增加系統性能。
3)能根據連接請求的類型,如是普通文本、圖象等靜態文檔請求,還是asp、cgi等的動態文檔請求,把相應的請求引向相應的伺服器來處理,提高系統的性能及安全性。
七層負載均衡缺點表現在如下幾個方面: 
1)七層負載均衡受到其所支持的協議限制(一般只有HTTP),這樣就限制了它應用的廣泛性。
2)七層負載均衡檢查HTTP報頭會占用大量的系統資源,勢必會影響到系統的性能,在大量連接請求的情況下,負載均衡設備自身容易成為網路整體性能的瓶頸。

5.    負載均衡策略

在實際應用中,我們可能不想僅僅是把客戶端的服務請求平均地分配給內部伺服器,而不管伺服器是否宕機。而是想使Pentium III伺服器比Pentium II能接受更多的服務請求,一臺處理服務請求較少的伺服器能分配到更多的服務請求,出現故障的伺服器將不再接受服務請求直至故障恢復等等。選擇合適的負載均衡策略,使多個設備能很好的共同完成任務,消除或避免現有網路負載分佈不均、數據流量擁擠反應時間長的瓶頸。在各負載均衡方式中,針對不同的應用需求,在OSI參考模型的第二、三、四、七層的負載均衡都有相應的負載均衡策略。
負載均衡策略的優劣及其實現的難易程度有兩個關鍵因素:負載均衡演算法;對網路系統狀況的檢測方式和能力。
1、負載均衡演算法
1)輪循均衡(Round Robin):每一次來自網路的請求輪流分配給內部中的伺服器,從1至N然後重新開始。此種均衡演算法適合於伺服器組中的所有伺服器都有相同的軟硬體配置並且平均服務請求相對均衡的情況。
2)權重輪循均衡(Weighted Round Robin):根據伺服器的不同處理能力,給每個伺服器分配不同的權值,使其能夠接受相應權值數的服務請求。例如:伺服器A的權值被設計成1,B的權值是 3,C的權值是6,則伺服器A、B、C將分別接受到10%、30%、60%的服務請求。此種均衡演算法能確保高性能的伺服器得到更多的使用率,避免低性能的伺服器負載過重。
3)隨機均衡(Random):把來自網路的請求隨機分配給內部中的多個伺服器。
4)權重隨機均衡(Weighted Random):此種均衡演算法類似於權重輪循演算法,不過在處理請求分擔時是個隨機選擇的過程。
5)響應速度均衡(Response Time):負載均衡設備對內部各伺服器發出一個探測請求(例如Ping),然後根據內部中各伺服器對探測請求的最快響應時間來決定哪一臺伺服器來響應客戶端的服務請求。此種均衡演算法能較好的反映伺服器的當前運行狀態,但這最快響應時間僅僅指的是負載均衡設備與伺服器間的最快響應時間,而不是客戶端與伺服器間的最快響應時間。
6)最少連接數均衡(Least Connection):客戶端的每一次請求服務在伺服器停留的時間可能會有較大的差異,隨著工作時間加長,如果採用簡單的輪循或隨機均衡演算法,每一臺伺服器上的連接進程可能會產生極大的不同,並沒有達到真正的負載均衡。最少連接數均衡演算法對內部中需負載的每一臺伺服器都有一個數據記錄,記錄當前該伺服器正在處理的連接數量,當有新的服務連接請求時,將把當前請求分配給連接數最少的伺服器,使均衡更加符合實際情況,負載更加均衡。此種均衡演算法適合長時處理的請求服務,如FTP。 
7)處理能力均衡:此種均衡演算法將把服務請求分配給內部中處理負荷(根據伺服器CPU型號、CPU數量、記憶體大小及當前連接數等換算而成)最輕的伺服器,由於考慮到了內部伺服器的處理能力及當前網路運行狀況,所以此種均衡演算法相對來說更加精確,尤其適合運用到第七層(應用層)負載均衡的情況下。
8)DNS響應均衡(Flash DNS):在Internet上,無論是HTTP、FTP或是其它的服務請求,客戶端一般都是通過功能變數名稱解析來找到伺服器確切的IP地址的。在此均衡演算法下,分處在不同地理位置的負載均衡設備收到同一個客戶端的功能變數名稱解析請求,併在同一時間內把此功能變數名稱解析成各自相對應伺服器的IP地址(即與此負載均衡設備在同一位地理位置的伺服器的IP地址)並返回給客戶端,則客戶端將以最先收到的功能變數名稱解析IP地址來繼續請求服務,而忽略其它的IP地址響應。在種均衡策略適合應用在全局負載均衡的情況下,對本地負載均衡是沒有意義的。
2、網路系統狀況的檢測方式
儘管有多種的負載均衡演算法可以較好的把數據流量分配給伺服器去負載,但如果負載均衡策略沒有對網路系統狀況的檢測方式和能力,一旦在某台伺服器或某段負載均衡設備與伺服器網路間出現故障的情況下,負載均衡設備依然把一部分數據流量引向那台伺服器,這勢必造成大量的服務請求被丟失,達不到不間斷可用性的要求。所以良好的負載均衡策略應有對網路故障、伺服器系統故障、應用服務故障的檢測方式和能力:
1)Ping偵測:通過ping的方式檢測伺服器及網路系統狀況,此種方式簡單快速,但只能大致檢測出網路及伺服器上的操作系統是否正常,對伺服器上的應用服務檢測就無能為力了。
2)TCP Open偵測:每個服務都會開放某個通過TCP連接,檢測伺服器上某個TCP埠(如Telnet的23口,HTTP的80口等)是否開放來判斷服務是否正常。
3)HTTP URL偵測:比如向HTTP伺服器發出一個對main.html文件的訪問請求,如果收到錯誤信息,則認為伺服器出現故障。
3、其他因素
負載均衡策略的優劣除受上面所講的兩個因素影響外,在有些應用情況下,我們需要將來自同一客戶端的所有請求都分配給同一臺伺服器去負擔,例如伺服器將客戶端註冊、購物等服務請求信息保存的本地資料庫的情況下,把客戶端的子請求分配給同一臺伺服器來處理就顯的至關重要了。有幾種方式可以解決此問題:
1)一是根據IP地址把來自同一客戶端的多次請求分配給同一臺伺服器處理,客戶端IP地址與伺服器的對應信息是保存在負載均衡設備上的;
2)二是在客戶端瀏覽器 cookie內做獨一無二的標識來把多次請求分配給同一臺伺服器處理,適合通過代理伺服器上網的客戶端。
3)還有一種路徑外返回模式(Out of Path Return),當客戶端連接請求發送給負載均衡設備的時候,中心負載均衡設備將請求引向某個伺服器,伺服器的回應請求不再返回給中心負載均衡設備,即繞過流量分配器,直接返回給客戶端,因此中心負載均衡設備只負責接受並轉發請求,其網路負擔就減少了很多,並且給客戶端提供了更快的響應時間。此種模式一般用於HTTP伺服器群,在各伺服器上要安裝一塊虛擬網路適配器,並將其IP地址設為伺服器群的VIP,這樣才能在伺服器直接回應客戶端請求時順利的達成三次握手。

6.    負載均衡實施要素

1)性能
性能是我們在引入均衡方案時需要重點考慮的問題,但也是一個最難把握的問題。衡量性能時可將每秒鐘通過網路的數據包數目做為一個參數,另一個參數是均衡方案中伺服器群所能處理的最大併發連接數目,但是,假設一個均衡系統能處理百萬計的併發連接數,可是卻只能以每秒2個包的速率轉發,這顯然是沒有任何作用的。性能的優劣與負載均衡設備的處理能力、採用的均衡策略息息相關,並且有兩點需要註意:一、均衡方案對伺服器群整體的性能,這是響應客戶端連接請求速度的關鍵;二、負載均衡設備自身的性能,避免有大量連接請求時自身性能不足而成為服務瓶頸。有時我們也可以考慮採用混合型負載均衡策略來提升伺服器群的總體性能,如DNS負載均衡與NAT負載均衡相結合。另外,針對有大量靜態文檔請求的站點,也可以考慮採用高速緩存技術,相對來說更節省費用,更能提高響應性能;對有大量ssl/xml內容傳輸的站點,更應考慮採用ssl/xml加速技術。
2)可擴展性
IT技術日新月異,一年以前最新的產品,現在或許已是網路中性能最低的產品;業務量的急速上升,一年前的網路,現在需要新一輪的擴展。合適的均衡解決方案應能滿足這些需求,能均衡不同操作系統和硬體平臺之間的負載,能均衡HTTP、郵件、新聞、代理、資料庫、防火牆和 Cache等不同伺服器的負載,並且能以對客戶端完全透明的方式動態增加或刪除某些資源。
3)靈活性
均衡解決方案應能靈活地提供不同的應用需求,滿足應用需求的不斷變化。在不同的伺服器群有不同的應用需求時,應有多樣的均衡策略提供更廣泛的選擇。
4)可靠性
在對服務質量要求較高的站點,負載均衡解決方案應能為伺服器群提供完全的容錯性和高可用性。但在負載均衡設備自身出現故障時,應該有良好的冗餘解決方案,提高可靠性。使用冗餘時,處於同一個冗餘單元的多個負載均衡設備必須具有有效的方式以便互相進行監控,保護系統儘可能地避免遭受到重大故障的損失。
5)易管理性
管是通過軟體還是硬體方式的均衡解決方案,我們都希望它有靈活、直觀和安全的管理方式,這樣便於安裝、配置、維護和監控,提高工作效率,避免差錯。在硬體負載均衡設備上,目前主要有三種管理方式可供選擇:一、命令行介面(CLI:Command Line Interface),可通過超級終端連接負載均衡設備串列介面來管理,也能telnet遠程登錄管理,在初始化配置時,往往要用到前者;二、圖形用戶介面(GUI:Graphical User Interfaces),有基於普通web頁的管理,也有通過Java Applet 進行安全管理,一般都需要管理端安裝有某個版本的瀏覽器;三、SNMP(Simple Network Management Protocol,簡單網路管理協議)支持,通過第三方網路管理軟體對符合SNMP標準的設備進行管理。

 


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 本文是為了學習ABP的使用,是翻譯ABP官方文檔的一篇實戰教程,我暫時是優先翻譯自己感興趣或者比較想學習的部分,後續有時間希望能將ABP系列翻譯出來,除了自己能學習外,有可能的話希望幫助一些英文閱讀能力稍微差一點的同學(當然我自己也不一定翻譯的多好,大家共同學習)。 其實這篇文章也花了我一些時間,突 ...
  • 本文主要是對 ".NET Core開發日誌——Middleware" 的補遺,但是會從看起來平平無奇的RequestDelegate開始敘述,所以以其作為標題,也是合情合理。 RequestDelegate是一種委托類型,其全貌為 ,MSDN上對它的解釋,"A function that can p ...
  • 一、知識介紹 ①ASP.NET 使用的是MVC模式,開發工具Visual studio ,語言C# ②Oracle是比較重型的資料庫,這裡主要介紹連接資料庫,對數據進行具體的使用 ③Visual Studio連接資料庫都是需要dll文件,方法相似。 二、步驟 ①新建一個ASP項目 ②右擊項目或引用, ...
  • [TOC] MEF 在 WPF 中的簡單應用 MEF 的開發模式主要適用於插件化的業務場景中,C/S 和 B/S 中都有相應的使用場景,其中包括但不限於 、 、`WPF UWP DotNet Core` 也是支持的。 在上篇文章中,筆者大致講述如果在控制台程式中創建一個簡單的 MEF 應用程式。如果 ...
  • 專為解答C#初級問題 QQ 群 731738614 ...
  • 判斷連網的方法介紹 1. InternetGetConnectedState 此函數獲取網路狀態有延時,且對網卡傷害較大 MSDN官方自己推薦不建議使用,不管是連網狀態下還是斷網情況下,獲取的網路狀態都有不准確的案例,如下: (BUG) InternetGetConnectedState API r ...
  • //從微信伺服器中下載文件到本地 public JsonResult UploadRecord(string ServerId) { try { member m = base.CurrentUser; string msg = "成功"; bool success = true; SiteSett ...
  • SSH是什麼 1. Secure Shell 安全外殼協議 2. 建立在應用層基礎上的安全協議 3. 可靠、轉為遠程登陸會話和其他網路提供安全性的協議 4. SSH客戶端是用於多種平臺 伺服器安裝SSH服務 1. 安裝: 2. 啟動: 3. 設置開啟運行: 4. 查看進程是否存在: 客戶端安裝SSH ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...