黃東生，陳慶奎

（上海理工大學 光電信息與計算機工程學院，上海 200093）

0 引言

隨著物聯(lián)網(wǎng)［1］的高速發(fā)展、AI 數(shù)據(jù)流的不斷增加，給物聯(lián)網(wǎng)服務器設備對于數(shù)據(jù)流的處理帶來了極大的挑戰(zhàn)。為了應對這種現(xiàn)狀，大量研究人員和企業(yè)人員開始將目光投向了邊緣計算［2］，并將其作為云計算的補充和優(yōu)化，加快數(shù)據(jù)處理的速率。邊緣計算可以在云的外圍部署集群服務器，集群服務器中的計算節(jié)點對于數(shù)據(jù)流實施不同的處理，可以采用流水線加工的方式并行地對數(shù)據(jù)流的各個階段進行計算處理，如進行AI 圖像并發(fā)數(shù)據(jù)流的流水線處理，前期由一組流處理節(jié)點獲取到數(shù)百個圖像的數(shù)據(jù)流并對數(shù)據(jù)流進行預處理，然后發(fā)送到下一組流處理節(jié)點進行圖像信息分析，再將分析結(jié)果發(fā)送到下一組流處理節(jié)點進行信息匯總，這樣每個流處理節(jié)點處理并發(fā)數(shù)據(jù)流的一部分，形成一條流水線加工的方式處理數(shù)據(jù)流既能減輕單個計算節(jié)點的工作壓力，又方便各個計算節(jié)點功能的維護與擴展。實現(xiàn)邊緣計算的服務器集群的前提是有個高性能的通信方法。有很多種實現(xiàn)邊緣計算服務節(jié)點通信的方法，其中一方面是采購專用的網(wǎng)絡通信設備、比如Myrinet、ATM 和ServerNet等［3］，但是這些通信設備價格普遍比較高昂，無法進行大規(guī)模的普及。另一方面隨著硬件技術的發(fā)展，普通的網(wǎng)絡設備價格走低，網(wǎng)卡上的端口數(shù)量和通信速度在逐漸提升，CPU 核心數(shù)量也在日益增加。但是如何充分利用這些設備資源成為業(yè)界研究和討論的問題。伴隨著這些問題，Intel 在2014 年發(fā)布了數(shù)據(jù)平面開發(fā)套件DPDK（Data Plane Development Kit）［4］。DPDK 使用DMA 技術和DDIO 技術直接進行內(nèi)存訪問［5］，并利用大頁技術，減少了中斷的發(fā)生，將數(shù)據(jù)的處理從內(nèi)核態(tài)轉(zhuǎn)移到用戶態(tài)［6-7］，繞過了傳統(tǒng)系統(tǒng)的內(nèi)核協(xié)議棧，不用進行多次數(shù)據(jù)的封裝與拆裝，大大地提高了數(shù)據(jù)的處理效率。DPDK 還能很方便有效地管理計算節(jié)點內(nèi)的網(wǎng)卡端口和CPU 核：實時調(diào)度端口與CPU 核資源去執(zhí)行任務和計算出端口與CPU核的負載程度并及時反饋給系統(tǒng)，為邊緣計算服務集群的實現(xiàn)提供了方法。

為了提升邊緣計算服務集群的通信能力與計算節(jié)點內(nèi)對數(shù)據(jù)流的處理速度與通信速度，滿足大規(guī)模數(shù)據(jù)流的實時處理需求，本文提出了并發(fā)AI 數(shù)據(jù)流處理節(jié)點內(nèi)的通信模型，并制作相關系統(tǒng)來驗證本文方法。該系統(tǒng)利用DPDK 的綁定機制與線程親和性等技術，根據(jù)CPU 核資源的負載情況結(jié)合線性規(guī)劃算法和排序算法均衡地為資源分配模型的接收過程、計算過程和發(fā)送過程綁定CPU核，提高核的利用率；還實現(xiàn)了基于DPDK 的高效數(shù)據(jù)流接收；根據(jù)數(shù)據(jù)流的id 類型進行分類排序再計算；實時監(jiān)控集群內(nèi)網(wǎng)卡端口的負載情況；依據(jù)網(wǎng)卡端口的負載情況制定各端口的調(diào)度策略，計算出各個端口的數(shù)據(jù)負載量，以提高系統(tǒng)性能，提高系統(tǒng)資源利用率。

