适用于边缘计算的6H并行计算架构

李 磊,郑黎明,王宏义,柴永毅,刘培国

(1.国防科技大学电子科学学院,湖南 长沙 410073;2.中国电子科技集团公司第十五研究所,北京 100083;3.军委装备发展部体系评估中心,北京 100009)

1 引言

近年来,物联网、大数据、人工智能、5G等技术的大规模应用催生了一大批新的互联网应用,如智慧城市、智慧工厂、自动驾驶、增强现实、虚拟现实等。传统的云集中式计算模型采用“云+端”两级模式,将传感器产生的所有数据通过网络上传至云计算中心,利用云计算中心的超强计算能力来集中解决应用的计算需求问题[1]。然而,针对万物互联的泛在式计算需求,云计算集中式计算模式存在一系列问题:

(1)云计算中心接入带宽和计算资源无法支撑接入设备的指数式增长[2]。

(2)无法满足低延时、高服务质量类应用需求。

(3)存在丢失大量本地环境信息的风险,可能导致大数据分析效果不理想。

(4)存在隐私泄露和核心数据不受控的风险。

为解决上述问题,广大研究人员从不同的角度提出了不同的解决思路[3,4],如移动边缘计算MEC(Mobil-Edge Computing)、雾计算(Fog Computing)和移动云计算MCC(Mobil Could Computing);各大学及研究组织也启动了多个相关项目,如微云(Cloudlet)、CDRD(Central Office Re- Architected as a Datacenter)、Nebula和FemtoCloud等。本文总结如下:

(1)雾计算。为满足万物互联的泛在式计算需求,思科拓展了云计算的概念,提出将计算资源、存储资源、数据及数据分析服务扩展到网络边缘,使用户能够在本地分析和管理数据,即雾计算。雾计算是一种面向物联网的分布式计算模型,其计算节点不是性能强大的服务器,而是性能较弱、更为分散的各种功能计算机,如IoT节点、联网的车辆、无线传感器节点、路由网关和各类控制器等。雾计算强调的是所有空闲的联网设备都共享计算和存储资源,重点是让计算和存储在空闲设备之间迁移,是典型的去中心化分布式计算环境。

(2)移动边缘计算。在5G技术的推动下,电信标准化组织和移动运营商为避免移动承载网络被管道化,提出希望将5G网络与移动互联网及物联网业务深度融合,以提升移动网络带宽的经济价值。为此,欧洲电信标准协会ETSI(European Telecommunications Standards Institute)提出了移动边缘计算,其基本思想是把云平台从移动核心网络内部迁移到移动接入网边缘,实现计算及存储资源的弹性利用。这一概念将传统电信蜂窝网络与互联网及物联网业务进行了深度融合,旨在减少移动业务交互的端到端时延,发掘无线网络的内在能力,从而提升用户体验,给电信运营商的运作模式带来全新变革,并建立新型的产业链及网络生态圈。

(3)移动云计算。移动云计算是在云计算基础上,针对用户端计算资源和存储资源有限的特征,引入移动代理技术,实现计算服务和存储服务在云端、边缘节点、用户端动态迁移的计算模式[5]。当用户端移动设备的计算和存储资源无法满足计算需求时,移动云计算框架将大块数据的存储和密集计算任务交给可能是边缘节点也可能是云计算中心的远程主机执行。Cloudlet是卡内基梅隆大学一个研究组织对移动云计算模式的一种典型实现[6]。

虽然移动边缘计算、雾计算、移动云计算等的出发点不尽相同,但它们都体现了万物联网时代对新计算模式的需求,实时的服务响应速度、稳定的服务质量、为用户提供定制化服务已逐渐成为用户关注的焦点。本文将计算、存储等服务迁移到更靠近数据源所在的网络上运行。尽可能减小数据往返云端的延时、减少网络带宽需求的计算模式统称为边缘计算。

2 边缘计算架构分析

