數(shù)據(jù)中心網(wǎng)絡四層負載均衡技術綜述*

李 力，汪 碩，黃 韜，劉韻潔

(1.東南大學網(wǎng)絡空間安全學院，江蘇 南京 211189；2.北京郵電大學網(wǎng)絡與交換技術國家重點實驗室，北京 100876；3.網(wǎng)絡通信與信息安全紫金山實驗室，江蘇 南京 211111)

1 引言

由于提供了計算、存儲等資源，數(shù)據(jù)中心承擔著為越來越多的網(wǎng)絡設備、用戶和業(yè)務流程提供支撐和通信的重任，成為實體經(jīng)濟與網(wǎng)絡融合的一個重要環(huán)節(jié)，也是我國新基建的七大領域之一。近年隨著云計算和大數(shù)據(jù)的迅速發(fā)展，數(shù)據(jù)中心規(guī)模不斷擴大，據(jù)思科全球云指數(shù)報告，全球超大規(guī)模數(shù)據(jù)中心的數(shù)量在5年內(nèi)增長了2倍，數(shù)據(jù)中心IP流量則以27% 的復合年均增長率增長，現(xiàn)已達到了15.3 ZB的數(shù)量級[1]。云服務使得用戶幾乎在任何有網(wǎng)絡的地方都可以通過多種設備隨時訪問內(nèi)容和服務，這些訪問請求最終都將匯集到數(shù)據(jù)中心，根據(jù)Alexa提供的網(wǎng)絡流量排名，大型服務提供商如Google、Youtube、淘寶和百度將可能承擔億級的并發(fā)訪問，因此國內(nèi)外互聯(lián)網(wǎng)巨頭不斷優(yōu)化數(shù)據(jù)中心結(jié)構(gòu)與功能。比如Facebook數(shù)據(jù)中心機器間的流量每隔不到一年的時間就以2倍的速度增長[2]，Google在10年內(nèi)將數(shù)據(jù)中心容量擴展了100倍[3]。

為了應對數(shù)據(jù)的指數(shù)級增長和高并發(fā)訪問，大型數(shù)據(jù)中心都需要部署負載均衡模塊，以處理來自外部或內(nèi)部的巨大工作負載，提高資源利用率。負載均衡器涉及數(shù)據(jù)中心幾乎全部的外部進入流量和一半的內(nèi)部流量[4]，因此負載均衡對托管在數(shù)據(jù)中心中的服務的性能至關重要。負載均衡器一般位于路由器和最終服務器之間，能夠在一組后端服務器之間平均分配工作負載，有效處理客戶向服務器發(fā)出的請求。四層負載均衡主要利用傳輸層的信息，如IP地址和端口，來將請求均衡分發(fā)到服務器集群的節(jié)點。在很長一段時間內(nèi)，負載均衡器作為硬件存在于數(shù)據(jù)中心中，典型的商用負載均衡硬件有F5[5]、Array[6]和NetScaler[7]。但是，隨著服務部署逐漸云化與虛擬化，應用程序變得更加復雜，基于軟件的負載均衡得到了大規(guī)模使用。章文嵩等[8]于1998年創(chuàng)建和開發(fā)了Linux 虛擬服務器LVS(Linux Virtual Server)開源項目，將基于IP層的負載均衡調(diào)度方法集成到了Linux內(nèi)核當中，這也成為了后續(xù)多個軟件負載均衡器設計的基礎。如阿里巴巴在LVS的基礎上增加了完全網(wǎng)絡地址轉(zhuǎn)換FullNAT(Full Network Address Translation)的轉(zhuǎn)發(fā)方式和SYN代理(SYNproxy)，以進行SYN泛洪(SYN Flood)攻擊的防御[9]，愛奇藝DPVS[10]、京東SKYLB[11]和美團MGW[12]則通過內(nèi)核旁路、數(shù)據(jù)平面開發(fā)套件DPDK(Data Plane Development Kit)[13]和零復制等技術實現(xiàn)了更高的轉(zhuǎn)發(fā)性能。

國外的互聯(lián)網(wǎng)巨頭如Microsoft提出了Ananta[4]，通過三層架構(gòu)實現(xiàn)了負載均衡的可擴展性；Duet[14]和Rubik[15]則以軟硬件混合部署的方式克服了軟件負載均衡器高延遲的弱點；Google提出的Maglev[16]和Github提出的GLB[17]以繞過Linux內(nèi)核的方式優(yōu)化了軟件負載均衡器的性能；Miao等[18]提出的SilkRoad在專用集成電路ASIC(Application Specific Integrated Circuit)交換芯片上實現(xiàn)了有狀態(tài)硬件負載均衡器的設計，能夠在服務器池頻繁更新的情況下保證連接的一致性；Olteanu等[19]提出的Beamer和Araujo等[20]提出的Faild通過采用服務器側(cè)路由重定向的無狀態(tài)方案，防止遭受分布式拒絕服務攻擊DDoS(Distributed Denial of Service)攻擊；Barbette等[21]則是將狀態(tài)信息以Cookie的方式存儲于數(shù)據(jù)包中,并能采用有狀態(tài)和無狀態(tài)2種方式部署。近3年的負載均衡設計均采用了基于ASIC交換芯片的硬件部署方式，從而以低成本獲取高轉(zhuǎn)發(fā)性能，可見可編程交換轉(zhuǎn)發(fā)技術是目前的研究熱點和發(fā)展趨勢。