1 相關工作

針對邊緣計算服務集群的構(gòu)建，如何在資源受限的集群計算節(jié)點上處理數(shù)據(jù)流已經(jīng)成為研究的熱門方向。文獻［8］構(gòu)建了基于Kafka 的預警數(shù)據(jù)匯集分發(fā)系統(tǒng)架構(gòu)，說明了Kafka 集群原生負載均衡存在的問題，并提出了一種動態(tài)負載均衡算法，利用采集各代理節(jié)點運行時的負載指標計算負載值，但Kafka 主要是針對應用層通信進行加速，對于系統(tǒng)的底層通信并不能提供很好的支持。文獻［9］提出一種多網(wǎng)卡帶寬疊加方案，其原理是所定義的端口負載均衡模型來對數(shù)據(jù)進行收發(fā)，達到端口的均衡利用，以實現(xiàn)數(shù)據(jù)傳輸?shù)姆€(wěn)定性和高效性，但是主要研究的是網(wǎng)卡端口的通信加速，并沒有針對CPU 核的數(shù)據(jù)處理進行優(yōu)化研究。傳統(tǒng)網(wǎng)絡通信方案制約著相關行業(yè)的發(fā)展，經(jīng)業(yè)界行業(yè)內(nèi)人員的不斷研究，目前已出現(xiàn)了如netmap、DPDK 等高性能網(wǎng)絡數(shù)據(jù)包處理框架。其中，netmap基于共享內(nèi)存的思想，提供了一套用戶態(tài)的庫函數(shù)來訪問共享內(nèi)存，繞過系統(tǒng)內(nèi)核的數(shù)據(jù)包處理操作，實現(xiàn)了用戶態(tài)和網(wǎng)卡之間的數(shù)據(jù)包高性能傳遞［10］，但是netmap 框架仍然需要依賴中斷機制來進行數(shù)據(jù)包的發(fā)送與接收，未完全解決通信瓶頸。DPDK 結(jié)合了netmap 共享內(nèi)存技術，并采用輪詢模式與混合中斷輪詢模式，在數(shù)據(jù)包收發(fā)時，減少了中斷處理的開銷。近年來，因DPDK 部署起來比較簡單、社區(qū)參與人員較多、技術發(fā)展快而被廣大業(yè)內(nèi)人員使用。文獻［11］提出一種基于DPDK 的捕獲數(shù)據(jù)包的方法，使用DPDK 提出的RSS 數(shù)據(jù)分發(fā)算法充分發(fā)揮了多端口通信性能。但RSS 的分發(fā)是基于五元組，就是數(shù)據(jù)包必須包含源IP 地址、源端口、目的IP 地址、目的端口和使用的協(xié)議才能進行數(shù)據(jù)包的分發(fā)，主要針對網(wǎng)絡層及其以上的協(xié)議，若只在同一局域網(wǎng)內(nèi)通信，RSS則不適用，還有就是若不考慮網(wǎng)卡端口的負載情況而使用RSS 分發(fā)算法，容易造成端口的擁塞。文獻［12］則是將DPDK 應用在網(wǎng)絡虛擬化，將SRIVO 與DPDK 結(jié)合，利用DPDK 底層的高速數(shù)據(jù)處理性能，來提升云計算網(wǎng)絡中密集型數(shù)據(jù)在轉(zhuǎn)發(fā)方面的通信性能，但是這對硬件的要求比較高，部署成本和難度較大。上述研究成果，有的只是針對網(wǎng)卡端口設計了相關的調(diào)度策略，但并沒有充分利用CPU 核資源［9-12］；還有些是沒有設計任何端口的調(diào)度策略，直接利用網(wǎng)卡進行數(shù)據(jù)的收發(fā)［8］，沒有針對計算節(jié)點中的多核多網(wǎng)卡設計相關并發(fā)數(shù)據(jù)流的調(diào)度策略。本文在計算節(jié)點內(nèi)部根據(jù)網(wǎng)卡端口與CPU 核的負載情況結(jié)合相關算法計算出網(wǎng)卡端口和CPU 核的有效調(diào)度策略，均衡各個過程的CPU 核綁定，使計算節(jié)點處理并發(fā)數(shù)據(jù)流的速率更優(yōu)。將計算完成的數(shù)據(jù)發(fā)送給服務器集群中的下一個計算節(jié)點進行下一步計算，計算節(jié)點之間存在著一對一、一對多和多對多的數(shù)據(jù)流通信方式，為了提高集群整體的性能，研究了針對計算節(jié)點中的計算資源進行均衡利用的劃分方法。