学术界和产业界提出并实现了多种边缘计算体系架构,但大部分是参考云计算体系架构,将边缘计算节点简单地等同云计算节点,采用软件定义网络SDN(Software Defined Network)和网络功能虚拟化NFV(Network Functions Virtualization)实现计算节点的动态管理。最典型的有针对5G技术发展提出的移动边缘计算体系架构,如ETSI发布的MEC(Mobile-Edge Computing)技术白皮书[7],给出了移动边缘计算的详细架构,其核心是MEC服务器,它用于提供计算资源、存储空间、连接以及相关无线网络的实时信息等。MEC服务平台主要由3部分组成:主机平台、应用平台及APP管理平台。MEC主机平台分为MEC的硬件资源层与MEC的虚拟层。MEC硬件资源层主要包括CPU、GPU、内存、硬盘和网络等资源,MEC虚拟层提供IaaS(Infrastructure as a Ser- vice)服务。MEC应用平台主要为MEC平台上的各类应用程序提供一组标准化的、通用化的基础服务,包括服务注册、服务之间的通信、无线网络服务、流量卸载功能。APP管理平台主要是通过一组标准的API接口,实现对托管的APP及APP虚拟机进行生命周期管理。

文献[8]针对物联网的计算需求,提出了统一的雾计算架构,并对雾计算的分类法进行了研究。文献[9]对移动云计算进行了总结,对比分析了各种已经实现的移动云计算体系架构。整体上来说,移动边缘计算、雾计算、移动云计算在体系架构上都是基于云计算体系架构,进行适当的修改完善。与云计算体系架构不同的主要是更加关注计算任务在多个计算节点之间的迁移。

还有一些研究针对某一类特定的应用场景设计了特定的边缘计算体系结构。文献[10]针对物联网设备设计了PhiPU,使用异构多核的结构并行处理深度学习任务和普通的计算任务(实时操作系统)。文献[11]为解决云中心计算模式在深度学习方面的弊端,提出了一种自动化增强式计算框架(In-situ AI),该框架通过数据诊断选择最小数据移动的计算模式,将深度学习任务部署到边缘计算节点。文献[12]针对大规模视频监控应用,采用3层计算结构解决图像的实时计算问题。文献[13]针对雾计算节点组织问题,提出采用软件定义网络的方式组织所有雾计算节点,实现节点之间的消息路由,针对单个节点,提出了一种实现隐私保护的分层体系结构。

综上所述,提出和实现的边缘计算构架基本都是基于虚拟化、SDN、NFV技术,解决了很多现实问题,但深入分析后发现它们依然存在以下问题:

(1)虚拟化导致系统配置优化成本增加。

已有一些研究证明,Hypervisors虚拟化技术对性能的影响很小。但是,通过分析及大量的实验发现,达到虚拟机最优性能往往需要根据具体的应用、资源情况(计算、存储、网络)进行有针对性的优化[14]。文献[15]通过实验证明,不同的虚拟机技术,不同的测试用例,往往导致性能差异很大。每个虚拟机技术有不同的适用场景,每个虚拟机需要根据实际使用场景进行有针对性的优化才能实现最佳的性能。对具体的实验数据进行分析可知,在不同硬件平台上采用通用的虚拟机配置,不进行有针对性的优化,将导致性能急剧下降。特别是在雾计算环境下,需要将各种移动计算资源纳入计算体系,这将导致系统优化配置难度激增。

(2)虚拟化技术资源管理的粒度不够细。

以虚拟化技术构建的计算架构,通常将面向特定服务的一组应用部署在一个虚拟机中。Hypervisors生命周期管理的粒度为虚拟机,但是许多计算任务需要对整个计算任务进行并行化划分,消除计算性能瓶颈,采用并行计算和微服务的思想提高整体性能。特别是在边缘计算环境下,计算节点的可用资源有限,往往希望将任务进行细粒度划分后分派到不同的计算节点。

