基于DPDK的邊緣集群內低成本高速通信方案

吳明杰，陳慶奎

1(上海理工大學 管理學院，上海 200093) 2(上海理工大學 光電信息與計算機工程學院，上海 200093)

1 引 言

隨著物聯網[1]規模的不斷擴大，數據的不斷增加，基于云的物聯網解決方案將承受更大的壓力.為了緩解這一現狀，越來越多的企業開始將目光轉向邊緣計算[2]，并將其作為云的延伸擴展，以加快數據分析的速度，減少延遲.邊緣計算是一種分散式計算架構，將終端的部分計算需求從原有的云計算中心分配到邊緣計算集群中[3].這樣不僅能夠充分緩解數據中心的計算和通信壓力，還能充分利用邊緣計算集群的資源，改善用戶的響應需求和計算需求.邊緣計算的關鍵不僅僅是計算性能，還需要高速的處理機制和通信機制.

據估計，未來50%的物聯網數據將在數據源頭附近進行處理，包括設備端和邊緣側.而且，隨著邊緣AI[4，5]的興起，使得越來越多的人工智能應用如智能監控、車聯網、自動駕駛等被部署在邊緣側.這不僅使得邊緣節點所面臨的數據量增加，邊緣集群內通信的數據量也將驟增，這對邊緣集群內的通信帶寬提出了更高的要求.

物聯網設備的龐大規模，決定了邊緣計算節點的數量不可能少，而且是高度分布式的.他們不僅分布在辦公室、工廠、校園等場所，有些甚至分布在遙遠的、難以訪問的地方.邊緣計算節點不僅要執行數據采集、程序更新、設備管理和監控、機器學習模型更新等高級功能，而且還要進行實時的數據處理、AI計算等.這些決定了邊緣計算節點需要低成本和支持復雜業務的屬性.如何以較低的成本實現邊緣計算節點對復雜任務的支持，將會是研究熱點.

本文針對邊緣計算對集群內高速通信的需求，提出一種以較低成本實現更高帶寬的通信方案.相比于傳統的通信方案，本文提出的方案能夠在提供相同帶寬的情況下，成本縮減2/3，延遲降低10%，丟包率降低60%.

2 相關工作

隨著邊緣計算所面臨的數據和業務規模增加，邊緣節點的實現方式也由單機擴展到了集群，而且集群內的通信數據量和頻率的增加，對帶寬也提出了更高的要求.雖然現在的網絡設備帶寬從最初的百兆增加至千兆，但是網絡帶寬的增長速度遠不及網絡流量，千兆帶寬對于實時性較高的業務也顯得捉襟見肘.萬兆帶寬的高昂價格，也使得其難以普及.在邊緣集群內實現萬兆帶寬連接，將會增加邊緣節點的成本負擔.

現有的服務器操作系統的bonding模式[6]，可以通過多網卡增加服務器帶寬，但其實現復雜，甚至需要專用的通信設備.而且bonding模式下，單條網絡連接無法突破單張物理網卡理論速率的限制，要想充分利用多張網卡的疊加帶寬，必須運用多線程多連接技術[7]，增加了使用難度，傳統的網絡協議和處理機制也使得網絡帶寬的利用率不高.現有通信技術主要從兩方面進行改進：一方面通過硬件手段如FPGA等專用硬件進行數據包處理.賴裕平、馬秀等人基于輪詢系統的特性，提出一種基輪詢的mac協議的FPGA設計[8].利用FPGA的可重構和靈活的特性從硬件手段進行通信性能的提升.雖然性能提升明顯，降低了傳輸時延，提高了總線利用率，但是價格昂貴，也沒有從根本上解決內核協議性能低下的問題.另一方面通過對現有的傳輸協議進行改進或者進行數據量壓縮.例如Hei X等人提出一種基于UDP的Deque-ERUDP高效傳輸協議，通過協議動態的提升通信效率，降低網絡阻塞[9].而Betzel F等人則從數據角度出發，采用近似壓縮削減冗余數據量[10].然而這種方式容易丟失數據細節并消耗大量計算資源.在2014年，Intel針對x86架構推出了一種數據平面開發套件DPDK[11，12]，旨在應對網絡中數據包的高速傳輸.DPDK利用用戶態驅動、親和性、內存大頁和輪詢等技術，使得網卡的收發速率可接近線速[13，14].DPDK繞過傳統的內核協議棧，將數據鏈路層數據直接交給用戶進程處理，減少了通信過程中數據的交付時延[15].DPDK對于多核和多網口的支持，能夠成倍地增加通信帶寬.DPDK的眾多特性，能夠極大地提升網絡通信效率[16].

