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

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

1 引言

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

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

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

2 四層負(fù)載均衡設(shè)計概述

2.1 四層負(fù)載均衡概述

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

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

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

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

2.2 四層負(fù)載均衡設(shè)計原則

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

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

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

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

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

2.3 四層負(fù)載均衡常用算法

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

Table 1 Summary of static scheduling algorithms

Table 2 Summary of dynamic scheduling algorithms

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

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

Figure 2 Consistent hash圖2 一致性哈希

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

3 四層負(fù)載均衡技術(shù)應(yīng)用

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

3.1 基于軟件的四層負(fù)載均衡體系

3.1.1 Ananta

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

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

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

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

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

3.1.2 Maglev

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

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

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

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

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

3.2.1 Duet

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

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

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

相較SLB,Duet的設(shè)計主要是為了提升數(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池的頻繁變化而變化，這將導(dǎo)致部分連接違反連接一致性。

3.2.2 Rubik

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

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

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

3.3 基于硬件的四層負(fù)載均衡體系

3.3.1 SilkRoad

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

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

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

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

3.3.2 Beamer

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

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

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

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

3.3.3 Faild

Faild是一個針對內(nèi)容分發(fā)網(wǎng)絡(luò)CDN(Content Delivery Network)的無狀態(tài)負(fù)載均衡設(shè)計，此場景下數(shù)據(jù)中心物理空間受到很大限制，需要更高效率的負(fù)載均衡機制來最大程度地吸收DDoS攻擊，實現(xiàn)無縫故障轉(zhuǎn)移，從而降低服務(wù)維護(hù)對可用性的影響，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地址都對應(yīng)一個擴展MAC地址，該地址由控制器根據(jù)服務(wù)器狀態(tài)通過一致性哈希算法進(jìn)行修改，包含當(dāng)前和之前選擇的后端信息。主機端收到數(shù)據(jù)包后判斷兩者信息是否一致，不一致則將非首次建立的本地連接數(shù)據(jù)包重定向至之前的后端處理。

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

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

3.3.4 Cheetha

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

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

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

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

4 四層負(fù)載均衡體系比較

4.1 四層負(fù)載均衡器性能衡量指標(biāo)

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

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

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

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

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

4.2 負(fù)載均衡方案性能比較

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

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

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

4.3 展望與未來研究方向

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

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

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

Table 3 Comparison of load balancing schemes

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

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

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

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

4.3.3 人工智能與機器學(xué)習(xí)技術(shù)

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

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

5 結(jié)束語

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