面向邊緣集群內(nèi)AI數(shù)據(jù)流的雙平面調(diào)度模型

吳明杰，陳慶奎

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

E-mail ：WMJ826WMJ@163.com

1 引 言

近年來隨著物聯(lián)網(wǎng)[1]終端設(shè)備的劇增，基于云計(jì)算[2]的物聯(lián)網(wǎng)解決方案開始顯露其短板.終端設(shè)備規(guī)模的不斷擴(kuò)大將極大的增加通信延遲和計(jì)算延時，這將無法為用戶提供可接受的計(jì)算需求和響應(yīng)需求.邊緣計(jì)算[3]正是為緩解這一現(xiàn)狀而提出的新解決方案.其作為云計(jì)算模式的拓展延伸，能夠在更加接近用戶端進(jìn)行部署.這將極大的降低通信開銷，減少響應(yīng)延遲，為用戶提供更好的體驗(yàn).如圖1所示的′云-邊協(xié)作框架′[4]將會是未來非常流行的物聯(lián)網(wǎng)解決方案.

圖1 云-邊協(xié)作框架Fig.1 Cloud-edge collaboration framework

AI(人工智能)[5]技術(shù)近幾年得到了快速的發(fā)展，并且逐漸向邊緣端拓展.云計(jì)算模式的高延遲限制了AI的廣泛應(yīng)用，終端設(shè)備的低計(jì)算能力也無法使AI部署于其上，這使得邊緣數(shù)據(jù)中心[6]成為承載AI計(jì)算負(fù)載的最佳平臺.而且，設(shè)備端持續(xù)增長的實(shí)時AI計(jì)算需求對邊緣數(shù)據(jù)中心的性能也提出了更高的要求[7].

為了滿足邊緣AI對邊緣數(shù)據(jù)中心的高性能需求，本文針對邊緣集群提出一種由控制平面和數(shù)據(jù)平面組成的雙平面通信架構(gòu).控制平面負(fù)責(zé)處理數(shù)據(jù)流調(diào)度和集群監(jiān)控等控制信息，數(shù)據(jù)平面負(fù)責(zé)數(shù)據(jù)的快速傳輸.本文也針對AI數(shù)據(jù)流提出了基于消息的傳輸協(xié)議，能夠有效的降低數(shù)據(jù)傳輸負(fù)載.最后還提出了AI數(shù)據(jù)流的集群內(nèi)調(diào)度模型.實(shí)驗(yàn)表明，雙平面AI數(shù)據(jù)流的調(diào)度模型，能夠有效的降低AI數(shù)據(jù)流的計(jì)算延時，提高邊緣集群的數(shù)據(jù)流接入和處理能力.

2 相關(guān)工作

隨著邊緣計(jì)算的興起，邊緣微型數(shù)據(jù)中心作為云計(jì)算數(shù)據(jù)中心的縮小版，面臨著同樣的任務(wù)通信和調(diào)度問題[8].而且，實(shí)時邊緣計(jì)算對于邊緣集群的響應(yīng)時間提出了更高的要求[9].

對于通信延時問題，研究人員提出了基于硬件和基于軟件的通信性能提升技術(shù).硬件方面已經(jīng)提出了各種專用的網(wǎng)絡(luò)硬件解決方案.代表性的如EZChip的NP-4和Yorneam Illit的NPS-400(Mellanox Technologies)(1)http://www.mellanox.com，Cavium的OCTEON(2)http://www.cavium.com系列，Tilera的Tile-Gx(3)http://www.mellanox.com產(chǎn)品.基于軟件的解決方案使得人們對于SDN[10](軟件定義網(wǎng)絡(luò))和NFV(網(wǎng)絡(luò)功能虛擬化)[11]的興趣.代表性的如NTOP的PF-RING(4)http://www.ntop.org/products/packet-capture/pf-ring，Intel的DPDK[12]，以及6WIND的6WINDGate(5)http://www.6wind.com/products/6windgate.一些研究和應(yīng)用中已經(jīng)提出了通過將兩個平面分離而實(shí)現(xiàn)靈活的網(wǎng)絡(luò)控制的網(wǎng)絡(luò)切片技術(shù)，如Pongracz等人[13]提出一種LTE環(huán)境下的SDN架構(gòu).此外，將SDN技術(shù)應(yīng)用于物聯(lián)網(wǎng)環(huán)境也出現(xiàn)了一些研究.Yaakoumis等[14]描述了一種在物聯(lián)網(wǎng)環(huán)境中分割家庭網(wǎng)絡(luò)的原型，他將物理網(wǎng)絡(luò)切成多層，以隔離不同運(yùn)營商的流量和帶寬.Qing等[15]提出了1個SDN控制器和控制器角色，例如資源匹配和流調(diào)度.