在成本受限和高速率傳輸需求的驅動下，改進網絡協議和處理機制、多網口并行通信是一種新的出路.本文基于Intel的DPDK技術提出一種多網卡的高速傳輸方案.該方案首先利用DPDK用戶態驅動技術，將數據包的處理移至用戶空間，不僅繞過了系統內核協議棧，使網卡能夠接近線速率傳輸，而且結合DPDK多核多網口的特性[17]，實現了多網口的并行高速傳輸和帶寬疊加；其次，利用操作系統Socket本地回環機制[18，19]，為用戶應用提供語言無關的調用接口，并且單條連接能夠達到多張網卡的疊加帶寬.

3 設 計

DPDK是繞過傳統的內核協議棧，能夠接近網卡的線速進行數據收發.再結合CPU多核特性，DPDK能夠充分利用多張網卡的疊加帶寬，使十張千兆網卡的疊加帶寬能夠與一張萬兆網卡相匹敵，但成本卻降低了很多.DPDK是C語言開發的，對于其他高級語言的支持不夠友好.因此，本文想利用操作系統的套接字機制，實現DPDK對于多語言編程環境的支持.套接字的回環機制作為本地操作系統不同進程間的通信方式之一，能夠實現DPDK進程與不同語言的用戶進程之間進行通信.為了驗證操作系統本地回環機制的帶寬，本文在配有DDR3-1600Mhz的服務器上使用Iperf軟件進行測試，最終測得本地回環的TCP通信帶寬為60Gbps，經過優化的UDP通信帶寬為14Gbps.操作系統本地回環機制的帶寬不僅能過支持DPDK多張千兆網卡疊加帶寬，甚至能夠支持DPDK多張萬兆網卡的疊加帶寬.因此，本文的這種通信方案具有很高的升級空間和應用前景.

3.1 物理拓撲

DPDK利用UIO技術，將數據鏈路層數據直接交給用戶進程處理.因此，用戶需要自定義通信協議.DPDK基于數據鏈路層的數據包處理技術決定了網絡拓撲簡單，網絡設備要求低，僅需要二層網絡設備即可實現通信.

圖1 物理拓撲Fig.1 Physical topology

如圖1所示，本文的方案通過普通網線將服務器的多張網卡與二層交換機相連，對傳統的網絡結構沒有影響.而且，集群節點的擴展與傳統的交換機級聯技術并無沖突，只需將待擴展服務器的多張網卡通過網線接入二層交換機即可實現.

3.2 系統框架

通過操作系統套接字的本地回環機制，本文的通信方案能夠支持不同高級語言應用的使用.如圖2所示，虛線左側為傳統通信，右側為本文的通信方案.本文的通信方案與傳統的通信方案相互兼容共存，可以為集群內的主機間提供兩套通信方案，能夠支持更加復雜的上層任務.本文的通信方案基于DPDK實現底層多網卡的數據收發，通過本地回環機制為用戶應用提供統一的使用接口.而且，內部也實現了多網卡的負載均衡以及多應用的帶寬均衡機制.

圖2 系統框架Fig.2 System framework

4 實 現

4.1 通信模型

本文的通信方案利用本地回環機制為用戶提供使用接口，底層的通信過程對用戶是透明的.同時，通信過程也是全雙工的，即在通信過程中數據發送和接收方可以同時互相通信.如圖3所示，集群內主機Node1和Node2的通信過程.

圖3 通信模型Fig.3 Communication model

