天天看點

詳談群集計劃與負載均衡

并行叢集計算僅是面向高速計算方面的一種應用,負載均衡則是為多個伺服器高可用性服務提供保障的一種技術。負載均衡可用于多種應用系統,如:Web、檔案傳輸ftp、電子商務、資料流多媒體、DNA和郵件等。

下面有篇文章講得不錯,可供參考(有兩張圖看不到很可惜)

Internet的規模每一百天就會增長一倍,客戶希望獲得7天24小時的不間斷可用性及較快的系統反應時間,而不願屢次看到某個站點“Server Too Busy”及頻繁的系統故障。  網絡的各個核心部分随着業務量的提高、通路量和資料流量的快速增長,其處理能力和計算強度也相應增大,使得單一裝置根本無法承擔。在此情況下,如果扔掉現有裝置去做大量的硬體更新,這樣将造成現有資源的浪費,而且如果再面臨下一次業務量的提升,這又将導緻再一次硬體更新的高額成本投入,甚至性能再卓越的裝置也不能滿足目前業務量的需求。于是,負載均衡機制應運而生。  負載均衡(Load Balance)建立在現有網絡結構之上,它提供了一種廉價有效透明的方法擴充網絡裝置和伺服器的帶寬、增加吞吐量、加強網絡資料處理能力、提高網絡的靈活性和可用性。  負載均衡有兩方面的含義:首先,大量的并發通路或資料流量分擔到多台節點裝置上分别處理,減少使用者等待響應的時間;其次,單個重負載的運算分擔到多台節點裝置上做并行處理,每個節點裝置處理結束後,将結果彙總,傳回給使用者,系統處理能力得到大幅度提高。  本文所要介紹的負載均衡技術主要是指在均衡伺服器群中所有伺服器和應用程式之間流量負載的應用,目前負載均衡技術大多數是用于提高諸如在Web伺服器、FTP伺服器和其它關鍵任務伺服器上的Internet伺服器程式的可用性和可伸縮性。 負載均衡技術分類   目前有許多不同的負載均衡技術用以滿足不同的應用需求,下面從負載均衡所采用的裝置對象、應用的網絡層次(指OSI參考模型)及應用的地理結構等來分類。軟/硬體負載均衡   軟體負載均衡解決方案是指在一台或多台伺服器相應的作業系統上安裝一個或多個附加軟體來實作負載均衡,如DNS Load Balance,CheckPoint Firewall-1 ConnectControl等,它的優點是基于特定環境,配置簡單,使用靈活,成本低廉,可以滿足一般的負載均衡需求。  軟體解決方案缺點也較多,因為每台伺服器上安裝額外的軟體運作會消耗系統不定量的資源,越是功能強大的子產品,消耗得越多,是以當連接配接請求特别大的時候,軟體本身會成為伺服器工作成敗的一個關鍵;軟體可擴充性并不是很好,受到作業系統的限制;由于作業系統本身的Bug,往往會引起安全問題。  硬體負載均衡解決方案是直接在伺服器和外部網絡間安裝負載均衡裝置,這種裝置我們通常稱之為負載均衡器,由于專門的裝置完成專門的任務,獨立于作業系統,整體性能得到大量提高,加上多樣化的負載均衡政策,智能化的流量管理,可達到最佳的負載均衡需求。  負載均衡器有多種多樣的形式,除了作為獨立意義上的負載均衡器外,有些負載均衡器內建在交換裝置中,置于伺服器與Internet連結之間,有些則以兩塊網絡擴充卡将這一功能內建到PC中,一塊連接配接到Internet上,一塊連接配接到後端伺服器群的内部網絡上。  一般而言,硬體負載均衡在功能、性能上優于軟體方式,不過成本昂貴。   本地/全局負載均衡  負載均衡從其應用的地理結構上分為本地負載均衡(Local Load Balance)和全局負載均衡(Global Load Balance,也叫地域負載均衡),本地負載均衡是指對本地的伺服器群做負載均衡,全局負載均衡是指對分别放置在不同的地理位置、有不同網絡結構的伺服器群間作負載均衡。  本地負載均衡能有效地解決資料流量過大、網絡負荷過重的問題,并且不需花費昂貴開支購置性能卓越的伺服器,充分利用現有裝置,避免伺服器單點故障造成資料流量的損失。其有靈活多樣的均衡政策把資料流量合理地配置設定給伺服器群内的伺服器共同負擔。即使是再給現有伺服器擴充更新,也隻是簡單地增加一個新的伺服器到服務群中,而不需改變現有網絡結構、停止現有的服務。  全局負載均衡主要用于在一個多區域擁有自己伺服器的站點,為了使全球使用者隻以一個IP位址或域名就能通路到離自己最近的伺服器,進而獲得最快的通路速度,也可用于子公司分散站點分布廣的大公司通過Intranet(企業内部網際網路)來達到資源統一合理配置設定的目的。  全局負載均衡有以下的特點: 實作地理位置無關性,能夠遠距離為使用者提供完全的透明服務。 除了能避免伺服器、資料中心等的單點失效,也能避免由于ISP專線故障引起的單點失效。 解決網絡擁塞問題,提高伺服器響應速度,服務就近提供,達到更好的通路品質。 網絡層次上的負載均衡  針對網絡上負載過重的不同瓶頸所在,從網絡的不同層次入手,我們可以采用相應的負載均衡技術來解決現有問題。  随着帶寬增加,資料流量不斷增大,網絡核心部分的資料接口将面臨瓶頸問題,原有的單一線路将很難滿足需求,而且線路的更新又過于昂貴甚至難以實作,這時就可以考慮采用鍊路聚合(Trunking)技術。  鍊路聚合技術(第二層負載均衡)将多條實體鍊路當作一條單一的聚合邏輯鍊路使用,網絡資料流量由聚合邏輯鍊路中所有實體鍊路共同承擔,由此在邏輯上增大了鍊路的容量,使其能滿足帶寬增加的需求。  現代負載均衡技術通常操作于網絡的第四層或第七層。第四層負載均衡将一個Internet上合法注冊的IP位址映射為多個内部伺服器的IP位址,對每次TCP連接配接請求動态使用其中一個内部IP位址,達到負載均衡的目的。在第四層交換機中,此種均衡技術得到廣泛的應用,一個目标位址是伺服器群VIP(虛拟IP,Virtual IP address)連接配接請求的資料包流經交換機,交換機根據源端和目的IP位址、TCP或UDP端口号和一定的負載均衡政策,在伺服器IP和VIP間進行映射,選取伺服器群中最好的伺服器來處理連接配接請求。  第七層負載均衡控制應用層服務的内容,提供了一種對通路流量的高層控制方式,适合對HTTP伺服器群的應用。第七層負載均衡技術通過檢查流經的HTTP報頭,根據報頭内的資訊來執行負載均衡任務。  第七層負載均衡優點表現在如下幾個方面: 通過對HTTP報頭的檢查,可以檢測出HTTP400、500和600系列的錯誤資訊,因而能透明地将連接配接請求重新定向到另一台伺服器,避免應用層故障。 可根據流經的資料類型(如判斷資料包是圖像檔案、壓縮檔案或多媒體檔案格式等),把資料流量引向相應内容的伺服器來處理,增加系統性能。 能根據連接配接請求的類型,如是普通文本、圖象等靜态文檔請求,還是asp、cgi等的動态文檔請求,把相應的請求引向相應的伺服器來處理,提高系統的性能及安全性。   第七層負載均衡受到其所支援的協定限制(一般隻有HTTP),這樣就限制了它應用的廣泛性,并且檢查HTTP報頭會占用大量的系統資源,勢必會影響到系統的性能,在大量連接配接請求的情況下,負載均衡裝置自身容易成為網絡整體性能的瓶頸。 在實際應用中,我們可能不想僅僅是把用戶端的服務請求平均地配置設定給内部伺服器,而不管伺服器是否當機。而是想使Pentium III伺服器比Pentium II能接受更多的服務請求,一台處理服務請求較少的伺服器能配置設定到更多的服務請求,出現故障的伺服器将不再接受服務請求直至故障恢複等等。  選擇合适的負載均衡政策,使多個裝置能很好的共同完成任務,消除或避免現有網絡負載分布不均、資料流量擁擠反應時間長的瓶頸。在各負載均衡方式中,針對不同的應用需求,在OSI參考模型的第二、三、四、七層的負載均衡都有相應的負載均衡政策。   負載均衡政策的優劣及其實作的難易程度有兩個關鍵因素:一、負載均衡算法,二、對網絡系統狀況的檢測方式和能力。  考慮到服務請求的不同類型、伺服器的不同處理能力以及随機選擇造成的負載配置設定不均勻等問題,為了更加合理的把負載配置設定給内部的多個伺服器,就需要應用相應的能夠正确反映各個伺服器處理能力及網絡狀态的負載均衡算法:輪循均衡(Round Robin):每一次來自網絡的請求輪流配置設定給内部中的伺服器,從1至N然後重新開始。此種均衡算法适合于伺服器組中的所有伺服器都有相同的軟硬體配置并且平均服務請求相對均衡的情況。 權重輪循均衡(Weighted Round Robin):根據伺服器的不同處理能力,給每個伺服器配置設定不同的權值,使其能夠接受相應權值數的服務請求。例如:伺服器A的權值被設計成1,B的權值是3,C的權值是6,則伺服器A、B、C将分别接受到10%、30%、60%的服務請求。此種均衡算法能確定高性能的伺服器得到更多的使用率,避免低性能的伺服器負載過重。 随機均衡(Random):把來自網絡的請求随機配置設定給内部中的多個伺服器。 權重随機均衡(Weighted Random):此種均衡算法類似于權重輪循算法,不過在處理請求分擔時是個随機選擇的過程。 響應速度均衡(Response Time):負載均衡裝置對内部各伺服器發出一個探測請求(例如Ping),然後根據内部中各伺服器對探測請求的最快響應時間來決定哪一台伺服器來響應用戶端的服務請求。此種均衡算法能較好的反映伺服器的目前運作狀态,但這最快響應時間僅僅指的是負載均衡裝置與伺服器間的最快響應時間,而不是用戶端與伺服器間的最快響應時間。最少連接配接數均衡(Least Connection):用戶端的每一次請求服務在伺服器停留的時間可能會有較大的差異,随着工作時間加長,如果采用簡單的輪循或随機均衡算法,每一台伺服器上的連接配接程序可能會産生極大的不同,并沒有達到真正的負載均衡。最少連接配接數均衡算法對内部中需負載的每一台伺服器都有一個資料記錄,記錄目前該伺服器正在處理的連接配接數量,當有新的服務連接配接請求時,将把目前請求配置設定給連接配接數最少的伺服器,使均衡更加符合實際情況,負載更加均衡。此種均衡算法适合長時處理的請求服務,如FTP。處理能力均衡:此種均衡算法将把服務請求配置設定給内部中處理負荷(根據伺服器CPU型号、CPU數量、記憶體大小及目前連接配接數等換算而成)最輕的伺服器,由于考慮到了内部伺服器的處理能力及目前網絡運作狀況,是以此種均衡算法相對來說更加精确,尤其适合運用到第七層(應用層)負載均衡的情況下。 DNS響應均衡(Flash DNS):在Internet上,無論是HTTP、FTP或是其它的服務請求,用戶端一般都是通過域名解析來找到伺服器确切的IP位址的。在此均衡算法下,分處在不同地理位置的負載均衡裝置收到同一個用戶端的域名解析請求,并在同一時間内把此域名解析成各自相對應伺服器的IP位址(即與此負載均衡裝置在同一位地理位置的伺服器的IP位址)并傳回給用戶端,則用戶端将以最先收到的域名解析IP位址來繼續請求服務,而忽略其它的IP位址響應。在種均衡政策适合應用在全局負載均衡的情況下,對本地負載均衡是沒有意義的。 盡管有多種的負載均衡算法可以較好的把資料流量配置設定給伺服器去負載,但如果負載均衡政策沒有對網絡系統狀況的檢測方式和能力,一旦在某台伺服器或某段負載均衡裝置與伺服器網絡間出現故障的情況下,負載均衡裝置依然把一部分資料流量引向那台伺服器,這勢必造成大量的服務請求被丢失,達不到不間斷可用性的要求。是以良好的負載均衡政策應有對網絡故障、伺服器系統故障、應用服務故障的檢測方式和能力:Ping偵測:通過ping的方式檢測伺服器及網絡系統狀況,此種方式簡單快速,但隻能大緻檢測出網絡及伺服器上的作業系統是否正常,對伺服器上的應用服務檢測就無能為力了。 TCP Open偵測:每個服務都會開放某個通過TCP連接配接,檢測伺服器上某個TCP端口(如Telnet的23口,HTTP的80口等)是否開放來判斷服務是否正常。 HTTP URL偵測:比如向HTTP伺服器發出一個對main.html檔案的通路請求,如果收到錯誤資訊,則認為伺服器出現故障。   負載均衡政策的優劣除受上面所講的兩個因素影響外,在有些應用情況下,我們需要将來自同一用戶端的所有請求都配置設定給同一台伺服器去負擔,例如伺服器将用戶端注冊、購物等服務請求資訊儲存的本地資料庫的情況下,把用戶端的子請求配置設定給同一台伺服器來處理就顯的至關重要了。有兩種方式可以解決此問題,一是根據IP位址把來自同一用戶端的多次請求配置設定給同一台伺服器處理,用戶端IP位址與伺服器的對應資訊是儲存在負載均衡裝置上的;二是在用戶端浏覽器cookie内做獨一無二的辨別來把多次請求配置設定給同一台伺服器處理,适合通過代理伺服器上網的用戶端。