任務(wù)調(diào)度方面研究人員也提出了很多方案.Dong等[16]提出基于優(yōu)先級的邊緣計(jì)算資源分配方法.Cao等[17]提出結(jié)合網(wǎng)絡(luò)資源和設(shè)備資源對CNN網(wǎng)絡(luò)進(jìn)行動態(tài)切片的模型，以優(yōu)化任務(wù)完成時間.Jia等[18]提出了一種在線啟發(fā)式負(fù)載均衡任務(wù)遷移算法，以縮短終端設(shè)備上的應(yīng)用完成時間.Guo等[19]提出一種節(jié)能的動態(tài)遷移和資源調(diào)度策略，以降低能耗并縮短應(yīng)用完成時間.Fang等[20]提出一種基于GPU能耗的并發(fā)數(shù)據(jù)流實(shí)時動態(tài)遷移模型，旨在提高任務(wù)執(zhí)行的可靠性.目前邊緣環(huán)境下的計(jì)算遷移任務(wù)調(diào)度問題也有一些研究.Zhang等[21]將終端設(shè)備延遲敏感的計(jì)算任務(wù)遷移到邊緣云，并提出兩階段任務(wù)調(diào)度成本優(yōu)化算法，以降低系統(tǒng)成本.Qi等[22]提出一種結(jié)合網(wǎng)絡(luò)狀況和設(shè)備條件的自適應(yīng)調(diào)度算法.

基于前人的研究成果，結(jié)合SDN雙平面以及物理網(wǎng)絡(luò)切片的思想，本文提出基于Intel DPDK(6)http://www.dpdk.org技術(shù)的針對邊緣集群的雙平面通信框架，將控制平面網(wǎng)絡(luò)和數(shù)據(jù)平面網(wǎng)絡(luò)從物理上隔離.其次，考慮邊緣集群內(nèi)計(jì)算節(jié)點(diǎn)網(wǎng)絡(luò)資源和計(jì)算資源使用情況，提出數(shù)據(jù)流動態(tài)遷移模型.

3 設(shè)計(jì)

3.1 物理拓?fù)?/h3>

邊緣集群作為云計(jì)算在物聯(lián)網(wǎng)應(yīng)用方面的補(bǔ)充，決定了其應(yīng)對物聯(lián)網(wǎng)數(shù)據(jù)接入和計(jì)算的高密度任務(wù).任務(wù)調(diào)度和監(jiān)控往往需要近乎實(shí)時，對于時延非常敏感.傳統(tǒng)的單平面架構(gòu)會存在一些缺陷.當(dāng)數(shù)據(jù)傳輸占用了大量帶寬時，會造成控制或者調(diào)度命令的傳輸滯后，這可能會加重計(jì)算節(jié)點(diǎn)的負(fù)載，甚至是宕機(jī).

圖2 物理拓?fù)銯ig.2 Physical topology

如圖2所示，通過使用多張網(wǎng)卡，本文的雙平面通信框架能夠從物理上將控制平面和數(shù)據(jù)平面分離，互不干擾，從而實(shí)現(xiàn)控制和調(diào)度命令的即時傳輸.數(shù)據(jù)平面數(shù)據(jù)通過DPDK技術(shù)進(jìn)行快速傳輸，能夠提供較高的傳輸速率.

3.2 系統(tǒng)框架

本文所研究的邊緣集群節(jié)點(diǎn)都配有多張網(wǎng)卡，分為控制平面網(wǎng)口和數(shù)據(jù)平面網(wǎng)口.控制平面網(wǎng)口通過傳統(tǒng)網(wǎng)絡(luò)架構(gòu)和協(xié)議互連，構(gòu)成1個LAN環(huán)境.數(shù)據(jù)平面通過1個或者多個二層交換機(jī)相連，其在DPDK之上構(gòu)建傳輸協(xié)議.邊緣集群節(jié)點(diǎn)分為3類：管理節(jié)點(diǎn)，數(shù)據(jù)流接入節(jié)點(diǎn)，GPU計(jì)算節(jié)點(diǎn).管理節(jié)點(diǎn)上包括終端設(shè)備管理模塊，接入負(fù)載均衡模塊，節(jié)點(diǎn)資源狀態(tài)監(jiān)控模塊，數(shù)據(jù)流調(diào)度模塊，計(jì)算模型管理模塊，即時信息反饋模塊.數(shù)據(jù)流接入節(jié)點(diǎn)上包括數(shù)據(jù)流接入轉(zhuǎn)發(fā)模塊和節(jié)點(diǎn)資源狀態(tài)模塊.數(shù)據(jù)流接入轉(zhuǎn)發(fā)模塊負(fù)責(zé)設(shè)備數(shù)據(jù)流的接收和根據(jù)數(shù)據(jù)流轉(zhuǎn)發(fā)表進(jìn)行數(shù)據(jù)流轉(zhuǎn)發(fā)；節(jié)點(diǎn)資源狀態(tài)模塊負(fù)責(zé)定時上傳節(jié)點(diǎn)帶寬負(fù)載和接入負(fù)載等監(jiān)控信息.GPU計(jì)算節(jié)點(diǎn)上包括數(shù)據(jù)流接收計(jì)算模塊和節(jié)點(diǎn)資源狀態(tài)監(jiān)控模塊.數(shù)據(jù)流接收計(jì)算模塊負(fù)責(zé)數(shù)據(jù)流的接收和模型計(jì)算；節(jié)點(diǎn)資源狀態(tài)模塊負(fù)責(zé)定時上傳節(jié)點(diǎn)帶寬負(fù)載和計(jì)算負(fù)載等監(jiān)控信息.

圖3 框架概覽Fig.3 Framework overview