(3)虚拟机之间通信和迁移成本过高。

虚拟化技术帮助云计算中心提升伸缩性和灵活性,集中式管理简化了资源和服务的管理和维护。相对云计算中心,边缘计算环境地理更加分布、硬件更加异构、可用资源更加动态、I/O操作更加频繁。虚拟机需要构建虚拟化操作系统,导致整体容量达上百兆,非常不利于在动态计算环境下进行迁移。文献[15]已经证明在I/O操作密集时,虚拟机的性能将大幅下降。

(4)不同虚拟机技术的虚拟化主机之间互操作差。

到现阶段为止,虚拟化技术及虚拟化产品众多,有商用的也有开源的,超过10种。不同的虚拟机采用的技术和方案不同,虚拟机之间的通信没有统一标准,导致通信困难。计算任务在同类虚拟机之间能轻松迁移,但是在不同技术的虚拟机之间迁移则存在诸多困难。

综上,现有针对云计算的虚拟化技术不是特别适合边缘计算场景,需要更加轻量级的虚拟化技术。另一方面,已经有研究表明,采用Docker等轻量级虚拟化技术来处理边缘计算任务能取得更好的效果[16]。本文针对边缘计算场景,凝练了高性能、高可用、高可扩展、高模块化、高可伸缩、高易用的6H计算需求,基于轻量化虚拟机技术,充分借鉴并拓展并行计算架构,提出了适用于边缘计算环境的6H并行计算架构。

3 6H计算需求

针对物联网、5G等典型应用场景,边缘计算架构需要满足以下6H计算需求:

(1)高可用性。5G应用包括高可靠、低时延通信场景,远程医疗、自动驾驶、无人机控制等应用,对网络和服务的可用性提出了严苛的要求。但是,在边缘计算动态环境,计算节点动态加入和退出、任务动态装载,所以边缘计算体系架构需要在动态环境下解决高可用问题。

(2)高性能。边缘计算环境中很多计算节点是网络边缘设备、智能移动设备,各计算节点存在计算资源受限的情况。为了在资源受限的节点上运行深度学习、增强学习、图像处理等人工智能算法,需要提供高性能的计算架构,充分整合和利用各计算节点的计算资源,汇聚成高性能的一体化计算架构,对外提供高性能计算服务。

(3)高可扩展性。在边缘计算环境下,随着用户数量和应用的增加,计算和存储需求必然不断增加。计算架构能通过简单增加硬件的方式满足不断增长的计算和存储需求,即系统性能随着加入的计算节点数量的增加呈线性增长。

(4)高模块化。在高度动态化的边缘计算环境,计算异常情况明显增多,需要采用虚拟化技术有效隔离每个计算模块,限定异常的影响范围。另一方面,需要对所有计算任务进行细粒度划分。针对计算瓶颈,可以采用并行计算和软件定义网络等思路,对计算瓶颈模块启动多个计算实例,有效减少系统的部署和集成难度。

(5)高可伸缩性。在边缘计算动态环境下,加入的可用计算和存储资源动态变化。计算架构能适应不同规模的硬件条件,既能有效组织少量节点,满足小规模计算和存储需求,也能适用大规模计算节点环境,满足大规模计算和存储需求。

(6)高易用性。相对普通编程,并行编程的难度较高,需要提供简单的编程模型和易用的用户界面,用户可以方便地划分、管理和部署所有计算任务,提高系统的易用性。

4 6H计算架构

4.1 6H计算架构概述

从物理部署架构上看,6H计算架构和移动边缘计算、雾计算、移动云计算等架构类似,具体部署场景如图1所示。

在图1中,边缘计算服务器具有一定的稳定性,性能较好,作为主服务器使用,是6H分布式计算环境的核心。物联网设备接入网络,从属于不同的边缘计算服务器。边缘计算服务器按照计算任务情况、网络情况、计算节点资源情况,给物联网设备分配计算任务。

