吴明杰，陈庆奎

1(上海理工大学 管理学院，上海 200093)2(上海理工大学 光电信息与计算机工程学院，上海 200093)

E-mail ：WMJ826WMJ@163.com

1 引 言

近年来随着物联网[1]终端设备的剧增，基于云计算[2]的物联网解决方案开始显露其短板.终端设备规模的不断扩大将极大的增加通信延迟和计算延时，这将无法为用户提供可接受的计算需求和响应需求.边缘计算[3]正是为缓解这一现状而提出的新解决方案.其作为云计算模式的拓展延伸，能够在更加接近用户端进行部署.这将极大的降低通信开销，减少响应延迟，为用户提供更好的体验.如图1所示的′云-边协作框架′[4]将会是未来非常流行的物联网解决方案.

图1 云-边协作框架Fig.1 Cloud-edge collaboration framework

AI(人工智能)[5]技术近几年得到了快速的发展，并且逐渐向边缘端拓展.云计算模式的高延迟限制了AI的广泛应用，终端设备的低计算能力也无法使AI部署于其上，这使得边缘数据中心[6]成为承载AI计算负载的最佳平台.而且，设备端持续增长的实时AI计算需求对边缘数据中心的性能也提出了更高的要求[7].

为了满足边缘AI对边缘数据中心的高性能需求，本文针对边缘集群提出一种由控制平面和数据平面组成的双平面通信架构.控制平面负责处理数据流调度和集群监控等控制信息，数据平面负责数据的快速传输.本文也针对AI数据流提出了基于消息的传输协议，能够有效的降低数据传输负载.最后还提出了AI数据流的集群内调度模型.实验表明，双平面AI数据流的调度模型，能够有效的降低AI数据流的计算延时，提高边缘集群的数据流接入和处理能力.

2 相关工作

随着边缘计算的兴起，边缘微型数据中心作为云计算数据中心的缩小版，面临着同样的任务通信和调度问题[8].而且，实时边缘计算对于边缘集群的响应时间提出了更高的要求[9].

对于通信延时问题，研究人员提出了基于硬件和基于软件的通信性能提升技术.硬件方面已经提出了各种专用的网络硬件解决方案.代表性的如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产品.基于软件的解决方案使得人们对于SDN[10](软件定义网络)和NFV(网络功能虚拟化)[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.一些研究和应用中已经提出了通过将两个平面分离而实现灵活的网络控制的网络切片技术，如Pongracz等人[13]提出一种LTE环境下的SDN架构.此外，将SDN技术应用于物联网环境也出现了一些研究.Yaakoumis等[14]描述了一种在物联网环境中分割家庭网络的原型，他将物理网络切成多层，以隔离不同运营商的流量和带宽.Qing等[15]提出了1个SDN控制器和控制器角色，例如资源匹配和流调度.

任务调度方面研究人员也提出了很多方案.Dong等[16]提出基于优先级的边缘计算资源分配方法.Cao等[17]提出结合网络资源和设备资源对CNN网络进行动态切片的模型，以优化任务完成时间.Jia等[18]提出了一种在线启发式负载均衡任务迁移算法，以缩短终端设备上的应用完成时间.Guo等[19]提出一种节能的动态迁移和资源调度策略，以降低能耗并缩短应用完成时间.Fang等[20]提出一种基于GPU能耗的并发数据流实时动态迁移模型，旨在提高任务执行的可靠性.目前边缘环境下的计算迁移任务调度问题也有一些研究.Zhang等[21]将终端设备延迟敏感的计算任务迁移到边缘云，并提出两阶段任务调度成本优化算法，以降低系统成本.Qi等[22]提出一种结合网络状况和设备条件的自适应调度算法.

基于前人的研究成果，结合SDN双平面以及物理网络切片的思想，本文提出基于Intel DPDK(6)http://www.dpdk.org技术的针对边缘集群的双平面通信框架，将控制平面网络和数据平面网络从物理上隔离.其次，考虑边缘集群内计算节点网络资源和计算资源使用情况，提出数据流动态迁移模型.

3 设计

3.1 物理拓扑

边缘集群作为云计算在物联网应用方面的补充，决定了其应对物联网数据接入和计算的高密度任务.任务调度和监控往往需要近乎实时，对于时延非常敏感.传统的单平面架构会存在一些缺陷.当数据传输占用了大量带宽时，会造成控制或者调度命令的传输滞后，这可能会加重计算节点的负载，甚至是宕机.

图2 物理拓扑Fig.2 Physical topology

如图2所示，通过使用多张网卡，本文的双平面通信框架能够从物理上将控制平面和数据平面分离，互不干扰，从而实现控制和调度命令的即时传输.数据平面数据通过DPDK技术进行快速传输，能够提供较高的传输速率.

3.2 系统框架

本文所研究的边缘集群节点都配有多张网卡，分为控制平面网口和数据平面网口.控制平面网口通过传统网络架构和协议互连，构成1个LAN环境.数据平面通过1个或者多个二层交换机相连，其在DPDK之上构建传输协议.边缘集群节点分为3类：管理节点，数据流接入节点，GPU计算节点.管理节点上包括终端设备管理模块，接入负载均衡模块，节点资源状态监控模块，数据流调度模块，计算模型管理模块，即时信息反馈模块.数据流接入节点上包括数据流接入转发模块和节点资源状态模块.数据流接入转发模块负责设备数据流的接收和根据数据流转发表进行数据流转发；节点资源状态模块负责定时上传节点带宽负载和接入负载等监控信息.GPU计算节点上包括数据流接收计算模块和节点资源状态监控模块.数据流接收计算模块负责数据流的接收和模型计算；节点资源状态模块负责定时上传节点带宽负载和计算负载等监控信息.

图3 框架概览Fig.3 Framework overview

系统整体流程如图3所示.1)管理员在集群管理节点上注册和上传任务计算模型；集群管理节点将计算模型分发给GPU计算节点；2)终端设备向集群管理节点注册数据流以及数据流需要的计算模型，管理节点返回该终端设备数据流的接入节点地址，终端设备进行数据流发送；3)数据流接入节点和GPU计算节点定时向管理节点发送实时带宽负载，接入负载和计算负载等信息；4)管理节点根据GPU计算节点上传的资源状态信息进行数据流调度，并下发数据流转发规则到数据流接入节点，数据流接入节点根据本地的数据流转发进行数据流转发；5)GPU计算节点接收数据流，并根据对应计算模型进行数据计算，如果产生即时反馈信息，则需要发送给管理节点，由管理节点将信息推送给终端设备；需要储存和记录的结果信息上传至云端数据中心.