為了實現本文的通信方案，我們自定義了通信協議，各字段含義與占用字節數如圖4所示.DPDK是基于數據鏈路層的數據傳輸，Ethernet數據幀頭內的目的MAC字段需要根據上層應用傳入的目的節點決定.因此，需要實現類似于傳統ARP網絡協議的機制，可以根據節點編號獲取目的主機的MAC地址列表，并本地緩存.上層用戶應用需要填充服務類型、目的節點編號、目的回環端口、源節點編號、源回環端口、數據長度以及數據字段.Ethernet數據幀頭內MAC地址有基于DPDK的模塊進行填充，并通過負載均衡算法，選擇合適的網口進行發送.

圖4 協議字段Fig.4 Protocol field

4.2 內存模型

DPDK提供的許多內存對象模型來應對數據包的高速處理，本文利用MBuf與ring內存模型進行數據的處理.如圖5所示，用戶應用UA_1首先與本地回環公共端口進行連接(TCP需要，UDP不需要)，連接建立后即可發送數據，并且在接收端口進行數據接收.DPDK模塊的主邏輯核在本地回環公共端口進行連接接入和數據接收，如果為TCP連接，需要將用戶端的連接端口和連接套接字sock_fd對象記錄到TCP_conn_Table 表中，UDP則不需要此步操作.主邏輯核接收到傳輸數據，首先從DPDK_rte環境中申請MBuf對象，并填充數據段以及節點編號、端口等信息，并將其放入由多個ring組成的公共發送緩沖區Public_send_buffer中.

DPDK模塊的多個從邏輯核將從公共發送緩沖區Public_send_buffer中取出待發送MBuf，根據其目的節點和源節點的編號，從Node_MACs_table表中根據負載均衡算法和輪詢算法選出本地發送網卡和目的接收網卡，將其MAC地址填充到MBuf的Ethernet數據幀頭內，并在相應的網卡端口進行數據發送.多個從邏輯核也從各網卡端口不停地接收數據，根據數據包的服務類型字段和端口字段將數據包發送到對應的本地回環端口上.如果是TCP連接的數據包，需要通過TCP_conn_Table 表查找對應的連接套接字sock_fd，并將數據發送到該sock_fd.

4.3 端口負載均衡模型

對于多端口并行通信，端口負載均衡是必不可少的.傳統的端口分發策略包括平衡循環法和權重輪詢法，由于其只考慮數據收發的公平性，并未考慮到實際運行環境(如端口負載、端口性能等)，容易出現端口擁塞和大量丟包問題.高效的端口負載均衡算法才能夠保證數據的高速率傳輸，過于復雜的算法并不適用.為了保證數據傳輸的高效性和穩定性，根據網口的實時負載信息，本文提出一種動態負載均衡機制，如圖6所示.

發送核心從公共發送緩沖區Public_send_buffer中取出待發送mbuf，并從中提取五元組信息Quintuple(ptype，s_node，d_node，s_pump，d_pump)，其中s_node表示源節點編號，d_node表示目的節點編號，s_pump表示源端口號，d_pump表示目的端口號，ptype表示服務類型.首先，利用微軟拓普利茲算法對提取到的五元組信息計算散列值，并與端口總數進行取模運算，選擇出發送網口.根據選擇出的網口負載情況，決定是否調用調整函數重新選擇合適的發送網口.然后，根據輪詢算法選擇出目的節點的接收端口.最終得到一個最四元組Quad(s_port，s_mac，d_port，d_mac)，對應信息填入以太網包頭后，調用DPDK端口發送數據.

圖5 內存模型Fig.5 Memory model

根據DPDK提供的網口統計信息函數所獲取到的網卡動態參數，建立網口負載信息模型，對端口選擇提供參考.各符號在表1中進行了詳細的說明.

圖6 端口負載均衡模型Fig.6 Port load balancing model

對于普遍的全雙工網卡，我們能夠得到6個基本的動態參數N_ip_porti，N_op_porti，N_ib_porti，N_ob_porti，N_imp_porti，N_iep_porti.通過時間周期T進行采集，可以計算出網口在T周期內的各參數的速率狀態V_ip_porti，V_op_porti，V_ib_porti，V_ob_porti，V_imp_porti，V_iep_porti，計算方式如公式(1)-式(7)所示.

(1)

(2)

(3)

(4)

(5)

(6)

(7)

(8)

(9)

(10)

(11)

(12)

(13)

(14)

表1 符號描述Table 1 Symbol description