将地理位置上、逻辑功能上相关的边缘计算服务器共同组成分布式计算环境,采用多网络浮动IP的集群方式实现高可用分布式计算环境,其组网方式如图2所示。所有的边缘服务器都具备2套网络资源,一套用于对外提供服务(如果被选中作为主服务器),一套用于系统内部进程间通信。

Figure 2 Edge server networking method

单个计算节点计算架构如图3所示,处于最底层的是CPU、内存、网络等计算资源;计算资源层以上是操作系统层;操作系统层上有虚拟化容量引擎,上面是一个个轻量级虚拟进程。在边缘服务器上,有APP服务进程和SDN控制进程。由于采用轻量化虚拟机技术,一个轻量化虚拟机就对应并行计算中一个具体的进程,在后面描述的过程中,计算进程等同于轻量化虚拟机。

Figure 3 Architecture of single computing node

各个模块的功能和作用如下所示:

(1)计算资源层主要包括边缘服务器及参与计算的边缘设备所属资源(包括计算、存储和网络资源)。

(2)操作系统层主要包括各种不同类型的操作系统,核心要求是轻量级虚拟化技术需要支持不同的操作系统。

(3)虚拟化容器引擎主要是根据任务进程管理需要,对轻量级虚拟机进行动态装载、运行、停止、卸载及运行状态监控等。

(4)进程间通信框架主要是采用并行计算技术,提供了一套基于消息机制的进程间数据传递模型,以及一套对应的编程框架。

(5)服务管理进程主要用于实现各个服务的注册、性能监控、管理等功能,针对性能要求及瓶颈,根据计算策略自动在合适的服务器上启动新的进程实例,并更新全局消息路由信息。

(6)操作支持系统OOS(Operation Support Systems)进程,主要对各个服务器、轻量级虚拟机的相关配置及资源进行管理。

(7)SDN控制进程主要根据APP服务进程的要求,将用户请求分解为不同的计算任务,并将不同的计算任务正确路由到不同的计算节点及计算进程,计算结束后,将结果反馈给APP服务进程。

(8)APP服务进程主要接收用户APP发来的业务操作,并将SDN控制进程返回的计算结果反馈给用户,典型的如Web服务器进程。

其中SDN控制进程和APP服务进程作为主服务器特有的功能,只部署在边缘服务器上。

4.2 交互模型

交互模型规定了各进程/轻量级虚拟机之间的交互方式,主要包括通信模式、命令帧格式及消息路由机制。

进程间通信主要在TCP/IP网络通信基础上,充分参考和借鉴并行计算框架MPI的设计思路,支持点对点、广播等通信机制,点对点通信采用管道方式,支持PULL和PUSH 2种模式。每个进程绑定2个标识,一个是发送端标识,一个是接收端标识,采用TCP://IP:Port的方式标识,其中IP、Port支持通配符。通信模型如图4所示。

Figure 4 Inter process communication model

系统采用JSON统一定义了进程之间交互的消息格式,具体如下所示:

{

Sender_Pid：UINT32;//发送者进程号

Receiver_Pid：UINT32;//接受者进程号

CMD_Code：UINT32;//命令码

Task_ID：UINT32;//任务码

Frame_Type：UNIT32;//消息帧类别

Frame_NO：UNIT32;//消息帧序号,用于多帧

Priority：UINT32;//消息帧处理优先级

Created_Time：time;//创建时间

Data_length：UINT32;//消息帧长度

Custome_Data：String;//客户自定义

}

消息帧中的CMD_Code是命令码,命令码是整个系统消息处理和路由的核心,每个服务器上的服务管理进程管理本机及本机附属的移动结算节点上的所有计算进程,所有其他进程需要向该进程注册,更新消息路由表。其他进程在发送消息时,根据消息路由表计算出消息的目的进程,实现业务操作的软件可定义。

4.3 CMD-Worker-Handler编程模型

