帳號:
密碼:
最新動態
 
產業快訊
CTIMES / 文章 /
伺服器負載平衡器技術與架構探微
 

【作者: Veena Kondapalli】   2004年12月04日 星期六

瀏覽人次:【21635】

伺服器負載平衡器(Server Load Balancers;SLBs)為立即平衡企業網路共享環境中服務眾多可用伺服器負載(traffic)的設備。早期,負載平衡是一套位於控制區(Control plane)的「輪流平均」(round robin)軟體演算法,負責管理負載量。這套演算法並沒有將負載、連線類型或伺服器是否達到良好狀態納入考量。硬體的發展也已隨著線路速度增加及不同類型服務的發明並進。


硬體架構的SLB雖然能在速度上符合某種程度的擴張需求,但應付現今網際網路負載上卻需要比單純的負載平衡具備更智慧的功能。新型SLB裝備比先前的伺服器負載平衡器更智慧,而且具備更高的整合功能,能偵測超過64Bytes的封包(需具備IP轉送偵測深度),以執行第四層(L4)到第七層(L7)的封包交換,也就是網路搜尋引擎扮演重要角色的位置。本文將描述負載平衡的必備條件、各種的伺服器負載平衡演算法以及高階伺服器負載平衡器的特色。最後,這裡也介紹網路搜尋引擎給予SLB的協助。


為何需要伺服器負載平衡?

許多資訊內容密集的應用已經到達超出單一伺服器所能提供充分處理的程度。這樣的狀況下,企業與服務商必須很快且順暢地為使用者新增額外的伺服器。伺服器負載平衡使得多重伺服器表現有如單一伺服器的表現,或稱為「單一虛擬服務」,毫無痕跡地在多部伺服器間分散處理用戶需求。


伺服器負載平衡最重要的必備條件有:


  • ●高可用性;


  • ●可擴充性;


  • ●具備有線傳輸速度的效能。




《圖一 伺服器負載平衡器》
《圖一 伺服器負載平衡器》

SLB為企業資料中心提供了成本優勢。SLB不需中斷虛擬伺服器群組中其他成員作業即可新增與移除伺服器。只要新增服務品質(QoS)特色,伺服器就可以隨時維持運作,提供高度可用性。SLB也允許具成本效益的擴充性,因為新的伺服器可以隨時加入虛擬群組中,而不需要將舊的伺服器移除。


為了在SLB中增加有線傳輸速度的效能,現有處理L4到L7封包交換的負載平衡器,必須具備應用程式架構負載平衡。當執行L4交換時,就必須要執行封包的深層偵測,以確保應用封包能被送到相對的虛擬服務群組中。


如何做到負載平衡?

在IP網路中,伺服器可以依照所提供的服務或是有時根據終端用戶的位置進行群組。這個群組會有一個邏輯IP目標位址,稱為VIP(virtual IP address),實際上代表伺服器的陣列。每台伺服器仍保有其個別唯一的實體IP位址,其作用是讓SLB導引負載量。這個實體IP位址會被紀錄在SLB的交談表(session table)中。


在企業架構中,SLB有兩種使用方式,透明模式(transparent mode)以及代理模式(proxy mode),如(圖一)與(圖二)所示。


透明模式

在透明模式中,SLB利用修正IP目標的封包頭段將封包轉送給實體的伺服器。VIP則被修改為實體伺服器的IP位址。此處的封包數值也因此需要修正。經過修改的封包則接著被轉送至各個目的伺服器。這種方式被稱為是「遞移」(hand-off)。之後便由伺服器來建立交談(session)並且確認(acknowledge)該請求。當伺服器送出資料時,SLB便會修改封包的來源位址成為群組的VIP,並且轉送該封包到網路上。同樣的,此處的封包數值需要修正。



《圖二 通透SLB交換細節》
《圖二 通透SLB交換細節》