系統(tǒng)整體流程如圖3所示.1)管理員在集群管理節(jié)點(diǎn)上注冊和上傳任務(wù)計(jì)算模型；集群管理節(jié)點(diǎn)將計(jì)算模型分發(fā)給GPU計(jì)算節(jié)點(diǎn)；2)終端設(shè)備向集群管理節(jié)點(diǎn)注冊數(shù)據(jù)流以及數(shù)據(jù)流需要的計(jì)算模型，管理節(jié)點(diǎn)返回該終端設(shè)備數(shù)據(jù)流的接入節(jié)點(diǎn)地址，終端設(shè)備進(jìn)行數(shù)據(jù)流發(fā)送；3)數(shù)據(jù)流接入節(jié)點(diǎn)和GPU計(jì)算節(jié)點(diǎn)定時向管理節(jié)點(diǎn)發(fā)送實(shí)時帶寬負(fù)載，接入負(fù)載和計(jì)算負(fù)載等信息；4)管理節(jié)點(diǎn)根據(jù)GPU計(jì)算節(jié)點(diǎn)上傳的資源狀態(tài)信息進(jìn)行數(shù)據(jù)流調(diào)度，并下發(fā)數(shù)據(jù)流轉(zhuǎn)發(fā)規(guī)則到數(shù)據(jù)流接入節(jié)點(diǎn)，數(shù)據(jù)流接入節(jié)點(diǎn)根據(jù)本地的數(shù)據(jù)流轉(zhuǎn)發(fā)進(jìn)行數(shù)據(jù)流轉(zhuǎn)發(fā)；5)GPU計(jì)算節(jié)點(diǎn)接收數(shù)據(jù)流，并根據(jù)對應(yīng)計(jì)算模型進(jìn)行數(shù)據(jù)計(jì)算，如果產(chǎn)生即時反饋信息，則需要發(fā)送給管理節(jié)點(diǎn)，由管理節(jié)點(diǎn)將信息推送給終端設(shè)備；需要儲存和記錄的結(jié)果信息上傳至云端數(shù)據(jù)中心.

3.3 AI數(shù)據(jù)流特征分析

隨著邊緣AI的興起，如何在資源受限的終端設(shè)備上執(zhí)行AI計(jì)算成為研究熱點(diǎn).目前，終端設(shè)備進(jìn)行部分?jǐn)?shù)據(jù)預(yù)處理或者計(jì)算部分任務(wù)，后續(xù)任務(wù)通過網(wǎng)絡(luò)交由附近的邊緣集群進(jìn)行計(jì)算的方式成為主流.其中，中間結(jié)果數(shù)據(jù)稱為AI數(shù)據(jù)流.AI數(shù)據(jù)流往往是源源不斷地?cái)?shù)值型矩陣數(shù)據(jù)，包括小數(shù).如圖片預(yù)處理的結(jié)果，CNN計(jì)算的中間結(jié)果.

巨量的AI數(shù)據(jù)流必然對網(wǎng)絡(luò)傳輸造成嚴(yán)重的壓力，這就需要高壓縮的通信協(xié)議來緩解.目前比較流行的技術(shù)包括Protobuf，XML，JSON，Thrift等.其中最熱門的當(dāng)屬Google的Protobuf了.Protobuf由于更小，更快，更簡便備受人們青睞.但是Protobuf作為Google公司內(nèi)部使用的工具[23]，在通用性上差很多.而且，對于數(shù)值型矩陣或者圖片的傳輸不夠友好，往往需要轉(zhuǎn)換為文件形式后進(jìn)行傳輸，這將增加傳輸?shù)臄?shù)據(jù)量.為此，本文專門設(shè)計(jì)了基于消息的AI數(shù)據(jù)流傳輸協(xié)議，這將會在后續(xù)章節(jié)詳細(xì)介紹.

4 實(shí) 現(xiàn)

4.1 控制平面

控制平面的主要功能是:1)處理與終端設(shè)備之間的相關(guān)消息；2)監(jiān)控集群各節(jié)點(diǎn)包括接入節(jié)點(diǎn)和計(jì)算節(jié)點(diǎn)資源狀態(tài)；3)根據(jù)狀態(tài)信息實(shí)時調(diào)度集群內(nèi)數(shù)據(jù)流的傳輸；4)管理集群內(nèi)計(jì)算模型的上傳和分發(fā).由于控制平面構(gòu)建于局域網(wǎng)之上，因此傳統(tǒng)的數(shù)據(jù)傳輸協(xié)議都可以使用，如HTTP，TCP，UDP，RPC等.

數(shù)據(jù)流調(diào)度是控制平面最重要的功能之一，如何高效的進(jìn)行數(shù)據(jù)流調(diào)度成為難題.在數(shù)據(jù)流遷移的過程中會產(chǎn)生延遲：控制消息的傳輸和執(zhí)行可能會產(chǎn)生延時；數(shù)據(jù)流遷移到目標(biāo)節(jié)點(diǎn)的過程中可能由于網(wǎng)絡(luò)原因會產(chǎn)生延時；數(shù)據(jù)流到達(dá)目的節(jié)點(diǎn)之后，由于目的節(jié)點(diǎn)并發(fā)能力有限，可能需要排隊(duì)等待，也會增加延時.如果遷移的總延時太長，將會增加任務(wù)的響應(yīng)時間，影響用戶體驗(yàn).任務(wù)的遷移對于保持邊緣集群的可靠性和穩(wěn)定性至關(guān)重要.數(shù)據(jù)流的接入負(fù)載均衡已經(jīng)有很多成熟、高效的算法，本文不予研究.

