負載均衡簡介一、可伸縮網絡服務的設計與實現1、 網絡服務的需求 隨著Internet的飛速發展和對我們生活的深入影響,互聯網的用戶數和網絡流量正以幾何級數增長,這對網絡服務的可伸縮性 提出很高的要求。另外, 隨著電子商務等關鍵性應用在網上運行,任何例外的服務中斷都將造成不可估量的損失,服務的高可用性也越來越重要。所以,對用硬件和軟件方法實現高可伸縮、 高可用網絡服務的需求不斷增長,這種需求可以歸結以下幾點:
單服務器顯然不能處理不斷增長的負載。這種服務器升級方法有下列不足: 一是升級過程繁瑣,機器切換會使服務暫時中斷,并造成原有計算資源的浪費; 二是越往高端的服務器,所花費的代價越大; 三是一旦該服務器或應用軟件失效,會導致整個服務的中斷。 針對上述需求,我們給出了基于IP層和基于內容請求分發的負載平衡調度解決方法,并在Linux內核中實現了這些方法,將一組服務器構成一個實現可 伸縮的、高可用網絡服務的服務器集群,我們稱之為Linux虛擬服務器(Linux Virtual Server)。在LVS集群中,使得服務器集群的結構對客戶是透明的,客戶訪問集群提供的網絡服務就像訪問一臺高性能、高可用的服務器一樣。客戶程序不 受服務器集群的影響不需作任何修改。系統的伸縮性通過在服務機群中透明地加入和刪除一個節點來達到,通過檢測節點或服務進程故障和正確地重置系統達到高可 用性。 2、 LVS集群的通用結構 LVS集群采用IP負載均衡技術和基于內容請求分發技術。調度器具有很好的吞吐率,將請求均衡地轉移到不同的服務器上執行,且調度器自動屏蔽掉服務器的故障,從而將一組服務器構成一個高性能的、高可用的虛擬服務器。
圖1.1:LVS集群的體系結構 為此,在設計時需要考慮系統的透明性、可伸縮性、高可用性和易管理性。LVS集群的體系結構如圖1.1所示,它有三個主要組成部分:
調度器采用IP負載均衡技術、基于內容請求分發技術或者兩者相結合。在IP負載均衡技術中,需要服務器池擁有相同的內容提供相同的服務。當客戶請求 到達時,調度器只根據負載情況從服務器池中選出一個服務器,將該請求轉發到選出的服務器,并記錄這個調度;當這個請求的其他報文到達,也會被轉發到前面選 出的服務器。在基于內容請求分發技術中,服務器可以提供不同的服務,當客戶請求到達時,調度器可根據請求的內容和服務器的情況選擇服務器執行請求。因為所 有的操作都是在操作系統核心空間中將完成的,它的調度開銷很小,所以它具有很高的吞吐率。 服務器池的結點數目是可變的。當整個系統收到的負載超過目前所有結點的處理能力時,可以在服務器池中增加服務器來滿足不斷增長的請求負載。對大多數網絡服務來說,結點與結點間不存在很強的相關性,所以整個系統的性能可以隨著服務器池的結點數目增加而線性增長。 后端存儲通常用容錯的分布式文件系統,如AFS、GFS、Coda和Intermezzo等。分布式文件系統為各服務器提供共享的存儲區,它們訪問 分布式文件系統就像訪問本地文件系統一樣。同時,分布式文件系統提供良好的伸縮性和可用性。 二、IP負載均衡技術 本章節將描述三種IP負載均衡技術VS/NAT、VS/TUN和VS/DR的工作原理,以及它們的優缺點。在以下描述中,我們稱客戶的socket和服務器的socket之間的數據通訊為連接,無論它們是使用TCP還是UDP協議。 1、 通過NAT實現虛擬服務器(VS/NAT) 由于IPv4中IP地址空間的日益緊張和安全方面的原因,很多網絡使用保留IP地址(10.0.0.0/255.0.0.0、172.16.0.0 /255.128.0.0和192.168.0.0/255.255.0.0)[64, 65, 66]。這些地址不在Internet上使用,而是專門為內部網絡預留的。當內部網絡中的主機要訪問Internet或被Internet訪問時,就需要 采用網絡地址轉換(Network Address Translation, 以下簡稱NAT),將內部地址轉化為Internets上可用的外部地址。NAT的工作原理是報文頭(目標地址、源地址和端口等)被正確改寫后,客戶相信 它們連接一個IP地址,而不同IP地址的服務器組也認為它們是與客戶直接相連的。由此,可以用NAT方法將不同IP地址的并行網絡服務變成在一個IP地址 上的一個虛擬服務。 VS/NAT的體系結構如圖3.1所示。在一組服務器前有一個調度器,它們是通過Switch/HUB相連接的。這些服務器提供相同的網絡服務、相 同的內容,即不管請求被發送到哪一臺服務器,執行結果是一樣的。服務的內容可以復制到每臺服務器的本地硬盤上,可以通過網絡文件系統(如NFS)共享,也 可以通過一個分布式文件系統來提供。
圖3.1:VS/NAT的體系結構 客戶通過Virtual IP Address(虛擬服務的IP地址)訪問網絡服務時,請求報文到達調度器,調度器根據連接調度算法從一組真實服務器中選出一臺服務器,將報文的目標地址 Virtual IP Address改寫成選定服務器的地址,報文的目標端口改寫成選定服務器的相應端口,最后將修改后的報文發送給選出的服務器。同時,調度器在連接Hash 表中記錄這個連接,當這個連接的下一個報文到達時,從連接Hash表中可以得到原選定服務器的地址和端口,進行同樣的改寫操作,并將報文傳給原選定的服務 器。當來自真實服務器的響應報文經過調度器時,調度器將報文的源地址和源端口改為Virtual IP Address和相應的端口,再把報文發給用戶。我們在連接上引入一個狀態機,不同的報文會使得連接處于不同的狀態,不同的狀態有不同的超時值。在TCP 連接中,根據標準的TCP有限狀態機進行狀態遷移;在UDP中,我們只設置一個UDP狀態。不同狀態的超時值是可以設置的,在缺省情況下,SYN狀態的超 時為1分鐘,ESTABLISHED狀態的超時為15分鐘,FIN狀態的超時為1分鐘;UDP狀態的超時為5分鐘。當連接終止或超時,調度器將這個連接從 連接Hash表中刪除。 這樣,客戶所看到的只是在Virtual IP Address上提供的服務,而服務器集群的結構對用戶是透明的。對改寫后的報文,應用增量調整Checksum的算法調整TCP Checksum的值,避免了掃描整個報文來計算Checksum的開銷。 在一些網絡服務中,它們將IP地址或者端口號在報文的數據中傳送,若我們只對報文頭的IP地址和端口號作轉換,這樣就會出現不一致性,服務會中斷。 所以,針對這些服務,需要編寫相應的應用模塊來轉換報文數據中的IP地址或者端口號。我們所知道有這個問題的網絡服務有FTP、IRC、H.323、 CUSeeMe、Real Audio、Real Video、Vxtreme / Vosiac、VDOLive、VIVOActive、True Speech、RSTP、PPTP、StreamWorks、NTT AudioLink、NTT SoftwareVision、Yamaha MIDPlug、iChat Pager、Quake和Diablo。 2、 通過IP隧道實現虛擬服務器(VS/TUN) 在VS/NAT的集群系統中,請求和響應的數據報文都需要通過負載調度器,當真實服務器的數目在10臺和20臺之間時,負載調度器將成為整個集群系 統的新瓶頸。大多數Internet服務都有這樣的特點:請求報文較短而響應報文往往包含大量的數據。如果能將請求和響應分開處理,即在負載調度器中只負 責調度請求而響應直接返回給客戶,將極大地提高整個集群系統的吞吐量。 IP隧道(IP tunneling)是將一個IP報文封裝在另一個IP報文的技術,這可以使得目標為一個IP地址的數據報文能被封裝和轉發到另一個IP地址。IP隧道技 術亦稱為IP封裝技術(IP encapsulation)。IP隧道主要用于移動主機和虛擬私有網絡(Virtual Private Network),在其中隧道都是靜態建立的,隧道一端有一個IP地址,另一端也有唯一的IP地址。 我們利用IP隧道技術將請求報文封裝轉發給后端服務器,響應報文能從后端服務器直接返回給客戶。但在這里,后端服務器有一組而非一個,所以我們不可 能靜態地建立一一對應的隧道,而是動態地選擇一臺服務器,將請求報文封裝和轉發給選出的服務器。這樣,我們可以利用IP隧道的原理將一組服務器上的網絡服 務組成在一個IP地址上的虛擬網絡服務。VS/TUN的體系結構如圖3.3所示,各個服務器將VIP地址配置在自己的IP隧道設備上。
圖3.3:VS/TUN的體系結構
3、 通過直接路由實現虛擬服務器(VS/DR) 跟VS/TUN方法相同,VS/DR利用大多數Internet服務的非對稱特點,負載調度器中只負責調度請求,而服務器直接將響應返回給客戶,可 以極大地提高整個集群系統的吞吐量。該方法與IBM的NetDispatcher產品中使用的方法類似,但IBM的NetDispatcher是非常昂貴 的商品化產品,我們也不知道它內部所使用的機制,其中有些是IBM的專利。 VS/DR的體系結構如圖3.6所示:調度器和服務器組都必須在物理上有一個網卡通過不分段的局域網相連,即通過交換機或者高速的HUB相連,中間 沒有隔有路由器。VIP地址為調度器和服務器組共享,調度器配置的VIP地址是對外可見的,用于接收虛擬服務的請求報文;所有的服務器把VIP地址配置在 各自的Non-ARP網絡設備上,它對外面是不可見的,只是用于處理目標地址為VIP的網絡請求。
圖3.6:VS/DR的體系結構 VS/DR負載調度器也只處于從客戶到服務器的半連接中,按照半連接的TCP有限狀態機進行狀態遷移。 4、 三種方法的優缺點比較 三種IP負載均衡技術的優缺點歸納在下表中: VS/NAT-----服務器上升到一定數量時,負載調度器容易出現瓶頸;吞吐量小 VS/TUN-------吞吐量比較大 VS/DR---------吞吐量比較大
注:以上三種方法所能支持最大服務器數目的估計是假設調度器使用100M網卡,調度器的硬件配置與后端服務器的硬件配置相同,而且是對一般Web服 務。使用更高的硬件配置(如千兆網卡和更快的處理器)作為調度器,調度器所能調度的服務器數量會相應增加。當應用不同時,服務器的數目也會相應地改變。所 以,以上數據估計主要是為三種方法的伸縮性進行量化比較。 a) Virtual Server via NAT VS/NAT 的優點是服務器可以運行任何支持TCP/IP的操作系統,它只需要一個IP地址配置在調度器上,服務器組可以用私有的IP地址。缺點是它的伸縮能力有限, 當服務器結點數目升到20時,調度器本身有可能成為系統的新瓶頸,因為在VS/NAT中請求和響應報文都需要通過負載調度器。 b) Virtual Server via IP Tunneling 在VS/TUN 的集群系統中,負載調度器只將請求調度到不同的后端服務器,后端服務器將應答的數據直接返回給用戶。這樣,負載調度器就可以處理大量的請求,它甚至可以調 度百臺以上的服務器(同等規模的服務器),而它不會成為系統的瓶頸。即使負載調度器只有100Mbps的全雙工網卡,整個系統的最大吞吐量可超過 1Gbps。所以,VS/TUN可以極大地增加負載調度器調度的服務器數量。VS/TUN調度器可以調度上百臺服務器,而它本身不會成為系統的瓶頸,可以 用來構建高性能的超級服務器。 VS/TUN技術對服務器有要求,即所有的服務器必須支持“IP Tunneling”或者“IP Encapsulation”協議。目前,VS/TUN的后端服務器主要運行Linux操作系統,我們沒對其他操作系統進行測試。因為“IP Tunneling”正成為各個操作系統的標準協議,所以VS/TUN應該會適用運行其他操作系統的后端服務器。 c) Virtual Server via Direct Routing 跟VS/TUN方法一樣,VS/DR調度器只處理客戶到服務器端的連接,響應數據可以直接從獨立的網絡路由返回給客戶。這可以極大地提高LVS集群系統的伸縮性。跟VS/TUN相比,這種方法沒有IP隧道的開銷,但是要求負載調度器與實際服務器都有一塊網卡連在同一物理網段上,服務器網絡設備(或者設備別名)不作ARP響應,或者能將報文重定向(Redirect)到本地的Socket端口上。 三、負載調度算法 如何通過負載調度器將請求高效地分 發到不同的服務器執行,使得由多臺獨立計算機組成的集群系統成為一臺虛擬服務器;客戶端應用程序與集群系統交互時,就像與一臺高性能的服務器交互一樣。 如何將請求流調度到各臺服務器,使得各臺服務器盡可能地保持負載均衡。IPVS在內核中所實現的各種連接調度算法; 在下面描述中,我們稱客戶的socket和服務器的socket之間的數據通訊為連接,無論它們是使用TCP還是UDP協議。對于UDP數據報文的 調度,IPVS調度器也會為之建立調度記錄并設置超時值(如5分鐘);在設定的時間內,來自同一地址(IP地址和端口)的UDP數據包會被調度到同一臺服 務器。 八種調度算法(rr,wrr,lc,wlc,lblc,lblcr,dh,sh) 五、內核中的基于內容請求分發KTCPVS 由于用戶空間TCP Gateway的開銷太大,導致其伸縮能力有限。為此,我們提出在操作系統的內核中實現Layer-7交換方法,來避免用戶空間與核心空間的切換開銷和內 存復制的開銷。在Linux操作系統的內核中,我們實現了Layer-7交換,稱之為KTCPVS(Kernel TCP Virtual Server)。以下幾小節將介紹KTCPVS的體系結構、實現方法、負載平衡和高可用特征等。 1、 KTCPVS的體系結構 KTCPVS集群的體系結構如圖6.3所示:它主要由兩個組成部分,一是KTCPVS交換機,根據內容不同將請求發送到不同的服務器上;二是后端服務器,可運行不同的網絡服務。KTCPVS交換機和后端服務器通過LAN/WAN互聯。
圖6.3 :KTCPVS集群的體系結構 KTCPVS交換機能進行根據內容的調度,將不同類型的請求發送到不同的后端服務器,再將結果返回給客戶,后端服務器對客戶是不可見的。所 以,KTCPVS集群的結構對客戶是透明的,客戶訪問集群提供的網絡服務就像訪問一臺高性能、高可用的服務器一樣,故我們也稱之為虛擬服務器。客戶程序不 受服務器集群的影響不需作任何修改。
|
|||||||||||||||||||||||||
| >> 相關文章 | |||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||