這種交談從SLB封包偵測引擎偵測TCP封包表頭時開始;如果封包含有一個SYN封包,便會開始以TCP session進行交談。此處封包表頭的資料會被移除,然後被送到一個分類(classification)表單中。在這裡查詢(lookup)的結果會與封包表頭資訊結合,並存放於資料流表單(flow table)。資料流表單不斷地追蹤執行中的交談。利用設定好的負載平衡演算法,SLB會指引這個交談的終點伺服器,這樣的程序稱為「聯繫」(binding)。實體伺服器的資訊接著會被存到一個相關的資料流表單記憶體中。如果這個封包不是SYN封包,表頭資訊將被抽離,並與存放於資料流表單中的資訊比對。目標伺服器被存放於相關的資料流表單記憶體中。封包將會再依此資料被修改,然後透過通透模式傳輸。當收到一個FIN的封包時,這個對談就終止,之後資料流表單中的起始與目標伺服器的資料就可以作廢了。



《圖三 通透性聯繫(Transparent Binding) 》
《圖三 通透性聯繫(Transparent Binding) 》

代理模式

SLB以代理模式運作以應付L7密集的偵測。這種模式也稱為延遲聯繫(delay-binding)。此時SLB終止到用戶端的TCP 交談,並且在SLB與伺服器間建立另一個交談,將用戶端與伺服器分開。這會造成延長用戶端指令(request)與伺服器的回應(response)時間。封包表頭分類與資料流表單在此裡的作用與在透明模式中的相同。SLB接著產生回應用戶端需要的ACK以及自己的SYN封包,以建立與實體伺服器間的交談。SLB也會負責產生封包的序列號碼。



《圖四 代理SLB交換模式細節》
《圖四 代理SLB交換模式細節》

SLB包含TCP接合(CP-splicing)的功能,以增加轉送封包的效能。這是在透明模式與代理模式間的折衷。在啟始的TCP 溝通(handshake)之後,並且也建立了資料流,封包便會直接經由伺服器轉送到用戶端。



《圖五 代理模式延遲聯繫》
《圖五 代理模式延遲聯繫》

管理資料流

當有用戶端送出新指令時,SLB交換器就會執行負載平衡。這個指令將被編址於VIP,也就是代表某個虛擬的伺服器群組虛擬IP位址。SLB的工作就是負責將所有後續的指令引導到VIP以及同一部實體伺服器上,這類決定是根據一定規則或方法而執行,稱為「聯繫」(binding)。SLB接著必須要將這些指令所代表的交談引導到實體伺服器上。存放聯繫資訊的表單便是資料流表單(Flow table)。


轉送查詢(Forwarding lookups)

雖然交談表單提供了引導交談目標伺服器的資訊,但通常還會有一份額外的轉送表單(forwarding table),是為了要更新特定伺服器IP所對應的MAC位址。當任何在L3或L2的交換轉送表單更新時,便會建立額外的轉送表單。


伺服器負載平衡演算法

SLB利用演算法做聯繫的決定。這些動作都可以透過軟體在控制層(control-plane)中制訂出「政策」(policies)。已設定的演算法與優先處理資訊都存放於一個分類表單中。這些資訊用來定義資料流表單中的項目。要注意的是,伺服器負載平衡僅發生於聯繫時(或當交談建立指令時),並非為了接下來的交談指令。在交談建立後,該交談所相關的目標資料就會被存入資料流表單中,而封包就會依照這些資訊被引導到適當的伺服器上。下列都是SLB常用的演算法,用以協助判斷導引負載量到伺服器中。


每台伺服器的交談數目

利用持續追蹤在資料流表單中每台伺服器的處理項目數目就可統計出交談(資料流)的數目。詳細的作法可以在SLB中計算,以控制在伺服器陣列間交談的分配。這個方法可以用來平衡伺服器陣列間的負載量。


輪流平均(Round-robin)或比重分配(weighted round-robin)

SLB將會依序或依比重分配順序引導資料流,以平衡多台伺服器間的負載量。這項演算法佔用SLB最少的處理程序。簡單的狀態機(state machine)就可以持續追蹤連接埠的順序。


應用程式