2 基本定義

定義1 流處理節(jié)點指為了減輕單個流處理節(jié)點（計算節(jié)點）處理數(shù)據(jù)的壓力而采用流水線加工的方式來處理并發(fā)AI 數(shù)據(jù)流。每個流處理節(jié)點都會對并發(fā)AI 數(shù)據(jù)流進行接收、存儲、計算和發(fā)送處理，這里給出并發(fā)AI 數(shù)據(jù)流的串行處理過程如圖1 所示。圖1中，流處理節(jié)點A接收圖像信息數(shù)據(jù)，進行圖像預處理，如簡單去除圖像、圖像標點和形成AI 數(shù)據(jù)流的通信單元等操作，然后將預處理完成的數(shù)據(jù)并發(fā)地傳輸?shù)搅魈幚砉?jié)點B結(jié)合CPU 或GPU進行圖像分析計算，將分析結(jié)果再傳輸?shù)搅魈幚砉?jié)點C進行數(shù)據(jù)匯總等操作，這樣一套流水加工的方式，不用將所有操作交給一個流處理節(jié)點處理，減輕了單個流處理節(jié)點的壓力，提高效率。

圖1 并發(fā)AI 數(shù)據(jù)流的串行處理過程Fig.1 Serial processing of concurrent AI data streams

定義2 AI 數(shù)據(jù)流與通信單元通信單元是流處理節(jié)點（計算節(jié)點）的接收、存儲、計算和發(fā)送的基本單元；經(jīng)過智能終端的AI 計算得出的中間結(jié)果稱為AI 數(shù)據(jù)流，AI 數(shù)據(jù)流（AIStream）是由一個或多個通信單元按序組成的一條連續(xù)單元序列。

AI 數(shù)據(jù)流與通信單元如圖2 所示。由圖2 可知，一條AI 數(shù)據(jù)流可由多個通信單元（U）組成，每個U都是向DPDK 創(chuàng)建的內(nèi)存池［13-14］（mempool）申請而來，U的主要部分結(jié)構(gòu)可表示為U（head，data），其中head為頭部區(qū)域，主要包括的字段有des目的地址、src源地址和type通信單元類型，本文主要介紹2 種類型：FT_TYPE類型，用于更新流轉(zhuǎn)發(fā)表端口信息；DATA_TYPE類型，用于存儲AI 數(shù)據(jù)流信息使各個流節(jié)點進行讀取、計算和傳輸，不同的類型所對應的data數(shù)據(jù)域的結(jié)果也不同，當然，head部分的字段格式對所有類型的通信單元是一樣的，詳細情況見數(shù)據(jù)傳輸協(xié)議。

圖2 AI 數(shù)據(jù)流與通信單元Fig.2 AI data flow and communication unit

定義3 通信速度指計算節(jié)點的網(wǎng)卡端口單位時間內(nèi)發(fā)送和接收通信單元的數(shù)量。

定義4 處理速度指計算節(jié)點的CPU 核單位時間內(nèi)處理通信單元的數(shù)量。

3 系統(tǒng)模型與實現(xiàn)