2 四層負載均衡設計概述

2.1 四層負載均衡概述

按照IOS七層模型的劃分，負載均衡可分為四層負載均衡和七層負載均衡。四層負載均衡使用傳輸層定義的信息作為如何在一組服務器之間分配客戶端請求的基礎，即僅基于數(shù)據(jù)包頭中的五元組(源/目的IP，源/目的端口，協(xié)議)進行負載均衡決策，典型的有LVS。七層負載均衡可以檢查請求的內(nèi)容并根據(jù)應用層的信息將請求分發(fā)到不同的服務器，即通過應用層協(xié)議、URL、瀏覽器類別和語言等信息進一步進行負載分擔，典型的有Nginx[22]和HAProxy[23]。

四層與七層負載均衡的區(qū)別主要如下：(1) 技術原理：前者使用五元組信息進行轉(zhuǎn)發(fā)，后者本質(zhì)是進行內(nèi)容交換和代理，建立在前者的基礎之上，對負載均衡設備的性能要求更高；(2) 應用場景：前者主要用于TCP應用，客戶端與后端直接建立連接，后者廣泛用于HTTP協(xié)議，需要負載均衡器與后端額外建立連接，雖然增加了網(wǎng)絡靈活性，但對報頭的檢查將增加網(wǎng)絡損耗；(3) 安全性：后者可以根據(jù)應用層信息設定多種安全過濾策略，對流量進行有效的清洗，前者的安全策略所采用的信息較少，但使用場景更為廣泛，對設備要求不高，能進行高性價比的基礎防御。

隨著云與虛擬化的發(fā)展，數(shù)據(jù)中心的資源通常被拆分為多個虛擬主機VM(Virtual Machine)共同協(xié)調(diào)處理任務，網(wǎng)絡服務運行在多個虛擬主機上，每個VM擁有一個直接IP DIP(Direct IP address)，但對外僅提供一個或少量虛擬IP VIP(Virtual IP address)。用戶通過VIP訪問服務，流量到達負載均衡器后將被均勻分配到每一個后端實例上。圖1是數(shù)據(jù)中心典型的三級負載均衡結(jié)構(gòu)，為了實現(xiàn)大連接并發(fā)，劃分多個服務實例進行負載分擔，用戶流量到達路由器后根據(jù)源IP進行等價多路徑路由ECMP(Equal-Cost Multi-Path routing)，實現(xiàn)流量的初步分配，數(shù)據(jù)包到達四層負載均衡器后再根據(jù)VIP、端口號和負載均衡算法選擇后端實例，將目的地址從VIP轉(zhuǎn)換為DIP，七層負載均衡器再根據(jù)URL等應用信息進一步進行內(nèi)容交換或代理，最終將數(shù)據(jù)包轉(zhuǎn)發(fā)到服務實例。

Figure 1 Structure of data center load balancing 圖1 數(shù)據(jù)中心負載均衡結(jié)構(gòu)圖

2.2 四層負載均衡設計原則

在部署四層負載均衡時除了要考慮不同應用場景的特殊需求和方案性能之外，還需要考慮以下幾項基本設計原則：

(1)連接一致性。數(shù)據(jù)中心網(wǎng)絡需要不斷處理故障，部署新服務，升級現(xiàn)有服務并對流量增加做出反應，文獻[18]調(diào)研顯示后端VIP服務升級將導致DIP池的頻繁增加或刪除，其中很多集群的DIP池每分鐘將更新10次以上，因此需要保證連接一致性，以免影響服務能力。連接一致性指即使在DIP池發(fā)生更改的情況下，同一連接始終映射到同一后端實體。將正在連接的數(shù)據(jù)包發(fā)往不同的DIP會導致連接斷開，應用程序需要幾微秒到幾秒的時間才能從斷開的連接中恢復，這將導致無法提供99.9%或更高的正常運行時間以滿足服務等級協(xié)議SLA(Service-Level Agreement)。

(2)可擴展性。文獻[4]調(diào)研指出VIP流量約占數(shù)據(jù)中心總流量的44%，對于擁有4萬臺服務器的數(shù)據(jù)中心，負載均衡器需要處理約44 Tbps的流量。負載均衡器需要處理的流量會隨著整體流量的增加而同步增加，縱向擴展模型使得部署者不得不以極高的代價更換更大容量的負載均衡設備，且更換過程較為復雜，因此通過添加更多類似的設備來獲得更大處理能力的橫向擴展模型更加符合實際應用。由于采用了負載均衡集群的方式，為保證連接一致性還需要在各負載均衡器之間進行數(shù)據(jù)同步，使得多個LB可以同時處理發(fā)往同一VIP的數(shù)據(jù)包。

(3)負載分配均勻。負載能否得到有效的分配取決于負載均衡算法，常用的負載均衡算法將在2.3節(jié)介紹。由于四層負載均衡的路由決策僅基于存儲在網(wǎng)絡數(shù)據(jù)包頭中的信息，缺乏對流量的可見性，很難快速判定請求的性質(zhì)，因此需要提前考慮負載生成情況和可用服務器資源，并在做出路由決策時進行一定程度的猜測。有效的負載均衡策略將提高數(shù)據(jù)中心的資源利用率，針對不同的應用場景與流量特性可以采取不同的均衡算法，因此在保證連接一致性的情況下四層負載均衡能夠采取多種算法增加其使用場景與靈活性。