3.3 AI数据流特征分析

随着边缘AI的兴起，如何在资源受限的终端设备上执行AI计算成为研究热点.目前，终端设备进行部分数据预处理或者计算部分任务，后续任务通过网络交由附近的边缘集群进行计算的方式成为主流.其中，中间结果数据称为AI数据流.AI数据流往往是源源不断地数值型矩阵数据，包括小数.如图片预处理的结果，CNN计算的中间结果.

巨量的AI数据流必然对网络传输造成严重的压力，这就需要高压缩的通信协议来缓解.目前比较流行的技术包括Protobuf，XML，JSON，Thrift等.其中最热门的当属Google的Protobuf了.Protobuf由于更小，更快，更简便备受人们青睐.但是Protobuf作为Google公司内部使用的工具[23]，在通用性上差很多.而且，对于数值型矩阵或者图片的传输不够友好，往往需要转换为文件形式后进行传输，这将增加传输的数据量.为此，本文专门设计了基于消息的AI数据流传输协议，这将会在后续章节详细介绍.

4 实 现

4.1 控制平面

控制平面的主要功能是:1)处理与终端设备之间的相关消息；2)监控集群各节点包括接入节点和计算节点资源状态；3)根据状态信息实时调度集群内数据流的传输；4)管理集群内计算模型的上传和分发.由于控制平面构建于局域网之上，因此传统的数据传输协议都可以使用，如HTTP，TCP，UDP，RPC等.

数据流调度是控制平面最重要的功能之一，如何高效的进行数据流调度成为难题.在数据流迁移的过程中会产生延迟：控制消息的传输和执行可能会产生延时；数据流迁移到目标节点的过程中可能由于网络原因会产生延时；数据流到达目的节点之后，由于目的节点并发能力有限，可能需要排队等待，也会增加延时.如果迁移的总延时太长，将会增加任务的响应时间，影响用户体验.任务的迁移对于保持边缘集群的可靠性和稳定性至关重要.数据流的接入负载均衡已经有很多成熟、高效的算法，本文不予研究.

4.2 数据平面

数据平面的主要任务是数据流的快速传输和任务计算.其通信功能是基于Intel DPDK技术设计和实现的，以提高数据传输的性能，基于之前的研究中所提出的基于 DPDK 的边缘集群内高速通信方案.该方案充分利用的DPDK的众多特性，提供快速的数据报处理、转发和传输特性，并借助于Linux系统的socket本地回环机制，为上层提供了与编程语言无关的类UDP通信接口.如图4所示，双平面通信路径在集群节点内的流程从物理线路上进行了隔离，两个平面的数据传输不会相互影响.

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