4.2 數(shù)據(jù)平面

數(shù)據(jù)平面的主要任務(wù)是數(shù)據(jù)流的快速傳輸和任務(wù)計(jì)算.其通信功能是基于Intel DPDK技術(shù)設(shè)計(jì)和實(shí)現(xiàn)的，以提高數(shù)據(jù)傳輸?shù)男阅?，基于之前的研究中所提出的基?DPDK 的邊緣集群內(nèi)高速通信方案.該方案充分利用的DPDK的眾多特性，提供快速的數(shù)據(jù)報(bào)處理、轉(zhuǎn)發(fā)和傳輸特性，并借助于Linux系統(tǒng)的socket本地回環(huán)機(jī)制，為上層提供了與編程語言無關(guān)的類UDP通信接口.如圖4所示，雙平面通信路徑在集群節(jié)點(diǎn)內(nèi)的流程從物理線路上進(jìn)行了隔離，兩個平面的數(shù)據(jù)傳輸不會相互影響.

圖4 基于DPDK的通信模型Fig.4 Communication model based on DPDK

4.3 基于消息的數(shù)據(jù)傳輸協(xié)議

針對AI數(shù)據(jù)流傳輸，本文設(shè)計(jì)和實(shí)現(xiàn)了基于消息的傳輸機(jī)制.如圖5所示，每一消息都包含有FID(流編號)、MID(消息編號)、M_Time(消息時間戳)和M_Type(消息類型).消息類型分為字符型數(shù)據(jù)和數(shù)值型數(shù)據(jù).字符型數(shù)據(jù)作為計(jì)算結(jié)果或者通知的格式.數(shù)值型數(shù)據(jù)作為待計(jì)算的圖像或者矩陣數(shù)據(jù)的格式，需要指明該數(shù)據(jù)的Model_ID(計(jì)算模型編號)，Byte_Type(矩陣數(shù)值類型)，以及矩陣的Len(長)和Wid(寬)，方便數(shù)據(jù)解析.Byte_Type指定了單個矩陣數(shù)值占用的字節(jié)數(shù).

消息的大小往往超過了以太網(wǎng)數(shù)據(jù)幀大小的限制，在傳輸?shù)倪^程中需要切片和重組.因此也設(shè)計(jì)和實(shí)現(xiàn)了消息切片的格式和可靠傳輸協(xié)議.每一個消息切片都包含有FID(流編號)、MID(消息編號)、M_Time(消息時間戳)字段、M_len(消息長度)、P_Type(消息切片類型)和P_content(消息切片內(nèi)容).根據(jù)P_Type(消息切片類型)可以分為消息切片數(shù)據(jù)，切片重傳請求，消息重傳回應(yīng)，消息重傳詢問.每一個消息切片都有P_Num(切片編號)、P_Total(切片總數(shù))和P_Len切片長度，最后為切片數(shù)據(jù).

圖5 消息和切片格式定義Fig.5 Message and fragment format definition

基于消息傳輸?shù)目煽總鬏敊C(jī)制實(shí)現(xiàn)如下：1)發(fā)送節(jié)點(diǎn)緩存消息切片，并進(jìn)行發(fā)送；發(fā)送完成后向接收節(jié)點(diǎn)發(fā)送消息重傳詢問；2)接收節(jié)點(diǎn)不斷的接收消息切片并緩存；若收到消息切片的最后一個切片或者是發(fā)送節(jié)點(diǎn)的消息重傳詢問，需要回應(yīng)一個消息重傳請求；3)發(fā)送節(jié)點(diǎn)收到消息重傳請求，進(jìn)行丟失校驗(yàn)并對對應(yīng)的數(shù)據(jù)包重新發(fā)送.在規(guī)定時間內(nèi)如果發(fā)送節(jié)點(diǎn)收到接收節(jié)點(diǎn)接收完全的通知，完成此消息的發(fā)送；如果超時，則進(jìn)行下一條消息的發(fā)送.如果接收端在規(guī)定的時間內(nèi)未收齊該消息，則丟棄.這樣是為了保證AI數(shù)據(jù)流實(shí)時計(jì)算的特性.

4.4 數(shù)據(jù)流調(diào)度模型和算法

數(shù)據(jù)流在集群內(nèi)的耗時包括傳輸時間，排隊(duì)時間和計(jì)算時間.傳輸時間可以分為外網(wǎng)傳輸時間和集群內(nèi)傳輸時間.其中，外網(wǎng)傳輸時間受外部網(wǎng)絡(luò)環(huán)境的影響；集群內(nèi)傳輸時間不僅受集群內(nèi)帶寬限制，也受調(diào)度算法的影響.排隊(duì)時間可以通過好的調(diào)度算法進(jìn)行優(yōu)化.計(jì)算時間受到節(jié)點(diǎn)計(jì)算力的影響.因此，集群管理節(jié)點(diǎn)對于集群內(nèi)數(shù)據(jù)流的調(diào)度不僅要考慮計(jì)算節(jié)點(diǎn)的計(jì)算負(fù)載，還要考慮計(jì)算節(jié)點(diǎn)的網(wǎng)絡(luò)負(fù)載.無論是網(wǎng)絡(luò)負(fù)載還是計(jì)算負(fù)載的過高，都會影響任務(wù)的完成時間.因此，本文對GPU計(jì)算節(jié)點(diǎn)的實(shí)時網(wǎng)絡(luò)負(fù)載和計(jì)算負(fù)載進(jìn)行模型分析，為數(shù)據(jù)流的高效調(diào)度提供理論依據(jù).相關(guān)符號在表1中進(jìn)行了詳細(xì)的說明.