(4)故障無縫轉(zhuǎn)移。負載均衡器是滿足應用程序正常運行時間SLA的關鍵組件，需要在計劃內(nèi)和計劃外的停機期間均保持可用性。因此，負載均衡需要支持具有故障轉(zhuǎn)移機制的N+1備份模型來維護應用程序和保證服務的高可用性。在不中斷活動流的情況下，所有系統(tǒng)組件都可以優(yōu)雅地進入和退出服務，即系統(tǒng)中某一節(jié)點發(fā)生故障后，另一個節(jié)點可以接管其工作負載，現(xiàn)有架構(gòu)的每個元素，包括主機、交換機和負載均衡器自身都能夠無縫添加和刪除。

2.3 四層負載均衡常用算法

負載均衡算法按其狀態(tài)特點可以分為靜態(tài)調(diào)度算法和動態(tài)調(diào)度算法[24,25]。靜態(tài)調(diào)度算法提前確定調(diào)度策略，不考慮系統(tǒng)負載實時變化，常用算法如表1所示。動態(tài)調(diào)度算法將根據(jù)后端服務器的負載變化動態(tài)調(diào)整調(diào)度策略，常用算法如表2所示。

Table 1 Summary of static scheduling algorithms

Table 2 Summary of dynamic scheduling algorithms

不同算法將根據(jù)其特點應用于不同的場景，如靜態(tài)調(diào)度算法常用于具有規(guī)律流特性的網(wǎng)絡或較為簡單的網(wǎng)絡，WRR和WLC可用于多服務器異構(gòu)集群，LBLC和LBLCR在內(nèi)容分發(fā)集群中能獲得較好效果。雖然上述算法各有其特性，但仍存在難以具化服務器處理能力、權(quán)值設定主觀和連接數(shù)難以完全代表負載情況等問題。因此，在這些算法的基礎上，還有研究人員提出基于動態(tài)反饋的均衡算法[26]、基于負載權(quán)值的負載均衡算法[27]、基于遺傳算法的負載均衡算法[28]和基于神經(jīng)網(wǎng)絡反饋機制的負載均衡算法[29]等多種調(diào)度算法。

IP地址哈希法的缺陷在于服務器節(jié)點的數(shù)量變化將導致計算得到的后端節(jié)點變化，從而違反連接一致性。根據(jù)四層負載均衡需保持連接一致性的特性，目前廣泛應用于四層負載均衡的調(diào)度算法為Karger等[30]提出的一致性哈希算法，該算法能夠有效降低集群擴縮容和單點故障的負面影響。如圖2所示，一致性哈希將哈希值映射到0～232-1的環(huán)形空間中，這些值將順時針分配到第1個節(jié)點上，避免因單個節(jié)點退出而造成的大量數(shù)據(jù)遷移。

Figure 2 Consistent hash圖2 一致性哈希

針對節(jié)點數(shù)量較少時易導致的不均勻性，Dynamo[31]引入虛擬節(jié)點的概念對一致性哈希進行了改進，文獻[32]又提出虛擬節(jié)點的自我調(diào)整機制以減少計算開銷，針對異構(gòu)集群的應用場景，文獻[33]提出了自適應的一致性哈希算法。

3 四層負載均衡技術應用

目前國內(nèi)外已經(jīng)存在多種四層負載均衡體系，負載均衡器可以作為硬件設備運行，也可以由軟件定義。隨著對云服務需求的增長，昂貴且難于擴展的專用硬件負載均衡器逐漸被替換為軟件負載均衡器SLB(Software Load Balancer)， SLB成本低、可用性高和靈活性強，但會存在一些延遲。如今，基于可編程芯片的交換機可替代SLB，同時還能降低成本、保證連接一致性，并提供更佳的性能。

3.1 基于軟件的四層負載均衡體系

3.1.1 Ananta

Ananta是一個能滿足多租戶云環(huán)境、可橫向擴展的軟件負載均衡器。數(shù)據(jù)中心采用三級架構(gòu)，包括頂層的路由器，運行在服務器中的軟件多路復用器SMux(Software Multiplexers)和運行在每臺服務器上的主機代理HA(Host Agent)。

圖3為Ananta接受流量的路徑圖，頂層路由器通過ECMP將目的為VIP的數(shù)據(jù)包定向到某一個SMux，每個SMux通過邊界網(wǎng)關協(xié)議BGP(Border Gateway Protocol)宣布自己成為所有VIP的下一跳，內(nèi)部存儲所有VIP到DIP的映射，并為VIP選擇一個DIP，再通過IP-in-IP[34]協(xié)議封裝數(shù)據(jù)包，將外部IP報頭的目標地址設為選擇的DIP。在服務器側(cè)，由HA對傳入的數(shù)據(jù)包進行解封裝，重寫目標地址和端口，最終發(fā)送到VM。HA還攔截VM傳出的數(shù)據(jù)包，并將源IP從DIP重寫為VIP，通過直接服務器返回DSR(Direct Server Return)將響應數(shù)據(jù)包轉(zhuǎn)發(fā)回客戶端。

Figure 3 Data packet network flow in Ananta圖3 Ananta數(shù)據(jù)包網(wǎng)絡流向