4.3 基于消息的数据传输协议

针对AI数据流传输，本文设计和实现了基于消息的传输机制.如图5所示，每一消息都包含有FID(流编号)、MID(消息编号)、M_Time(消息时间戳)和M_Type(消息类型).消息类型分为字符型数据和数值型数据.字符型数据作为计算结果或者通知的格式.数值型数据作为待计算的图像或者矩阵数据的格式，需要指明该数据的Model_ID(计算模型编号)，Byte_Type(矩阵数值类型)，以及矩阵的Len(长)和Wid(宽)，方便数据解析.Byte_Type指定了单个矩阵数值占用的字节数.

消息的大小往往超过了以太网数据帧大小的限制，在传输的过程中需要切片和重组.因此也设计和实现了消息切片的格式和可靠传输协议.每一个消息切片都包含有FID(流编号)、MID(消息编号)、M_Time(消息时间戳)字段、M_len(消息长度)、P_Type(消息切片类型)和P_content(消息切片内容).根据P_Type(消息切片类型)可以分为消息切片数据，切片重传请求，消息重传回应，消息重传询问.每一个消息切片都有P_Num(切片编号)、P_Total(切片总数)和P_Len切片长度，最后为切片数据.

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

基于消息传输的可靠传输机制实现如下：1)发送节点缓存消息切片，并进行发送；发送完成后向接收节点发送消息重传询问；2)接收节点不断的接收消息切片并缓存；若收到消息切片的最后一个切片或者是发送节点的消息重传询问，需要回应一个消息重传请求；3)发送节点收到消息重传请求，进行丢失校验并对对应的数据包重新发送.在规定时间内如果发送节点收到接收节点接收完全的通知，完成此消息的发送；如果超时，则进行下一条消息的发送.如果接收端在规定的时间内未收齐该消息，则丢弃.这样是为了保证AI数据流实时计算的特性.

4.4 数据流调度模型和算法

数据流在集群内的耗时包括传输时间，排队时间和计算时间.传输时间可以分为外网传输时间和集群内传输时间.其中，外网传输时间受外部网络环境的影响；集群内传输时间不仅受集群内带宽限制，也受调度算法的影响.排队时间可以通过好的调度算法进行优化.计算时间受到节点计算力的影响.因此，集群管理节点对于集群内数据流的调度不仅要考虑计算节点的计算负载，还要考虑计算节点的网络负载.无论是网络负载还是计算负载的过高，都会影响任务的完成时间.因此，本文对GPU计算节点的实时网络负载和计算负载进行模型分析，为数据流的高效调度提供理论依据.相关符号在表1中进行了详细的说明.

表1 符号描述Table 1 Symbol description

首先是对GPU计算节点的网络负载建立数学模型.DPDK提供了最基本的网口参数如Nip-Gj-porti(网口接收数据包的总数)，Nib-Gj-porti(网口成功接收字节的总数)，Niep-Gj-porti(网口接收错误数据包的总数)，Nimp-Gj-porti(网口接收丢弃数据包的总数).通过公式(1)-公式(7)可以计算出Vib-Gj-porti(网口成功接收字节的速率)，Vieb-Gj-porti(网口接收错误字节的速率)，Vimb-Gj-porti(网口接收丢弃字节的速率).公式(8)为网口真实的字节接收速率(应该包括错误和丢弃的).通过公式(9)可以计算出该网口的实时负载率.为了防止信息采集时的突发干扰，本文采用平滑过渡方式对网口负载率进行修正，通过调整因子γ，通常取值为0.8，结合前次采集值与当前采集值进行一定比例的求和，计算出调整后的网口实时负载率，如公式(10).计算节点总的网络负载由公式(11)计算得出，为后续节点是否进行迁移作参考.

(1)

(2)

(3)

(4)

(5)

(6)

(7)

(8)

(9)

(10)

(11)

公式(12)计算出单个网口的剩余带宽，并通过公式(13)进行平滑调整，计算出调整后的剩余可用带宽.公式(14)为计算节点的总的剩余带宽，这将为后续的迁移节点选择提供参考.

(12)

(13)

(14)