還有一種路徑外傳回模式(Out of Path Return),當用戶端連接配接請求發送給負載均衡裝置的時候,中心負載均衡裝置将請求引向某個伺服器,伺服器的回應請求不再傳回給中心負載均衡裝置,即繞過流量配置設定器,直接傳回給用戶端,是以中心負載均衡裝置隻負責接受并轉發請求,其網絡負擔就減少了很多,并且給用戶端提供了更快的響應時間。此種模式一般用于HTTP伺服器群,在各伺服器上要安裝一塊虛拟網絡擴充卡,并将其IP位址設為伺服器群的VIP,這樣才能在伺服器直接回應用戶端請求時順利的達成三次握手。

負載均衡實施要素   負載均衡方案應是在網站建設初期就應考慮的問題,不過有時随着通路流量的爆炸性增長,超出決策者的意料,這也就成為不得不面對的問題。當我們在引入某種負載均衡方案乃至具體實施時,像其他的許多方案一樣,首先是确定目前及将來的應用需求,然後在代價與收效之間做出權衡。  針對目前及将來的應用需求,分析網絡瓶頸的不同所在,我們就需要确立是采用哪一類的負載均衡技術,采用什麼樣的均衡政策,在可用性、相容性、安全性等等方面要滿足多大的需求,如此等等。  不管負載均衡方案是采用花費較少的軟體方式,還是購買代價高昂在性能功能上更強的第四層交換機、負載均衡器等硬體方式來實作,亦或其他種類不同的均衡技術,下面這幾項都是我們在引入均衡方案時可能要考慮的問題: 性能:性能是我們在引入均衡方案時需要重點考慮的問題,但也是一個最難把握的問題。衡量性能時可将每秒鐘通過網絡的資料包數目做為一個參數,另一個參數是均衡方案中伺服器群所能處理的最大并發連接配接數目,但是,假設一個均衡系統能處理百萬計的并發連接配接數,可是卻隻能以每秒2個包的速率轉發,這顯然是沒有任何作用的。 性能的優劣與負載均衡裝置的處理能力、采用的均衡政策息息相關,并且有兩點需要注意:一、均衡方案對伺服器群整體的性能,這是響應用戶端連接配接請求速度的關鍵;二、負載均衡裝置自身的性能,避免有大量連接配接請求時自身性能不足而成為服務瓶頸。 有時我們也可以考慮采用混合型負載均衡政策來提升伺服器群的總體性能,如DNS負載均衡與NAT負載均衡相結合。另外,針對有大量靜态文檔請求的站點,也可以考慮采用高速緩存技術,相對來說更節省費用,更能提高響應性能;對有大量ssl/xml内容傳輸的站點,更應考慮采用ssl/xml加速技術。 可擴充性:IT技術日新月異,一年以前最新的産品,現在或許已是網絡中性能最低的産品;業務量的急速上升,一年前的網絡,現在需要新一輪的擴充。合适的均衡解決方案應能滿足這些需求,能均衡不同作業系統和硬體平台之間的負載,能均衡HTTP、郵件、新聞、代理、資料庫、防火牆和 Cache等不同伺服器的負載,并且能以對用戶端完全透明的方式動态增加或删除某些資源。 靈活性:均衡解決方案應能靈活地提供不同的應用需求,滿足應用需求的不斷變化。在不同的伺服器群有不同的應用需求時,應有多樣的均衡政策提供更廣泛的選擇。 可靠性:在對服務品質要求較高的站點,負載均衡解決方案應能為伺服器群提供完全的容錯性和高可用性。但在負載均衡裝置自身出現故障時,應該有良好的備援解決方案,提高可靠性。使用備援時,處于同一個備援單元的多個負載均衡裝置必須具有有效的方式以便互相進行監控,保護系統盡可能地避免遭受到重大故障的損失。 易管理性:不管是通過軟體還是硬體方式的均衡解決方案,我們都希望它有靈活、直覺和安全的管理方式,這樣便于安裝、配置、維護和監控,提高工作效率,避免差錯。在硬體負載均衡裝置上,目前主要有三種管理方式可供選擇:一、指令行接口(CLI:Command Line Interface),可通過超級終端連接配接負載均衡裝置串行接口來管理,也能telnet遠端登入管理,在初始化配置時,往往要用到前者;二、圖形使用者接口(GUI:Graphical User Interfaces),有基于普通web頁的管理,也有通過Java Applet 進行安全管理,一般都需要管理端安裝有某個版本的浏覽器;三、SNMP(Simple Network Management Protocol,簡單網絡管理協定)支援,通過第三方網絡管理軟體對符合SNMP标準的裝置進行管理。   負載均衡配置執行個體 DNS負載均衡   DNS負載均衡技術是在DNS伺服器中為同一個主機名配置多個IP位址,在應答DNS查詢時,DNS伺服器對每個查詢将以DNS檔案中主機記錄的IP位址按順序傳回不同的解析結果,将用戶端的通路引導到不同的機器上去,使得不同的用戶端通路不同的伺服器,進而達到負載均衡的目的。  DNS負載均衡的優點是經濟簡單易行,并且伺服器可以位于internet上任意的位置。但它也存在不少缺點: 為了使本DNS伺服器和其他DNS伺服器及時互動,保證DNS資料及時更新,使位址能随機配置設定,一般都要将DNS的重新整理時間設定的較小,但太小将會使DNS流量大增造成額外的網絡問題。 一旦某個伺服器出現故障,即使及時修改了DNS設定,還是要等待足夠的時間(重新整理時間)才能發揮作用,在此期間,儲存了故障伺服器位址的客戶計算機将不能正常通路伺服器。 DNS負載均衡采用的是簡單的輪循負載算法,不能區分伺服器的差異,不能反映伺服器的目前運作狀态,不能做到為性能較好的伺服器多配置設定請求,甚至會出現客戶請求集中在某一台伺服器上的情況。 要給每台伺服器配置設定一個internet上的IP位址,這勢必會占用過多的IP位址。   判斷一個站點是否采用了DNS負載均衡的最簡單方式就是連續的ping這個域名,如果多次解析傳回的IP位址不相同的話,那麼這個站點就很可能采用的就是較為普遍的DNS負載均衡。但也不一定,因為如果采用的是DNS響應均衡,多次解析傳回的IP位址也可能會不相同。不妨試試Ping一下www.yesky.com,www.sohu.com,www.yahoo.com。  現假設有三台伺服器來應對www.test.com的請求。在采用BIND 8.x DNS伺服器的unix系統上實作起來比較簡單,隻需在該域的資料記錄中添加類似下面的結果:   www1 IN A       192.1.1.1   www2 IN A       192.1.1.2   www3 IN A       192.1.1.3   www     IN CNAME    www1  www     IN CNAME    www2  www     IN CNAME    www3  在NT下的實作也很簡單,下面詳細介紹在win2000 server下實作DNS負載均衡的過程,NT4.0類似:打開“管理工具”下的“DNS”,進入DNS服務配置控制台。 打開相應DNS 伺服器的“屬性”,在“進階”頁籤的“伺服器選項”中,選中“啟用循環”複選框。此步相當于在系統資料庫記錄HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDNSParameters中添加一個雙位元組制值(dword值)RoundRobin,值為1。 打開正向搜尋區域的相應區域(如test.com),建立主機添加主機 (A) 資源記錄,記錄如下: www IN A       192.1.1.1 www IN A       192.1.1.2 www IN A       192.1.1.3 在這裡可以看到的差別是在NT下一個主機名對應多個IP位址記錄,但在unix下,是先添加多個不同的主機名分别對應個自的IP位址,然後再把這些主機賦同一個别名(CNAME)來實作的。 在此需要注意的是,NT下本地子網優先級會取代多宿主名稱的循環複用,是以在測試時,如果做測試用的客戶機IP位址與主機資源記錄的IP在同一有類掩碼範圍内,就需要清除在“進階”頁籤“伺服器選項”中的“啟用netmask排序”。 NAT負載均衡  NAT(Network Address Translation 網絡位址轉換)簡單地說就是将一個IP位址轉換為另一個IP位址,一般用于未經注冊的内部位址與合法的、已獲注冊的Internet IP位址間進行轉換。适用于解決Internet IP位址緊張、不想讓網絡外部知道内部網絡結構等的場合下。每次NAT轉換勢必會增加NAT裝置的開銷,但這種額外的開銷對于大多數網絡來說都是微不足道的,除非在高帶寬有大量NAT請求的網絡上。  NAT負載均衡将一個外部IP位址映射為多個内部IP位址,對每次連接配接請求動态地轉換為一個内部伺服器的位址,将外部連接配接請求引到轉換得到位址的那個伺服器上,進而達到負載均衡的目的。  NAT負載均衡是一種比較完善的負載均衡技術,起着NAT負載均衡功能的裝置一般處于内部伺服器到外部網間的網關位置,如路由器、防火牆、四層交換機、專用負載均衡器等,均衡算法也較靈活,如随機選擇、最少連接配接數及響應時間等來配置設定負載。   NAT負載均衡可以通過軟硬體方式來實作。通過軟體方式來實作NAT負載均衡的裝置往往受到帶寬及系統本身處理能力的限制,由于NAT比較接近網絡的低層,是以就可以将它內建在硬體裝置中,通常這樣的硬體裝置是第四層交換機和專用負載均衡器,第四層交換機的一項重要功能就是NAT負載均衡。   下面以執行個體介紹一下Cisco路由器NAT負載均衡的配置:   現有一台有一個串行接口和一個Ethernet接口的路由器,Ethernet口連接配接到内部網絡,内部網絡上有三台web伺服器,但都隻是低端配置,為了處理好來自Internet上大量的web連接配接請求,是以需要在此路由器上做NAT負載均衡配置,把發送到web伺服器合法Internet IP位址的封包轉換成這三台伺服器的内部本地位址。 其具體配置過程如下: 做好路由器的基本配置,并定義各個接口在做NAT時是内部還是外部接口。 然後定義一個标準通路清單(standard access list),用來辨別要轉換的合法IP位址。 再定義NAT位址池來辨別内部web伺服器的本地位址,注意要用到關鍵字rotary,表明我們要使用輪循(Round Robin)的方式從NAT位址池中取出相應IP位址來轉換合法IP封包。 最後,把目标位址為通路表中IP的封包轉換成位址池中定義的IP位址。   相應配置檔案如下:interface Ethernet0/0ip address 192.168.1.4 255.255.255.248ip nat inside!interface Serial0/0ip address 200.200.1.1 255.255.255.248 ip nat outside! ip access-list 1 permit 200.200.1.2!ip nat pool websrv 192.168.1.1 192.168.1.3 netmask 255.255.255.248 type rotary ip nat inside destination list 1 pool websrv   反向代理負載均衡  普通代理方式是代理内部網絡使用者通路internet上伺服器的連接配接請求,用戶端必須指定代理伺服器,并将本來要直接發送到internet上伺服器的連接配接請求發送給代理伺服器處理。  反向代理(Reverse Proxy)方式是指以代理伺服器來接受internet上的連接配接請求,然後将請求轉發給内部網絡上的伺服器,并将從伺服器上得到的結果傳回給internet上請求連接配接的用戶端,此時代理伺服器對外就表現為一個伺服器。  反向代理負載均衡技術是把将來自internet上的連接配接請求以反向代理的方式動态地轉發給内部網絡上的多台伺服器進行處理,進而達到負載均衡的目的。   反向代理負載均衡能以軟體方式來實作,如apache mod_proxy、netscape proxy等,也可以在高速緩存器、負載均衡器等硬體裝置上實作。 反向代理負載均衡可以将優化的負載均衡政策和代理伺服器的高速緩存技術結合在一起,提升靜态網頁的通路速度,提供有益的性能;由于網絡外部使用者不能直接通路真實的伺服器,具備額外的安全性(同理,NAT負載均衡技術也有此優點)。  其缺點主要表現在以下兩個方面: 反向代理是處于OSI參考模型第七層應用的,是以就必須為每一種應用服務專門開發一個反向代理伺服器,這樣就限制了反向代理負載均衡技術的應用範圍,現在一般都用于對web伺服器的負載均衡。 針對每一次代理,代理伺服器就必須打開兩個連接配接,一個對外,一個對内,是以在并發連接配接請求數量非常大的時候,代理伺服器的負載也就非常大了,在最後代理伺服器本身會成為服務的瓶頸。   一般來講,可以用它來對連接配接數量不是特别大,但每次連接配接都需要消耗大量處理資源的站點進行負載均衡,如search。   下面以在apache mod_proxy下做的反向代理負載均衡為配置執行個體:在站點www.test.com,我們按提供的内容進行分類,不同的伺服器用于提供不同的内容服務,将對http://www.test.com/news的通路轉到IP位址為192.168.1.1的内部伺服器上處理,對http://www.test.com/it的通路轉到伺服器192.168.1.2上,對http://www.test.com/life的通路轉到伺服器192.168.1.3上,對http://www.test.com/love的通路轉到合作站點http://www.love.com上,進而減輕本apache伺服器的負擔,達到負載均衡的目的。  首先要确定域名www.test.com在DNS上的記錄對應apache伺服器接口上具有internet合法注冊的IP位址,這樣才能使internet上對www.test.com的所有連接配接請求發送給本台apache伺服器。  在本台伺服器的apache配置檔案httpd.conf中添加如下設定:   proxypass     /news    http://192.168.1.1   proxypass     /it    http://192.168.1.2   proxypass     /life     http://192.168.1.3   proxypass     /love     http://www.love.com   注意,此項設定最好添加在httpd.conf檔案“Section 2”以後的位置,伺服器192.168.1.1-3也應是具有相應功能的www伺服器,在重新開機服務時,最好用apachectl configtest指令檢查一下配置是否有誤。

