面向条件受限环境的动态可重构异构计算平台*

杨鹏飞，刘 波，党佳乐，吕文凯

0 引 言

自动驾驶、物联网、星载、机载计算等行业和领域，越来越多的应用场景是在体积、重量、功耗等条件和资源受限的环境下.嵌入式计算设备既要自身具有强大的计算和管理能力，又要实现与其他设备相互协同，协作处理复杂的任务场景.如未来星载计算机既要能够独立进行系统管理和任务执行，又要能与其它星载计算机实现互联协作[1-2]，这对条件受限下的高性能异构计算提出了更高的要求.不同类型、架构、数量的器件构成的异构化的计算平台，包括CPU、DSP、GPU、FPGA、NPU和其它可编程逻辑等各种计算资源[3-4]，能够较好的满足算力需求，但同时也给平台的架构设计、系统管理、网络集群构建与应用开发部署提出了更大挑战.

可重构计算能够通过在线方式对计算机硬件结构进行升级或修改，从而更好的满足嵌入式计算设备架构共融、资源共用、协同处理的“云”化发展趋势和技术要求[5].但可重构计算概念的提出主要是针对于硬件层面，解决专用集成电路开发周期长、灵活性差的缺陷，所以更多的研究仍集中在可重构逻辑器件、系统硬件性能提升，较少的考虑平台级架构以及系统管理软件与调度策略对系统性能的提升，从而忽略了在系统级的管理调度以及在软件层面的可重构计算对系统性能的提升[6].而可重构计算要发挥效能优势，可重构硬件是基础，平台架构是关键，资源、通信和架构的自组织协同和动态自演化理论与技术是核心，信息快速存储与检索是提升平台效能的有效途径，有必要对其涉及内容展开深入研究[7].此外，对于任务驱动模型，从任务接入到任务执行完成的过程中，涉及到故障的自动检测、计算节点的自动切换以及任务的自动恢复等问题.为保证任务持续高效的执行，计算平台的高可用性是必要的.因此，急需一种任务驱动的、异构资源可自组织协同和统一化管理的、高可用的可重构异构计算平台.

基于以上分析，本文提出了一种任务驱动的嵌入式可重构异构计算平台，与传统平台相比，该平台具有以下三方面优势：

(1)通过集群构建的方式，统一管理调度集群中的嵌入式计算节点，同时集群具有自动构建能力，实现了异构计算资源的自组织协同与统一化管理.

(2)基于容器化的方式，进行任务的快速部署，同时细化了资源管理的粒度，提高资源利用率.

(3)基于B/S模式开发Web可视化界面，提供统一的用户接入接口，用户端随遇接入，便于使用和管理平台.

1 平台架构

本文按照自顶向下的设计方法，首先给出任务驱动的嵌入式可重构异构计算平台的总体架构，然后分层介绍详细的设计细节.

如图1所示，一种任务驱动的嵌入式可重构异构计算平台包括三层：用户接入层、系统中间件层及硬件层.其中，用户接入层实现用户的任务接入，包括Web可视化模块与任务接入模块.系统中间件层通过动态集群构建模块实现嵌入式集群的构建与管理、任务池构建模块构建集群的任务池、资源池构建模块构建集群的资源池、虚拟计算环境构建模块实现任务执行的虚拟计算环境的构建.硬件层实现嵌入式计算节点上异构资源的统一接入及板间网络化互联.

用户通过用户接入层实现任务的接入，任务接入模块按照一定的负载均衡策略将任务分发到集群中.集群中的主节点提取任务池中的任务，在资源池中为任务匹配资源.匹配成功后，主节点进行任务下发，计算节点利用容器虚拟化技术，构建任务执行的虚拟计算环境执行任务.

图1 平台分层架构图Fig.1 The diagram of platform layered architecture

1.1 用户接入层