每个计算任务对应一个轻量级虚拟机,也就是一个典型的计算进程。每个计算任务又按照处理的业务不同划分为多个功能模块,也就是划分成若干个Worker,每个Worker对应操作系统原生态的线程,进程作为这些Worker的容器。在进程启动时,根据配置信息动态加载Worker。具体的编程模型如图5所示。

Figure 5 CMD worker handler programming model

在并行化程序编程时,用户只需要关注自己的业务逻辑实现。将业务逻辑分解成不同的计算任务(Process),再将计算任务分解为不同的功能模块(Worker),功能模块包含多个功能需求(Handler),每个功能需求对应一个命令码。将所有任务分解成命令码以后,规划好全局路由信息。在具体编程时,则只需要扩展CMD Handler,在CMD Handler中处理针对具体消息的处理逻辑。

5 原型系统测试

考虑到Python的灵活性和C++语言的高效性,本文采用Python/C++混合编程模式实现了一个6H计算框架。其中,随业务变动较大的业务逻辑采用Python语言实现,相对固定且要求处理性能的进程间通信、消息队列管理、高可用等模块采用C++语言实现,采用Python和C/C++语言的相互调用机制实现2种语言的交互,参数传输采用JSON序列化方式。

测试环境包括测试的实施场地及测试系统等内容。项目所有的测试工作都严格按照相应的测试标准设置测试环境,并在测试前进行仪器设备的校准。本节仅对测试环境重点的几个方面进行说明。

在边缘计算典型硬件条件下,采用物联网典型用例对该计算框架进行了测试。测试主要关注计算架构的高性能、高可用、高可扩展、高模块化、高可伸缩方面。高易用性从CMD-Worker-Handler编程模型能充分体现。

5.1 测试环境

5.1.1 网络环境

测试组网如图6所示,共6台边缘服务器,通过千兆交换机实现互连,相关的传感器按照逻辑关系划分到不同的边缘服务器管辖。6台边缘服务器采用随机选举的方式产生主节点,当主节点选定以后,主节点绑定对外IP地址,其他边缘服务器作为从节点工作。

Figure 6 Network diagram for prototype system testing

5.1.2 软硬件环境

所有的边缘服务器采用HP Gen8 DL388e服务器,2颗6核2.2 GHz主频的CPU,内存为24 GB,采用国产麒麟操作系统,Linux内核版本为2.6.32。为了进行性能测试,开发了各式传感器模拟器,在本文实验过程中,模拟实现了RFID传感器。软件压力测试工具采用WebBench。所有网络通信采用千兆网交换机。

5.2 测试设计及测试结果

5.2.1 单节点并行性

采用1台测试模拟服务器模拟100个传感器,每个传感器产生10条数据,每条传感数据处理逻辑在边缘服务器上耗时0.1 s。设计单节点测试场景:6H计算架构运行于1台边缘计算服务器上,连接的100个传感器连续向6H计算架构发送10条传感数据,在边缘服务器上依次启动1个、2个、3个和4个处理进程,事件路由策略采用随机方式。实验重复100次。

边缘服务器上启动1个、2个、3个和4个处理进程时,传感数据处理计算耗时如图7所示。

Figure 7 Comparison of calculation time for different number of processes

在多颗多核CPU硬件条件下,1个、2个、3个和4个进程条件下计算时间基本成比例减少,说明6H计算架构在单节点条件下具有较好的并行性。

5.2.2 多节点并行性

测试环境类似单节点并行性,设计多节点测试场景:6H计算架构中依次运行1台、2台、3台、4台、5台和6台边缘计算服务器,连接的100个传感器连续向6H计算架构发送10条传感数据,在边缘服务器上运行1个处理进程,事件路由策略采用随机方式。实验重复100次。

6H计算架构中边缘服务器依次为1台、2台、3台、4台、5台和6台时,传感数据处理计算耗时如图8所示。

Figure 8 Comparison of calculation time for different number of edge servers