流處理節(jié)點內(nèi)的并發(fā)AI 數(shù)據(jù)流的通信過程如圖3 所示。圖3中，系統(tǒng)首先通過DPDK 綁定網(wǎng)卡端口以便并行地接收邊緣服務集群中其它流處理節(jié)點（計算節(jié)點）傳輸來的AI 數(shù)據(jù)流（AIStream）中的通信單元；接收過程從網(wǎng)卡端口獲取通信單元并根據(jù)通信單元的id進行分類，繼而保存至對應的接收環(huán)（RR）中；每個RR都有一個與之對應的計算線程（CTP），CTP將RR中的通信單元按序組合成一條單元序列進行計算操作，將計算結(jié)果存儲到對應的發(fā)送環(huán)（SR）中，圖3 中的RR1中的通信單元由CTP1處理，再將處理后的AI數(shù)據(jù)轉(zhuǎn)存至SR1；發(fā)送過程根據(jù)流轉(zhuǎn)發(fā)表（FT）并結(jié)合通信單元調(diào)度策略將發(fā)送環(huán)SR中的通信單元并發(fā)地傳輸?shù)较乱粋€流處理節(jié)點進行下一步AI數(shù)據(jù)流的處理。端口監(jiān)控（PM）模塊主要是實時監(jiān)控集群中各個計算節(jié)點的網(wǎng)卡端口的負載情況，將負載情況及時更新到流轉(zhuǎn)發(fā)表中，為通信單元調(diào)度策略與AI 數(shù)據(jù)流的轉(zhuǎn)發(fā)提供數(shù)據(jù)支持。

圖3 流處理節(jié)點內(nèi)的并發(fā)AI 數(shù)據(jù)流通信過程Fig.3 Concurrent AI data stream communication process within stream processing nodes

3.1 數(shù)據(jù)傳輸協(xié)議

數(shù)據(jù)傳輸協(xié)議的類型由協(xié)議頭部（head）中的type字段控制，主要有2 種傳輸協(xié)議類型：DATA_TYPE類型和FT_TYPE類型。AI數(shù)據(jù)流DATA_TYPE類型通信單元格式如圖4 所示。圖4中，type字段為DATA_TYPE的通信單元格式，其中des為接收通信單元的計算節(jié)點網(wǎng)卡端口的MAC地址，即為目的MAC，占6 字節(jié)；src為發(fā)送通信單元的計算節(jié)點網(wǎng)卡端口的MAC地址，即為源MAC，占6字節(jié)；node為計算節(jié)點編號，主要是用于判斷通信單元的來源與轉(zhuǎn)發(fā)，占2 字節(jié)；id為通信單元編號，主要用于分類，屬于同一數(shù)據(jù)流的通信單元id都是一樣的，是用于通信單元分類計算的重要屬性，占2字節(jié)；seq為通信單元的序號，序號是連續(xù)編排的，方便最終數(shù)據(jù)按序組合成完整的數(shù)據(jù)流，占4 字節(jié)；size為當前通信單元中實際需要被處理的數(shù)據(jù)大小，占4 字節(jié)；data為需要計算處理的實際數(shù)據(jù)。

圖4 AI 數(shù)據(jù)流DATA_TYPE 類型通信單元格式Fig.4 AI data stream DATA_TYPE type communication unit format

AI 數(shù)據(jù)流FT_TYPE類型通信單元格式如圖5所示。圖5中，type字段為FT_TYPE的通信單元格式，當網(wǎng)卡端口收到此類型的通信單元時，則由端口監(jiān)控模塊將FT_TYPE類型的通信單元中的數(shù)據(jù)信息更新到流轉(zhuǎn)發(fā)表中。其中，協(xié)議頭部與DATA_TYPE類型的通信單元格式一樣，node字段所表達的內(nèi)容也為計算節(jié)點編號；cnt為該node編號所對應的流處理節(jié)點的網(wǎng)卡端口個數(shù)；p_mac為網(wǎng)卡端口的MAC地址，編號為0～cnt；p_load為網(wǎng)卡端口所對應的端口負載并與端口MAC地址一一對應。

圖5 AI 數(shù)據(jù)流FT_TYPE 類型通信單元格式Fig.5 AI data stream FT_TYPE type communication unit format

3.2 接收過程

通過DPDK 的核綁定技術為接收過程綁定若干CPU 核、簡稱Recv核，并通過Recv 核將網(wǎng)卡端口接收的通信單元分類轉(zhuǎn)存至接收環(huán)RR中，這一過程稱為接收過程。此時網(wǎng)卡端口的通信速度與Recv 核的處理速度存在一定限制，若Recv 核過多，總處理速度太快，則可能會造成模型中其它過程因CPU 核的分配不均衡而使任務執(zhí)行速度慢下來。下面就是系統(tǒng)通信模型結(jié)合線性規(guī)劃算法為接收過程均衡地綁定CPU 核的理論描述過程。