表1 符號描述Table 1 Symbol description

首先是對GPU計(jì)算節(jié)點(diǎn)的網(wǎng)絡(luò)負(fù)載建立數(shù)學(xué)模型.DPDK提供了最基本的網(wǎng)口參數(shù)如Nip-Gj-porti(網(wǎng)口接收數(shù)據(jù)包的總數(shù))，Nib-Gj-porti(網(wǎng)口成功接收字節(jié)的總數(shù))，Niep-Gj-porti(網(wǎng)口接收錯誤數(shù)據(jù)包的總數(shù))，Nimp-Gj-porti(網(wǎng)口接收丟棄數(shù)據(jù)包的總數(shù)).通過公式(1)-公式(7)可以計(jì)算出Vib-Gj-porti(網(wǎng)口成功接收字節(jié)的速率)，Vieb-Gj-porti(網(wǎng)口接收錯誤字節(jié)的速率)，Vimb-Gj-porti(網(wǎng)口接收丟棄字節(jié)的速率).公式(8)為網(wǎng)口真實(shí)的字節(jié)接收速率(應(yīng)該包括錯誤和丟棄的).通過公式(9)可以計(jì)算出該網(wǎng)口的實(shí)時負(fù)載率.為了防止信息采集時的突發(fā)干擾，本文采用平滑過渡方式對網(wǎng)口負(fù)載率進(jìn)行修正，通過調(diào)整因子γ，通常取值為0.8，結(jié)合前次采集值與當(dāng)前采集值進(jìn)行一定比例的求和，計(jì)算出調(diào)整后的網(wǎng)口實(shí)時負(fù)載率，如公式(10).計(jì)算節(jié)點(diǎn)總的網(wǎng)絡(luò)負(fù)載由公式(11)計(jì)算得出，為后續(xù)節(jié)點(diǎn)是否進(jìn)行遷移作參考.

(1)

(2)

(3)

(4)

(5)

(6)

(7)

(8)

(9)

(10)

(11)

公式(12)計(jì)算出單個網(wǎng)口的剩余帶寬，并通過公式(13)進(jìn)行平滑調(diào)整，計(jì)算出調(diào)整后的剩余可用帶寬.公式(14)為計(jì)算節(jié)點(diǎn)的總的剩余帶寬，這將為后續(xù)的遷移節(jié)點(diǎn)選擇提供參考.

(12)

(13)

(14)

對GPU節(jié)點(diǎn)的計(jì)算負(fù)載建立數(shù)學(xué)模型.基于多任務(wù)并行計(jì)算時任務(wù)的響應(yīng)時間為優(yōu)化目標(biāo)，以提升響應(yīng)速度.公式(15)為整個集群內(nèi)的數(shù)據(jù)流數(shù)量.通過公式(16)可以計(jì)算出計(jì)算節(jié)點(diǎn)上每條數(shù)據(jù)流占用的平均帶寬.數(shù)據(jù)流的單個任務(wù)計(jì)算耗時由公式(17)得出，并且由公式(18)可以計(jì)算出計(jì)算節(jié)點(diǎn)上所有數(shù)據(jù)流單個任務(wù)的計(jì)算耗時總和，再由公式(20)計(jì)算每條數(shù)據(jù)流單個任務(wù)的平均計(jì)算耗時.公式(19)作為計(jì)算節(jié)點(diǎn)所有數(shù)據(jù)流單個任務(wù)的最大計(jì)算耗時，一定程度上反應(yīng)了計(jì)算節(jié)點(diǎn)的計(jì)算負(fù)載.由公式(22)和(23)，可以計(jì)算出計(jì)算節(jié)點(diǎn)的計(jì)算負(fù)載率.公式(21)計(jì)算出計(jì)算節(jié)點(diǎn)剩余可用的計(jì)算耗時，為后續(xù)的遷移節(jié)點(diǎn)選擇提供參考.

(15)

(16)

Tdelay-flowk-Gj(t)=Tend-flowk-Gj(t)-Tarrive-flowk-Gj(t)

(17)

(18)

Tdelay-MAX-Gj(t)=max{Tdelay-flowk-Gj(t)}，k=1，2，…，N-flow-Gj(t)

(19)

(20)

Tdelay-ava-Gj(t)=T-Tdelay-MAX-Gj(t)

(21)

Tdelay-Gj(t)=Tdelay-MAX-Gj(t)-T

(22)

(23)