如图2所示，用户接入层包括Web可视化模块与任务接入模块.其中，Web可视化模块为任务接入提供Web可视化界面，进行任务、资源、用户的管理，并为用户接入和授权提供保证；任务接入模块为用户提供统一接入地址，运用代理保证统一接入的高可用性并将任务按照一定的负载均衡策略在集群间分发.

图2 用户接入层示意图Fig.2 The diagram of user access layer

Web可视化模块，为多重用户提供不同的可视化交互界面，帮助用户基于安全机制实现任务管理、资源管理、用户管理和其他管理.

任务接入模块，用于接收用户的任务请求，如图3所示，该模块是由多个计算节点搭建的代理集群，基于Virtual Router Redundancy Protocol (VRRP)[8]协议实现代理集群中的节点共有一个虚拟IP (VIP)，当VIP绑定的节点Master故障时，VIP会漂移到一个Slave节点上，此Slave节点上升为新的Master，继续提供任务接入服务，从而为用户提供一个统一、高可用的访问接口，保证了任务接入的高可用性.同时，代理集群按照一定的负载均衡策略，将任务分配到多个集群中，从而提高任务处理的并发度和吞吐量、提高平台资源的利用率.

图3 任务接入模块结构示意图Fig.3 The schematic diagram of task access module

1.2 系统中间件层

如图4所示，系统中间件层通过动态集群构建模块、任务池构建模块、资源池构建模块及虚拟计算环境构建模块实现集群、任务池、资源池的构建；实现资源自组织协同和统一化管理；匹配任务与资源，配合混合时间驱动，利用虚拟化技术构建实现实时可控的、可重构的虚拟计算环境进行任务执行.

1.2.1 动态集群构建模块

动态集群构建模块实现嵌入式集群的构建.多个嵌入式计算板卡在物理上呈现分布式、承载异构计算资源的特点，动态集群构建模块将分布式嵌入式节点的计算能力进行集中，构建集群，对资源和任务统一调度、管理.动态集群构建模块由心跳检测、数据库一致性、动态中心选举三部分组成.

(1)心跳检测

心跳检测实现集群中节点健康状态的检测，在节点地位对等的主从服务方式下，对各个节点进行存活检测，将新的计算节点加入集群，对故障节点进行删除，是实现资源自组织协同和统一化管理的基础.当删除计算节点时，通过下述数据库一致性策略同步数据库中集群的节点信息，删除故障节点的信息.

(2)数据库一致性

数据库一致性实现集群中各个节点数据库数据的同步.一方面，当有读数据库操作时，从节点可以分担请求、减小主节点的压力.另一方面，由于每一个计算节点均知晓集群的任务、资源配置信息，当主节点故障时，可以利用下述动态中心选举策略选举出新的主节点，同步数据库中数据，从而解决了主节点单点故障的问题.

(3)动态中心选举

动态中心选举实现了集群中主控制节点的动态选择，在数据库一致性的基础上，利用选举策略动态选择主节点，主节点负责集群中任务、资源的统一管理，实现集群的动态构建.选举出的主节点负责任务的下发，即将具体的任务及任务相关的配置信息，按照一定的策略分发到某一计算节点中.当某一计算节点发生故障时，主节点负责故障迁移并将该故障节点上的任务重新下发.

1.2.2 任务池构建模块

任务池构建模块构建集群的任务池，任务池中包含集群的全部任务信息，主节点从任务池中顺序提取任务进行处理.

1.2.3 资源池构建模块

资源池构建模块包括资源发现与可用性检测两部分.在嵌入式计算板卡启动时，完成资源配置的扫描，获取已注册的设备信息并对设备进行健康检测，将可用资源信息存入数据库的资源列表中，实现资源发现与可用性检测，借助数据库一致性策略构建集群的资源池.资源池中包含了整个集群各个嵌入式计算节点的资源类型、资源数目、资源健康状态等信息.新加入集群的节点，通过资源发现与可用性检测将异构资源信息加入到资源池中，对于故障和失效节点，在心跳检测机制和数据库一致性的基础上，资源池自组织的清除故障和失效节点的异构资源信息，从而实现异构计算资源的自组织协同和统一化管理.