計算節(jié)點中網(wǎng)卡端口總數(shù)量為n，通信速度分別為D＝｛u1，u2，…，un｝，CPU 核總數(shù)量為m，處理速度分別為V＝｛v1，v2，…，vm｝，一般情況下核的處理速度大于端口的通信速度，但是若CPU 核在同時處理多個任務時，分配給單個任務的處理速度可能比通信速度小。此種情況下，在接收過程中，設Recv 核的數(shù)量為a，因為網(wǎng)卡端口總的通信速度大于CPU 核總的處理速度會造成Recv 核來不及分類和轉(zhuǎn)存網(wǎng)卡端口接收的通信單元而導致數(shù)據(jù)的丟失，所以需要求出a的值以及與其對應Recv 核的處理速度需要滿足如下條件：

滿足式（1）的條件下，目標函數(shù)為：

通過規(guī)劃論中線性規(guī)劃算法，在式（1）的約束下求出式（2）目標函數(shù)中Zrv的最小取值，此時可以求出Recv 核的數(shù)量a以及在V中選擇的對應Recv核的處理速度此時為接收過程均衡配置的CPU核，既能及時處理網(wǎng)卡端口接收的通信單元，又能提高Recv 核的利用率。

3.3 發(fā)送過程

發(fā)送過程并發(fā)地從各個SR中獲取計算完成后的通信單元，并采用端口調(diào)度策略規(guī)劃每個網(wǎng)卡端口傳輸通信單元的數(shù)量，再將分類后的通信單元序列（數(shù)據(jù)流）傳輸?shù)较乱唤M對應的流處理節(jié)點繼續(xù)進行處理。若發(fā)送過程傳遞給網(wǎng)卡端口的速度大于網(wǎng)卡端口總的通信速度，則可能會造成網(wǎng)口來不及發(fā)送通信單元而丟失數(shù)據(jù)，所以發(fā)送過程綁定的CPU 核有一定的限制，網(wǎng)卡端口的通信速度在3.1節(jié)已求出，需要給出發(fā)送過程綁定的CPU 核（Send核）的數(shù)量f，以及在V中選擇的Send 核的處理速度Vsend＝則需要滿足Send 核的處理應該恒定小于網(wǎng)卡端口總的通信速度，即并且Send 核盡可能與CLA 核不重合，即Vcla∩Vsend≈?，求出合適的f以及對應的，設y初始值為無限大，x為-1，循環(huán)以下步驟：

3.4 計算過程

計算過程中的每個計算線程（CTP）從對應的接收環(huán)RR中獲取通信單元，并會根據(jù)字段seq進行按序計算，這一過程稱為計算過程。計算過程中一般會對數(shù)據(jù)進行大量的復雜計算，如GPU 計算、圖像識別計算和數(shù)據(jù)故障分析或耗時的系統(tǒng)調(diào)度等。系統(tǒng)為計算過程均衡地綁定多個CPU 核、簡稱CALC核，并使用DPDK 技術為每個CALC 核綁定一個或多個計算線程（CTP）。并發(fā)AI 數(shù)據(jù)流的大部分處理時間都在計算過程中，所以這個過程需要配置處理速度較快的CALC 核來加快計算過程。因為并發(fā)數(shù)據(jù)流的大部分處理時間都在CALC 過程中，所以這個過程需要配置處理速度較快的CALC 核來加快計算過程，為CALC 過程綁定的CPU 核的數(shù)量為e，以及在V中為計算過程選擇的CPU 核的處理速度此時應將剩余的CPU 核全部分配給CALC 過程，則e＝m -a -b -f，其中m為CPU 核總數(shù)，a為Recv 核數(shù)，b為CLA 核數(shù)，f為Send 核數(shù)，與之對應的Vcalc為Vcalc?V且Vcalc∩Vrv≈?，Vcalc∩Vcla≈?，Vcalc∩Vsend≈?，表示Vcalc所包含的計算核盡量不與其它過程所取的核有交集。