公式(24)顯示出計(jì)算節(jié)點(diǎn)數(shù)據(jù)流遷移的情況.當(dāng)計(jì)算節(jié)點(diǎn)網(wǎng)絡(luò)故障或者計(jì)算故障時，該節(jié)點(diǎn)上的數(shù)據(jù)流需要整體遷移到其他計(jì)算節(jié)點(diǎn)；當(dāng)計(jì)算節(jié)點(diǎn)出現(xiàn)網(wǎng)絡(luò)超載或者計(jì)算超載時，需要將該節(jié)點(diǎn)上部分?jǐn)?shù)據(jù)流遷移到其他節(jié)點(diǎn)上.無論是整體遷移還是部分遷移，都可以通過公式(25)計(jì)算出該節(jié)點(diǎn)待遷出數(shù)據(jù)流的數(shù)量.在遷入節(jié)點(diǎn)選擇時，還需要評估每個節(jié)點(diǎn)可接受的遷入數(shù)據(jù)流數(shù)量.公式(26)結(jié)合計(jì)算節(jié)點(diǎn)的網(wǎng)絡(luò)容量和計(jì)算容，選擇最小可接受遷入數(shù)據(jù)流的數(shù)量.

(24)

Nmigr-Gj(t)=

(25)

(26)

數(shù)據(jù)流遷移分為3個步驟:首先，計(jì)算出計(jì)算節(jié)點(diǎn)的待遷出數(shù)據(jù)流數(shù)量n，并從計(jì)算節(jié)點(diǎn)當(dāng)前數(shù)據(jù)流集合中選出n條數(shù)據(jù)流組成待遷出數(shù)據(jù)流集合F；其次，計(jì)算出所有可遷入數(shù)據(jù)流的計(jì)算節(jié)點(diǎn)集合G，并根據(jù)其可用帶寬資源和可用計(jì)算資源進(jìn)行降序排序；最后，依次遍歷可遷入計(jì)算節(jié)點(diǎn)集合G，根據(jù)其可接受數(shù)據(jù)流數(shù)量m(m<=n)，將F中的m條數(shù)據(jù)流遷入節(jié)點(diǎn)G[k]，一直到F中的數(shù)據(jù)流為空.在整過過程中，如果可遷入數(shù)據(jù)流的計(jì)算節(jié)點(diǎn)集合G為空，則說明集群中數(shù)據(jù)流以達(dá)到飽和狀態(tài)，需要提醒管理人員或者寫事件日志.在一輪數(shù)據(jù)流遷移后，待遷出數(shù)據(jù)流集合F不為空，也說明集群中數(shù)據(jù)流以達(dá)到飽和狀態(tài)，需要提醒管理人員或者寫事件日志.具體的遷移過程由算法1給出.

算法1.數(shù)據(jù)流遷移算法

Start

Step 1.get the set F of data flows to be migrated for node j

1)Get the number n of data flows to be migrated based on formula 26

2)Select F from the data flow set of node j

Step 2.get the set G of computing nodes that can be migrated into the data flows

1)Select the set M with bandwidth resources and computing resources that are not 0 from the set of computing nodes

2)Sort the nodes of set M in descending order by bandwidth resources and computing resources

3)Then get the set G

Step 3.Traverse the set G，and match the data flows

For：k = 0；k++；G[k]do

If：G[k] is nonethen

Alarm events and write logs

If：F is nonethen

Allocation is complete，and end

Else：

Calculate the number m of data streams that G[k] can migrate by formula 27

Endif

Endfor

If：F is not nonethen

Alarm events and write logs

Endif

Perform data flow migration according to the correspondence between G[k] and m

End

5 實(shí) 驗(yàn)

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

為了驗(yàn)證本文方案的性能，本文使用10臺主機(jī)搭建邊緣集群，其中3臺作為接入節(jié)點(diǎn)，剩余6臺作為計(jì)算節(jié)點(diǎn)，1臺作為管理節(jié)點(diǎn).每個節(jié)點(diǎn)配置詳細(xì)信息如表2所示，計(jì)算節(jié)點(diǎn)配置了GTX970或者GTX1080顯卡.每臺服務(wù)器Hug Page 為8G，rx和tx各1個，且大小為1024，CPU核心占用5個.

表2 主機(jī)配置信息Table 2 Host configuration information

5.2 評估指標(biāo)

為了對本文模型進(jìn)行性能評估，提出了多個指標(biāo)，如數(shù)據(jù)流容量，消息丟棄率，任務(wù)延遲率和任務(wù)丟棄率.

數(shù)據(jù)流容量FN是指集群可以穩(wěn)定接入的數(shù)據(jù)流數(shù)量.

FN=N-flow-G

(27)

消息丟棄率MAR是指在周期T內(nèi)因網(wǎng)絡(luò)傳輸而丟棄消息的數(shù)量占消息總數(shù)量的比例，能夠反映網(wǎng)絡(luò)性能.

(28)

任務(wù)延遲率TDR是指任務(wù)計(jì)算的延時與周期T之比，能夠反映任務(wù)計(jì)算的延遲程度.

(29)

任務(wù)丟棄率TAR是指排隊(duì)任務(wù)因超時未計(jì)算而放棄的任務(wù)數(shù)量與排隊(duì)任務(wù)的總數(shù)量之比.

(30)

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