盡管Ananta中的單個SMux的容量有限，但其可以通過擴展處理大量流量。第一，系統(tǒng)部署了多個SMux并通過ECMP劃分流量，SMux將VIP到DIP映射存儲在服務器主內(nèi)存中，通過服務器的增加可以簡單地進行擴展。第二，DSR使得負載均衡器不再處理響應數(shù)據(jù)包，確保只有傳入流量或VIP流量才會通過負載均衡器，并且Ananta還采用了快速路徑的機制來增強可伸縮性，即所有服務間流量轉(zhuǎn)發(fā)直接使用DIP而非VIP，但這同時也抵消了使用VIP的好處，比如需要進行策略配置時只能使用數(shù)量極大的DIP而非VIP。

相較傳統(tǒng)硬件負載均衡器，Ananta的設計主要解決了面對日益增長的流量負載均衡難以擴展的問題，雖然以軟件的部署方式降低了成本，同時也增加了靈活性，但也會增加延遲并限制吞吐量，Ananta造成的延遲約為1 ms，且為了達到處理大流量的目的，需要部署的SMux數(shù)量約占數(shù)據(jù)中心規(guī)模的10%[14]，這對現(xiàn)在的數(shù)據(jù)中心建設來說是不可接受的。

3.1.2 Maglev

Maglev是由Google公司開發(fā)的一個與Ananta一樣運行在Linux服務器上的大型分布式軟件負載均衡系統(tǒng)。圖4為Maglev接受流量的路徑圖，流量從路由器通過ECMP到達Maglev，Maglev通過通用路由封裝GRE(Generic Routing Encapsulation)[35]封裝數(shù)據(jù)包后轉(zhuǎn)發(fā)到最終服務器，最終服務器收到數(shù)據(jù)包進行解封裝并使用DSR將響應數(shù)據(jù)包發(fā)回至客戶端。

Figure 4 Data packet network flow in Maglev圖4 Maglev數(shù)據(jù)包網(wǎng)絡流向

Maglev將Ananta HA的網(wǎng)絡地址轉(zhuǎn)換NAT(Network Address Translation)功能用一個外部系統(tǒng)替代完成，取消了快速轉(zhuǎn)發(fā)機制，并對單機性能進行了優(yōu)化，主要方式是繞過內(nèi)核，使其直接從網(wǎng)卡接收數(shù)據(jù)包，再用合適的GRE頭部重寫封裝數(shù)據(jù)包后發(fā)回。處理過程如圖4所示，Maglev收到數(shù)據(jù)包后首先計算五元組哈希并將數(shù)據(jù)包分配到不同的接收隊列，實現(xiàn)批量并行處理，每個隊列對應不同的包重寫線程。Maglev維護一張連接表，該表存儲現(xiàn)有連接的上次選擇結(jié)果，以保證連接一致性。包重寫線程執(zhí)行以下操作：(1) 過濾掉沒有匹配到任何VIP的包；(2) 再次計算五元組的哈希值并在連接表中查找；(3) 對于已建立的連接，如上次選擇的后端可用，則將繼續(xù)采用之前的選擇，否則將根據(jù)一致性哈希重新選擇后端，再將此結(jié)果加入連接表；(4)選擇結(jié)束后以GRE頭部進行封裝發(fā)送到傳輸隊列。

相較Ananta，Maglev的設計主要解決了基于內(nèi)核的SLB會對網(wǎng)絡性能造成損害的問題，其評估表示非繞過內(nèi)核的設計吞吐量相較Maglev將少30%，且轉(zhuǎn)發(fā)性能與網(wǎng)卡NIC(Network Interface Controller)有一定聯(lián)系，在包重寫線程數(shù)不足5時，吞吐量隨著線程數(shù)增加，超過5時NIC將成為性能瓶頸，更高速度的網(wǎng)卡對吞吐量的提升不明顯，因此Maglev難以適應更高速度的網(wǎng)絡。

3.2 軟硬結(jié)合的四層負載均衡體系

3.2.1 Duet

Duet是一個能夠同時提供擴展性與高性能的負載均衡設計，通過將負載均衡功能嵌入到數(shù)據(jù)中心現(xiàn)有的交換機中，作為硬件多路復用器HMux(Hardware Multiplexer)實現(xiàn)了低延遲和高容量，并輔之一定數(shù)量的SMux以保證靈活性與可用性。之所以可以這樣設計，是因為實現(xiàn)負載均衡器所需的流量拆分和數(shù)據(jù)包封裝2個核心功能都能在交換機中實現(xiàn)，比如通過ECMP實現(xiàn)流量拆分，使用隧道技術實現(xiàn)數(shù)據(jù)包封裝。

在虛擬化環(huán)境中，由于HMux無法2次封裝數(shù)據(jù)包，因此還需要HA再次進行NAT，如圖5所示。到達HMux的數(shù)據(jù)包將依次匹配3個表，首先匹配轉(zhuǎn)發(fā)(forwarding )表，再根據(jù)IP 五元組的哈希值計算ECMP表的索引，每個索引對應一個隧道(tunneling)表中的DIP，最后再將匹配到的DIP封裝為數(shù)據(jù)包的外部IP報頭。由于交換機表容量有限，Duet將VIP到DIP的映射表劃分到多個交換機上存儲，并通過BGP使得目的為不同VIP的數(shù)據(jù)包路由到不同交換機處理。VIP到DIP的映射分布式存儲在多個HMux的方式導致Duet難以在網(wǎng)絡故障期間實現(xiàn)高可用性，因此SMux中將存儲完整的連接表，在HMux不可用的時候進行功能遷移。