應用系統負載平衡是將特定應用程式的指令引導到特定的應用系統伺服器中。首先,應用程式可以透過L4資訊中的連接埠數目被定義。網頁伺服器一般使用的連接埠號是80,FTP伺服器一般則是用20與21,SSH伺服器用22,Telnet伺服器用23等。其次,利用L7偵測就可以分辨在相同通訊埠或通訊協定下所對應的不同服務項目。這允許採用同一個HTTP協定但不同服務的負載流(streams)得以傳送至不同的伺服器。


特定的用戶端

特定的負載平衡是為特定用戶端而設。允許特定用戶端使用特定的伺服器,可以保證達到服務層級協議的服務品質。只要查看Cookie值、URI、或SSL session Ids,用戶端的識別資料便可以保留在資料流表單中。SLB可以利用URL偵察所得到的路徑(URL)或檔名資訊執行負載平衡。這些需要利用字串搜尋以找出特定字串。交換機可以尋找關鍵字「index」以引導所有進來的請求到最穩定的網頁伺服器。


現今高階SLB特色

目前所用的SLB不只提供單純伺服器負載平衡的功能,因為許多SLB廠商已經將SLB與高階 L3路由器整合在一起。此外,對於以交談為主的伺服器負載平衡而言,L4到L7交換功能與其他整合特性讓SLB能提供新的服務,例如QoS、安全性、服務持續性以及備援功能。還有一些額外的特點,像是L3與L4多重協定交換功能、IDS支援、VLAN支援、URL或SSL ID為基礎的平衡或持續性、系統狀態檢查、伺服器備援檢查以及GlobalSLB(GSLB)等等,都可讓現有的SLB將客戶的網路架構最小化。


整合L2/L3交換路由的SLB

對大部分的企業而言,L2交換機提供伺服器負載平衡裝置與伺服器群(server farm)間的連接。當系統要連接SLB到提供網際網路存取的備援路由器時,就會需要一組額外的L2交換機。



《圖六 一般的交換器與SLB連結架構》
《圖六 一般的交換器與SLB連結架構》

這個方法相當複雜且昂貴,每個產品都是一個「功能的區塊」(island of functionality),這些區塊通常會有另一複製的部分以減少單一的錯誤發生。此外,這些分層的協定都沒有彼此互動,因此發生錯誤事件時並不具備回復的能力。另一項缺點是SLB無法以有線傳輸的速度運作,因此可能會降低執行效能。


為了解決這些問題,許多廠商將L2/L3路由交換器與SLB的功能整合在一起,並拿掉設備維護方面額外負擔,而交換機也具備有線線路的傳輸速度。這裡的例子是具備L2/L3交換功能的Extreme Networks Summit7i Server Load Balancer。



《圖七 整合交換器與SLB之架構》
《圖七 整合交換器與SLB之架構》

L4到L7的交換功能

儘管無法實際上在L4到L7上進行「交換」的動作,但可以在L2與L3上根據較高層的資訊進行交換的動作。交換機與路由器利用L4的資訊(例如儲存五種分類項目的表單)作為存取控制與分類決策之用。SLB利用這些資訊以及其它高層資訊,將應用程式的請求導引到特定的應用伺服器上。除了以交談為架構的伺服器負載平衡外,SLB L4到L7的交換能力與其它特點的整合讓新的服務,像是QoS、安全性、持續服務以及備援等都可以整合到SLB中。


第四層到第七層的交換器允許負載能在每個交談進行管理,保證了端點對端點的連線。每個交談都須經過用戶端與伺服器的確認才能建立。每個交談所附帶的狀態資訊會影響到交換時資料轉送的決定。全狀態(Stateful)的資料轉送是無法單由L2與L3的訊息達成。


每個進入的封包都會經過分類以控制網路訊務。要執行L4~L7的資料分類,系統就必須要檢視URLs、檔案形式以及其它在封包應用層中的資訊。這些結合L2與L3的資訊會被卸載到分類表單中。分類的結果可以用來決定交談的優先權,以及受到請求的伺服器被要求使用的負載平衡演算法。


入侵偵測系統(Intrusion Detection System;IDS)的支援