本文將所提出的雙平面架構(gòu)應(yīng)用于社區(qū)養(yǎng)老視頻監(jiān)控系統(tǒng).首先終端設(shè)備如樹莓派等對采集到的視頻圖像進(jìn)行人體輪廓粗略檢測；將檢測到的人體輪廓區(qū)域中人體特殊部位進(jìn)行模糊處理以保護(hù)隱私；將模糊處理后的人體輪廓區(qū)域的圖像進(jìn)行OpenPose人體姿態(tài)檢測的部分計(jì)算；將中間計(jì)算結(jié)果封裝為單個消息，發(fā)送到邊緣集群進(jìn)行后續(xù)人體姿態(tài)檢測與狀態(tài)識別.其中，消息大小為1MB，消息切片大小為750B.

圖6 節(jié)點(diǎn)單張千兆網(wǎng)口的MARFig.6 MAR of a Gigabit NIC for node

首先對調(diào)度模型的網(wǎng)絡(luò)傳輸性能進(jìn)行測試.該實(shí)驗(yàn)測試傳統(tǒng)單平面模型和本文雙平面模型在網(wǎng)絡(luò)傳輸方面的性能.在一對一模式下，1臺接入節(jié)點(diǎn)和1臺計(jì)算節(jié)點(diǎn)(各配1張千兆網(wǎng)卡，消息到達(dá)計(jì)算節(jié)點(diǎn)不進(jìn)行計(jì)算)，發(fā)送不同數(shù)量的數(shù)據(jù)流消息FN，記錄MAR隨FN的變化值.從圖6中可以看出，本文的網(wǎng)絡(luò)方案比傳統(tǒng)方案能夠在無消息丟失的情況下提升約30%的數(shù)據(jù)流容量，這歸功于前者數(shù)據(jù)傳輸基于DPDK的快速包處理和轉(zhuǎn)發(fā)技術(shù).

圖7 集群單張千兆網(wǎng)口的MARFig.7 MAR of a Gigabit NIC for cluster

對集群模式下的網(wǎng)絡(luò)性能進(jìn)行對比，結(jié)果如圖7.3臺接入節(jié)點(diǎn)和6臺計(jì)算節(jié)點(diǎn)(各配一張千兆網(wǎng)卡，每個計(jì)算節(jié)點(diǎn)的數(shù)據(jù)流均勻分配，消息到達(dá)計(jì)算節(jié)點(diǎn)不進(jìn)行計(jì)算)，發(fā)送不同數(shù)量的數(shù)據(jù)流消息FN，記錄MAR隨FN的變化值.同樣的，在集群模式下，本文的網(wǎng)絡(luò)方案比傳統(tǒng)方案能夠在無消息丟失的情況下提升約一倍的數(shù)據(jù)流容量.最后也發(fā)現(xiàn)，3臺接入節(jié)點(diǎn)比1臺接入節(jié)點(diǎn)的數(shù)據(jù)流容量多出3倍左右，說明集群數(shù)據(jù)流容量的大小與接入節(jié)點(diǎn)的數(shù)量有關(guān).

在一對一模式下，數(shù)據(jù)平面使用多張網(wǎng)卡的網(wǎng)絡(luò)性能進(jìn)行測試.1臺接入節(jié)點(diǎn)和1臺計(jì)算節(jié)點(diǎn)(各配5張千兆網(wǎng)卡，一張連接控制平面，4張連接數(shù)據(jù)平面，消息到達(dá)計(jì)算節(jié)點(diǎn)不進(jìn)行計(jì)算)，發(fā)送不同數(shù)量的數(shù)據(jù)流消息FN，記錄MAR隨FN的變化值，如圖8所示.在數(shù)據(jù)流到達(dá)300以后開始出現(xiàn)消息丟失，相比圖6中的70以后出現(xiàn)消息丟失，翻了4倍左右，與網(wǎng)卡數(shù)量相同，說明集群數(shù)據(jù)流容量的大小與接入節(jié)點(diǎn)的數(shù)據(jù)平面網(wǎng)卡數(shù)量有關(guān).

圖8 節(jié)點(diǎn)5張千兆網(wǎng)口的MARFig.8 MAR of five Gigabit NICs for node

在集群模式下，3臺接入節(jié)點(diǎn)和6臺計(jì)算節(jié)點(diǎn)(各配5張千兆網(wǎng)卡，1張連接控制平面，4張連接數(shù)據(jù)平面，每個計(jì)算節(jié)點(diǎn)的數(shù)據(jù)流均勻分配，消息到達(dá)計(jì)算節(jié)點(diǎn)不進(jìn)行計(jì)算)，發(fā)送不同數(shù)量的數(shù)據(jù)流消息FN，記錄MAR隨FN的變化值，如圖9所示.集群的數(shù)據(jù)流容量達(dá)到了900而未出現(xiàn)消息丟失，可以從數(shù)據(jù)看出，集群的數(shù)據(jù)流容量與接入節(jié)點(diǎn)數(shù)量以及接入節(jié)點(diǎn)數(shù)據(jù)平面網(wǎng)卡數(shù)量有關(guān)，擴(kuò)展集群數(shù)據(jù)流容量可以通過增加接入節(jié)點(diǎn)數(shù)量和接入節(jié)點(diǎn)數(shù)據(jù)平面網(wǎng)卡數(shù)量.

圖9 集群5張千兆網(wǎng)口的MARFig.9 MAR of five Gigabit NICs for cluster