对GPU节点的计算负载建立数学模型.基于多任务并行计算时任务的响应时间为优化目标，以提升响应速度.公式(15)为整个集群内的数据流数量.通过公式(16)可以计算出计算节点上每条数据流占用的平均带宽.数据流的单个任务计算耗时由公式(17)得出，并且由公式(18)可以计算出计算节点上所有数据流单个任务的计算耗时总和，再由公式(20)计算每条数据流单个任务的平均计算耗时.公式(19)作为计算节点所有数据流单个任务的最大计算耗时，一定程度上反应了计算节点的计算负载.由公式(22)和(23)，可以计算出计算节点的计算负载率.公式(21)计算出计算节点剩余可用的计算耗时，为后续的迁移节点选择提供参考.

(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)显示出计算节点数据流迁移的情况.当计算节点网络故障或者计算故障时，该节点上的数据流需要整体迁移到其他计算节点；当计算节点出现网络超载或者计算超载时，需要将该节点上部分数据流迁移到其他节点上.无论是整体迁移还是部分迁移，都可以通过公式(25)计算出该节点待迁出数据流的数量.在迁入节点选择时，还需要评估每个节点可接受的迁入数据流数量.公式(26)结合计算节点的网络容量和计算容，选择最小可接受迁入数据流的数量.

(24)

Nmigr-Gj(t)=

(25)

(26)

数据流迁移分为3个步骤:首先，计算出计算节点的待迁出数据流数量n，并从计算节点当前数据流集合中选出n条数据流组成待迁出数据流集合F；其次，计算出所有可迁入数据流的计算节点集合G，并根据其可用带宽资源和可用计算资源进行降序排序；最后，依次遍历可迁入计算节点集合G，根据其可接受数据流数量m(m<=n)，将F中的m条数据流迁入节点G[k]，一直到F中的数据流为空.在整过过程中，如果可迁入数据流的计算节点集合G为空，则说明集群中数据流以达到饱和状态，需要提醒管理人员或者写事件日志.在一轮数据流迁移后，待迁出数据流集合F不为空，也说明集群中数据流以达到饱和状态，需要提醒管理人员或者写事件日志.具体的迁移过程由算法1给出.

算法1.数据流迁移算法

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 实 验

5.1 实验环境

为了验证本文方案的性能，本文使用10台主机搭建边缘集群，其中3台作为接入节点，剩余6台作为计算节点，1台作为管理节点.每个节点配置详细信息如表2所示，计算节点配置了GTX970或者GTX1080显卡.每台服务器Hug Page 为8G，rx和tx各1个，且大小为1024，CPU核心占用5个.

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

5.2 评估指标

为了对本文模型进行性能评估，提出了多个指标，如数据流容量，消息丢弃率，任务延迟率和任务丢弃率.

数据流容量FN是指集群可以稳定接入的数据流数量.

FN=N-flow-G

(27)

消息丢弃率MAR是指在周期T内因网络传输而丢弃消息的数量占消息总数量的比例，能够反映网络性能.

(28)

任务延迟率TDR是指任务计算的延时与周期T之比，能够反映任务计算的延迟程度.

(29)

任务丢弃率TAR是指排队任务因超时未计算而放弃的任务数量与排队任务的总数量之比.

(30)

5.3 实验分析

本文将所提出的双平面架构应用于社区养老视频监控系统.首先终端设备如树莓派等对采集到的视频图像进行人体轮廓粗略检测；将检测到的人体轮廓区域中人体特殊部位进行模糊处理以保护隐私；将模糊处理后的人体轮廓区域的图像进行OpenPose人体姿态检测的部分计算；将中间计算结果封装为单个消息，发送到边缘集群进行后续人体姿态检测与状态识别.其中，消息大小为1MB，消息切片大小为750B.

图6 节点单张千兆网口的MARFig.6 MAR of a Gigabit NIC for node

首先对调度模型的网络传输性能进行测试.该实验测试传统单平面模型和本文双平面模型在网络传输方面的性能.在一对一模式下，1台接入节点和1台计算节点(各配1张千兆网卡，消息到达计算节点不进行计算)，发送不同数量的数据流消息FN，记录MAR随FN的变化值.从图6中可以看出，本文的网络方案比传统方案能够在无消息丢失的情况下提升约30%的数据流容量，这归功于前者数据传输基于DPDK的快速包处理和转发技术.

图7 集群单张千兆网口的MARFig.7 MAR of a Gigabit NIC for cluster

对集群模式下的网络性能进行对比，结果如图7.3台接入节点和6台计算节点(各配一张千兆网卡，每个计算节点的数据流均匀分配，消息到达计算节点不进行计算)，发送不同数量的数据流消息FN，记录MAR随FN的变化值.同样的，在集群模式下，本文的网络方案比传统方案能够在无消息丢失的情况下提升约一倍的数据流容量.最后也发现，3台接入节点比1台接入节点的数据流容量多出3倍左右，说明集群数据流容量的大小与接入节点的数量有关.

