一個(gè)并發(fā)AI 數(shù)據(jù)流處理節(jié)點(diǎn)內(nèi)的通信模型

黃東生，陳慶奎

（上海理工大學(xué) 光電信息與計(jì)算機(jī)工程學(xué)院，上海 200093）

0 引言

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

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

1 相關(guān)工作

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

2 基本定義

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

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

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

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

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

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

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

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

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

圖3 流處理節(jié)點(diǎn)內(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為接收通信單元的計(jì)算節(jié)點(diǎn)網(wǎng)卡端口的MAC地址，即為目的MAC，占6 字節(jié)；src為發(fā)送通信單元的計(jì)算節(jié)點(diǎn)網(wǎng)卡端口的MAC地址，即為源MAC，占6字節(jié)；node為計(jì)算節(jié)點(diǎn)編號(hào)，主要是用于判斷通信單元的來源與轉(zhuǎn)發(fā)，占2 字節(jié)；id為通信單元編號(hào)，主要用于分類，屬于同一數(shù)據(jù)流的通信單元id都是一樣的，是用于通信單元分類計(jì)算的重要屬性，占2字節(jié)；seq為通信單元的序號(hào)，序號(hào)是連續(xù)編排的，方便最終數(shù)據(jù)按序組合成完整的數(shù)據(jù)流，占4 字節(jié)；size為當(dāng)前通信單元中實(shí)際需要被處理的數(shù)據(jù)大小，占4 字節(jié)；data為需要計(jì)算處理的實(shí)際數(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的通信單元格式，當(dāng)網(wǎng)卡端口收到此類型的通信單元時(shí)，則由端口監(jiān)控模塊將FT_TYPE類型的通信單元中的數(shù)據(jù)信息更新到流轉(zhuǎn)發(fā)表中。其中，協(xié)議頭部與DATA_TYPE類型的通信單元格式一樣，node字段所表達(dá)的內(nèi)容也為計(jì)算節(jié)點(diǎn)編號(hào)；cnt為該node編號(hào)所對(duì)應(yīng)的流處理節(jié)點(diǎn)的網(wǎng)卡端口個(gè)數(shù)；p_mac為網(wǎng)卡端口的MAC地址，編號(hào)為0～cnt；p_load為網(wǎng)卡端口所對(duì)應(yīng)的端口負(fù)載并與端口MAC地址一一對(duì)應(yīng)。

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

3.2 接收過程

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

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

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

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

3.3 發(fā)送過程

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

3.4 計(jì)算過程

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

在CPU 核數(shù)量不足的情況下，如某系統(tǒng)只有2個(gè)CPU 核可用，應(yīng)盡可能使計(jì)算過程有一個(gè)獨(dú)立的核可用，其它過程共用另一個(gè)CPU核，因?yàn)橐话闱闆r下計(jì)算數(shù)據(jù)所花費(fèi)的時(shí)間較多，耗能較大，所以應(yīng)多分配CPU 核到計(jì)算過程中，但是具體情況則視實(shí)際情況而定。

3.5 緩沖環(huán)

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

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

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

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

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

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

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

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

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

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

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

4 實(shí)驗(yàn)分析

4.1 實(shí)驗(yàn)環(huán)境

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

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

圖7 實(shí)驗(yàn)中服務(wù)器的布局Fig.7 The layout of the server in the experiment

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

表2 服務(wù)器配置信息Tab.2 Server configuration information

4.2 性能評(píng)估指標(biāo)

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

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

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

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

4.3 實(shí)驗(yàn)過程與分析

4.3.1 通信性能和丟包率

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 結(jié)束語

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