混合型負載均衡  在有些大型網絡,由于多個伺服器群内硬體裝置、各自的規模、提供的服務等的差異,我們可以考慮給每個伺服器群采用最合适的負載均衡方式,然後又在這多個伺服器群間再一次負載均衡或群集起來以一個整體向外界提供服務(即把這多個伺服器群當做一個新的伺服器群),進而達到最佳的性能。我們将這種方式稱之為混合型負載均衡。此種方式有時也用于單台均衡裝置的性能不能滿足大量連接配接請求的情況下。   下圖展示了一個應用示例,三個伺服器群針對各自的特點,分别采用了不同的負載均衡方式。當用戶端發出域名解析請求時,DNS伺服器依次把它解析成三個伺服器群的VIP,如此把用戶端的連接配接請求分别引向三個伺服器群,進而達到了再一次負載均衡的目的。  在圖中大家可能注意到,負載均衡裝置在網絡拓樸上,可以處于外部網和内部網絡間網關的位置,也可以和内部伺服器群處于并行的位置,甚至可以處于内部網絡或internet上的任意位置,特别是在采用群集負載均衡時,根本就沒有單獨的負載均衡裝置。   伺服器群内各伺服器隻有提供相同内容的服務才有負載均衡的意義,特别是在DNS負載均衡時。要不然,這樣會造成大量連接配接請求的丢失或由于多次傳回内容的不同給客戶造成混亂。  是以,如圖的這個示例在實際中可能沒有多大的意義,因為如此大的服務内容相同但各伺服器群存在大量差異的網站并不多見。 但做為一個示例,相信還是很有參考意義的。