在边缘服务器依次为1台、2台、3台、4台、5台和6台时计算时间基本成比例减少,说明6H计算架构在多节点条件下具有较好的并行性。

5.2.3 单节点高并发

在测试模拟服务器上运行WebBench压力测试工具,模拟用户通过Web服务器访问内部计算逻辑,Web服务器处理及内部业务逻辑处理在边缘服务器上的计算耗时为2 s。设计单节点高并发测试场景:6H计算架构中只运行1台边缘计算服务器,同时部署Web服务器进程和业务计算逻辑进程,连接的不同数量用户连续向6H计算架构发送Web请求,事件路由策略采用随机方式。实验重复100次。

不同数量用户发送请求时,请求数量及失败请求失败数量如图9所示。

Figure 9 Number of failed requests with different concurrent requests (single node)

图9中横坐标为WebBench中模拟的并发用户数量,左侧纵坐标是Web请求数量,右侧纵坐标是Web请求失败数量。单台服务器,并发在线用户为1 000时,系统能提供可靠的服务,说明6H计算架构在单节点条件下具有较好的性能。

5.2.4 多节点高并发

测试环境类似单节点高并发,设计多节点高并发测试场景:6H计算架构中只运行5台边缘计算服务器,其中1台负责处理Web请求,4台部署业务计算逻辑,连接的不同数量用户连续向6H计算架构发送Web请求,事件路由策略采用随机方式。实验重复100次。

不同数量用户发送请求时,请求数量及失败请求数量如图10所示。图10中横坐标为WebBench中模拟的并发用户数量,左侧纵坐标是Web请求数量,右侧纵坐标是Web请求失败数量。多台服务器,并发在线用户为6 000时,系统能提供可靠的服务,说明6H计算架构在多节点条件下具有较好的性能。

Figure 10 Number of failed requests with different concurrent requests (multiple nodes)

5.2.5 高可用测试

在图6所示的测试网络条件下,从3个方面测试其可用性:主节点网络故障、从节点网络故障和节点网络故障恢复。

当主节点网络故障时,其他从节点发现和主节点的心跳包发送失败后,连续重试连接。如果连续多次重试失败后,所有从节点按照配置的选举规则重新选择主节点。主节点则绑定外部IP,启动主服务进程,更新全局路由表。在实验时,设定重试5次,优先选择内网IP地址二进制值小的主机做主节点。重复10次实验,主节点网络故障后,52 s内恢复正常服务。

当从节点网络故障时,主节点和其他从节点发现和故障从节点的心跳包发送失败后,连续重试连接。如果连续多次重试失败后,主节点更新全局路由表,将故障从节点的计算任务路由到其他服务器处理。如需要在其他服务器上启动服务进程,则请求从服务器加载相关进程。在实验时,设定重试5次,在其他服务器上不需要加载其他进程,重复10次实验,从节点网络故障后,服务不受影响。

当节点故障恢复时,恢复节点向所有节点发送心跳包,请求加入计算框架。恢复节点按照主节点需求及恢复节点的配置信息加载计算任务进程,主节点更新全局路由表。在实验时,重复10次实验,从节点网络故障恢复后,38 s内恢复的故障节点加入6H计算框架并提供正常服务。

6 结束语

本文深入分析边缘计算的需求特点,基于轻量级虚拟化、软件定义网络、并行计算等基本理念,提出适用于边缘计算环境的6H并行计算架构,即高性能、高可用、高可扩展、高模块化、高可伸缩、高易用。为验证6H并行计算架构的合理性和科学性,本文采用Python/C++混合编程模式实现了一个6H计算框架,在边缘计算典型硬件条件下,采用物联网典型用例对该计算框架进行了测试,其结果表明,该计算框架并行度接近1,可扩展性很好,可伸缩性好,具有很高的可用性。下一步将在本文基础上,将6H计算框架应用于实际的边缘计算环境,服务于视频处理、人工智能等应用场景。