在CPU 核數(shù)量不足的情況下，如某系統(tǒng)只有2個CPU 核可用，應盡可能使計算過程有一個獨立的核可用，其它過程共用另一個CPU核，因為一般情況下計算數(shù)據(jù)所花費的時間較多，耗能較大，所以應多分配CPU 核到計算過程中，但是具體情況則視實際情況而定。

3.5 緩沖環(huán)

緩沖環(huán)是利用DPDK 技術創(chuàng)建的Ring 來緩存通信單元，其具有先進先出，可以設置最大空間，指針存儲在表中，多消費者或單消費者（這里，消費者是指數(shù)據(jù)對象出隊機制），多生產(chǎn)者或單生產(chǎn)者入隊（這里，生產(chǎn)者是指數(shù)據(jù)對象入隊機制）等特點，優(yōu)點是數(shù)據(jù)交換速度快，使用簡單，還可用于巨型數(shù)據(jù)的入隊和出隊操作。本文將緩沖環(huán)分為2 種。一種是用于接收初始通信單元分類的接收緩沖環(huán)RR，另一種是緩存計算后等待發(fā)送的通信單元的發(fā)送緩沖環(huán)SR。

3.6 端口監(jiān)控與流轉(zhuǎn)發(fā)表

端口監(jiān)控（PM）模塊綁定一個空閑的或有空余負載的CPU 核、簡稱PM核，用于監(jiān)控服務器集群中計算節(jié)點的端口通信負載情況并及時更新到流轉(zhuǎn)發(fā)表（FT）中，PM 模塊還需要將其所在計算節(jié)點的網(wǎng)卡端口負載情況每隔一個時間段就發(fā)布給服務器集群內(nèi)的其它計算節(jié)點，以便服務器集群中的計算節(jié)點能實時掌控全局網(wǎng)卡端口負載情況，有助于轉(zhuǎn)發(fā)數(shù)據(jù)時填充目的MAC。

FT 主要作為一個流id與流處理節(jié)點的映射表，指引AI 數(shù)據(jù)流轉(zhuǎn)發(fā)到下一個流處理節(jié)點。

流轉(zhuǎn)發(fā)表的結(jié)構(gòu)FT（id，node（mac，load））見表1。表1中，展示了當前流處理節(jié)點中第i條AI數(shù)據(jù)流在計算后應轉(zhuǎn)發(fā)到下一跳節(jié)點nodei，其中mac為nodei的MAC地址，用于通信單元目的地址填充；load為nodei所對應流處理節(jié)點的各個端口負載，主要用于端口調(diào)度策略的計算。在整個計算資源均衡分配模型中PM 核的工作負載較小，因此可利用Recv 核、CLA 核或Send 核的空余負載并發(fā)地執(zhí)行PM 模塊的功能，若還有剩余的CPU 核則可以分配給PM 模塊或計算過程。

表1 流轉(zhuǎn)發(fā)表結(jié)構(gòu)Tab.1 Flow forwarding table structure

3.7 端口調(diào)度策略

將SR中的通信單元序列（計算完成的AI 數(shù)據(jù)流）通過網(wǎng)卡端口并行地傳輸給下一組計算節(jié)點，均衡各個網(wǎng)卡端口的通信負載需要進一步考慮每個網(wǎng)卡端口發(fā)送通信單元的數(shù)量，制定端口的調(diào)度策略，均衡網(wǎng)卡端口的通信負載。當前網(wǎng)卡端口總發(fā)送的通信單元數(shù)量為N，需要求出為各網(wǎng)卡端口分配的通信單元的數(shù)量｛s1，s2，…，sn｝，則調(diào)度分配策略如下：

當Zt取最小值時，可達到最優(yōu)的端口調(diào)度，此時可求出每個端口的通信單元發(fā)送量｛s1，s2，…，sn｝。

在計算出各端口的調(diào)度策略后，發(fā)送過程需要根據(jù)發(fā)送網(wǎng)卡端口先填充每個待發(fā)送的通信單元U的U.src，U.src為發(fā)送該通信單元的網(wǎng)卡端口地址，再根據(jù)每個通信單元的U.id到流轉(zhuǎn)發(fā)表中找到對應計算節(jié)點的目的網(wǎng)卡端口信息，U.des填充如圖6所示。若對應計算節(jié)點的FT.node.load還有空余負載，可以將FT.node.load對應的FT.node.mac填入U.des，若FT.node.load沒有空余負載，則繼續(xù)掃描下一個FT.node.load。