Figure 5 Data packet network flow in Duet圖5 Duet數(shù)據(jù)包網(wǎng)絡流向

相較SLB,Duet的設計主要是為了提升數(shù)據(jù)包轉(zhuǎn)發(fā)的性能，同時提出了軟硬件混合部署的架構(gòu)，充分利用數(shù)據(jù)中心現(xiàn)有交換機的剩余能力，以此降低部署成本，并且其提供的容量增加了10倍，SMux的數(shù)量較Ananta減少了約87%,在SMux數(shù)量相同時延遲僅為Ananta的1/10甚至更低。Duet雖然提供了一定程度的故障轉(zhuǎn)移能力，但HMux中的映射表會隨著DIP池的頻繁變化而變化，這將導致部分連接違反連接一致性。

3.2.2 Rubik

數(shù)據(jù)中心中的流量環(huán)回現(xiàn)象會大大增加數(shù)據(jù)中心網(wǎng)絡的帶寬使用率，不僅會造成成本增加，而且還容易導致網(wǎng)絡出現(xiàn)瞬態(tài)擁塞，從而影響對延遲敏感的服務。為了減少重定向流量對鏈路利用的影響而提出了Rubik，Rubik同樣使用HMux和SMux的混合設計，旨在最大程度地提高HMux能夠處理的VIP流量,以降低成本。

Rubik設計時主要依據(jù)本地性和端點靈活性2個原則。本地性意在將負載均衡器更加靠近源和將要選擇的后端，由于VIP流量的不平衡性，即對于特定的VIP，不同機頂ToR(Top of Rack)交換機產(chǎn)生的流量規(guī)模不同，從而可以在同一ToR交換機的后端集群平衡特定VIP流量，這將減少進入核心網(wǎng)絡的總流量。端點靈活性意在使將要選擇的后端更加靠近源，根據(jù)不同VIP對應的后端集群的規(guī)模，Rubik將通過分配算法決定每個VIP對應后端的位置，使其與產(chǎn)生VIP流量的源ToR交換機更接近。

Rubik能夠最大程度地將流量負載均衡控制在單個ToR交換機內(nèi)，總帶寬使用量約為Duet的1/3，在總流量一致時(97%)，最大鏈路利用MLU(Maximum Link Utilization)約為Duet的1/4，同時提供可擴展性和可用性優(yōu)勢，雖然Rubik進行了性能上的優(yōu)化，但同樣存在違反連接一致性的問題。

3.3 基于硬件的四層負載均衡體系

3.3.1 SilkRoad

SilkRoad是一個基于可編程交換機芯片的有狀態(tài)負載均衡設計，其目的是應對流量激增與保證一致性，由交換機直接完成負載均衡的功能。SilkRoad部署于可編程協(xié)議無關P4(Programming Protocol-Independent Packet Processors)[36]交換機中，交換機的流水線(pipeline)可以維護多張表并執(zhí)行匹配-動作(match-action)的操作，匹配項及對應動作均可自定義。

圖6顯示了系統(tǒng)中數(shù)據(jù)包的處理過程，數(shù)據(jù)包首先到達連接表，為了節(jié)約有限的片上存儲，匹配字段為五元組的哈希摘要，表項匹配則轉(zhuǎn)入DIP池表選擇DIP并封裝轉(zhuǎn)發(fā)；反之，則說明需要建立新連接，匹配VIP表選定版本號并轉(zhuǎn)入DIP池表，隨后在連接表中插入新連接的狀態(tài)，由于插入之前后續(xù)數(shù)據(jù)包就會到來，此時DIP池更新將破壞連接一致性，于是采用Transit表維持等待中的連接。Transit表采用了寄存器的方式來保證原子性，并使用布隆過濾器(Bloom Filter)進行成員資格檢查，以區(qū)分新舊DIP池版本，若匹配則說明該DIP池的更新還未完成，使用舊版本號選擇DIP。

Figure 6 Data packet network flow in SilkRoad圖6 SilkRoad數(shù)據(jù)包網(wǎng)絡流向

單個基于ASIC交換機的負載均衡器可以替代數(shù)百個SLB，并將成本降低2個數(shù)量級以上，解決軟件處理數(shù)據(jù)包導致的開銷高、抖動和延遲高的問題。而Duet和Rubik將負載均衡功能建立在不能進行連接跟蹤的傳統(tǒng)交換機上，因而需要軟件輔助完成，可編程交換機的出現(xiàn)使得兩者得以集成，使其可以同時具有高性能與靈活性。SilkRoad雖然可以平衡約一千萬個連接，但這在面臨流量激增和DDoS攻擊時依然顯得不足，而外加存儲設備又可能導致轉(zhuǎn)發(fā)性能的下降，因此其適用性還需進一步驗證。

3.3.2 Beamer

存儲每個連接的狀態(tài)并做出負載均衡決策的設計雖然易于實施，但存在服務器或負載均衡器擴展導致連接斷開、因泛洪攻擊而無法維護連接狀態(tài)，有狀態(tài)SLB吞吐量大幅降低等問題。Beamer是一個無狀態(tài)可擴展的負載均衡設計，利用已經(jīng)存儲在后端服務器中的連接狀態(tài)來重定向數(shù)據(jù)包，以保證連接一致性。