為防止負載信息因采集干擾而出現突變，提高負載信息準確性，本文對計算得到的網口負載率進行自動調節，使其平滑過渡.平滑過渡計算公式如公式(15)、公式(16)所示，其中r為調整因子，通常設置為0.8.

Li*_porti(t)=r×Li_porti(t)+(1-r)×Li_porti(t-1)

(15)

Lo*_porti(t)=r×Lo_porti(t)+(1-r)×Lo_porti(t-1)

(16)

為了衡量當前網口負載率相比其他網口負載率是否過高，提出網口負載均衡度.網口負載均衡度能夠體現出網口之間負載率的差異程度，對于是否調用調整函數具有參考價值.網口接收負載均衡度和發送負載均衡度由公式(19)、公式(20)給出定義.對于發送網口選擇，當網口發送負載均衡度超過用戶定義的負載均衡度閾值δ時，調用調整函數重新選擇合適的發送網口；對于接收網口選擇，當網口接收負載均衡度超過用戶定義的負載均衡度閾值δ時，調用調整函數重新選擇合適的接收網口.最終返回最優的網口信息四元組Quad(s_port, s_mac, d_port, d_mac).

(17)

(18)

(19)

(20)

4.4 帶寬分配模型

由于本地回環機制的帶寬遠遠高于網卡的帶寬，因此需要對用戶應用的發送進行限制.而且，在多用戶應用發送數據時，還必須保證帶寬公平性，限制每個用戶應用的發送帶寬.用戶應用在發送數據時，可以根據速率調節模塊計算值動態調整實時發送速率.如圖7所示，DPDK模塊將多網卡的總帶寬共享到Share_info中的Total_BW.每個應用在發送數據之前，需要增加Share_info中的應用數量APP_NB.Rate_BW 為DPDK模塊對所有網卡可用帶寬的實時監控值.

圖7 帶寬分配模型Fig.7 Bandwidth allocation model

Vavailable_ob_porti(t)=Vmax_ob_porti-V_ob_porti(t)

(21)

(22)

(23)

(24)

(25)

5 實 驗

5.1 實驗環境

為了驗證本文方案的性能，我們使用10臺普通主機和一臺48口千兆二層交換機搭建邊緣集群.服務器配置詳細信息如表2所示.每臺服務器CPU為8核心Intel Xeon E3-1230 V2@3.3Ghz，兩張4口Intel-I350-T4千兆網卡，共8網口.BPCM系統是基于DPDK-17.11.3版本開發，配置了8G大頁內存，端口接收隊列和發送隊列各1個，且大小為1024，可調節.由于服務器CPU為8核心，且有8個網口，為避免CPU核心全占用對實驗數據產生影響，本文采用4張網卡作為多網卡傳輸性能測試，占用5個CPU核心進行數據處理.

表2 主機配置信息Table 2 Host configuration information

實驗前，我們首先使用Iperf3軟件對主機的本地回環機制的帶寬進行了測試，測試結果如表3所示.從表3中可以看出，隨著線程數量的增加，TCP和UDP帶寬有所增加，但當線程數量超過3時，帶寬不再增加.而且在多線程時，各線程均勻分配總帶寬.

表3 本地回環帶寬測試Table 3 Local loop-back bandwidth test

5.2 性能評估

由于本文方案的DPDK模塊并未實現可靠傳輸，因此選取傳統UDP通信進行對比.套接字本地回環機制的TCP和UDP通信帶寬遠遠高于多張網卡的疊加帶寬，并非本文方案的通信瓶頸，因此實驗中本地回環選取TCP或者UDP，并不會對實驗數據產生太大影響.在接下來的實驗中，我們方案的本地回環選取UDP作為通信方式.我們討論了在單張千兆網卡和10張千兆網卡兩種情況下傳統UDP與本文方案的傳輸性能.通過多次發送10GB的數據，并且選取數據包大小分別為64B、128B、256B、516B、1024B，統計傳輸速率、丟包率以及傳輸延時.

如圖8所示，在單張千兆網卡和單條連接的實驗中，得益于DPDK用戶驅動和內存大頁等技術，使數據包的處理時間大幅降低，基于DPDK的本文傳輸方案在傳輸速率、丟包率和延時上都優于傳統UDP通信.