1.2.4 虚拟计算环境构建模块

虚拟计算环境构建模块将任务与任务所需资源匹配，根据任务的需求，主节点构建任务执行的虚拟计算环境，即构建任务执行环境的相关配置信息，随任务一同下发给计算节点，计算节点将任务与配置环境整合，利用容器虚拟化技术构建任务执行的虚拟计算环境[9].这样实现了资源与环境的构建由任务触发，根据任务的需要动态的生成与调整，即实现了任务驱动.在此任务驱动的计算平台上，我们将应用及运行环境打包为Docker镜像并上传到Docker仓库中.使用Docker的方式构建虚拟计算环境，其启动快速，属于秒级别[10].如图5所示，计算节点按照主节点下发的配置信息从Docker仓库中拉取镜像，构建任务执行的虚拟计算环境即可，这样就可以将应用的安装、环境的配置自动化的完成[11].此外，配合混合时间驱动设计，以保证控制的确定性和实时性.

图4 系统中间件层示意图Fig.4 The diagram of system middleware layer

1.3 硬件层

硬件层负责嵌入式计算板卡上异构资源统一接入、板间网络化互联，实现了标准的可扩展的高速系统总线和异构资源统一化组件封装和接入，使得异构资源能够按照统一的调用接口及协议进行管理和通信，为系统高扩展性和异构资源的组件化服务提供硬件支撑.如图6所示，硬件资源模块采用“总线-组件”的体系结构设计，将挂载有异构计算资源的控制器板卡通过消息总线定义的标准接口进行网路化互联通信.当有新的计算板卡接入时，只需要在系统中将对应的板卡IP上进行相应配置，即可实现新资源的发现和定位.

虚拟计算环境构建中，任务执行的环境由任务和任务配置信息动态生成，即任务的执行环境是由任务驱动构建的，基于容器化技术，其执行环境是动态可重构的.

图5 基于Docker的虚拟计算环境构建Fig.5 Virtual computing environment construction based on Docker

图6 异构计算资源板卡互联示意图Fig.6 Schematic diagram of heterogeneous computing resource board card interconnection

2 分析与实验

本文利用AIO-RK3399、Core-RK3399ProD、Xilinx UltraScale+MPSoC ZCU102，3种共5张板卡搭建文中所述异构计算平台，所述板卡的硬件信息如表1所示，平台实物图如图7所示.

表1 平台硬件信息Tab.1 Hardware informations for the platform

图7 平台实物图Fig.7 Physical platform

针对平台的特点，任务执行的高可用性是关键，因此首先对本文提出的平台的高可用性进行分析.此外，基于动态集群构建模块与资源池构建模块，集群可以实现对计算节点和异构计算资源自组织协同与统一化管理.为了说明本文中基于容器化技术的任务执行方式的优势，对容器中任务执行的计算性能和资源开销进行了分析.

2.1 平台的高可用性分析

下面分别从任务接入、任务下发和任务执行的三方面说明本文提出的平台架构的高可用性.

2.1.1 高可用的任务接入

在用户接入层中，任务接入模块基于VRRP协议实现代理集群中的节点共有一个虚拟IP(VIP)，当VIP绑定的节点故障时，VIP自动漂移到新的代理节点，对于用户而言感知不到代理服务器的变化，从而为用户提供一个统一、高可用的访问接口，保证了任务接入的高可用性.

2.1.2 高可用的任务下发

本文采用主节点动态选举技术，当集群中当前的主节点故障时，通过心跳检测和数据库一致性策略，该主节点将从集群中去除，同步数据库后通过动态中心选举策略选举出新的主节点，继续进行任务下发，避免了主节点宕机导致整个集群的崩溃，提高了集群的容错性，保证了集群中主节点的高可用性，进而保证了任务下发的高可用性.