圖7為Beamer處理數(shù)據(jù)包的過程，為了克服原哈希算法的缺點，Beamer設計了一個由固定數(shù)量的桶(bucket)組成的中間層，若服務器發(fā)生增減則通過在ZooKeeper[37]中存儲新的映射來完成桶的遷移。Beamer為每個桶保存先前選擇的后端DIP PDIP(Previous Direct IP address)及重新分配的時間TS (TimeStamp)，當?shù)竭_服務器的數(shù)據(jù)包非SYN或不屬于本地連接時，將根據(jù)數(shù)據(jù)包頭中封裝的TS判斷是否將數(shù)據(jù)包轉(zhuǎn)發(fā)到之前的后端，最終使得新服務器可以處理新連接，已建立連接仍由先前的服務器處理。

Figure 7 Data packet network flow in Beamer圖7 Beamer數(shù)據(jù)包網(wǎng)絡流向

Beamer可以采用FastClick[38]或者P4交換機[39]2種部署方式，使用穩(wěn)定哈希算法和Daisy chaining技術保證連接一致性，包處理速度相較SLB提升了2倍，面臨網(wǎng)絡故障和服務器增減時其吞吐量都能進行平滑過渡。Beamer無狀態(tài)的設計雖然減輕了負載均衡的處理與存儲壓力，但Daisy chaining導致的服務器間頻繁的流量重定向也會增加服務器開銷。

3.3.3 Faild

Faild是一個針對內(nèi)容分發(fā)網(wǎng)絡CDN(Content Delivery Network)的無狀態(tài)負載均衡設計，此場景下數(shù)據(jù)中心物理空間受到很大限制，需要更高效率的負載均衡機制來最大程度地吸收DDoS攻擊，實現(xiàn)無縫故障轉(zhuǎn)移，從而降低服務維護對可用性的影響，F(xiàn)aild主要通過交換機封裝狀態(tài)信息和主機端重定向?qū)崿F(xiàn)。

圖8為Faild處理數(shù)據(jù)包的過程，交換機維持FIB(Forward Information dataBase)表和ARP(Address Resolution Protocol)表，F(xiàn)IB將VIP映射到一組固定的虛擬下一跳，以此繞過路由表來避免連接重置。ARP表中每個下一跳IP地址都對應一個擴展MAC地址，該地址由控制器根據(jù)服務器狀態(tài)通過一致性哈希算法進行修改，包含當前和之前選擇的后端信息。主機端收到數(shù)據(jù)包后判斷兩者信息是否一致，不一致則將非首次建立的本地連接數(shù)據(jù)包重定向至之前的后端處理。

Figure 8 Data packet network flow in Faild圖8 Faild數(shù)據(jù)包網(wǎng)絡流向

Faild使數(shù)據(jù)中心任意組件的移除都不會影響現(xiàn)有連接，流量繞行也不會引起較高延遲和主機端的CPU開銷，相較Beamer，F(xiàn)aild有明確的使用場景，但性能較差，且其數(shù)據(jù)平面查找表的配置依賴供應商的應用程序編程接口API(Application Programming Interface)來完成，同樣只能進行一次重定向，無法應對同一DIP的多次改變。

3.3.4 Cheetha

基于哈希的算法注重保證連接一致性而非負載分擔的均勻性，Cheetha是一個可部署任何負載均衡算法并保證一致性的負載均衡機制，可以無狀態(tài)和有狀態(tài)2種方式部署，設計的核心是將連接的狀態(tài)信息編碼于cookie中。

圖9為Cheetha無狀態(tài)設計中數(shù)據(jù)包處理過程，對于SYN包，首先根據(jù)VIP與均衡算法進行選擇與轉(zhuǎn)發(fā)，然后服務器將server id與五元組加密哈希的異或結(jié)果作為cookie加入數(shù)據(jù)包；對于后續(xù)的數(shù)據(jù)包，Cheetha將cookie與五元組加密哈希異或后得到server id與DIP。Cheetha有狀態(tài)設計維護多個連接表，通過SYN包的五元組加密哈希建立表項并添加cookie到數(shù)據(jù)包頭中，后續(xù)數(shù)據(jù)包通過cookie快速索引，由于可建立連接的數(shù)量與cookie的大小有關，因此采用了分區(qū)與cookie重用的策略。

Figure 9 Data packet network flow in Cheetha圖9 Cheetha數(shù)據(jù)包網(wǎng)絡流向

Cheetha同樣可以采用FastClick和P4交換機2種方式部署，具有可擴展性、高內(nèi)存效率、快速的數(shù)據(jù)包處理能力和針對阻塞攻擊的恢復能力。無狀態(tài)版本的流量完成時間FCT(Flow Completion Time)約為利用DPDK或接收端縮放RSS哈希的30%～50%，有狀態(tài)版本增加了流的可見性，連接跟蹤使其可以完成更復雜的網(wǎng)絡功能。哈希過程中使用的密鑰僅由負載均衡器維護，對服務器側(cè)不透明，從而防御惡意流量。cookie使得表項的增刪改查只需在數(shù)據(jù)平面進行，但cookie會被附加在每個請求中，無形中增加了流量。