最后，對所提出集群內(nèi)數(shù)據(jù)流調(diào)度算法性能進(jìn)行了測試.經(jīng)過前期測試，GTX1080GP能夠達(dá)到每秒處理45數(shù)據(jù)流的數(shù)據(jù)，而GTX970GPU能夠達(dá)到每秒處理21數(shù)據(jù)流的數(shù)據(jù).在一對一模式下，1臺接入節(jié)點(diǎn)和兩臺計(jì)算節(jié)點(diǎn)(各配一張千兆網(wǎng)卡，每個計(jì)算節(jié)點(diǎn)的數(shù)據(jù)流均勻分配，消息到達(dá)計(jì)算節(jié)點(diǎn)進(jìn)行GPU計(jì)算，計(jì)算節(jié)點(diǎn)分別安裝GTX1080和GTX970)，發(fā)送不同數(shù)量的數(shù)據(jù)流消息FN，記錄和TDR，TAR隨FN的變化值.從圖10中可以看出，無調(diào)度模型的TDR和TAR在數(shù)據(jù)流數(shù)量到達(dá)40以后開始增長；有調(diào)度模型的TDR和TAR在數(shù)據(jù)流數(shù)量超過50以后開始增長.有調(diào)度模型相比于無調(diào)度模型將數(shù)據(jù)流容量提升了20%.相同情況下，無GPU計(jì)算時數(shù)據(jù)流容量超過70以后出現(xiàn)MAR，有GPU計(jì)算時數(shù)據(jù)流容量超過40以后出現(xiàn)MAR，可以看出GPU的處理能力也影響著數(shù)據(jù)流容量.

圖10 節(jié)點(diǎn)單張千兆網(wǎng)口的TDR，TARFig.10 TDR and TAR of a Gigabit NIC for node

圖11 集群5張千兆網(wǎng)口的TDR，TARFig.11 TDR and TAR of five Gigabit NICs for cluster

在集群模式下，3臺接入節(jié)點(diǎn)和6臺計(jì)算節(jié)點(diǎn)(各配5張千兆網(wǎng)卡，一張連接控制平面，4張連接數(shù)據(jù)平面，消息到達(dá)計(jì)算節(jié)點(diǎn)進(jìn)行GPU計(jì)算，兩臺計(jì)算節(jié)點(diǎn)安裝GTX1080，4臺計(jì)算節(jié)點(diǎn)安裝GTX970，每個計(jì)算節(jié)點(diǎn)的數(shù)據(jù)流均勻分配)，發(fā)送不同數(shù)量的數(shù)據(jù)流消息FN，記錄和TDR，TAR隨FN的變化值.從圖11中可以看出，無調(diào)度模型的TDR和TAR在數(shù)據(jù)流數(shù)量到達(dá)140以后開始明顯增長；有調(diào)度模型的TDR和TAR在數(shù)據(jù)流數(shù)量超過160以后開始增長.有調(diào)度模型相比于無調(diào)度模型將數(shù)據(jù)流容量提升了15%.從數(shù)據(jù)也可以看出，集群GPU數(shù)量的增加能夠增大集群數(shù)據(jù)流容量.

6 總 結(jié)

在本文中提出一種針對邊緣計(jì)算場景下的AI數(shù)據(jù)流計(jì)算系統(tǒng)的雙平面架構(gòu).該架構(gòu)分為控制平面和數(shù)據(jù)平面.控制平面負(fù)責(zé)集群管理和數(shù)據(jù)流調(diào)度等控制命令的傳輸，基于傳統(tǒng)TCP/IP網(wǎng)絡(luò)協(xié)議的LAN.數(shù)據(jù)平面負(fù)責(zé)AI數(shù)據(jù)流的傳輸，基于之前的研究，利用DPDK多網(wǎng)卡并行通信技術(shù)實(shí)現(xiàn)基于消息的傳輸協(xié)議.雙平面的架構(gòu)能夠從物理線路上將集群控制和數(shù)據(jù)流命令與數(shù)據(jù)流數(shù)據(jù)分離，避免數(shù)據(jù)流數(shù)據(jù)擁塞時造成調(diào)度命令的傳輸延遲和丟棄，進(jìn)而導(dǎo)致集群性能下降或者故障.在雙平面架構(gòu)的基礎(chǔ)上，本文提出了兼顧計(jì)算節(jié)點(diǎn)網(wǎng)絡(luò)負(fù)載和計(jì)算負(fù)載的任務(wù)遷移調(diào)度模型.該模型旨在通過數(shù)據(jù)流調(diào)度，保證任務(wù)的完成時間和集群的穩(wěn)定運(yùn)行.實(shí)驗(yàn)結(jié)果顯示，本文提出的雙平面架構(gòu)傳輸方案能夠增加集群數(shù)據(jù)流容量30%而不丟消息；雙平面架構(gòu)調(diào)度模型能夠增加集群數(shù)據(jù)流容量15%而不出現(xiàn)任務(wù)丟棄.

本文接下來的研究工作將集中于擴(kuò)展基于消息的傳輸協(xié)議和調(diào)度模型優(yōu)化.作為AI計(jì)算的中間數(shù)據(jù)，AI數(shù)據(jù)流可能是多維的，因此擴(kuò)展該協(xié)議使其更具普適性非常有意義.調(diào)度模型優(yōu)化的方向應(yīng)該考慮到集群能耗以及GPU計(jì)算能耗等因素.