現有操作系統對于多網卡的并行傳輸并不友好，雖然內核中提供多網卡的bonding模塊，但該模塊主要用于網絡負載均衡與冗余.要實現帶寬的增加，還需要交換機支持IEEE802.3ad 動態鏈路聚合.bonding模塊雖然能夠增加總帶寬，但是無法突破單個連接的帶寬限制(千兆網卡的理論速率).要實現總帶寬的傳輸速率，還需要多連接與多線程技術的配合.為了進行多網卡并行傳輸性能對比，我們將發送服務器和接收服務器的4張網卡通過Linux系統的bonding模塊綁定為模式4，并且啟用LAN內交換機的LACP功能.

圖8 單張千兆網口-單條連接Fig.8 Single gigabit NIC-single connection

在多網卡單條連接的實驗中，傳統UDP由于受到操作系統bonding模式底層實現的限制，傳輸速率無法突破單張網卡的理論速率.本文傳輸方案基于DPDK多核技術的支持，能夠將4張網卡的總帶寬充分利用起來，使用戶在單條連接內即可使用多張網卡的疊加帶寬，實驗結果如圖9所示.

在多網卡多連接的實驗中，傳統UDP通信方式中我們創建4個線程，每個線程建立一條連接，每條連接保證使用底層不同的物理網卡，進行并發性數據發送測試，結果如圖10所示.傳統的UDP雖然也可以使用多張網卡的疊加帶寬，但是受限于系統內核協議棧的處理耗時，其帶寬利用率不高，丟包率和傳輸時延大大增加.而且多連接多線程技術會增加編程難度，需要額外的數據同步技術支持，在大多數數據傳輸場景并不適用.本文的方案能夠在單條連接內提供多張網卡的疊加帶寬，不僅降低了編程難度，而且傳輸延時大幅降低.

圖9 4張千兆網口-單條連接Fig.9 Four gigabit NICs-single connection

圖10 4張千兆網口-多條連接Fig.10 Four gigabit NICs-multiple connections

對本文的端口負載均衡算法性能進行驗證，與傳統的端口輪詢算法進行對比.通過多次發送10GB的數據，并且選取數據包大小分別為64B、128B、256B、516B、1024B.統計了各網口的負載率以及丟包率.如圖11(a)所示，本文提出的端口負載均衡算法比輪詢算法使各網口的負載率更加均勻，而且丟包率也相應的減少，如圖11(b)所示.

圖11 端口負載均衡Fig.11 Port load balancing

本文的速率調節模塊是為了保證多用戶應用帶寬公平性和減少用戶無效數據傳輸而設計的.實驗中模擬5個應用程序依次發送10GB數據，并且選取數據包大小分別為64B、128B、256B、516B、1024B統計各應用的占用帶寬和丟包率.如圖12(a)所示，總帶寬幾乎完全利用，而且各用戶應用均勻的分配帶寬.圖12(a)顯示速率調節一定程度上減少丟包率.

圖12 多應用帶寬分配Fig.12 Multi-application bandwidth allocation

6 總 結

本文在邊緣集群內對低成本、高速率通信帶寬需求的驅動下，基于DPDK提出廉價多網卡提高帶寬的方案.本文的方案不僅能夠在單條連接內提供多張網卡的疊加帶寬，降低編程難度，而且在可擴展性、可升級性、實施簡便性上都更具優勢.利用操作系統的Socket本地回環機制，本文的方案還能夠為用戶提供語言無關的調用接口.通過本文設計的端口負載均衡算法和速率調節模塊，能夠在均衡使用帶寬的同時，減少丟包率和傳輸時延.最后，我們也做了成本對比，如表4所示，本文的通信方案能夠將邊緣集群內組網的成本降低2/3，同時提供相同的通信帶寬.

本文的工作雖然能夠以低成本提供高帶寬，但在可靠性方面未進行研究.接下來的工作我們將在硬件可靠性和軟件可靠性等方面進一步研究，如多交換機備份，可靠傳輸協議等.

表4 搭建10臺規模萬兆帶寬連接邊緣集群的網絡設備成本Table 4 Cost of building 10 sets of 10-Gigabit bandwidth network equipment connected to the edge cluster