4 四層負載均衡體系比較

4.1 四層負載均衡器性能衡量指標

(1) 部署成本與難度：主要依據(jù)是否能有效利用現(xiàn)有設備。軟件易于部署，適應性強，且成本較低；硬件一般具有更高的設備成本和維護成本，且較難與現(xiàn)有架構(gòu)相適應。

(2) 可靠性：主要包括是否滿足連接一致性與故障轉(zhuǎn)移。在節(jié)點頻繁更新時違反連接一致性的連接個數(shù)將是評價服務質(zhì)量的重要指標，因為這將會導致服務延遲增加甚至會話的重新建立；LB的增加和退出可能導致部分連接狀態(tài)丟失，在此過程中的連接數(shù)、吞吐量等也應當?shù)玫狡交倪^渡。

(3) 轉(zhuǎn)發(fā)性能：主要包括連接并發(fā)數(shù)、吞吐量和轉(zhuǎn)發(fā)時延。當流量到達負載均衡器時，不同設備和均衡算法的處理時間不同，小并發(fā)數(shù)、低吞吐量或高延遲將導致負載均衡器成為整個服務提供中的性能瓶頸。

(4) 負載平衡性：主要判斷節(jié)點負載分配是否均勻。節(jié)點的負載率為節(jié)點當前負載與節(jié)點能力的比值，而節(jié)點的性能指標則包括CPU使用率、內(nèi)存使用率和磁盤I/O活動時間等，各節(jié)點的負載率越接近負載平衡性越高。

(5) 安全性能：主要判斷LB對惡意流量的防御能力。判斷標準包括應對惡意流量時節(jié)點負載率、CPU消耗、占用內(nèi)存和攻擊響應時間等，高效益的LB在分配流量時能夠進行安全防御而減少專用安全設備的成本。

4.2 負載均衡方案性能比較

結(jié)合文獻[20,40,41]對部分負載均衡方案的總結(jié)，本文將從部署方式與性能2個角度對各方案進行比較，結(jié)果如表3所示。負載均衡模塊能夠以軟件、硬件或軟硬結(jié)合的方式部署，為了克服SLB的性能弱點，可通過將封裝與分流的功能卸載到交換機處理，或者通過DPDK、零拷貝等方式進行優(yōu)化，加速數(shù)據(jù)平面轉(zhuǎn)發(fā)。傳統(tǒng)交換機結(jié)合軟件的混合架構(gòu)被證明可行，同時創(chuàng)新地使用可編程轉(zhuǎn)發(fā)芯片構(gòu)建低成本高性能的負載均衡器也成為可能，但要融入現(xiàn)有架構(gòu)還需要一段時間。

以負載均衡模塊是否維護每個連接的狀態(tài)分為有狀態(tài)和無狀態(tài)2種方案，狀態(tài)可存儲于承擔負載均衡功能的服務器或可編程交換機中。有狀態(tài)方案均衡算法一般利用一致性哈希或五元組哈希值進行ECMP，結(jié)合維護在負載均衡器中的用戶狀態(tài)以實現(xiàn)一致性，也因此得以實現(xiàn)更為復雜的網(wǎng)絡功能。無狀態(tài)方案均衡算法同樣采用哈希和ECMP，但借助可編程轉(zhuǎn)發(fā)技術或Cookie等手段將用戶狀態(tài)存入數(shù)據(jù)包中，再由服務器對數(shù)據(jù)包再次處理，如修改協(xié)議棧、路由重定向和創(chuàng)建Cookie等操作，從而實現(xiàn)連接一致性，因此將增加額外開銷。此外，上述方案大多是一致性哈希的優(yōu)化算法，Cheetha[20]能夠自由選擇更適應流量特征的均衡算法，從而提高了負載平衡性。

在性能方面：(1)負載均衡系統(tǒng)的瓶頸一般受限于其部署架構(gòu)和平臺，如交換芯片內(nèi)存、交換機和服務器的性能，對于利用特殊結(jié)構(gòu)或算法維護狀態(tài)的方案，性能取決于算法的邏輯設計，如Daisy chaining引發(fā)的重定向、Cookie大小影響的連接數(shù)等；(2)硬件架構(gòu)通常具有更快的速度和更低的延遲，SLB將為每個數(shù)據(jù)包增加50 μs到1 ms的處理延遲[20]；(3)當負載均衡器出現(xiàn)故障，上層交換機將流量分配至備份負載均衡器處理，有狀態(tài)方案可能因連接表丟失而造成中斷連接，且目前還未出現(xiàn)基于可編程交換機的負載均衡集群方案，能否實現(xiàn)集群連接表同步還需進一步研究；(4)保存狀態(tài)使得負載均衡器難以防御DDoS這樣資源耗盡類的安全攻擊，因為其無法判斷當前連接性質(zhì)，大量短鏈接的建立將很快耗盡設備內(nèi)存，雖然可以針對連接做出超時時間的設定，但仍無法面對DDoS攻擊數(shù)量和規(guī)模持續(xù)增加，文獻[42,43]還提出了負載均衡與DDoS檢測、緩解相結(jié)合的技術，值得進一步研究該技術與四層負載均衡方案的適配性。

4.3 展望與未來研究方向

4.3.1 負載均衡算法優(yōu)化