2.1.3 高可用的任务执行

当某一计算节点故障后，通过心跳检测和数据库一致性策略，该计算节点将被从集群中去除，所有在该节点上正在执行的任务将失败并由主节点重新进行资源分配和任务下发，从而实现了任务迁移，保证了任务执行的高可用性.

从上面三方面的分析可以看出，本文提出的平台架构在任务生命周期的各个阶段(任务接入、任务下发、任务执行)均是高可用的.

2.2 资源自组织协同与统一管理

新的计算节点加入到集群中时，通过资源池构建模块的资源发现与可用性检测功能即可检测到计算节点的资源信息并保存到数据库中；通过心跳检测，集群中的节点检测到新的计算节点并将其信息存储到数据库中.之后，数据库一致性模块同步集群数据库，将新计算节点的资源信息同步到集群所有节点上.到此，新的计算节点及节点上的异构计算资源自动加入集群中.当集群中某一节点故障(脱离集群)时，集群通过心跳检测，检测到节点的故障状态，将故障节点的节点信息和资源信息从数据库中移除，数据库一致性策略同步集群资源状态，则故障节点的信息已不再集群中，即自动清除了故障节点.从上述过程可以看出，本文提出的平台架构，实现了计算节点的热插拔和异构资源的自适应接入和删除，资源由集群统一调度管理，实现了异构资源的自组织协同和统一化管理.

2.3 容器中任务执行的性能及资源占用分析

为了测试在容器中执行任务与在主机中执行任务时处理器的计算性能与资源占用情况的差异，在ZCU102平台上利用Linpack测试工具[12]以浮点计算峰值为评价指标测试处理器的计算性能、利用Apache Benchmark对Nginx服务进行压力测试并利用Nmon监控资源占用情况[13].

2.3.1 Linpack测试

假设处理器每个时钟周期的浮点运算次数为1，则理论处理器浮点运算峰值为1.2 GHz×1×4核=4.8Gflops.

Linpack测试结果如表2所示，其中Max表示测试得到的实际处理器浮点计算峰值，定义最大效率为Max与理论处理器浮点计算峰值的比值.我们用最大效率作为处理器计算能力的评价指标.

表2 处理器浮点计算峰值最大效率对比Tab.2 The comparisons of processor floating-pointcomputes peak maximum efficiency

表2中可以看出，相比主机，容器中的任务执行没有损失处理器的计算能力.

2.3.2 Apache Benchmark测试

分别对主机与容器中的Nginx服务进行远程访问压力测试，利用Nmon得到的监控结果如表3所示.其中，PE(usr%+sys%)表示任务在用户空间与内核空间处理器的占用比，PE-WAvg表示处理器资源占用的加权平均占比.

表3 处理器资源占用对比Tab.3 The comparison of PE resource consumption

表3中可以看出，相比于主机，容器中的处理器加权平均占比减少了6.6%，即容器中的资源占用更少.

综合以上两种测试可以看到，相比于主机，在容器环境中不会有明显的计算性能下降，却有效的减少了资源的占用.此外，基于容器化的任务分配和部署方式细化了任务占用资源的粒度，其粒度不再是片级，而是任务所需的资源大小，即多个任务各自占有资源的一部分，从而大大提高了资源的利用率.

因此，在本文提出的平台上，基于容器化的任务计算环境的构建在不损失计算能力的条件下，可以有效的提高异构计算资源的利用率、减少资源占用，从而提升平台的性能.

3 结 论

本文针对嵌入式计算节点，提出了一种任务驱动的嵌入式可重构异构计算平台，从用户接入、系统中间件、硬件三层详细阐述了平台的架构和设计，实现了一种任务驱动的、高可用的、异构计算资源自组织协同与统一化管理的嵌入式计算平台.