Copyright © 2012 杭州華三通信技術有限公司 版權所有,保留一切權利。 非經本公司書麵許可,任何單位和個人不得擅自摘抄、複製本文檔內容的部分或全部, 並不得以任何形式傳播。本文檔中的信息可能變動,恕不另行通知。 |
隨著Internet的快速發展和業務量的不斷提高,基於網絡的數據訪問流量迅速增長,特別是對數據中心、大型企業以及門戶網站等的訪問,其訪問流量甚至達到了10Gb/s的級別;同時,服務器網站借助HTTP、FTP、SMTP等應用程序,為訪問者提供了越來越豐富的內容和信息,服務器逐漸被數據淹沒;另外,大部分網站(尤其電子商務等網站)都需要提供不間斷24小時服務,任何服務中斷或通信中的關鍵數據丟失都會造成直接的商業損失。所有這些都對應用服務提出了高性能和高可靠性的需求。
但是,相對於網絡技術的發展,服務器處理速度和內存訪問速度的增長卻遠遠低於網絡帶寬和應用服務的增長,網絡帶寬增長的同時帶來的用戶數量的增長,也使得服務器資源消耗嚴重,因而服務器成為了網絡瓶頸。傳統的單機模式,也往往成為網絡故障點。
圖1 現有網絡的不足
針對以上情況,有以下幾種解決方案:
(1) 服務器進行硬件升級:采用高性能服務器替換現有低性能服務器。
該方案的弊端:
· 高成本:高性能服務器價格昂貴,需要高額成本投入,而原有低性能服務器被閑置,造成資源浪費。
· 可擴展性差:每一次業務量的提升,都將導致再一次硬件升級的高額成本投入,性能再卓越的設備也無法滿足當前業務量的發展趨勢。
· 無法完全解決現在網絡中麵臨的問題:如單點故障問題,服務器資源不夠用問題等。
(2) 組建服務器集群,利用負載均衡技術在服務器集群間進行業務均衡。
多台服務器通過網絡設備相連組成一個服務器集群,每台服務器都提供相同或相似的網絡服務。服務器集群前端部署一台負載均衡設備,負責根據已配置的均衡策略將用戶請求在服務器集群中分發,為用戶提供服務,並對服務器可用性進行維護。
該方案的優勢:
· 低成本:按照業務量增加服務器個數即可;已有資源不會浪費,新增資源無需選擇昂貴的高端設備。
· 可擴展性:當業務量增長時,係統可通過增加服務器來滿足需求,且不影響已有業務,不降低服務質量。
· 高可靠性:單台服務器故障時,由負載均衡設備將後續業務轉向其他服務器,不影響後續業務提供,保證業務不中斷。
圖2 負載均衡技術
SSL VPN網關、IPsec網關、防火牆網關等網關設備,因為業務處理的複雜性,往往成為網絡瓶頸。以防火牆網關為例:防火牆作為網絡部署的“警衛”,在網絡中不可或缺,但其往往不得不麵臨這樣的尷尬:網絡防衛越嚴格,需要越仔細盤查過往的報文,從而導致轉發性能越低,成為網絡瓶頸。
在這種情況,如果廢棄現有設備去做大量的硬件升級,必將造成資源浪費,隨著業務量的不斷提升,設備也將頻繁升級。頻繁升級的高成本是相當可怕的。因此將網關設備等同於服務器,組建網關集群的方案應運而生:將多個網關設備並聯到網絡中,從而形成集群,提高網絡處理能力。
信息時代,工作越來越離不開網絡,為了規避運營商出口故障帶來的網絡可用性風險,和解決網絡帶寬不足帶來的網絡訪問問題,企業往往會租用兩個或多個運營商出口(如:電信、網通等)。如何合理運用多個運營商出口,既不造成資源浪費,又能很好的服務於企業?傳統的策略路由可以在一定程度上解決該問題,但是策略路由配置不方便,而且不夠靈活,無法動態適應網絡結構變化,且策略路由無法根據帶寬進行報文分發,造成高吞吐量的鏈路無法得到充分利用。鏈路負載均衡技術通過動態算法,能夠在多條鏈路中進行負載均衡,算法配置簡單,且具有自適應能力,能很好的解決上述問題。
隨著社會各領域全球化進程的日益深化,實現各方麵信息的全球共享成為人們的迫切需求。然而,無論用戶的數據中心內部采用多麼完善的冗餘機製、安全的防範工具以及先進的負載均衡技術,單個數據中心的運行方式仍然不能保證關鍵業務的7×24小時不間斷運行。此外,單一的數據中心也無法使廣域範圍內全球各地用戶在訪問應用時具有相同的快速訪問感受。通過在不同物理位置構建多個數據中心,並利用全局負載均衡技術在多個數據中心間實現協調工作,引導用戶訪問最優的站點,當某個站點出現災難性的故障後依然可以讓其他站點為用戶提供服務,這樣便能有效解決上述問題。
負載均衡提供了一種廉價、有效、透明的方法擴展網絡設備和服務器的帶寬、增加吞吐量、加強網絡數據處理能力,提高網絡的靈活性和可用性。
負載均衡技術具有如下優點:
· 高性能:通過調度算法,將客戶端請求合理地均衡到後端各台服務器上,消除係統可能存在的瓶頸。
· 可擴展性:當服務的負載增長時,係統能被擴展來滿足需求,且不降低服務質量。
· 高可用性:通過健康性檢測功能,能實時監測應用服務器的狀態,保證在部分硬件和軟件發生故障的情況下,整個係統的服務仍然可用。
· 透明性:高效地使由多個獨立計算機組成的鬆耦合的服務係統構成一個虛服務器;客戶端應用程序與服務係統交互時,就像與一台高性能、高可用的服務器交互一樣,客戶端無須作任何修改。部分服務器的切入和切出不會中斷服務,而用戶覺察不到這些變化。
負載均衡設備對外提供的服務稱為虛服務。虛服務由VPN實例、虛服務IP地址、服務協議、服務端口號唯一標識,配置在負載均衡設備上。客戶的訪問請求通過公共或私有網絡到達負載均衡設備,匹配到虛服務後,由負載均衡設備按照既定策略分發給真實服務。
實服務是真實服務器提供的一種服務。該服務含義比較廣泛,可以是傳統的FTP、HTTP等業務應用,也可以是廣義的轉發服務,如防火牆網關負載均衡中,實服務隻是報文轉發路徑。
OAA即開放應用架構,是華三通信技術有限公司(以下簡稱H3C)提出的一個開放的軟硬件體係,它以路由器或以太網交換機這樣的傳統網絡設備為基礎,並在此基礎上,提供一套完整的軟、硬件標準接口。任何廠商隻要按照這樣的接口來生產軟件或硬件,這些新開發的軟硬件就可以和H3C係列路由器或以太網交換機等構成一個完整的係統,為客戶創造更大的價值。
持續性功能將屬於同一個應用層會話的多個連接定向到同一服務器,從而保證同一業務由同一個服務器處理(或鏈路轉發),並減少LB設備對服務和流量進行分發的次數。
負載均衡設備需要將業務流量根據某種算法分發給不同的實服務(實服務對應服務器負載均衡中的服務器、網關負載均衡中的網關設備和鏈路負載均衡中的鏈路),這個分發算法就是負載均衡調度算法。
在鏈路負載均衡中,就近性功能是指,實時探測鏈路的狀態,並根據探測結果選擇最優鏈路,保證流量通過最優鏈路轉發。
健康性功能是指負載均衡設備對真實的服務器是否能夠提供服務進行探測。依據不同的探測方法(即健康性檢測方法)可以探測出服務器是否存在,以及是否可以正常提供服務。
係統內置的ISP表描述了不同運營商擁有的地址段信息。鏈路負載均衡可以基於報文的源或目的地址(Outbound鏈路負載均衡基於目的地址,Inbound鏈路負載均衡基於源地址)查找ISP表,得到對應的運營商信息,根據運營商信息為該流量選擇一條物理鏈路。
GLB設備是具有全局負載均衡功能的LB設備,可以是一台獨立的設備,也可以與本地負載均衡在同一台設備上提供服務。
多個數據中心協作對外提供服務的描述。例如,通過分布在全球的多個站點對外提供WWW服務,但使用相同的域名www.domainname.com。為了便於管理,不同設備間配置的全局服務名稱應一致。
虛服務器是全局負載均衡中為了便於管理而抽象出來的概念,是用戶能夠直接訪問的主機。例如,一個數據中心對外提供一個IP地址,則可以抽象出一台服務器;一個數據中心對外有多個鏈路,配有多個訪問的IP地址,則可以抽象出多台服務器。虛服務器分為本地虛服務器和遠程虛服務器,不需要專門配置,是從本地虛服務和遠程設備上動態獲取的。
全局就近性是全局負載均衡中用於選取虛服務器的一種調度算法,是指通過探測虛服務器與用戶之間的網絡狀態,以及虛服務器本身的負載情況,根據探測結果選取最優的虛服務器來為用戶提供服務。
GLB設備之間會進行信息交互,例如獲取其它GLB設備上對應全局服務的虛服務器狀態信息、通知其它GLB設備進行就近性探測等,承載此類信息的協議為全局LB交互協議。
服務器負載均衡,顧名思義就是對一組服務器提供負載均衡業務。這一組服務器一般來說都處於同一個局域網絡內,並同時對外提供一組(或多組)相同(或相似)的服務。服務器負載均衡是數據中心最常見的組網模型。
服務器負載均衡分為四層(L4)服務器負載均衡和七層(L7)服務器負載均衡兩種:
· L4服務器負載均衡支持IPv4協議和IPv6協議,是基於流的服務器負載均衡,對報文進行逐流分發,將同一條流的報文分發給同一個服務器。L4服務器負載均衡對基於HTTP的7層業務無法做到按內容進行分發,限製了負載均衡業務的適用範圍。依據轉發方式,L4服務器負載均衡分為NAT方式和DR方式。
· L7服務器負載均衡隻支持IPv4協議,是基於內容的服務器負載均衡,對報文的承載內容進行深度解析,包括HTTP協議、RTSP協議等,根據其中的內容進行逐包分發,按既定策略將連接導向指定的服務器,實現了業務使用範圍更廣泛的服務器負載均衡。L7服務器負載均衡僅支持NAT方式。
NAT方式L4服務器負載均衡的組網靈活,後端服務器可以位於不同的物理位置,不同的局域網內。NAT方式下,LB設備分發服務請求時,進行目的IP地址轉換(目的IP地址為實服務的IP),通過路由將報文轉發給各個實服務。NAT方式L4服務器負載均衡的典型組網如圖3所示。
圖3 NAT方式L4服務器負載均衡
NAT方式L4服務器負載均衡包括以下幾個基本元素:
· LB Device:負責分發各種服務請求到多個Server的設備。
· Server:負責響應和處理各種服務請求的服務器。
· VSIP:對外提供的虛擬IP,供用戶請求服務時使用。
· Server IP:服務器的IP地址,供LB Device分發服務請求時使用。
客戶端將到VSIP的請求發送給服務器群前端的負載均衡設備,負載均衡設備上的虛服務接收客戶端請求,依次根據持續性功能、ACL策略、調度算法,選擇真實的服務器,再通過網絡地址轉換,用真實服務器地址重寫請求報文的目標地址後,將請求發送給選定的真實服務器;真實服務器的響應報文通過負載均衡設備時,報文的源地址被還原為虛服務的VSIP,再返回給客戶端,完成整個負載調度過程。
NAT方式L4服務器負載均衡的工作流程圖如圖4所示。
圖4 NAT方式L4服務器負載均衡流程圖
流程簡述請參見表1。
表1 NAT方式L4服務器負載均衡流程描述
步驟 | 說明 | 備注 |
(1) | Host發送服務請求報文 | 源IP為Host IP、目的IP為VSIP |
(2) | LB Device接收到請求報文後,借助持續性功能或調度算法計算出應該將請求分發給哪台Server | - |
(3) | LB Device使用DNAT技術分發報文 | 源IP為Host IP、目的IP為Server IP |
(4) | Server接收並處理請求報文,返回響應報文 | 源IP為Server IP、目的IP為Host IP |
(5) | LB Device接收響應報文,轉換源IP後轉發 | 源IP為VSIP、目的IP為Host IP |
從以上一係列的說明可以看出——在負載均衡時使用網絡地址轉換技術,NAT方式因此而得名。
組網靈活,對服務器沒有額外要求,不需要修改服務器配置,適用於各種組網。
相對於NAT方式,DR方式L4服務器負載均衡中隻有客戶端的請求報文通過LB,服務器的響應報文不經過LB,從而減少了LB的負載,有效的避免了LB成為網絡瓶頸。DR方式下,LB設備分發服務請求時,不改變目的IP地址,而將報文的目的MAC替換為實服務的MAC後直接把報文轉發給實服務。DR方式L4服務器負載均衡的典型組網如圖5所示。
圖5 DR方式L4服務器負載均衡
DR方式L4服務器負載均衡包括以下幾個基本元素:
· LB Device:負責分發各種服務請求到多個Server的設備。
· Server:負責響應和處理各種服務請求的服務器。
· VSIP:對外提供的虛擬IP,供用戶請求服務時使用。
· Server IP:服務器的IP地址,供LB Device分發服務請求時使用。
DR方式L4服務器負載均衡時,除了LB設備上配置了VSIP,真實服務器也都配置了VSIP,配置的VSIP要求不能響應ARP請求,例如在環回接口上配置VSIP。實服務除了VSIP,還需要配置一個真實IP,用於和LB通信,LB設備和真實服務器在同一個鏈路域內。發送給VSIP的報文,由LB分發給相應的真實服務器,從真實服務器返回給客戶端的報文直接通過交換機返回。
DR方式L4服務器負載均衡的工作流程圖如圖6所示。
圖6 DR方式L4服務器負載均衡流程圖
流程簡述請參見表2。
表2 DR方式L4服務器負載均衡流程描述
步驟 | 說明 | 備注 |
(1) | Host發送服務請求報文 | 源IP為Host IP、目的IP為VSIP |
(2) | General Device收到請求後轉發給LB Device | Server上的VSIP不會響應ARP請求 |
(3) | LB Device接收到請求報文後,借助持續性功能或調度算法計算出應該將請求分發給哪台Server | - |
(4) | LB Device分發報文 | 源IP為Host IP,目的IP為VSIP,目的MAC為Server的MAC地址 |
(5) | Server接收並處理請求報文,返回響應報文 | 源IP為VSIP、目的IP為Host IP |
(6) | General Device收到響應報文後,直接將報文轉發給Host | - |
從以上一係列的說明可以看出——負載均衡設備沒有采用傳統的轉發方式(查找路由表)來分發請求報文,而是通過修改目的MAC直接路由給服務器,DR方式也因此而得名。
隻有單邊報文經過負載均衡設備,負載均衡設備負擔小,不易成為瓶頸,轉發性能更強。
L7服務器負載均衡的典型組網如圖7所示。
圖7 L7服務器負載均衡
L7服務器負載均衡包括以下幾個基本元素:
· LB Device:負責分發各種服務請求到多個Server的設備。
· Server:負責響應和處理各種服務請求的服務器。
· Service group:實服務組是一個邏輯概念,是指依據多個服務器的一些公共屬性,將服務器劃分成不同的組。例如:可以按照不同的功用劃分為靜態資料存儲服務器組和動態交換服務器組;還可以按照不同的內容劃分為歌曲服務器組、視頻服務器組或圖片服務器組等。
· VSIP:對外提供的虛擬IP,供用戶請求服務時使用。
· Server IP:服務器的IP地址,供LB Device分發服務請求時使用。
客戶端首先與服務器群前端的負載均衡設備建立TCP連接,然後將到VSIP的請求發送給負載均衡設備。負載均衡設備上的虛服務接收客戶端請求,依次根據持續性功能、實服務組匹配策略、調度算法,選擇真實的服務器。然後,負載均衡設備先用客戶端地址與真實服務器建立TCP連接,再用真實服務器地址重寫客戶端請求報文的目標地址,並將請求發送給真實服務器。真實服務器的響應報文通過負載均衡設備時,報文的源地址被還原為虛服務的VSIP,再返回給客戶端,完成整個負載調度過程。
L7服務器負載均衡的工作流程圖如圖8所示。
圖8 L7服務器負載均衡流程圖
流程簡述請參見表3。
表3 L7服務器負載均衡流程描述
步驟 | 說明 | 備注 |
(1)~(3) | Host發起TCP連接請求,與LB Device建立TCP連接 | TCP連接請求的源IP為Host IP、目的IP為VSIP |
(4) | Host發送服務請求報文 | 源IP為Host IP、目的IP為VSIP |
(5) | LB Device收到請求後,根據匹配策略為該請求選擇一個合適的實服務組,再借助調度算法計算出應該將請求分發給該實服務組中的哪台Server,並緩存該請求報文 | - |
(6) | LB device向Server發SYN報文,序列號為Host的SYN報文序列號 | 源IP為Host IP、目的IP為Server IP |
(7) | Server發送SYN ACK報文 | 源IP為Server IP、目的IP為Host IP |
(8) | LB device接收Server的SYN ACK報文後,回應ACK報文 | 源IP為Host IP、目的IP為Server IP |
(9) | 修改步驟(5)中緩存的請求報文的目的IP和TCP序列號,然後發給Server | 源IP為Host IP、目的IP為Server IP |
(10) | Server發送響應報文到LB device | 源IP為Server IP、目的IP為Host IP |
(11) | LB device修改響應報文的源地址和TCP序列號後轉發給Host | 源IP為VSIP、目的IP為Host IP |
對報文進行深度解析獲取報文載荷中攜帶的信息,實現按內容進行分發,拓寬了負載均衡業務的適用範圍。適用於不同的服務器提供不同功能的組網。
網關負載均衡包括以下幾個基本元素:
· LB Device:負責分發請求發起方的網絡流量到多個網關設備。LB Device又分為一級和二級。如圖9所示,如果請求發起方的網絡流量方向為Host A > Host B,則LB Device A為一級,LB Device B為二級;如果請求發起方的網絡流量方向為Host B > Host A,則LB Device B為一級,LB Device A為二級。
· 網關設備:正常處理數據的網關設備,如:SSL VPN網關,IPsec網關,防火牆網關等。
以防火牆網關負載均衡為例,組網應用如圖9所示。
防火牆是基於會話開展業務的,即一個會話的請求和應答報文必須通過同一個防火牆。為了保證防火牆業務正常進行,內部組網不受影響,需要采用雙側負載均衡,即防火牆三明治。在這種組網環境中,對於流入流量,一級LB設備做防火牆負載均衡,二級LB設備保證從哪個防火牆進來的流量,還要從這個防火牆返回。流出流量正好相反。
圖10 防火牆負載均衡流程圖
表4 防火牆負載均衡流程描述
步驟 | 說明 | 備注 |
(1) | LB Device A接收流量 | - |
(2) | LB Device A依次根據持續性功能、負載均衡調度算法選擇一個Firewall,並將流量轉發給該Firewall | 由於防火牆基於會話開展業務,建議優先選用源地址散列算法 |
(3) | Firewall將流量轉發給LB Device B | - |
(4) | LB Device B作為二級LB Device,記錄轉發該流量的防火牆,並將流量轉發到目的地 | - |
(5) | LB Device B接收目的地發回的流量 | - |
(6) | LB Device B根據(4)中的記錄將流量轉發給同一個Firewall | - |
(7) | Firewall將流量轉發給LB Device A | - |
(8) | LB Device A將流量轉發回源地址 | - |
從以上一係列的說明可以看出——兩台LB Device之間並聯的防火牆進行網絡流量的負載分擔,提高了網絡的性能。兩側的LB Device和中間並聯的防火牆——我們稱之為三明治負載均衡。
服務對象為防火牆,提高防火牆組網靈活性。沒有特殊要求,適用於任何組網環境。
網關負載均衡也可以和服務器負載均衡融合使用,以防火牆網關和服務器負載均衡綜合組網為例,具體組網如圖11所示。
圖中Cluster A為防火牆負載均衡的集群,Cluster B為NAT方式服務器負載均衡的集群。綜合組網的工作流程就是防火牆、服務器負載均衡流程的疊加。這樣的組網方式既避免了防火牆成為網絡中的瓶頸,也提高了各種網絡服務(如HTTP、FTP)的性能和可用性。
鏈路負載均衡根據業務流量方向可以分為Outbound鏈路負載均衡和Inbound鏈路負載均衡兩種情況。
內網和外網之間存在多條鏈路時,通過Outbound鏈路負載均衡可以實現在多條鏈路上分擔內網用戶訪問外網服務器的流量。Outbound鏈路負載均衡的典型組網如圖12所示。
圖12 Outbound鏈路負載均衡組網圖
Outbound鏈路負載均衡包括以下幾個基本元素:
· LB device:負責將內網到外網流量分發到多條物理鏈路的設備。
· 物理鏈路:運營商提供的實際鏈路。
· VSIP:對外提供的虛服務IP,即用戶發送報文的目的網段。
Outbound鏈路負載均衡中VSIP為內網用戶發送報文的目的網段。用戶將訪問VSIP的報文發送到負載均衡設備後,負載均衡設備依次根據持續性功能、ACL策略、就近性算法、ISP表、調度算法選擇最佳的物理鏈路,並將內網訪問外網的業務流量分發到該鏈路。
圖13 Outbound鏈路負載均衡流程圖
表5 Outbound鏈路負載均衡流程描述
步驟 | 說明 | 備注 |
(1) | LB Device接收內網用戶流量 | - |
(2) | LB Device依次根據持續性功能、ACL策略、就近性算法、ISP表、調度算法進行鏈路選擇 | 在Outbound鏈路負載均衡組網中,通常使用就近性算法或帶寬調度算法實現流量分發 |
(3) | LB device按照鏈路選擇的結果將流量轉發給選定的鏈路 | - |
(4) | LB Device接收外網用戶流量 | - |
(5) | LB Device將流量轉發給內網用戶 | - |
· 可以和NAT應用網關共同組網,不同的鏈路使用不同的源地址,從而保證往返報文穿過同一條鏈路。
· 通過健康性檢測,可以檢查鏈路內任意節點的連通性,從而有效保證整條路徑的可達性。
· 通過調度算法,在多條鏈路間均衡流量,並支持按照帶寬進行負載均衡。
· 利用就近性算法動態計算鏈路的質量,將流量分發到當前最優鏈路上。
內網和外網之間存在多條鏈路時,通過Inbound鏈路負載均衡可以實現在多條鏈路上分擔外網用戶訪問內網服務器的流量。Inbound鏈路負載均衡的典型組網如圖14所示。
圖14 Inbound鏈路負載均衡組網圖
Inbound鏈路負載均衡包括以下幾個基本元素:
· LB device:負責引導外網流量通過不同物理鏈路轉發到內網,從而實現流量在多條物理鏈路上分擔的設備。同時,LB device還需要作為待解析域名的權威名稱服務器。
· 物理鏈路:運營商提供的實際鏈路。
· 本地DNS服務器:負責解析外網用戶發送的DNS請求、並將該請求轉發給權威名稱服務器——LB device的本地DNS服務器。
Inbound鏈路負載均衡中,負載均衡設備作為權威名稱服務器記錄域名與內網服務器IP地址的映射關係。一個域名可以映射為多個IP地址,其中每個IP地址對應一條物理鏈路。
外網用戶通過域名方式訪問內網服務器時,本地DNS服務器將域名解析請求轉發給權威名稱服務器——負載均衡設備,負載均衡設備依次根據ACL策略、就近性算法、ISP表選擇最佳的物理鏈路,並將通過該鏈路與外網連接的接口IP地址作為DNS域名解析結果反饋給外網用戶,外網用戶通過該鏈路訪問內網服務器。
圖15 Inbound鏈路負載均衡流程圖
表6 Inbound鏈路負載均衡流程描述
步驟 | 說明 | 備注 |
(1) | 外網用戶通過域名訪問內網服務器時,首先要進行DNS解析,向其本地DNS服務器發送DNS請求 | - |
(2) | 本地DNS服務器將DNS請求轉發給域名對應的權威名稱服務器——LB device | - |
(3) | LB device根據DNS請求的域名、ACL策略、就近性算法、ISP表選擇最優的物理鏈路,並將通過該物理鏈路與外網連接的接口IP地址作為域名解析結果 | 在Inbound鏈路負載均衡組網中,通常使用就近性算法實現外網到內網流量在多條鏈路間均衡 |
(4) | LB device按照域名解析的結果,將DNS應答發送給本地DNS服務器 | - |
(5) | 本地DNS服務器將解析結果轉發給用戶 | - |
(6) | 用戶使用解析結果選擇的鏈路,對內網服務器進行訪問 | - |
· 可以和服務器負載均衡配合適用,實現外網用戶訪問內網服務器流量在多條鏈路間均衡的同時,也實現了流量在多台服務器間均衡。
· 通過健康性檢測,可以檢查物理鏈路的連通性。
· 利用就近性算法動態計算鏈路的質量,通過應答報文引導後續業務流量使用當前最優的服務器業務出口。
全局負載均衡基於本地負載均衡,其中每一台GLB設備與其實服務之間所遵循的都是服務器負載均衡的工作機製,全局負載均衡實現的是不同GLB設備之間的均衡調度。全局負載均衡可實現四至七層報文在全局範圍內的負載均衡,其負載方式分為DNS智能解析、HTTP重定向、RTSP重定向和IP智能轉發四種,下麵將分別進行介紹。
當某應用在全球各個地點設置多個數據中心(站點)時,全局範圍內即存在多個服務器同時提供服務,DNS智能解析可以引導廣域網範圍內的不同用戶訪問最優服務器,使流量正確分擔到各個站點,實現全局各站點的負載均衡。
全局DNS智能解析負載均衡中,GLB設備作為DNS解析的權威服務器記錄域名與全局所有虛服務器(包括本地和遠程虛服務器)IP地址的映射關係。一個域名可以映射為多個IP地址,其中每個IP地址對應一台虛服務器。
用戶通過域名方式請求服務時,要先進行DNS解析。本地DNS服務器將用戶的域名解析請求轉發給本地的GLB設備(即權威DNS服務器),本地GLB設備根據全局調度算法從全局下的所有可用虛服務器中選舉出最優虛服務器,並將該最優虛服務器的IP地址作為DNS解析結果反饋給用戶,用戶向該IP地址請求服務。
圖17 全局DNS智能解析負載均衡流程圖
表7 全局DNS智能解析負載均衡流程描述
步驟 | 說明 | 備注 |
(1) | 用戶通過域名請求服務時,首先要進行DNS解析,向其本地DNS服務器發送DNS請求 | - |
(2) | 本地DNS服務器將DNS請求轉發給域名對應的權威DNS服務器——GLB設備 | - |
(3) | GLB設備根據DNS請求的域名,按照全局調度算法在全局所有可用的虛服務器中選舉出最優虛服務器,並將該最優虛服務器IP地址作為域名解析結果 | GLB設備上的全局服務引用的虛服務的負載均衡深度可以為4層或7層 |
(4) | GLB設備按照域名解析的結果,將DNS應答發送給本地DNS服務器 | - |
(5) | 本地DNS服務器將解析結果轉發給用戶 | - |
· 全局DNS智能解析負載均衡能引導廣域網範圍內的用戶訪問最優站點,隻要進行適當配置,就可以為全球不同地點的用戶帶來更好更快速的服務體驗。
· 全局DNS智能解析負載均衡優先於本地Inbound鏈路負載均衡,但二者可以配合使用。當全局DNS智能解析負載均衡不可用時,本地Inbound鏈路負載均衡依然可以在本地站點中進行鏈路負載均衡,進一步增強全局各站點服務的可靠性。
GLB設備也可能不對外提供DNS智能解析,而是針對某種特定應用進行全局負載均衡,例如隻對外提供HTTP業務的負載均衡或RTSP業務的負載均衡。由於全局HTTP重定向負載均衡和全局RTSP重定向負載均衡在實現原理上基本一致,故本文僅以全局HTTP重定向負載均衡為例進行詳細介紹。
當用戶通過IP地址向某站點服務器請求提供HTTP服務,而該服務器不能提供服務時,全局HTTP重定向負載均衡可將該HTTP請求重定向到全局中其他站點可用的最優服務器上,引導用戶向最優服務器請求服務。
用戶通過IP地址向某站點(如圖16中的GLB device(Local))上的某虛服務器請求HTTP服務,首先客戶端與虛服務器完成TCP三次握手,接著向該虛服務器發送HTTP請求報文。此時,GLB設備先根據本地服務器負載均衡策略選取為用戶提供服務的服務器。若選取成功,則直接按照本地服務器負載均衡的流程處理;若選取失敗,GLB設備將根據全局調度算法從所有可用的遠程虛服務器中選舉出一台最優虛服務器,並用該最優虛服務器的IP地址作為重定向的目的IP地址構造HTTP重定向報文反饋給客戶端。用戶收到HTTP重定向報文後,向選取出的最優虛服務器請求HTTP服務,先與最優虛服務器完成TCP三次握手,然後向其發送HTTP請求報文,由相應的GLB設備通過其本地服務器負載均衡策略選取服務器為用戶提供服務。
圖18 全局HTTP重定向負載均衡流程圖
表8 全局HTTP重定向負載均衡流程描述
步驟 | 說明 | 備注 |
(1) | 用戶通過虛服務IP地址向其本地GLB設備發送TCP連接建立請求,經過三次握手,成功建立TCP連接 | - |
(2) | 用戶向其本地GLB設備發送HTTP請求報文 | - |
(3) | 本地GLB設備根據本地服務器負載均衡選取實服務,由於本地的實服務繁忙或不可用,選取失敗,進入下麵的全局負載均衡流程 | - |
(4) | 本地GLB設備根據虛服務IP地址匹配出相應的全局服務,按照全局服務中指定的調度算法從全局所有可用的遠程虛服務器中選取出最優遠程虛服務器 | 本地GLB設備上的全局服務引用的虛服務的負載均衡深度須為7層 |
(5) | 本地GLB設備向用戶回複HTTP重定向報文,將選取出的最優遠程虛服務器的IP地址作為重定向的目的IP地址 | - |
(6) | 用戶收到HTTP重定向報文後,向位於遠程GLB服務器上的新服務器地址發送TCP連接請求,經過三次握手,成功建立TCP連接 | - |
(7) | 用戶向新服務器地址發送HTTP請求報文 | - |
(8) | 遠程GLB設備收到HTTP請求後,根據其本地服務器負載均衡策略選取出可以提供HTTP服務的實服務 | 遠程GLB設備上的全局服務引用的虛服務的負載均衡深度須為7層 |
(9) | 遠程GLB設備將HTTP請求轉發給選取出的實服務對應的實際提供服務的服務器 | - |
(10) | 服務器向遠程GLB設備回複HTTP響應報文 | - |
(11) | 遠程GLB設備將HTTP響應報文轉發給用戶 | - |
· 全局HTTP重定向負載均衡可以在用戶訪問的本地服務器不可用的情況下,正確地將用戶請求重定向遠程最優服務器上,有效保證了HTTP業務的持續性和可靠性。
· 全局HTTP重定向負載均衡巧妙地借助了HTTP協議固有的重定向功能,將通過全局調度算法從所有可用的遠程服務器中選舉出的最優服務器IP置於HTTP重定向報文中,並反饋給用戶,實現全局範圍內的HTTP重定向。
HTTP和RTSP報文重定向都隻適用於特定的協議,而對於用戶所需要的其他沒有重定向功能的應用,則無法實現全局負載均衡。所以其他協議需要另外的方法處理來協助完成全局負載均衡功能的實現,IP智能轉發便是一種有效的手段。
當某一站點服務器A(本地GLB設備)接收到用戶的業務請求報文,而本地服務器無法為其提供相應服務時,本地GLB設備將根據全局調度算法從所有可用的遠程虛服務器中選舉出一台最優虛服務器,並將該業務請求報文通過GRE隧道轉發給最優虛服務器所在的遠程GLB設備。遠程GLB設備收到轉發過來的業務請求報文後,對其進行有效處理,並將業務應答報文的源IP填充為服務器A的IP地址,直接反回給用戶。這樣,用戶便能獲得相應的服務。
圖19 全局IP智能轉發負載均衡流程圖
表9 全局IP智能轉發負載均衡流程描述
步驟 | 說明 | 備注 |
(1) | 用戶向本地GLB設備發送普通IP請求報文 | 目的IP為Local VSIP |
(2) | 本地GLB設備根據本地服務器負載均衡選取實服務,由於本地的實服務繁忙或不可用,選取失敗,進入下麵的全局負載均衡流程 | - |
(3) | 本地GLB設備根據虛服務IP地址匹配出相應的全局服務,按照全局服務中指定的調度算法從全局所有可用的遠程虛服務器中選取出最優遠程虛服務器 | 本地GLB設備上的全局服務引用的虛服務的負載均衡深度須為4層 |
(4) | 本地GLB設備通過GRE隧道將IP請求報文轉發給最優的遠程虛服務器所在的GLB設備 |
|
(5) | 遠程GLB設備收到轉發過來的IP請求報文後,根據其本地負載均衡策略選取出可以提供服務的實服務 | 遠程GLB設備上的全局服務引用的虛服務的負載均衡深度須為4層 |
(6) | 遠程GLB設備將IP請求報文轉發給選取出的實服務對應的實際提供服務的服務器 | - |
(7) | 服務器向遠程GLB設備回複應答報文 | - |
(8) | 遠程GLB設備將應答報文轉發給用戶 | 源IP填充為Local VSIP |
· IP智能轉發可以對任何業務報文進行智能轉發,實現所有IP業務流量的全局負載均衡,增強全局各種服務的可靠性和連續性。
· IP智能轉發雖然是一種“三角轉發”模式(即“客戶端>>本地GLB設備>>遠程GLB設備>>客戶端”),但其對於客戶端具有高度透明性,客戶端無須進行任何配置,用戶在訪問過程中也無須進行任何多餘的操作。
無論是服務器負載均衡、網關負載均衡,還是鏈路負載均衡,LB設備均處於關鍵路徑,LB設備的穩定性和安全性直接影響了網絡的可用性。為了避免單點故障,LB設備必須支持雙機熱備,即在兩台LB設備之間通過備份鏈路備份對端設備上的業務,保證兩台設備上的業務狀態是一致的。當其中一台設備發生故障時,利用VRRP或動態路由(例如OSPF)機製將業務流量切換到另一台設備,由於另一台設備已經備份了故障設備上的業務信息,業務數據流便可以從該設備上通過,從而在很大程度上避免了網絡業務的中斷。
LB雙機熱備方案支持兩種工作模式:
· 主備模式:兩台LB設備中一台作為主設備,另一台作為備份設備。主設備處理所有業務,並將產生的業務信息通過備份鏈路傳送到備份設備;備份設備不處理業務,隻用做備份。當主設備故障,備份設備接替主設備處理業務,從而保證新發起的負載均衡業務能正常處理,當前正在進行的負載均衡業務也不會中斷。
· 負載分擔模式:兩台LB設備均為主設備,都處理業務流量,同時又作為另一台設備的備份設備,備份對端的業務信息。當其中一台設備故障後,另一台設備負責處理全部業務,從而保證新發起的負載均衡業務能正常處理,當前正在進行的負載均衡業務也不會中斷。
以網關負載均衡為例,LB雙機熱備的組網如圖20所示。
LB設備通常以直聯和旁掛兩種方式部署在網絡中。
如圖21所示,直聯方式,即LB設備直接部署在網絡的主幹中,服務器和客戶端之間的負載均衡報文直接由LB設備進行路由。
如圖22所示,旁掛模式指LB設備不作為服務器和客戶端之間的路由設備,而是旁掛在路由設備上。旁掛模式也可以結合OAA方案使用,在路由設備上部署一塊具備LB功能的插卡,即可實現旁掛方式的負載均衡。在DR方式中,LB設備隻能使用旁掛模式。
旁掛模式中,用於中轉的路由交換設備上的配置至關重要。
從客戶端至服務器的流量如果要達到LB設備,必須在路由交換設備上設置到VSIP的路由。
從服務器到客戶端的流量如果不必經過LB設備,則可以通過中轉設備直接返回客戶端,如果需要返回LB,則有幾種方式:
· 服務器和LB在同一個二層網絡,服務器設置其網關為LB設備。
· 中轉設備上配置策略路由,將從服務器返回的流量定向到LB設備。
· LB設備在轉發客戶端流量時進行源NAT。
調度算法指對需要負載均衡的流量,按照一定的策略分發到指定的服務器群中的服務器或指定鏈路組的某條鏈路上,使得各台服務器或鏈路盡可能地保持負載均衡。
負載均衡技術持豐富的負載均衡調度算法。不同調度算法所實現的負載均衡效果不同,可以需要根據具體的應用場景,采用不同的算法。
靜態算法,即按照預先設定策略,進行分發,不考慮當前各實服務或鏈路的實際負載情況。算法特點:實現簡單,調度快捷。
依次將請求分發到不同的服務器或鏈路上,使得各個真實服務器或鏈路平均分擔用戶的連接請求。
如:實服務群中包含三個實服務A、B、C,假設各實服務均未達到連接上限,最後分發給A、B、C的連接數之比為1:1:1。
適用場景:服務器集群中各服務器性能或鏈路群中各鏈路帶寬相當,無優劣之分。
按照權值大小,依次將請求分發到不同的服務器或鏈路上,權值大的分配較多請求,權值小的分配較少請求。該算法可以解決服務器間性能或鏈路間帶寬不一的問題,權值標識服務器間性能或鏈路間帶寬差異。
如:實服務組中包含三個實服務A、B、C,其配置權值分別為:4、3、2。假設各實服務均未達到連接上限,最後分發給A、B、C的連接數之比為4:3:2。
適用場景:服務器集群中各服務器性能或鏈路集群中各鏈路帶寬存在差異。
將請求隨機分發到不同的服務器或鏈路上。從統計學角度看,調度結果為各個服務器或鏈路平均分擔用戶的連接請求。
適用場景:服務器集群中各服務器性能或鏈路群中各鏈路帶寬相當,無優劣之分。
將請求隨機分發到不同的服務器或鏈路上。從統計學角度看,調度結果為各個服務器或鏈路按照權值比重分擔用戶的連接請求,最後的比值和加權輪轉一致。
適用場景:服務器集群中各服務器性能或鏈路群中各鏈路帶寬存在差異。
通過一個散列(Hash)函數將來自同一個源IP的請求映射到一台服務器或鏈路上。
適用場景:需要保證來自同一個用戶的請求分發到同一個服務器或鏈路。
通過一個散列函數將來自同一個源IP和源端口號的請求映射到一台服務器或鏈路上。
適用場景:需要保證來自同一個用戶同一個業務的請求分發到同一台服務器或鏈路。
通過一個散列函數將去往同一個目的IP的請求映射到一台服務器或鏈路上。
適用場景:需要保證到達同一個目的地的請求分發到同一台服務器或鏈路。適用於網關負載均衡和鏈路負載均衡。
通過一個散列函數將UDP報文載荷中特定字段的內容相同的請求映射到一台服務器上。
適用場景:需要保證UDP報文載荷中特定字段內容相同的請求分發到同一台服務器。
按照優先級的大小以及指定的最小活動實服務/邏輯鏈路數,將請求分發到優先級較高的可用服務器或鏈路上。優先級相同的可用實服務或邏輯鏈路為一組,按優先級成組選取總數不少於最小活動實服務/邏輯鏈路數的實服務或邏輯鏈路,在選取的這些實服務或邏輯鏈路中以輪轉的方式進行調度。該算法可以解決有主備之分的實服務或鏈路中,在主的實服務或鏈路可用時,請求隻分給主的實服務或鏈路(優先級最大的實服務或鏈路),隻有在主的實服務或鏈路不可用時請求才會分發給備的實服務或鏈路(優先級小的實服務或鏈路)上。
如:實服務組中有兩個優先級為10的實服務和三個優先級為5的實服務,均可用,則當最小活動實服務數為2時,隻有優先級為10的兩個實服務參與輪轉調度;當最小活動實服務數為3時,優先級為10和優先級為5的實服務都參與輪轉調度。
適用場景:集群中的服務器或鏈路有主備之分。在主服務器或鏈路可用時,請求隻分發給主服務器或鏈路(優先級較大);在主服務器或鏈路不可用時,將請求分發給備服務器或鏈路(優先級較小)。
相對於靜態算法,動態算法根據各實服務或物理鏈路實際運行中的負載情況進行連接分發,分發效果更均衡。
負載均衡設備根據當前各服務器或鏈路的連接數來估計服務器或鏈路的負載情況,把新的連接分配給連接數最小的服務器或鏈路。該算法能把負載差異較大(連接保持時長差異較大)的請求平滑分發到各個服務器或鏈路上。
適用場景:服務器集群中各服務器性能或鏈路群中各鏈路帶寬相當,無優劣之分,不同用戶發起的連接保存時長差異較大。
調度新連接時盡可能使服務器或鏈路的已建立活動連接數和服務器或鏈路權值成比例,權值表明了服務器處理性能或鏈路實際帶寬。
適用場景:服務器集群中各服務器性能或鏈路群中各鏈路帶寬存在差異,不同用戶發起的連接保存時長差異較大。
負載均衡設備根據不同鏈路的實際剩餘帶寬及權值,將新連接分發到剩餘帶寬最大的鏈路上。
適用場景:鏈路群中各鏈路狀況(包括帶寬、擁塞程度等)存在差異。
鏈路負載均衡支持就近性功能。
· 對於Outbound鏈路負載均衡,就近性功能是指對目的地址匹配就近性表項的報文,使用表項中的鏈路進行轉發;如果沒有匹配的就近性表項,則進行就近性檢測,並生成動態就近性表項以指導報文轉發。
· 對於Inbound鏈路負載均衡,就近性功能是指對源地址匹配就近性表項的DNS報文,使用對應物理鏈路所屬DNS表項(域名匹配)的IP地址作為DNS解析結果;如果沒有匹配的就近性表項,則進行就近性檢測,並生成動態就近性表項以指導DNS解析。
鏈路負載均衡就近性檢測是負載均衡設備利用健康性檢測功能實時探測鏈路的狀態,Outbound鏈路負載均衡是以報文的目的地址為目的進行檢測,Inbound鏈路負載均衡是以DNS請求的源地址為目的進行檢測。根據檢測結果計算出最優鏈路,並通過最優鏈路轉發業務流量。支持的健康性檢測類型包括:
· DNS:通過DNS報文,檢測遠端DNS服務的可用性並獲得就近性計算參數。隻有Inbound鏈路負載均衡支持該檢測類型。
· ICMP:通過ICMP報文,檢測遠端地址的可達性並獲得就近性計算參數。
· TCP Half Open:通過建立TCP半開連接,檢測遠端地址的可達性並獲得就近性計算參數。
鏈路負載均衡的就近性檢測根據以下幾個參數進行加權計算,得出鏈路加權數,並根據鏈路加權數的大小判斷鏈路的優劣:
· 鏈路物理帶寬:即鏈路的可用帶寬值。
· 鏈路成本:取決於每條鏈路的成本值,比如租用聯通10M鏈路每月1萬元,租用電信10M鏈路每月1.5萬元,則兩條鏈路的成本比例為2:3,兩條鏈路成本的取值應該滿足該比例。
· 鏈路延遲時間(即RTT):通過健康性檢測獲得。
· 路由跳數(即TTL):通過健康性檢測獲得。
管理員也可以手工添加靜態就近性表項。當同時存在匹配的靜態就近性表項和動態就近性表項時,根據靜態優先和深度優先原則優先使用最深匹配的表項。
全局負載均衡中,就近性是用於選取虛服務器的一種調度算法。它是指,根據收到報文的源IP地址查找就近性表項,使用匹配到的表項中的虛服務器提供服務;如果沒有找到匹配的表項,則會先采用輪詢的方式選取一個虛服務器來提供服務,同時觸發每個虛服務器以收到報文的源IP地址為目的進行就近性探測,生成就近性表項用於指導後續的虛服務器選取。
全局負載均衡就近性檢測是全局負載均衡設備利用健康性檢測功能探測各站點虛服務器與客戶端(對於全局DNS智能解析負載均衡,這裏的客戶端是指Local DNS服務器)的網絡狀況,以報文的源地址為目的進行檢測。根據檢測結果計算出最優虛服務器。支持的健康性檢測類型包括:
· DNS:通過DNS報文,檢測遠端DNS服務的可用性並獲得就近性計算參數。
· ICMP:通過ICMP報文,檢測遠端地址的可達性並獲得就近性計算參數。
· TCP Half Open:通過建立TCP半開連接,檢測遠端地址的可達性並獲得就近性計算參數。
全局負載均衡的就近性檢測根據以下幾個參數進行加權計算,得出服務器加權數,並根據服務器加權數的大小判斷服務器的優劣:
· 鏈路延遲時間(即RTT):通過健康性檢測獲得。
· 路由跳數(即TTL):通過健康性檢測獲得。
· 服務器負載:即虛服務器當前處理的連接數除以其允許的最大並發連接數,再乘以100。
管理員也可以手動添加靜態就近性表項。當同時存在匹配的靜態就近性表項和動態就近性表項時,根據靜態優先和深度優先原則優先使用最深匹配的表項。
所謂健康性檢測,就是負載均衡設備定期對真實服務器或鏈路服務狀態進行探測,收集相應信息,及時隔離工作異常的服務器或鏈路。健康性檢測的結果除標識服務器或鏈路能否工作外,還可以統計出服務器或鏈路的響應時間,作為選擇服務器或鏈路的依據。
負載均衡技術支持豐富的健康性檢測類型,可以有效地探測和檢查服務器或鏈路的運行狀態。
· ICMP:向服務器集群中的服務器或鏈路上的節點發送ICMP Echo報文,若收到ICMP Reply,則服務器或鏈路正常。
· TCP:向服務器集群中服務器的某端口發起TCP連接建立請求,若成功建立TCP連接,則服務器正常。
· HTTP:與服務器集群中服務器的HTTP端口(默認情況為80)建立TCP連接,然後發出HTTP請求,若收到的HTTP應答內容正確,則服務器正常。
· FTP:與服務器集群中服務器的21號端口建立TCP連接,然後獲取服務器上的文件,若收到的文件內容正確,則服務器正常。
· TCP Half Open:向鏈路上節點的某端口發起TCP連接建立請求,若成功建立TCP半開連接,則鏈路正常。
· DNS:向服務器集群中的服務器或鏈路上的DNS服務器發送DNS請求,若收到正確的DNS應答,則服務器或鏈路正常。
· RADIUS:向服務器集群中的服務器發送RADIUS認證請求,若收到認證成功的應答,則服務器正常。
· SSL:向服務器集群中的服務器發送SSL連接建立請求,若成功建立SSL連接,則服務器正常。
· ARP:向服務器集群中的服務器發送ARP請求,若收到正確的ARP應答,則服務器正常。
· IMAP:與服務器集群中的IMAP服務器建立連接,並且使用預先指定的用戶名和密碼能夠成功登陸並打開相應的用戶郵箱,則服務器正常。
· POP3:與服務器集群中的POP3服務器的建立連接,並且使用預先指定的用戶名和密碼能夠成功登陸相應的用戶郵箱,則服務器正常。
· RTSP:與服務器集群中RTSP服務器建立連接,然後發出OPTION報文,若收到正確的應答,則服務器正常。
· SIP:向服務器集群中的SIP服務器發送OPTIONS請求,若收到正確的應答,則服務器正常。
· SMTP:與服務器集群中的SMTP服務器的建立連接,然後發出HELLO報文,若收到正確的應答,則服務器正常。
· SNMP:向服務器集群中的SNMP服務器發送請求,若收到正確的應答,則服務器正常。
· UDPNORMAL:向服務器集群中服務器的某端口發送UDP報文,檢測應用端口的可用性,隻要不收到服務器返回的ICMP不可達等出錯應答報文,就認為服務器的應用端口可用。由於UDPNORMAL類型的檢測不要求服務器必須發回響應,因此在實際應用中,建議將其與ICMP類型的檢測配合使用,通過ICMP檢測確定服務器IP地址是否可達。
一次業務交互可能包括多個TCP連接,如FTP應用(包含一個控製通道和多個數據通道)和HTTP應用。這些TCP連接間有些存在顯式關聯關係,如FTP應用,數據通道的TCP連接是通過控製通道協商得來的;有些存在隱含的關聯關係,如HTTP網絡購物,多條連接組成一次業務應用,且多個連接並不像FTP應用一樣有“父子”之分,能通過父通道(即控製通道)獲取子通道(即數據通道)信息,但所有該業務的請求應發給同一服務器,否則可能造成無法完成所請求的功能,因為其數據報文中攜帶隱含關聯信息,如Cookie。
將屬於同一個應用層會話的多個連接定向到同一服務器的功能,就是持續性功能。根據持續性原則,建立持續性表項,保證後續業務報文都送往同一個服務器處理。比如使用源地址建立持續性表項,保證持續性。
顯式關聯關係持續性功能是指如果某種應用(如FTP)包括多個具有顯式關聯關係的TCP連接,子通道五元組是通過父通道協商得來的,則負載均衡設備逐包分析父通道報文,一旦發現子通道協商信息,就會利用該信息建立父通道會話關聯表項,當子通道首報文到來時,根據關聯表項和父會話表項建立完整的會話表項,從而保證父子通道登錄同一台服務器。顯式關聯關係由負載均衡設備自動識別,無需配置策略。
基於源IP地址的持續性功能常用於L4服務器負載均衡和鏈路負載均衡應用中,用以確保同一個客戶端的業務能分配到同一個服務器或鏈路上。
負載均衡設備接收到某一客戶端的某一業務的首次請求時,建立持續性表項,記錄為該客戶分配的服務器情況,在持續性表項生存周期內,後續相同源IP地址的業務報文都將發往該服務器處理。
基於目的IP地址的持續性功能常用於鏈路負載均衡應用中,用以確保去往同一個目的地址的業務能分配到同一條鏈路上。
負載均衡設備接收到某一客戶端的某一業務的首次請求時,建立持續性表項,記錄為該客戶分配的鏈路情況,在持續性表項生存周期內,後續相同目的IP地址的業務報文都將分發到該鏈路轉發。
基於源端口的持續性功能常用於L4服務器負載均衡和鏈路負載均衡應用中,用以確保源端口相同的業務報文能分配到同一個服務器或鏈路上。
負載均衡設備接收到某一客戶端的某一業務的首次請求時,建立持續性表項,記錄為該客戶分配的服務器情況,在持續性表項生存周期內,後續相同源端口的業務報文都將發往該服務器處理。
基於目的端口的持續性功能常用於L4服務器負載均衡和鏈路負載均衡應用中,用以確保目的端口相同的業務報文能分配到同一條鏈路上。
負載均衡設備接收到某一客戶端的某一業務的首次請求時,建立持續性表項,記錄為該客戶分配的鏈路情況,在持續性表項生存周期內,後續相同目的端口的業務報文都將分發到該鏈路轉發。
基於源IP地址和源端口的持續性功能常用於L4服務器負載均衡和鏈路負載均衡應用中,用以確保源IP地址和源端口均相同的業務報文能分配到同一個服務器或鏈路上。
負載均衡設備接收到某一客戶端的某一業務的首次請求時,建立持續性表項,記錄為該客戶分配的服務器情況,在持續性表項生存周期內,後續相同源IP地址和源端口的業務報文都將發往該服務器處理。
基於目的IP地址和目的端口的持續性功能常用於L4服務器負載均衡和鏈路負載均衡應用中,用以確保目的IP地址和目的端口均相同的業務報文能分配到同一條鏈路上。
負載均衡設備接收到某一客戶端的某一業務的首次請求時,建立持續性表項,記錄為該客戶分配的鏈路情況,在持續性表項生存周期內,後續相同目的IP地址和目的端口的業務報文都將分發到該鏈路轉發。
基於Cookie的持續性功能常用於L7服務器負載均衡應用中,用以確保同一會話的報文能分配到同一個服務器上。根據服務器的應答報文中是否彙攜帶含有服務器信息的Set-Cookie字段,又可選擇采用Cookie插入或Cookie截取的持續性方法:
· Cookie插入:服務器的應答報文中不攜帶含有服務器信息的Set-Cookie字段,負載均衡設備會在報文中添加含有服務器信息的Set-Cookie字段。這樣,客戶端就會在請求報文中攜帶含有該服務器信息的Cookie字段,負載均衡設備按照Cookie字段中的服務器信息將請求報文發給相應的實服務。
· Cookie截取:服務器的應答報文中攜帶Set-Cookie字段,負載均衡設備根據用戶配置的Cookie標識截取應答報文中的Cookie值。對於後續客戶端的請求報文,如果匹配保存的Cookie值,則直接將請求報文發給相應的實服務。
基於SIP報文Call-ID的持續性功能常用於L7服務器負載均衡應用中,用以確保Call-ID相同的SIP報文能分配到同一個服務器上。
負載均衡設備接收到某一客戶端的某一業務的首次請求時,建立持續性表項,記錄為該客戶分配的服務器情況,在持續性表項生存周期內,後續相同Call-ID的SIP業務報文都將分發到該服務器處理。
基於HTTP報文頭的持續性功能常用於L7服務器負載均衡應用中,用以確保HTTP報文頭信息相同的報文能分配到同一個服務器上。
負載均衡設備接收到某一客戶端的某一業務的首次請求時,建立持續性表項,記錄為該客戶分配的服務器情況,在持續性表項生存周期內,後續HTTP報文頭信息相同的報文都將分發到該服務器處理。
基於RADIUS屬性值的持續性功能常用於L7服務器負載均衡應用中,用以確保屬性值信息相同的RADIUS報文能分配到同一個服務器上。
負載均衡設備接收到某一客戶端的某一業務的首次請求時,建立持續性表項,記錄為該客戶分配的服務器情況,在持續性表項生存周期內,後續屬性值Framed-IP-Address或User-Name(二者可通過配置選擇其一)信息相同的RADIUS報文都將分發到該服務器處理。
基於DHCP屬性值的持續性功能常用於L7服務器負載均衡應用中,用以確保屬性值信息相同的DHCP報文能分配到同一個服務器上。
負載均衡設備接收到某一客戶端的某一業務的首次請求時,建立持續性表項,記錄為該客戶分配的服務器情況,在持續性表項生存周期內,後續屬性值Transaction ID或Client Hardware Address(二者可通過配置選擇其一)信息相同的DHCP報文都將分發到該服務器處理。
L4服務器負載均衡在截取數據流以後,對數據包檢查與分析的部分僅限於IP報頭及TCP/UDP報頭,而不關心TCP或UDP包的內部信息。而L7服務器負載均衡則要求負載均衡設備除了支持基於4層的負載均衡以外,還要解析數據包中4層以上的信息,即應用層的信息。例如,可以解析HTTP協議,從數據包中提取出HTTP URL或Cookie信息。
L7服務器負載均衡控製應用層服務的內容,提供了一種對訪問流量的高層控製方式。與L4服務器負載均衡相比,L7服務器負載均衡具有如下優點:
· 可根據數據包內容(如判斷數據包是圖像文件、壓縮文件或多媒體文件格式等),把數據流量引向相應內容的服務器來處理,增加係統性能。
· 可根據連接請求的數據類型(比如根據URL來區分是請求普通文本、圖象等靜態文檔,還是請求ASP、CGI等動態文檔),把相應的請求引向相應的服務器來處理,提高係統的性能及安全性。
· 可基於應用層載荷進行持續性處理,相對於L4負載均衡基於地址和端口的持續性處理方式更加精細。
由於L7服務器負載均衡對應用層協議進行深度識別,因此,對於每種應用層協議都需要有獨立的識別機製,這大大限製了L7服務器負載均衡的應用擴展性,一般隻是針對HTTP進行負載均衡。同時,深度識別應用層協議,對係統性能也會有很大影響。
負載均衡提供了靈活的實服務/邏輯鏈路故障處理方法。當實服務組/邏輯鏈路組檢測到其中的某個實服務/邏輯鏈路發生故障時,可以有以下幾種方法來處理故障實服務/邏輯鏈路上已有的連接:
· 保持已有連接:LB設備不主動斷開與故障實服務/邏輯鏈路的連接,連接保持或斷開由協議自身的超時機製決定。此方法一般用於服務器負載均衡和Outbound鏈路負載均衡。
· 斷開已有連接:LB設備主動斷開與故障實服務/邏輯鏈路的連接。此方法一般用於服務器負載均衡和Outbound鏈路負載均衡。
· 重定向已有連接:LB設備將連接重定向到實服務組/邏輯鏈路組中其他可用的實服務/邏輯鏈路上。此方法一般用於網關負載均衡和Outbound鏈路負載均衡。
在L7服務器負載均衡中,每個虛服務中可以包含多個由具有一些公共屬性的服務器組成的實服務組。當LB設備收到用戶向某虛服務發來的請求時,如果虛服務未應用持續性功能,或者應用了持續性功能但不存在匹配的持續性表項,虛服務會根據預先設置的實服務組匹配策略選擇一個實服務組。
L7服務器負載均衡支持豐富的實服務組匹配策略。不同實服務組匹配策略所實現的負載均衡效果不同,可以需要根據具體需求采用不同的匹配策略。
根據HTTP協議報文頭的不同內容進行實服務組的匹配,包括以下幾種具體的匹配策略:
· Accept-Encoding:根據Accept-Encoding報文頭定義的客戶端瀏覽器所支持的壓縮模式進行實服務組的匹配。適用於服務器分別提供不同類型壓縮格式的組網場景。
· Accept-Language:據Accept-Language報文頭定義的客戶端瀏覽器所支持的語言編碼進行實服務組的匹配。適用於服務器分別提供不同種類語言的組網場景。
· Host:根據Host報文頭中攜帶的主機名進行實服務組的匹配。適用於服務器分別提供不同請求主機名的組網場景。
· Request-Method:根據Request-URI標識的資源上執行的方法進行實服務組的匹配。適用於服務器分別提供不同類型服務的組網場景,如設置GET服務器和PUT服務器使操作分離,簡化組網環境的層次結構並降低成本的場景。
· URL-File:根據資源文件或文件類型進行實服務組的匹配。適用於服務器分別提供不同類型文件的組網場景。
· URL-Function:根據資源獲取路徑進行實服務組的匹配。適用於服務器分別提供不同資源獲取路徑的組網場景。
· User-Agent:根據User-Agent報文頭中攜帶的客戶端瀏覽器類型進行實服務組的匹配。適用於服務器分別支持不同類型瀏覽器的組網場景。
· 自定義:根據用戶自行設置的其他HTTP協議報文頭包含的任意字段進行實服務組的匹配。適用於服務器分別提供不同服務類型的組網場景。
根據RTSP資源獲取路徑(即RTSP的URL-Function)進行實服務組的匹配。適用於服務器分別提供不同RTSP資源獲取路徑的組網場景。
當要在集群中新增一台服務器或新增一條鏈路時,由於某些服務器或鏈路剛上線時無法立即承擔大量的業務,可以對實服務組或邏輯鏈路組使能溫暖上線功能,並指定準備時間和溫暖上線時間。這樣,在準備時間內,負載均衡設備不會向新增的服務器或鏈路分配業務。準備時間到達後,在溫暖上線時間內,負載均衡設備會隨著時間的遞增逐步增加向該服務器或鏈路分配業務的量。在溫暖上線時間也到達後,LB設備開始向該服務器或鏈路正常分配業務。
對於IPv4服務器負載均衡和鏈路負載均衡,當要將某服務器/鏈路從集群中撤出,或者暫時停止使用某服務器/鏈路時,可以對相應的實服務/邏輯鏈路設置立即停止服務或使能慢宕功能:
· 立即停止服務後,LB設備不會再向該實服務/邏輯鏈路分配任何流量。
· 使能慢宕功能後,LB設備將實服務/邏輯鏈路上原有業務的流量仍然分配給該實服務/邏輯鏈路處理,但不會再向該實服務/邏輯鏈路分配新的業務。當原有業務處理完後,即可將相應的服務器/鏈路從集群中撤出。這樣可以避免服務器/鏈路的突然撤出而導致其上原有業務的中斷,從而保證業務的連續性。
IPv6服務器負載均衡隻支持使能慢宕功能,不支持立即停止服務功能。
在企業園區網絡中,為了實現對企業資源服務器的快速訪問,也需要采用負載均衡設備分擔企業數據訪問流量。在這種應用環境下,可以將負載均衡設備串接在網絡中,服務器通過網絡設備連接到負載均衡設備,服務器網關指向LB。
圖23 企業園區網應用組網圖
負載均衡設備直聯服務器部署模式的優點是:
· 部署簡單,是負載均衡設備的經典應用模式。
· 通過交換機連接負載均衡設備和服務器群,解決LB設備端口數量限製帶來的擴展性問題。
數據中心和大型門戶網站是負載均衡設備主要的應用場景,H3C推薦采用旁掛模式作為數據中心和大型門戶網站的組網模式。組網圖如圖24所示。
LB設備與彙聚層交換機之間有兩條鏈路或鏈路聚合組,這兩條鏈路(組)分別為L3鏈路和L2鏈路,服務器網關指向LB設備,對於需要負載均衡的流量,彙聚層將VSIP的下一跳指向LB,而LB的缺省路由指向彙聚層交換機。
旁掛部署模式的優點如下:
· 數據路徑清晰,易於運行維護、故障定位;
· 可以使用手工鏈路聚合,鏈路帶寬易於拓展,並提供鏈路高可靠性及其鏈路負載均衡能力;
· LB設備旁掛,易於LB升級和擴展。根據用戶服務器擴展情況,升級更高性能的LB設備或者增加LB設備;
· 業務部署靈活,對不需要負載均衡的流量可以旁路LB,避免對LB增加不必要負荷;
· 降低了對彙聚層交換機的要求,有助於網絡穩定運行。