負載均衡算法是能否保證負載均衡分配的核心，現(xiàn)有方案采用多種手段對一致性哈希進行優(yōu)化，將連接分配給后端實例而忽略了服務器實際負載。一致性哈希旨在保證連接一致性而非均衡性，因此它既不能根據(jù)后端服務器的能力與負載合理分配請求，也無法根據(jù)流的大小動態(tài)分配流量，以達到更好的平衡。

服務實例之間的負載不均衡是導致負載均衡系統(tǒng)出現(xiàn)額外處理延遲的主要原因，現(xiàn)在的解決方案如流量重定向?qū)⒃黾蛹s12.48%的額外流量[44]，連接跟蹤則會消耗大量內(nèi)存，從而導致網(wǎng)絡資源使用效率低下。針對此問題，服務器狀態(tài)感知和擁塞狀態(tài)感知的負載均衡系統(tǒng)也不斷出現(xiàn)[45 - 48]，通過周期性地探測、上報和調(diào)整權(quán)值，在滿足連接一致性的同時，實現(xiàn)服務實例之間的負載均衡分配和最佳網(wǎng)絡資源使用。雖然通過感知后端服務器負載可以在一定程度上縮減流完成時間，但預估流的大小并進行區(qū)分仍然是四層負載均衡的處理難點。

Table 3 Comparison of load balancing schemes

4.3.2 可編程轉(zhuǎn)發(fā)技術

為了克服傳統(tǒng)網(wǎng)絡硬件更新周期長、靈活性差的缺點，可編程轉(zhuǎn)發(fā)技術提出了一種高效益管理的網(wǎng)絡抽象，使網(wǎng)絡管理者可針對使用場景自由設計協(xié)議，而不依賴交換機開放的接口，因此利用成本較低的可編程交換機實現(xiàn)各項網(wǎng)絡功能包括負載均衡已成為當下的研究趨勢。

傳統(tǒng)SLB一般通過現(xiàn)有的IP-in-IP、GRE和通用UDP封裝GUE(Generic UDP Encapsulation)[49]等隧道技術將選擇的DIP封裝為外部包頭，并由主機端完成解封裝和NAT的過程，可編程轉(zhuǎn)發(fā)技術使負載均衡功能可直接在轉(zhuǎn)發(fā)平面定制，完成更加復雜的均衡決策。雖然目前可編程交換機還未大量部署，但隨著可編程轉(zhuǎn)發(fā)設備可存儲和維護的信息量與使用性的提升，將促進多功能、高性能的負載均衡方案的產(chǎn)生。

數(shù)據(jù)中心越來越多地使用智能網(wǎng)卡Smart NIC(Smart Network Interface Controller)[50]支持網(wǎng)絡虛擬化和特定于應用程序的任務，其專用的加速器和可編程的處理核心，使從通用CPU上卸載日益復雜的數(shù)據(jù)包處理任務[51,53]成為可能。基于P4語言的Smart NIC[54]也已經(jīng)出現(xiàn)，如何基于現(xiàn)有及新架構(gòu)的負載均衡模塊卸載到智能網(wǎng)卡將是日后的研究熱點之一。

4.3.3 人工智能與機器學習技術

數(shù)據(jù)中心網(wǎng)絡中，負載均衡機制本質(zhì)上是對流的調(diào)度，其設計受制于網(wǎng)絡應用場景與流量特性，而對動態(tài)系統(tǒng)中未來事件的預先了解通常可以提高系統(tǒng)的性能和效率[54]，如通過提前獲取流大小的信息將使負載均衡決策更加合理。企業(yè)集群中超過60%的工作是周期性的，具有可預測的資源使用模式，因此可以結(jié)合機器學習技術，通過分析與歸類歷史流特征構(gòu)建學習系統(tǒng)，實現(xiàn)根據(jù)流特性的負載決策。

軟件定義網(wǎng)絡SDN(Software Defined Network)場景下特有的流表特性提供了大量包含網(wǎng)絡信息的數(shù)據(jù)，使機器學習技術在數(shù)據(jù)分析和挖掘方面得以利用，如分析結(jié)果可用于負載均衡決策和惡意流量識別。負載均衡技術被證明能夠有效抵抗DDoS攻擊[56]，基于分類算法的流特征分析也被用于負載均衡系統(tǒng)[42]中，以應對不同類型的流量攻擊，因此結(jié)合機器學習和人工智能技術的數(shù)據(jù)中心網(wǎng)絡負載均衡方案是未來研究的一個熱點。

5 結(jié)束語

流量激增使數(shù)據(jù)中心需要有效的負載均衡機制來處理高并發(fā)訪問，提高資源利用率。負載均衡有軟件、軟硬結(jié)合、硬件3種不同的部署方式，基于服務器的軟件負載均衡成本低，能夠靈活實現(xiàn)多種網(wǎng)絡功能；軟硬結(jié)合架構(gòu)充分應用交換機的剩余能力，實現(xiàn)了高性能的轉(zhuǎn)發(fā)；基于可編程轉(zhuǎn)發(fā)技術的交換機兼具靈活性與高性能，并在近年得到多種實現(xiàn)，但還未大規(guī)模投入生產(chǎn)使用，且在數(shù)據(jù)平面轉(zhuǎn)發(fā)、均衡算法與安全防護等方面還需進行優(yōu)化。