SLB可以當成網路安全第一個關卡,如果任何L4與L7的封包表頭中有可疑的內容,則該封包會被送至入侵偵測系統(intrusion detection systems)中,而不會變成所有負載的瓶頸。


系統狀態檢查(Health Check)

一般來說,在大型的伺服器群中必須要確定所有的伺服器都能全功能運作。通常透過週期性的探測(pinging)虛擬服務所連接的伺服器,並且取得該伺服器中SYN的訊號。一些通訊協定,像是思科的Dynamic Feedback Protocol(DFP)就可以在SLB中作為系統狀態檢查使用。


SSL 持續性

為了要根據不同的應用平衡負載,系統會需要執行深層的資訊內容偵察。資訊內容的偵察同時也需要將送入的負載解碼,讓表頭的內容可以顯示出來。SSL加密與加速已經成為SLB前端的一部份。SLB必須執行SSL 交握協定(SSL Handshake Protocol),接著將送入的封包解密,再依照解密所顯示的要求將封包導引到適當的伺服器上。同樣的,這也有助於減輕伺服器在加解密工作上的負擔。


Global SLB(GSLB)

有些公司的伺服器群是根據伺服器的位置規劃的。對於一個包含許多遠端網站的網路來說,如果所有的遠端網站都無法運作或超出負荷,那麼要使用一部遠端網站執行應用程式時就會受到阻礙。Global SLB讓負載平衡負載可以跨越多個網站。GSLB會根據其DNS指令來源,進行分散式效能感知(Distributed performance awareness)以及用戶端地理位置感知(client geographic awareness)以消除連線延遲。利用這套方法,執行效能最好的網站會在其能力範圍之內處理最多的訊務,這也保護了效能最好的網站不會發生錯誤。


NSE與SLB

隨著越來越多的特點整合至SLB中,其功能也變得越來越複雜。整合L2/L3的SLB交換功能需要以有線傳輸速度運作,並且也要支援比以往更多的封包處理量。網路搜尋引擎(Network Search Engines;NSEs)大幅降低SLB中封包處理器在處理上的需求。早期,查詢(lookups)的動作是由封包處理器以軟體演算法進行,並且使用DRAM或SRAM記憶體空間儲存分類表單以及FIB表單。當速度晉升為最重要的需求時,原本以軟體執行的查詢引擎就會被NSE所取代。NSE是外接的硬體架構查詢引擎。多半是以三態內容尋址記憶體(Ternary Content Addressable Memories;TCAM)為架構的搜尋引擎。


目前的NSE可以在較高的線路速率上支援高達數百萬筆資料的大型表單。當有線網路速度不斷提昇到1/10/40 GigE時,封包處理器也需要執行更快速的查詢以及更多處理功能。NSE可以減輕封包處理器查詢的負擔,並且減少處理器的負擔。NSE可以減少電路板使用空間,因為單一的NSE可以支援的數百到數千筆資料的表單。多數在DRAM與SRAMs中以軟體執行的查詢方式都速度上的限制。NSE具備16個 全面屏蔽暫存器(global mask register),提供最多16種不同設定的屏蔽,讓系統可以在NSE中儲存多個表單。此外,NSE也自備屏蔽陣列,可以執行基礎屏蔽。這項特色有助於執行最長字首比對(longest prefix matching)。


結論

目前與下一代的SLB已不再單純提供負載平衡功能,其許多新功能,包括L4~L7交換功能,以及L2、L3的路由功能。有越來越多的SLB廠商將其SLB功能整合到其L2、L3交換路由器上。市場上的領導廠商,像是思科系統(Cisco Systems),便將其CSM 11500產品整合到像是Catalyst 6500與7600這類資訊內容服務交換器上。北電網路(Nortel Networks)也將其Alteon ACD交換器整合至該公司Passport 8600系列L2、L3交換路由器上。