圖6 U.des 填充Fig.6 U.des filling

4 實驗分析

4.1 實驗環(huán)境

為了驗證所設計的計算資源均衡分配模型的性能，研究使用了5 臺服務器作為邊緣服務集群中的計算節(jié)點來模擬將avi 格式的視頻數(shù)據(jù)轉(zhuǎn)換成mp4格式的視頻數(shù)據(jù)。其中，2 臺服務器設備產(chǎn)生視頻數(shù)據(jù)，1 臺服務器對視頻數(shù)據(jù)進行預處理，1 臺服務器對視頻數(shù)據(jù)流進行avi 到mp4 格式的轉(zhuǎn)碼操作，一臺服務器對最后的視頻數(shù)據(jù)進行整合匯總。

本次實驗中的各個服務器的布局情況如圖7 所示。圖7中，每個計算節(jié)點（服務器、流處理節(jié)點）會先安裝DPDK 進行網(wǎng)卡端口的綁定和系統(tǒng)的初始化操作，接著由2 個計算節(jié)點A和B生成視頻數(shù)據(jù)，再并發(fā)地將視頻數(shù)據(jù)傳輸給計算節(jié)點C進行預處理：將每個視頻進行id編號和切分等操作，形成視頻數(shù)據(jù)流后發(fā)送給計算節(jié)點D進行avi 格式到mp4 視頻格式的轉(zhuǎn)碼操作，再將轉(zhuǎn)碼后的視頻數(shù)據(jù)流發(fā)送給計算節(jié)點E進行視頻數(shù)據(jù)單元的組合，匯總形成完整的mp4 格式的視頻。

圖7 實驗中服務器的布局Fig.7 The layout of the server in the experiment

實驗環(huán)境中每個服務器節(jié)點上都有一個4 口千兆網(wǎng)卡，用來進行并發(fā)數(shù)據(jù)流的接收和發(fā)送，還有16 個CPU核，并通過上述各個過程的算法為各過程均衡綁定CPU核，服務器詳細配置信息見表2。

表2 服務器配置信息Tab.2 Server configuration information

4.2 性能評估指標

在對計算資源均衡分配模型進行評估時，選取網(wǎng)卡端口帶寬利用率、丟包率來對整個系統(tǒng)的性能進行評估、并發(fā)數(shù)據(jù)流的流量大小對模型中各個過程CPU 核綁定的情況進行分析和計算任務復雜度的變化對CALC 過程的核綁定的影響，因本文還未實現(xiàn)可靠傳輸，所以采用傳統(tǒng)UDP 通信來與本文方案做對比實驗。網(wǎng)卡端口帶寬利用率Rpt（t）計算公式如下：

其中，F(xiàn)pt(t) 表示當前時間端口通過的通信單元數(shù)量；Fpt（t -1）表示上次采集的值；Δt表示2 次收集的數(shù)據(jù)量的時間差；BW表示網(wǎng)卡端口的帶寬、即端口的通信速度。

端口丟包率Rloss（t）計算公式如下：

其中，Tsed表示當前網(wǎng)卡端口輸入的通信單元數(shù)量，Trv表示當前網(wǎng)卡端口輸出的通信單元數(shù)量。

4.3 實驗過程與分析

4.3.1 通信性能和丟包率

實驗中的計算節(jié)點都在同一局域網(wǎng)下，在計算節(jié)點C上將每個通信單元的大小從64 字節(jié)到1 024字節(jié)進行調(diào)整，并傳輸給計算機節(jié)點D，數(shù)據(jù)流數(shù)量為240 條。通信性能測試，主要在計算機節(jié)點D上測試本文單個端口的帶寬與不采用本文模型的系統(tǒng)內(nèi)核UDP 通信做對比實驗，在同樣的數(shù)據(jù)包和數(shù)據(jù)量情況下，通信性能與丟包率如圖8 所示。

圖8 通信性能和丟包率測試Fig.8 Communication performance and packet loss rate testing