在一对一模式下，数据平面使用多张网卡的网络性能进行测试.1台接入节点和1台计算节点(各配5张千兆网卡，一张连接控制平面，4张连接数据平面，消息到达计算节点不进行计算)，发送不同数量的数据流消息FN，记录MAR随FN的变化值，如图8所示.在数据流到达300以后开始出现消息丢失，相比图6中的70以后出现消息丢失，翻了4倍左右，与网卡数量相同，说明集群数据流容量的大小与接入节点的数据平面网卡数量有关.

图8 节点5张千兆网口的MARFig.8 MAR of five Gigabit NICs for node

在集群模式下，3台接入节点和6台计算节点(各配5张千兆网卡，1张连接控制平面，4张连接数据平面，每个计算节点的数据流均匀分配，消息到达计算节点不进行计算)，发送不同数量的数据流消息FN，记录MAR随FN的变化值，如图9所示.集群的数据流容量达到了900而未出现消息丢失，可以从数据看出，集群的数据流容量与接入节点数量以及接入节点数据平面网卡数量有关，扩展集群数据流容量可以通过增加接入节点数量和接入节点数据平面网卡数量.

图9 集群5张千兆网口的MARFig.9 MAR of five Gigabit NICs for cluster

最后，对所提出集群内数据流调度算法性能进行了测试.经过前期测试，GTX1080GP能够达到每秒处理45数据流的数据，而GTX970GPU能够达到每秒处理21数据流的数据.在一对一模式下，1台接入节点和两台计算节点(各配一张千兆网卡，每个计算节点的数据流均匀分配，消息到达计算节点进行GPU计算，计算节点分别安装GTX1080和GTX970)，发送不同数量的数据流消息FN，记录和TDR，TAR随FN的变化值.从图10中可以看出，无调度模型的TDR和TAR在数据流数量到达40以后开始增长；有调度模型的TDR和TAR在数据流数量超过50以后开始增长.有调度模型相比于无调度模型将数据流容量提升了20%.相同情况下，无GPU计算时数据流容量超过70以后出现MAR，有GPU计算时数据流容量超过40以后出现MAR，可以看出GPU的处理能力也影响着数据流容量.

图10 节点单张千兆网口的TDR，TARFig.10 TDR and TAR of a Gigabit NIC for node

图11 集群5张千兆网口的TDR，TARFig.11 TDR and TAR of five Gigabit NICs for cluster

在集群模式下，3台接入节点和6台计算节点(各配5张千兆网卡，一张连接控制平面，4张连接数据平面，消息到达计算节点进行GPU计算，两台计算节点安装GTX1080，4台计算节点安装GTX970，每个计算节点的数据流均匀分配)，发送不同数量的数据流消息FN，记录和TDR，TAR随FN的变化值.从图11中可以看出，无调度模型的TDR和TAR在数据流数量到达140以后开始明显增长；有调度模型的TDR和TAR在数据流数量超过160以后开始增长.有调度模型相比于无调度模型将数据流容量提升了15%.从数据也可以看出，集群GPU数量的增加能够增大集群数据流容量.

6 总 结

在本文中提出一种针对边缘计算场景下的AI数据流计算系统的双平面架构.该架构分为控制平面和数据平面.控制平面负责集群管理和数据流调度等控制命令的传输，基于传统TCP/IP网络协议的LAN.数据平面负责AI数据流的传输，基于之前的研究，利用DPDK多网卡并行通信技术实现基于消息的传输协议.双平面的架构能够从物理线路上将集群控制和数据流命令与数据流数据分离，避免数据流数据拥塞时造成调度命令的传输延迟和丢弃，进而导致集群性能下降或者故障.在双平面架构的基础上，本文提出了兼顾计算节点网络负载和计算负载的任务迁移调度模型.该模型旨在通过数据流调度，保证任务的完成时间和集群的稳定运行.实验结果显示，本文提出的双平面架构传输方案能够增加集群数据流容量30%而不丢消息；双平面架构调度模型能够增加集群数据流容量15%而不出现任务丢弃.

本文接下来的研究工作将集中于扩展基于消息的传输协议和调度模型优化.作为AI计算的中间数据，AI数据流可能是多维的，因此扩展该协议使其更具普适性非常有意义.调度模型优化的方向应该考虑到集群能耗以及GPU计算能耗等因素.