多數SLB廠商已開始製造具備這些特色的產品。例如北電網路Alteon Application Switch 2424、F5 Networks BIG-IP 5000、Foundry Networks ServerIron XL、Extreme Networks Summit7i以及Enterasys的X-Pedition,都具備L4~L7交換與L2、L3路由的功能。一些產品同時也支援GSLB、VLAN、IDS、WAP 閘道器以及網頁快取(Web Cache)功能。整體來說,下一代SLB會以線路速度運作,並以更有效率的附加特色執行許多原屬於網路的工作。為了達到要求的線路速度,並且能夠執行所有的功能,NSE將能大幅協助SLB。(作者為Cypress柏士半導體資料通訊通訊部應用工程師)


延 伸 閱 讀
隨著上網人數不斷的激增,寬頻網路的普及,許多大型的內容提供者 (ICP) 所面臨的最大挑戰就是巨量的使用者需求。相關介紹請見「DRWS直接路由網頁交換器」一文。
隨著近年來網路發展迅速,眾多企業利用網路的便利性及效率性,使整體企業的運作邁向 e 化的整合應用,然而 e 化的前題主要還是要配合網路實際環境。你可在「全功能負載平衡主機」一文中得到進一步的介紹。
本次調查結果,收錄了 102 家資安廠商,包含防毒、防火牆、入侵偵測/預防系統、負載平衡、 VPN 、 PKI 、身分認證、儲存、內容過濾等資安廠商,以及提供資安專業服務的資安管理顧問公司及系統整合商等,我們一次為您蒐集齊備。不論要找廠商或顧問,《 2004 資安廠商服務能量》滿足您的需要。在「2004資安廠商服務能量大調查」一文為你做了相關的評析。
最新消息

IDT 內容檢查引擎( PAX.ware 2500i )評估系統,是一個雙超高速乙太網路( Gigabit Ethernet )分類評估系統,用來協助進行早期的內容檢查評估,及以 Intel IXDP2400 發展平台為架構的同步硬體與軟體發展,可以加速並優化網路安全應用方面的封包處理。相關介紹請見「IDT與 Intel共同開發加速封包處理的高性能解決方案」一文。

Cypress Semiconductor 日前推出 Ayama 20000 系列網路搜尋引擎 (NSE) 元件樣本。 Ayama 20000 系列 NSE 介面已通過網路處理論壇 (Networking Processing Forum, NPF) 的 LA-1 規格認證,能支援各種商業網路處理器 (NPU) ,其中包括英特爾的 IXP2400/IXP2800/IXP2850 以及 AMCC 的 nP3700 。你可在「Cypress發表業界支援雙LA-1介面的最高效能NSE」一文中得到進一步的介紹。

全球整合通訊 IC 和網路搜尋引擎 (NSEs) 供應商 IDT(Integrated Device Technology) 宣佈推出業界成本最低的 32Kx72(2 百萬位元 ) 網路搜尋引擎產品 IDT 75N42102 與 IDT 75N43102 。在「IDT推出低成本的32Kx72網路搜尋引擎」一文為你做了相關的評析。

相關文章
運用nvSRAM 維持企業級SSD於電源故障時的可靠性
透過實作 掌握USB 3.0架構分層
手機螢幕觸控「筆」較有智慧
透視手機觸控螢幕感測器設計
家電產品觸控感測應用
comments powered by Disqus
相關討論
  相關新聞
» 研究:高階手機市場淪為中國手機品牌爭霸戰
» 歐洲首款Multibeam Mask Writer新機型強化半導體生態系
» 芝加哥大學開發新水凝膠半導體材料
» 英飛凌2024會計年度營收利潤雙增 預期2025年市場疲軟
» 英飛凌推出全球首款易於回收的非接觸式支付卡技術


刊登廣告 新聞信箱 讀者信箱 著作權聲明 隱私權聲明 本站介紹

Copyright ©1999-2024 遠播資訊股份有限公司版權所有 Powered by O3  v3.20.2048.3.147.48.240
地址:台北數位產業園區(digiBlock Taipei) 103台北市大同區承德路三段287-2號A棟204室
電話 (02)2585-5526 #0 轉接至總機 /  E-Mail: webmaster@ctimes.com.tw