由圖7 可知，通信單元的大小對通信帶寬的影響不大，而對于丟包率會有影響。柱狀圖為通信速率，由此可知，本文方案明顯優(yōu)于傳統(tǒng)UDP 通信速率；由折線圖可以看出傳統(tǒng)UDP 的丟包率在0.01%到0.05%之間，而本文方案的丟包率在0.001%到0.01%之間，比傳統(tǒng)UDP 通信的丟包率低10 倍左右。這2 個結(jié)果得益于DPDK 的高性能數(shù)據(jù)包處理機制，加速了數(shù)據(jù)包的處理，提高了通信帶寬，降低了丟包率。

4.3.2 計算核數(shù)量與通信核數(shù)量的變化

隨著并發(fā)數(shù)據(jù)流的增大，對各個通信過程（接收過程和發(fā)送過程）與計算過程綁定核的數(shù)量變化，與此同時在進行視頻轉(zhuǎn)碼時，會使用到GPU 來參與計算，所以在實驗過程中也記錄了GPU 負載的變化，如圖9 所示。

由圖9 可以看出，隨著并發(fā)數(shù)據(jù)流的增加，通信核的個數(shù)也逐漸增加，在總核數(shù)不變的情況下，分配給計算部分的計算核有所下降，但是一起參與計算的GPU 使用率逐漸增加，來彌補CPU 核計算能力不足的問題。

圖9 通信核數(shù)量與計算核數(shù)量和GPU 負載的變化Fig.9 Changes in the number of communication cores，the number of computing cores and GPU load

4.3.3 網(wǎng)卡端口均衡帶寬利用率測試

為測試端口調(diào)度策略的可行性，數(shù)據(jù)流源源不斷地從計算節(jié)點A和B傳輸給計算節(jié)點C、D和E，需要觀測計算節(jié)點C、D、E的網(wǎng)卡端口是否處在均衡使用狀態(tài)。各計算節(jié)點端口均衡使用情況如圖10 所示。

圖10 各計算節(jié)點端口均衡使用情況Fig.10 Balanced usage of ports on each computing node

此次測試是在120 條數(shù)據(jù)流的情況下進行的，通過圖10 可以發(fā)現(xiàn)，計算節(jié)點對網(wǎng)卡端口的使用相對均衡，各個端口帶寬利用率穩(wěn)定在60%左右，證明端口調(diào)度策略是可行的。

下面測試數(shù)據(jù)流大小對計算節(jié)點內(nèi)網(wǎng)卡端口利用率的影響。

數(shù)據(jù)流大小對帶寬利用率的影響如圖11 所示。由圖11 可知，隨著并發(fā)數(shù)據(jù)流逐漸增大，計算節(jié)點的平均帶寬利用率也在上升，最終穩(wěn)定在90%左右。

圖11 數(shù)據(jù)流大小對帶寬利用率的影響Fig.11 The effect of data stream size on bandwidth utilization

5 結(jié)束語

本文研究與分析了并行通信、DPDK 和計算節(jié)點內(nèi)的通信資源與計算資源，在邊緣服務集群中以流水加工串行的方式處理并發(fā)AI 數(shù)據(jù)流，以減輕各個計算節(jié)點的計算壓力與通信壓力，設計實現(xiàn)了一個并發(fā)AI 數(shù)據(jù)流處理節(jié)點內(nèi)的通信模型；然后對資源分配模型中的各個過程進行資源分析，并為每個過程均衡地分配CPU核，以提高CPU 核的利用率，同時還設計了端口調(diào)度策略用來均衡各端口的帶寬利用率，還加入了端口監(jiān)控模塊和流轉(zhuǎn)發(fā)表實時監(jiān)控服務器集群中的端口負載情況，將緩沖隊列中的數(shù)據(jù)轉(zhuǎn)發(fā)給下一個計算節(jié)點；最后，通過實驗驗證了計算資源均衡分配算法和端口調(diào)度算法的可行性，實現(xiàn)了計算資源的均衡分配，有效降低了邊緣服務集群中計算節(jié)點的部署成本，提高了計算節(jié)點的計算效率與通信速率。接下來為完善邊緣服務集群整體性能，將對模型的可靠性、能耗、CPU 核的并發(fā)處理能力進一步優(yōu)化降低通信核的數(shù)量等方面做更深入系統(tǒng)的探索與研究。