《ODCC:2023云边端协同的智能视频方案研究报告(111页).pdf》由会员分享,可在线阅读,更多相关《ODCC:2023云边端协同的智能视频方案研究报告(111页).pdf(111页珍藏版)》请在三个皮匠报告上搜索。
1、 1 云边端协同的智能视频方案研究 ODCC-2023-04003 编号 ODCC-2023-04003 I 云边端协同的智能视频方案研究 ODCC-2023-04003 版权声明版权声明 ODCC(开放数据中心委员会)发布的各项成果,受著作权法保护,编制单位共同享有著作权。转载、摘编或利用其它方式使用 ODCC 成果中的文字或者观点的,应注明来源:“开放数据中心委员会 ODCC”。对于未经著作权人书面同意而实施的剽窃、复制、修改、销售、改编、汇编和翻译出版等侵权行为,ODCC 及有关单位将追究其法律责任,感谢各单位的配合与支持。II 云边端协同的智能视频方案研究 ODCC-2023-0400
2、3 编写组编写组 项目经理:项目经理:叶王 百度国际科技(深圳)有限公司 工作组长:工作组长:陈炜 深圳市腾讯计算机系统有限公司 贡献专家:贡献专家:黄伟 北京百度网讯科技有限公司 郭利文 工业富联(富士康工业互联网股份有限公司)余丽雅 百度国际科技(深圳)有限公司 刘垚 百度国际科技(深圳)有限公司 陈俊 百度国际科技(深圳)有限公司 左轶鹏 北京百度网讯科技有限公司 刘逸流 北京百度网讯科技有限公司 李锴 中国移动研究院 常金凤 中国信息通信研究院 龚万春 比亚迪精密制造有限公司 张骏 英特尔 王贵林 京东云计算有限公司 袁华勇 腾讯科技(北京)有限公司 冼曙光 深圳江波龙电子股份有限公司
3、 林峰 深圳江波龙电子股份有限公司 III 云边端协同的智能视频方案研究 ODCC-2023-04003 前前 言言 很荣幸能够为您呈上这份方案文档,探讨了解我们在需求分析、技术框架、关键技术细节以及实际案例等多个方面所积累的知识和经验。本文档旨在为您呈现一个全面而深入的视角,带您深入了解我们团队所构建的创新性方案。随着信息技术的飞速发展,我们面临着新的挑战和机遇。在这个数字化时代,边缘计算作为一项前沿技术,已经引领着各行各业的变革。从智能设备到数据处理,从实时决策到安全性保障,边缘计算为我们开启了崭新的可能性。而本方案正是在这一背景下应运而生,致力于解决诸多现实场景中的技术瓶颈和挑战。在这份
4、方案文档中,您将深入了解我们所构建的技术框架,以及涵盖数据传输、设备管理、云边协同调度、安全性保障等多个关键技术的详细解释。我们不仅关注技术的内在,更注重技术在实际场景中的应用。因此,您还将在文档中找到丰富的案例分享,这些案例涵盖了从音视频领域到智慧校园、零售等多个领域的实际应用,希望能够为您提供灵感和启示。本方案的完成离不开团队的共同努力和合作,同时也得益于众多合作伙伴和专家的支持与建议。在此,我要对他们的付出表示深深的感谢。希望这份方案文档能够为您提供有益的信息和视角,帮助您更好地理解边缘计算领域的发展动向以及我们的创新成果。如果您在阅读过程中有任何疑问或建议,欢迎随时与我们联系。IV 云
5、边端协同的智能视频方案研究 ODCC-2023-04003 祝愿本文档能够为您带来价值,启发您在未来的技术探索中取得更多成就。衷心感谢!由于时间仓促,水平所限,错误和不足之处在所难免,欢迎各位读者批评指正。如有意见或建议请联系编写组。V 云边端协同的智能视频方案研究 ODCC-2023-04003 目目 录录 版权声明.I 编写组.II 前 言.III 一、需求分析.1 二、方案技术框架.3 三、关键技术详解.5(一)数据传输和存储技术.5(二)设备和应用管理.5 1 设备统一管控.6 2 应用管理.9 3 可观测性.12(三)云边端调度.14 1 单机轻量容器引擎.14 2 云边通道.23
6、3 云边协同调度.27 4 节点分组.32(四)算法维度.37 1 智能视频服务架构.37 2 弹性调度系统.48(五)视频维度.55 1 端侧数据采集技术.55 2 端侧推理任务平台.56 VI 云边端协同的智能视频方案研究 ODCC-2023-04003 3 边侧端数据接入、AI 分析和关键存证数据.58(六)安全相关.59 1 容器安全.59 2 盒子鉴权.61 3 mtls 证书.62(七)硬件平台支持技术.63 1 云边协同硬件服务器介绍.63 2 基于 Intel TDX 的机密计算.75 3 比亚迪边缘视频加速服务器硬件方案.89 四、案例分享.95 1 百度边缘音视频案例.95
7、 2 边云协同的视频分析技术在智慧校园之明厨亮灶中应用.97 3 智慧零售.100 五、总结和展望.102 1 云边端协同的智能视频方案研究 ODCC-2023-04003 云边端协同的智能视频方案研究报告云边端协同的智能视频方案研究报告 一、一、需求分析需求分析 随着人们对视频需求的不断增加,视频应用场景也不断扩大,包括监控、视频会议、在线教育、智慧城市、智能家居等领域,使得对视频处理能力的要求越来越高。云计算技术的快速发展为实现云边端协同的智能视频方案提供了技术支持,可以大大提高视频处理效率和准确性,并实现分布式计算和存储。物联网技术的广泛应用使得设备之间的连接更加紧密,也为云边端协同的智
8、能视频方案提供了技术支持,可以实现设备之间的信息传递和互操作。人工智能技术的不断进步和发展,尤其是深度学习等技术的应用,使得智能视频处理更加智能化和高效化,提高了视频处理的准确性和自动化程度。随着安全和隐私需求的提高,对视频处理的要求也越来越高,特别是在监控和安全领域。云边端协同的智能视频方案可以更好地保障视频数据的安全性和隐私性,提高整个系统的可靠性。综上所述,云边端协同的智能视频需求背景主要源于视频应用场景的扩大、云计算技术的快速发展、物联网技术的广泛应用、人工智能技术的进步以及安全和隐私需求的提高等因素。主要可以概括为以下几点:1.数据传输和存储需求:智能视频应用需要大量的数据传输和存储
9、,而边缘设备的处理能力有限,无法满足这些需求。因此,需 2 云边端协同的智能视频方案研究 ODCC-2023-04003 要将数据传输到云端进行存储和处理,并将处理结果传回边缘设备,实现云端和边缘设备之间的数据协同。2.实时性需求:智能视频应用通常需要实时处理视频数据,对于一些需要及时反馈的应用场景,如智能监控、智能交通等,要求对视频数据进行实时处理和分析。因此,需要边缘设备和云端之间建立低延迟的通信通道,以保证视频数据的实时传输和处理。3.算法优化需求:智能视频处理通常需要复杂的算法支持,而边缘设备的计算能力有限,无法支持较为复杂的算法,因此需要将算法部分放在云端进行处理。同时,为了降低传输
10、延迟和减少网络带宽的消耗,需要对算法进行优化,使其能够在边缘设备上运行,同时保证较高的准确率。4.安全性需求:智能视频处理涉及到大量的敏感信息,需要采取一系列的安全措施来保障数据的安全性,如数据加密、身份认证等。同时,需要建立完善的安全管理机制,包括安全审计、漏洞修复等,以确保系统的安全稳定运行。5.可扩展性需求:随着智能视频应用的不断发展和普及,需要能够支持更多的设备和用户接入,同时保证系统的稳定性和性能。6.用户体验需求:智能视频处理的最终目的是为用户提供高质量的服务体验,因此需要关注用户体验的各个方面,包括响应速度、图像清晰度、交互方式等,以满足用户的需求和期望。同时,需要进行用户调研和
11、反馈,不断改进和优化系统的功能和性能,提高用 3 云边端协同的智能视频方案研究 ODCC-2023-04003 户满意度。7.成本效益需求:在智能视频处理中,云端和边缘设备的资源使用需要考虑成本效益,如网络带宽、存储、计算资源等,需要根据实际情况进行优化和管理。端边云协同的智能视频系统需具备高效的视频采集和传输、端边智能分析、灵活的存储与检索、安全与隐私保护、可扩展性与兼容性、用户界面与交互、系统稳定性与可靠性等关键功能和性能。通过满足这些需求,智能视频系统能够提供高质量、可靠的监控和分析服务,为用户带来更安全、便捷的视频监控体验。二、二、方案技术框架方案技术框架 云边端协同的智能视频方案技术
12、框架可以采用以下主要技术:1.数据传输和存储技术:包括数据压缩、加密传输、云端存储、边缘存储等技术,以确保数据的安全传输和存储,并提高数据传输效率和存储利用率。2.实时性处理技术:包括流媒体传输技术、低延迟编码技术、并行处理技术等,以保证视频数据的实时处理和及时反馈处理结果。3.智能视频处理算法技术:包括目标检测、行为识别、人脸识别、视频分析等算法技术,以实现对视频数据的智能处理和分析。4.云边端协同调度技术:包括任务分配、资源调度、动态负载均衡等技术,以实现云边端协同处理任务的高效分配和调度。4 云边端协同的智能视频方案研究 ODCC-2023-04003 5.安全性保障技术:包括身份认证、
13、数据加密、安全审计、漏洞修复等技术,以确保系统的安全性和稳定性。6.用户交互界面技术:包括用户界面设计、交互方式设计等技术,以提供高质量的用户体验和友好的用户界面。基于以上技术,云边端协同的智能视频方案技术框架可以分为三层:1.应用层:用户通过界面操作,完成对智能视频处理的需求定义和任务发布等操作。2.云边端协同处理层:通过任务调度和资源分配等机制,将任务分配到云端和边缘端进行处理和分析,并实时反馈处理结果。3.基础设施层:提供数据传输和存储、实时处理、安全性保障 5 云边端协同的智能视频方案研究 ODCC-2023-04003 等基础支撑服务,以保证系统的高效稳定运行。在该技术框架下,云端和
14、边缘端协同处理任务,利用分布式计算资源和算法实现视频数据的智能处理和分析,提高了视频处理效率和准确率,并为用户提供了高质量的智能视频处理服务。三、三、关键技术详解关键技术详解 云边端协同的智能视频方案中,涉及到多种关键技术,以下对这些技术进行详细的介绍。(一)(一)数据传输和存储技术数据传输和存储技术 数据传输和存储技术是保证云边端协同的智能视频方案稳定和高效运行的关键技术。其中,数据压缩技术可以降低数据传输时的带宽占用和传输延迟,加密传输技术可以保证数据的安全性,云端存储技术可以提高数据存储利用率和容错性,边缘存储技术则可以提高数据访问速度和减轻云端的负担。(二)(二)设备和应用管理设备和应
15、用管理 设备和应用管理技术是保证端边云协同的智能视频解决方案能够正常运行的基础技术。该技术包括边缘和端设备的统一管控、应用管理和可观测性等关键技术,可以实现对边缘和端设备的有效管理、应用程序的灵活调度和监测,以确保系统的高效运行。下图是设备和应用管理的架构图。通过在传统的云端两层架构 6 云边端协同的智能视频方案研究 ODCC-2023-04003 之间添加边缘站点这一物理层,使得每个边缘节点由最近的站点进行管理,从而降低云端中心的负载、服务时延,并提高边缘节点的管控数量。图 3.1 设备和应用管理架构图 1 1设备统一管控设备统一管控 在端边云协同的智能视频解决方案中,设备统一管控技术起着至
16、关重要的作用,该技术涉及对边缘计算节点和端侧摄像头的管理和监控,包括但不限于设备的激活注册、配置、状态检测、软硬件更新等功能。1.1 1.1 边缘计算节点管理边缘计算节点管理 边缘计算节点主要负责承担边缘计算任务。设备统一管控技术可以通过以下方式对边缘计算节点进行管理:7 云边端协同的智能视频方案研究 ODCC-2023-04003 注册激活注册激活:如图 3.1 所示,各个边缘计算节点实际会被接入到不同 kubernetes 环境里,并由距离该节点最近的边缘 CDN 站点进行托管。该 CDN 站点的选取,是在边缘节点注册激活的过程中完成的,步骤如下:1.部署在边缘节点中的 agent 组件,
17、会定期汇报心跳到云端控制中心。2.从云端控制中心对该节点注册激活,后端会根据心跳信息依据节点的 IP 信息和 ISP 网络状况返回最佳站点。3.节点上的边缘 agent 获取到该信息后,便据此完成与边缘站点的云边通道连接工作。至此,该边缘节点便成功纳管至该系统里。在中心控制中心将可以管理和操作该边缘节点,包括但不限于在线状态查看、资源监控、应用部署、远程命令执行等。分组管理分组管理:边缘节点注册激活后,可以在中心控制台对指定的边缘节点进行分组管理,将它们单独划分为一个逻辑小集群,以提供应用多副本、容灾互备的能力。比如,同属于在一个营业门店内的边缘计算节点可以在同一个节点组内进行管理。状态监测状
18、态监测:可以监测节点的运行状态、资源利用率、负载情况等,以便及时进行故障排查和性能优化。状态监测主要分为设备状态检测和应用状态检测。其中,设备检测主要包括 8 云边端协同的智能视频方案研究 ODCC-2023-04003 节点的在线状态(设备与网络的连接是否正常)、运行状态(如 CPU、内存和存储资源的利用率等),而应用状态监测则是对各个应用程序的实时监测,包括但不限于应用的运行状态、错误和异常捕获等。软硬件更新软硬件更新:边缘节点上运行的软件组件,可能需要定期更新以修复漏洞、添加新功能或改进性能,每个软件组件都有唯一的版本号,管理员可以在中心控制台上查看到边缘节点的实际运行版本以及当前最新的
19、版本情况,并可以通过本方案提供远程软件更新能力来完成边缘节点版本升级。同时,设备上的固件也需要进行更新以获得最新的功能和修复漏洞,可以通过 OTA 升级技术完成远程固件更新,其中的步骤类似于软件更新。1.2 1.2 端侧摄像头设备管理端侧摄像头设备管理 端侧摄像头是智能视频解决方案中负责采集图像或视频数据的设备,采集到数据可结合模型算法应用实现视频内容分析和智能识别。基于标准的 GB28181 和 ONVIF 协议,本方案将实现各种摄像头的接入,屏蔽底层异构,对端侧摄像头进行统一管理,并提供以下能力:1.各品牌网络摄像头设备的识别 9 云边端协同的智能视频方案研究 ODCC-2023-0400
20、3 2.获取各设备的视频流地址 3.对所有设备的视频流地址进行统一管理,可获取视频流列表 4.对所有设备的存活状态进行检测,异常时做出相应的响应 5.可实现对设备的参数调整,如采样率等 6.设备与模型应用关联 2 2应用管理应用管理 应用管理是端边云协同的智能视频解决方案中的另一重要组成部分,它涉及到对各种应用程序的管理和部署。每个应用采用kubernetes Pod 方式部署,按类别分为官方应用、自定义应用、多合一算法这几类。此外,还可以将这些应用组成一体机应用进行统一管理。2.1 2.1 官方应用官方应用 官方应用是一系列与智能视频解决方案相关的应用,也是本方案的一部分。这些应用由包相关的
21、部署 yaml 文件和应用版本、描述等元信息组成。在智能视频领域里,这些应用可以是关于视频编解码的应用、也可以是对应场景的目标检测和跟踪算法应用。根据不同的场景和需求,通过云边通道,用户可以将应用下发到具体的边缘节点上,并设置不同的环境变量以满足实际需求。当应用成功部署到边缘节点后,应用的实例状态会上报回中心,10 云边端协同的智能视频方案研究 ODCC-2023-04003 其状态的流转图如下图所示:图 3.2 应用状态流转 此外,官方应用可以在边缘节点出厂时便内置进去,以减少应用部署时镜像拉取的时间,从而实现应用秒级别的启动。这些预置的信息同样会记录在中心控制中心里,用户可以通过中心查看预
22、置的应用,并直接启停它们。2.2 2.2 自定义应用自定义应用 自定义应用则是由用户自定义创建的容器应用,由用户自行管理版本。创建完后可以通过相同的方式下发部署到边缘节点。2.3 2.3 多合一算法多合一算法 不同场景需求并不相同,比如智慧交通和智慧园区场景里所需要的算法并不相同。为了赋予用户更高的自由度,以满足个性化、场景化需求,本方案设计了多合一算法的功能。该功能可根据不同的场景需求,由用户自行对多个算法进行自由组合。在使用多合一算法前,需要事先在中心定义好单个算子的名称、11 云边端协同的智能视频方案研究 ODCC-2023-04003 运行架构、所需的运行资源以及模型文件地址。当部署一
23、个多合一算法时,将会将这些信息整合在一起,通过模板创建实际的部署yaml 文件。该 yaml 文件会定义一个 initContainer 进程在算法实际启动前去拉取所需的运行数据,包括但不限于 AI 模型文件。这些数据的拉取地址会以环境变量的方式写入 yaml 里,由 initContainer 进程读取。同时,算子内部会挂载一个宿主机的目录,用于存储存储下来的数据。其中,download 目录用来存储下载的数据;data 目录用来存储算子运行时需要的数据。在 data 目录下按子算法名创建目录。为避免旧版本带来的脏数据,每次启动时,都需要清空,并且从download 复制需要的文件,流程如下
24、图所示 图 3.3 多合一算子启动流程 当 initContainer 完成数据的初始化工作后,真正的算法框架进程将会读取该路径下数据。完成进程初始化工作,监听端口,建 12 云边端协同的智能视频方案研究 ODCC-2023-04003 立 server,进而提供算法服务。2.4 2.4 一体机套件一体机套件 为了加速标品交付速度,本方案提出了一体机套件的功能,实现对于边缘节点的一键装机,标品快速交付,即支持将多款官方应用、官方算法等捆绑到一起,作为一个一体机套件包。从而用户可以一键进行统一部署、统一管理、统一删除。3 3可观测性可观测性 可观测性是端边云协同的智能视频解决方案中的重要技术之一
25、。它涉及对系统的运行状态和性能进行实时监测和分析,以便及时发现和解决潜在的问题。其中,底层基于 Victoria Metrics 的开源方案来构建整个监控架构,从而实现监测指标收集和数据存储和查询,架构如下图所示:13 云边端协同的智能视频方案研究 ODCC-2023-04003 图 3.4 监控架构图 每个边缘节点都会部署一个 vm-agent,用于实时收集系统中各个组件(node-exporter等)的监测指标,这些指标包括但不限于:系统资源利用率、应用性能指标、网络状况等。采集到的数据除了会推送到中心 vm-storage 组件外,还会推送到边缘节点上的 vm 单机版组件里,以便在边缘控
26、制台上直接查看到当前节点的运行状态。Victoria Metric 作为一种时间序列数据库,能够高效地存储和管理大量的监测数据。它提供了灵活的查询语言和API。因此可以对特定的监测指标进行实时查询、数据聚合和分析,并结合 grafana制作仪表盘,实现对系统的监测指标的可视化展示。14 云边端协同的智能视频方案研究 ODCC-2023-04003 此外,管理员或用户还可以设置报警规则,当监测指标超出设定的阈值或发生异常时,系统将自动触发报警通知,以便及时采取相应的措施。(三)(三)云边端调度云边端调度 表 3.1 术语表说明 edgelite 边缘侧的应用程序,容器运行底座,拥有控制面能力,管
27、理容器的生命周期 edge-tunnel 云边通道中在边缘侧的应用程序 cloud-tunnel 云边通道中在中心侧的应用程序 cloudlite 中心侧的应用程序,负责管理 edgelite,代理 edgleite到中心 k8s 的所有请求 1 1单机轻量容器引擎单机轻量容器引擎 随着 K8S 的普及,越来越多的上层系统开始搭建在 K8S 底座之上。边缘计算由云中心的延伸逐步演变为云-边-端一体化的基础设施,这个过程也会越发触及更靠近用户侧的边缘环境,这就使得越来越多边缘侧的小型机器或机房、盒子设备、甚至是单片机设备需要作为边缘侧算力节点纳入到边缘计算管理范畴。管理这些边缘设备难点在于克服异
28、构性、设备资源极端限制、边缘网络质量差等主要因素。目前云原 K8S 生已经被广泛用于云计算领域,完成应用到基础设施的敏捷CI/CD,但其设计针对的领域更多是对数据中心的成群节点的管理,对于边缘零散设备管理的技术配套仍然没跟上,所 15 云边端协同的智能视频方案研究 ODCC-2023-04003 以对 K8S 的边缘计算的轻量化修改适配势在必行。由于边缘计算业务场景充斥着大量的异构、小规格的边缘算力,像各种智能终端、设备,它们对资源的约束是极致的,无法接受额外的过多资源占用。所以,K8S轻量化成为了必须解决的首要问题、业务场景的基本需求。通过 K8S 边缘轻量化改造,精简 K8S 功能,对已有
29、框架的轻量化改造、容器引擎的轻量化实现,有效提升边缘业务并发启动速度,大幅降低稳态下的内存占用,满足用户的基本需求。与云边集群的普通节点不同,edgelite 适用于边缘一体机的使用场景,既满足单机独立运行的需求,又可以快速加入原生 K8s 集群,按照k8s原生API的方式统一管理单机盒子,包括对盒子查询、部署应用等。因此 edgelite 的场景具有以下特点:(1)独立性:单机与中心无任何依赖关系;单机之间的资源隔离,单机资源仅在本机可见,即意味着 service 不互通、pod 不互通。(2)资源的有限性:单机的 CPU、内存资源是有限的,单机侧要极致轻量,可视化平台按需开启,开启后总体占
30、用不超过200M(空载,不含 containerd)。(3)一般情况下不会出现大量的容器应用。(4)功能的有限性:单机仅满足基本的容器管理需求,包括Pod(包括 Pod 依赖的 ConfigMap 资源等)、Service、Node 16 云边端协同的智能视频方案研究 ODCC-2023-04003 等,资源的访问接口需要兼容原生 K8s 的 API。(5)云原生标准化:单机可以快速加入到原生K8s集群,实现统一的管理和维护;单机侧本身兼容原生 K8s。针对以上特点,我们 edgelite 架构整体设计如下图:图 3.5 edgelite 架构整体设计图 为了减少进程间的通信,从而降低内存,我
31、们设计了 cli 模块用来管理所有依赖子模块的集成问题,同时取消数据库存储,直接采用本地存储,也就是 storage 模块,取消了原有 list-watch 机制,采用 dispatch 模块完成资源的分发操作,同时对外提供标准 k8s 接口,设计了 server 模块,为了能够被标准 k8s 管理,将云边通道edge-tunnel 组件集成到 edgelite 里,最后基于 k8s 原有组件进行相应裁剪完成 kubelet、kube-proxy、containerd 裁剪统一集成到edgelite 里,实现必要组件 all in one。作为 All in One 的组件,EdgeLite
32、旨在集成在边缘部署所需的 17 云边端协同的智能视频方案研究 ODCC-2023-04003 进程和工具,只需部署 EdgeLite 一个组件,即可完成单机版的部署。这里主要涉及的是进程模块的封装问题,由 EdgeLite 的 Cli 命令行模块负责实现。详细方案如下:一个可执行文件扮演多个角色 同一个可执行文件可以作为不同的进程使用,例如,当文件名命名为 containerd 时,它运行起来就是一个 containerd 进程;当文件名命名为 edgelite 时,它运行起来的就是 edgelite 进程。这样一来,只需要一份代码和一个进程,就能包含多个服务。edgelite的做法是使用“
33、的代码编译出来的二进制包含了containerd、kubectl、crictl、ctr 进程。如果编译的二进制命名为 containerd,则运行二进制时启动的就是 containerd 进程。1.1 Ed1.1 EdgeLite ServergeLite Server 模块模块 EdgeLite Server 模块是一个接口服务模块,在边缘端提供访问k8s 资源对象的接口。它兼容 k8s 接口,并保持与原生 k8s 接口操作规范一致,使得与 k8s 相关的 kubectl、client-go 可以正常调用Server 模块接口。Server 模块的处理流程如下:18 云边端协同的智能视频方案
34、研究 ODCC-2023-04003(1)Server 服务模块启动并监听服务端口,使用 HTTP 监听本地地址(参数指定)。(2)Server 对接收到请求,对请求进行解析,解析出请求的k8s 资源类型和操作类型等信息(例如:Pod、Node 等资源类型)。(3)根据请求的资源类型和操作类型(CREATE、UPDATE、PATCH 等操作类型),进入相应的接口服务进行处理。(4)接口服务处理的操作通过 Storage 存储模块获取/存储。(5)对于更新事件的操作类型(CREATE、UPDATE、PATCH、DELETE),需要将更新事件 Push 到 Dispatcher 消息分发模块。1.
35、2 Edgelite1.2 Edgelite-StorageStorage 模块设计模块设计 该模块对接 edgelite server 接口,采用本地文件存储的方式完 成 资 源 对 象 的 存 储。为 了 确 保 写 一 致 性,该 模 块 维 护ResourceVersion,并负责生成 event 事件以对接 dispatcher。本地文件存储模块相较于单纯的读写本地文件,主要增加了以下两点能力:(1)解除文件存储和业务逻辑之间的耦合,通过Transform实现灵活调整。目前,该模块对接 server 资源接口,按照目录地址+文件名的方式来存放和索引资源。如果其他模块 19 云边端协同
36、的智能视频方案研究 ODCC-2023-04003(如 promlite)需要向本地存储迁移,可在初始化时自定义存储组织逻辑。(2)增加了读取缓存,可以减少访问相同资源的内存占用和速度。写操作都先在临时目录下进行,没有错误后,再拷贝到正常的路径完成写入,以保证写操作的原子性。写操作的主要逻辑如下:(1)维护 ResourceVersion。(2)拼接路径并创建 objType/namespace/。(3)创建文件并写入 objType/namespace/name。(4)生成 event 事件,调用 dispatcher。对于 create 操作:(1)如果资源已经存在,返回已存在错误。(2)
37、如果资源不存在,初始化资源的ResourceVersion 并执行写操作。对于 update 操作:(1)如果资源不存在,返回不存在错误。(2)更新资源的 ResourceVersion 并执行写操作。20 云边端协同的智能视频方案研究 ODCC-2023-04003 1.3 Edgelite1.3 Edgelite-DispatchDispatch 模块设计模块设计 在 EdgeLite 中,我们采用了一种与众不同的方式来实现组件之间的资源同步。与原生 K8s 不同,EdgeLite 将所有组件集成在一个进程中,因此组件之间的资源同步可以通过进程内的消息通信来完成,而不需要使用 HTTP 建
38、立 List/Watch 连接。这就避免了不必要的开销。在 EdgeLite 中,需要进行资源同步的场景主要是:当存储的K8s资源发生变化时,需要通知关注资源的相关模块。这种模式类似于消息订阅/发布的模式。目前,模块与模块之间没有相互传输消息的需求,即只有一对多的消息单向传递,而没有多对多或双向的消息传递。因此,我们只需要设计一个在 EdgeLite 中的消息分发模块,基于消息订阅/发布的模式即可。dispatcher 模块采用消息订阅发布的模式,每个客户端作为消息订阅者。dispatcher 模块会为每个客户端生成一个 watcher 对象,作为其监听任务。客户端通过监听 watcher 提
39、供的消息 channel,获得变更事件。storage模块是产生事件的源头,作为消息发布者,当存储对象发生变更时,将消息通知给每个监听此对象的 watcher。1.4 Edgelite1.4 Edgelite-Pod Controller Pod Controller 设计设计 为了实现轻量化,edgelite 删除了 k3s server 组件,并且不再支持 Deployment、DaemonSet 高阶应用部署。因此,单机版不再 21 云边端协同的智能视频方案研究 ODCC-2023-04003 具备保证指定实例个数的 Pod 运行的能力。如果单机因为资源达到配置的使用上限,造成 Pod
40、被驱逐删除,即使机器资源恢复到可用状态,被驱逐的 Pod 也无法自动恢复重启,从而造成业务异常。因此,单机版需要在保证轻量化的同时,也需要提供自动恢复被驱逐的 Pod 的能力。为了解决这个问题,我们自定义了一个 Controller,仅针对被驱逐的 Pod 进行自动恢复。其中,controller 仅在离线情况下(未纳管时)启用。Pod 被驱逐是因为 kubelet 根据采集的机器数据判断,当前机器可用资源已经小于配置的临界值,需要通过驱逐 Pod 来缓解和释放机器的资源使用,避免机器发生故障。Pod被驱逐时,Pod Status都会更新为 Failed 状态,此外,当机器可用资源小于临界值时
41、,kubelet 还会更新 node 的 status,显示某一项 NodeCondition 异常,并为 node 打上不可调度的污点,使得新增部署的容器无法运行,基于以上的特点,我们可以设置一个简单的 controller,仅对被驱逐的 Pod 进行特殊处理。22 云边端协同的智能视频方案研究 ODCC-2023-04003 图 3.6 Edgelite-Pod Controller 流程 23 云边端协同的智能视频方案研究 ODCC-2023-04003 2 2云边通道云边通道 在边缘计算场景下,许多边缘节点都位于私有网络中。由于节点私有网络 IP 不可达的原因,我们无法从云端主动向边缘
42、节点发送控制面消息,也无法直接从云端访问边缘设备上的HTTP、RTSP、FTP等服务。这导致常用的运维操作如日志查询、远程命令执行、指标数据查询等无法实现。因此,我们需要开辟一条云端与边缘侧的通道,以增强我们对边缘节点的控制能力。提供一个能够跨越局域网屏障,实现稳定可靠的数据传输,支持多种协议代理的云边协同通道。通过这种方式,我们可以构建出云-边-端一体化的请求通道解决方案,从而将中心云、边缘云、私有现场 IDC 和边缘盒子设备等整合成一个资源混合云,实现容器化编排和资源统一调度。要实现云边通道,需要在边缘节点和云端节点上分别构建edge-tunnel 和 cloud-tunnel 两个模块。
43、为了解决以下问题:(1)如何在云边传递云端请求;(2)如何拦截云端请求;(3)边缘如何处理云端请求;(4)高可用性的问题。2.1 2.1 使用使用 websocketwebsocket 构建云边通道,传递云端请求构建云边通道,传递云端请求 WebSocket 被用作云边通道的通信协议,Edge-Tunnel 作为客户端,Cloud-Tunnel 作为服务端,通过它们之间建立一条长连接来传递消息。Cloud-Tunnel使用Edge-Server模块来处理与Edge-Tunnel 24 云边端协同的智能视频方案研究 ODCC-2023-04003 的云边通道连接,Edge-Tunnel则使用Tu
44、nnel-Client模块与Cloud-Tunnel 建立连接。在 Edge-Tunnel 发起的连接请求的头部,携带节点名称作为其唯一标识。举例 http 代理的整体方案结构如下:cloud-tunnel 是云边通道的云端组件,作为 http 代理服务,负责将 http 客户端的请求代理转发到边缘进行处理。它包括 proxy server 和 tunnel server 两个模块:(1)Proxy Server Proxy Server 是 http 代理服务模块,负责代理 http 客户端的请求,并将 http 请求重新封装成 tunnel message,通过与 edge-tunnel
45、建立的 websocket 通道,转发给边缘设备的 http 服务进行处 25 云边端协同的智能视频方案研究 ODCC-2023-04003 理。(2)Tunnel Server Tunnel Server 是云边 websocket 通道的服务端,负责与每个边缘设备的 edge-tunnel 建立 websocket 连接,并将 edge-tunnel 返回的响应消息分发给代理请求的 Proxy Server 进行处理。2.2 DNS2.2 DNS 劫持云端请求劫持云端请求 tunnel-dns 是云边通道使用的 DNS 解析服务,它使用“tunnel-dns”名称的 configmap 作
46、为 DNS 记录解析表。在“tunnel-dns”这个 configmap 中,每个边缘设备和 cloud-tunnel 的映射关系都以“deviceName:cloud-tunnel ip”的形式记录。云端的 HTTP 客户端可以使用这个 DNS 解析,将请求发送给与目标边缘设备建立有云边通道的 cloud-tunnel。同时,如果 HTTP 客户端无法直接使用tunnel-dns 服务,也可以由 cloud-tunnel 读取这个 DNS 记录,将请求转发给真正建立有云边通道连接的 cloud-tunnel。apiVersion:v1 kind:ConfigMap metadata:nam
47、e:http-proxy namespace:kube-system 26 云边端协同的智能视频方案研究 ODCC-2023-04003 data:host:10.1.1.1 device1n /DNS 记录 2.3 edge2.3 edge-tunneltunnel 处理云端请求处理云端请求 edge-tunnel是云边通道的边端组件,负责将云端下发的请求消息转发给目标服务端进行处理。它主要包括 tunnel client 和 http client 两个模块。(1)tunnel client tunnel client 是云边通道 websocket 连接的客户端。edge-tunnel
48、启动后,它会与 cloud-tunnel 建立一条 websocket 连接,并作为云边通道的消息分发中心。根据从 cloud-tunnel 收到的 tunnel message 消息类型,它将请求分发给相应的 client 进行处理。(2)http client http client 是 edge-tunnel 的 http 客户端。当收到 cloud-tunnel 下发的 http 类型消息时,edge-tunnel 会将消息分发给 http client 进行处理。http client 会根据消息中封装的请求头、URL、查询参数、Body 等信息,重新构造一个新的 http 请求,并
49、发送给目标 http 服务端。当收到 http 响应时,http client 也会通过云边通道将其吐回给 cloud-tunnel,从而响应给云端 http 客户端。27 云边端协同的智能视频方案研究 ODCC-2023-04003 3.3.2.4 cloud3.3.2.4 cloud-tunneltunnel 路由请求实现高可用性路由请求实现高可用性 每个边缘节点都会运行一个名为 edge-tunnel 的模块,而这里的高可用性主要指 cloud-tunnel 模块。cloud-tunnel 可以在云端部署多份。在云端维护一个名为 CloudTunnel 的 configmap,cloud
50、-tunnel 启动时,都需要向 configmap 更新自己所管理的节点映射 data:node1 192.168.1.1:8999 node2 192.168.1.2:8999 多个实例共同维护 cloud-tunnel,并使用 configmap 来存储数据。当节点重新连接到 cloud-tunnel 时,数据将被更新。这样,每次访问边缘节点时,直接查询该 configmap 就可以准确路由到对应管理的 cloud-tunnel。3 3云边协同调度云边协同调度 我们希望不仅能够在边缘侧直接访问轻量化单机平台,而且能够在中心对所有单机进行统一纳管,并使用 K8s API 的方式管理这些单机
51、。因此,我们设计了一个 cloud-lite 模块,为中心提供纳管边缘单机的能力。在边缘离线的场景下,边缘控制面可以作为一个独立的系统,直接调度本地的资源,实现本地业务的运行。与此同时,当边缘设 28 云边端协同的智能视频方案研究 ODCC-2023-04003 备需要连接到中心时,可以通过中心统一管理边缘设备,实现完整全局的资源统一调度。这种模式可以保证边缘设备在离线的情况下仍然能够独立运行,并且当需要连接到中心时,可以实现资源的统一调度和管理。这种模式可以适用于一些需要实时响应的场景,例如智能制造、智能交通等。在智能制造中,边缘设备可以实时采集数据,并进行本地的处理和分析,从而实现对生产过
52、程的实时监控和调整。在智能交通中,边缘设备可以实时感知交通流量和路况,并做出相应的调度和指挥,从而实现交通的畅通和安全。因此,边缘控制面结合中心统一管理的方式,可以有效地实现边缘设备资源的调度和管理,并且可以适用于各种不同的场景。CloudLite 监听中心资源变化,通过 sync controller 云边通道主动下边缘发起更新 在 Cloudlite 架构中,为了实现对边缘单机的统一纳管和 K8s API 的管理,我们设计了一个名为 Cloudlite 的模块。该模块负责监听中心资源的变化,并通过云边通道主动下边缘发起更新。具体来说,Cloudlite 模块管理多个 K8s 资源的 con
53、troller,这些 controller 主要负责以下两个任务:(1)从边缘单机拉取资源,并同步到中心的 K8s 集群中;(2)从中心 K8s 集群中同步资源到边缘单机。其中,Cloudlite模块与边缘单机同步资源的通道是云边通道。该通道能够实时感知中心资源的变化,并将这些变化的信息主动下发到边缘单机中,从而实现对边缘资源的实时更新和同步。29 云边端协同的智能视频方案研究 ODCC-2023-04003 总的来说,Cloudlite模块的设计实现了对边缘单机的统一纳管和 K8s API 的管理,提高了 Cloudlite 架构的可靠性和效率。Cloudlite 是一个基于 Kuberne
54、tes 的云原生边缘计算框架,它提供了对边缘节点进行管理和调度的能力。在 cloudlite 中,我们需要关注 Pod、Node、Service、Endpoint、ConfigMap、Secret 六种资源,因此我们需要实现这六种资源的 control。每个单机节点 EdgeLite 连接中心 cloud-tunnel 成功时,视为纳管完成。cloud-tunnel 在中心 k8s 的 configmap 中记录纳管的节点名称。Sync controller 启动 ConfigMap Informer,监听 configmap 资源的变化。当 node-record 发生变更时,通过读取 no
55、de 记录表计算出新增和删除的节点列表,相应地启动和停止同步任务。manager是同步任务的管理器。当有新的节点纳管时,新建并启动该节点的同步任务;当节点被从中心删除时,停止并删除同步任务。syncer 是执行节点资源同步任务的模块。当启动之后,会周期性地执行同步任务,默认周期是 5min,可以参数配置。同步任务主要包括两个步骤:(1)向边缘节点下发资源,并查询全量的资源详情:EdgeLite提供批量处理资源的 http 接口。syncer 使用 tunnel-dns 记录的节点标识 node-id,通过云边通道发起 http 请求。30 云边端协同的智能视频方案研究 ODCC-2023-04
56、003(2)向中心 K8s 同步边缘节点的资源:syncer 从边缘查询到全量资源的结果后,通过遍历的方式逐个进行计算和同步。计算 除了 Sync controller 之外,还需要实现 pod、node、configmap、secret、service、endpoint 的 controller 用来完成中心资源到边缘单机的同步,这 6 种 controller 的实现方式基本是一致的,包含以下部分:Informer 监听资源的添加、更新和删除事件,并将资源的 key 值(资源 namespace+name)添加到工作队列 WorkQueue 中。syncResourceHandler 作为
57、 WorkQueue 的同步处理方式,消费并执行工作队列中的任务。syncResourceHandler 的主要工作过程如下:(1)查询中心和边缘是否存在资源。如果两者都不存在,则忽略该任务。(2)如果中心存在资源,而边缘不存在,则在边缘创建该资源。从 中 心 向 边 缘 创 建 的 资 源 都 打 上 注 解“kubernetes.io/owner.by.cloud=true”。(3)如果中心不存在资源,而边缘存在,则在边缘删除该资源。(4)如果中心和边缘都存在该资源,则需要以中心版本为主,比较资源是否发生变化,如果有则进行更新。(5)如果以上步骤在边缘执行失败,则需要将任务重新加入队列,等
58、待一段时间后重新执行同步。31 云边端协同的智能视频方案研究 ODCC-2023-04003 这里对于 Pod 和 Node 的同步需要一些特殊处理:(1)对于边缘同步到中心的 Pod,由于名称都带上了 nodeID 后缀,因此在向边缘请求时需要把后缀删除。(2)Pod 非强制删除时,Pod 会设置 DeleteTimeStamp,Pod Controller 需要判断 DeleteTimeStamp 是否为空。如果为空,则调用边缘删除 Pod 的接口,等待边缘删除 Pod 成功后,向中心回写一个强制删除 Pod 的请求。(3)Node Controller 只需要向边缘同步 Node 的更新
59、事件。当监听到 Node 删除事件时,只需要将 ConfigMap tunnel-dns 中记录的 node 删除。(4)向 EdgeLite 的请求是否需要重试,取决于请求通过云边通道代理是否成功,而不是响应码是否 200。对于集群级别的资源,只处理中心部署的资源:(1)中心有、边缘没有,在边缘创建;(2)中心没有、边缘有,(检查资源是否有使用),若没有则删除;(3)中心、边缘都有,以中心修改为准。边缘部署的资源:都不同步。Edgelite 全量同步接口:Edgelite 被纳管到中心后,向上为中心sync-controller提供同步资源接口(约定只同步pod和node),32 云边端协同
60、的智能视频方案研究 ODCC-2023-04003 同时接收中心返回的 service、configmap、namespaces 和 Secrets,并同步到本地,以完成边缘和中心的资源同步。边缘侧同步规则:(1)中心没有,边缘有,若中心创建的资源,边缘删除。(2)中心没有,边缘有,若非中心创建的资源,忽略。(3)中心有,边缘没有,在边缘创建资源(添加中心创建注解)。(4)中心有,边缘有,忽略(同名资源,中心不可修改)。(5)所有中心创建资源携带(注解kubernetes.io/owner.by.cloud=true)通过同步创建的资源均在写入前添加该注解。4 4节点分组节点分组 在传统的 K
61、8s 集群管理模式下,边缘节点 node 被视为同一层级平面,但由于资源异构、机器的运营商、云供应商不同,逻辑上自然会被划分为不同的组。对于 deployment 等资源部署,传统解决方案通过给 node 打标签、划分逻辑组,并使用 nodeSelector 或Affinity 限定部署在逻辑组中。然而,由于每个组都需要独立维护一个 deployment,因此需要大量的 YAML 文件,如果需要更新镜像地址,则需要手动更新每个所需的 deployment,管理困难且维护成本增加。33 云边端协同的智能视频方案研究 ODCC-2023-04003 原生 Kubernetes Service 的后
62、端端点扁平分布在集群中的任意节点。因此,跨不同分组节点的 Service 流量很可能会出现访问不可达或者访问效率低下的问题。有些服务我们希望每个区域中都运行一组有业务逻辑联系的服务。传统解决方案使用 DaemonSet 方式部署服务,以便每个边缘节点上均有所有服务的 Pod 副本。服务通过 localhost 访问,以便将调用链锁定在同一个节点内。以节点池的视角对不同边缘区域下的主机进行统一管理和运维,可以实现批量管理节点组内节点的 label、annotations 和 taints。通过使用新的单元化部署模型,将用户的工作负载部署在不同的节点池中,业务的实例数和版本都可以按照节点池的维度进
63、行统一管理。同时,服务闭环也可以在节点池中实现流转。CloudLite 和 Edgelite 同步网络拓扑信息,支持节点分组网络互通和流量拓扑 4.14.1 节点分组节点分组 自定义 K8s CRD 资源节点池 Nodepool,并通过指定标签来实现节点分组。随着 Kubernetes(k8s)的不断发展,自定义资源(Custom Resource Definition,CRD)已经成为 k8s 的一个重要特性。通过自定义资源,用户可以扩展 k8s 的功能,使其更加适应不同的应用场景。而在许多场景中,需要对节点进行分组管理,这就用到了自 34 云边端协同的智能视频方案研究 ODCC-2023-
64、04003 定义资源节点池 Nodepool。Nodepool 是一种用于管理节点组的新颖方法,它可以让用户根据特定的需求将节点分组,从而更好地利用和管理节点资源。在Nodepool 中,通过指定标签来实现节点的分组。用户可以为自己定义的节点池指定特定的标签,从而将具有相似属性的节点归为一类。这样的做法有助于更好地进行节点的管理、调度和扩展。Nodepool Controller 通过 Informer 机制监听 Node 和 Nodepool资源。Nodepool Controller 是 k8s 中的一个组件,它负责监听 Node和 Nodepool 资源,并帮助用户维护节点标签,保证对应
65、节点池的三类信息实时同步到 Node 上。Informer 是 k8s 中的一个机制,它可以帮助用户在不需要编写显式的 Watch API 的情况下,实现对资源的监听。Nodepool Controller 就是通过 Informer 机制来实现对 Node和 Nodepool 资源的监听的。Nodepool Handler 帮助用户维护节点标签,保证对应节点池的三类信息实时同步到 Node 上。Nodepool Handler 是 Nodepool Controller 的一个重要组件,它负责帮助用户维护节点标签,并保证对应节点池的三类信息实时同步到 Node 上。具体来说,Nodepool
66、 Handler 会根据 Nodepool 的定义和节点的标签,将节点添加或从对应的节点池中移除。此外,当节点池中的节点数量超过或不足预设阈值时,Nodepool Handler 35 云边端协同的智能视频方案研究 ODCC-2023-04003 还会自动扩展或缩减节点池的大小。4.2 4.2 节点分组网络互通节点分组网络互通 Edgelite 在纳管到 cloudlite 中心集群后,需要作为集群中的一个普通 k8s 节点使用,其中就需要 k8s 节点的容器网络能力。目前由于每个单机是作为一个独立的节点,每个节点之间的资源完全隔离,因此单机节点之间的容器网络也无法互通。为了对齐普通节点的容器
67、网络能力,我们需要打通单机节点之间的容器网络。子网分配:在目前的方案中,每个单机初始运行时使用参数“-cluster-cidr”指定容器网络的网段,由 flannel 自动划分一个子网网段,用于单机上运行 Pod 的 IP 分配。在这种情况下,每个单机可能使用的是相同的网段,也就是说不同单机上的 Pod 的 IP 可能是相同的。因此,一个想法是每个单机节点可以当作独立的集群来看待,不考虑单机的子网分配问题,而是考虑如何实现集群之间的容器网络互通。但是,目前业界实现的集群之间容器网络互通的方案不多,也不是非常现实的需求,所以暂时不考虑这种方式的实现。因此,要实现不同节点之间的容器网络互通,就需要
68、确保不同节点上的 Pod IP 在集群内是全局唯一的,这就需要为集群内的每个节点分配一个不冲突的子网网段。分配子网的策略可以自定义,也可以使用 k8s 默认的策略。要实现节点之间容器网络互通,基于 flannel 方案除了要求 pod 36 云边端协同的智能视频方案研究 ODCC-2023-04003 IP 唯一,还要求集群内的所有 node 对于 flannel 是可见的,因为flannel 需要根据 node 的公网 IP、以及子网网段建立路由规则,这些信息都记录在 node 资源中。因此,只要将集群内的节点信息同步给单机上的flannel,在节点之间物理网络联通的前提下,就能实现容器网络
69、的互通。这个同步过程由cloud-lite的synccontroller负责完成,sync controller 会调用 edgelite 的接口,向下同步集群级别的资源。edgelite 通过接口同步到的 node 列表,需要与本地的node 列表进行比对。4.3 4.3 流量分组流量分组 每个 EdgeLite 节点的 Service 流量访问是通过 kube-proxy(目前集成在 EdgeLite 中)控制的,kube-proxy 会根据每个 Service 的Endpoints 构建对 Service 实例的 iptables/ipvs 转发规则,因此控制kube-proxy 获取的
70、Endpoints 信息,就可以限制每个EdgeLite 节点对服务实例的访问。我们可以采用在云端 Cloudlite 组件中对Endpoints 进行控制,Endpoints 同步逻辑还是沿用目前的 Service Controller 同步实现,主要在同步过程中对 Endpoints 进行过滤处理。过滤流程:(1)监听 Endpoints 的变化事件(ADD/UPDATE/DELETE);(2)通 过Endpoints=Service=DeployGroup=37 云边端协同的智能视频方案研究 ODCC-2023-04003 NodePools;(3)遍历当前 Cloudlite 的所有边
71、端 EdgeLite 连接;(4)判断当前 EdgeLite 所在连接是否在 NodePool 中;(5)如果是,则过滤出 Endpoints 在这个 NodePool 中的后端Pod(即设置 Endpoints 的 subsets 后端列表),调用EdgeLite 创建或者更新 Endpoints。总之,通过在云端 Cloudlite 组件中对 Endpoints 进行控制,可以实现对每个 EdgeLite 节点的 Service 流量访问的限制。过滤流程主要是通过监听 Endpoints 的变化事件,然后通过 Endpoints=Service=DeployGroup=NodePools
72、的路径,判断当前 EdgeLite所在连接是否在 NodePool 中,如果是,则过滤出 Endpoints 在这个NodePool中的后端Pod,最后调用EdgeLite创建或者更新Endpoints。这样可以实现对不同 NodePool 的 Endpoints 进行分别管理,提高了管理的灵活性和可扩展性。(四)(四)算法维度算法维度 1 1智能视频服务架构智能视频服务架构 智能视频处理涉及视频编解码及算法识别,这部分工作对算力的有很高的要求。如果将这部分工作完全放在云端进行处理,那么云端服务将除了需要提供极大的算力支持,还需要考虑网络传输延迟及带宽费用等高昂的成本。为此,我们充分利用了边缘
73、计算的能 38 云边端协同的智能视频方案研究 ODCC-2023-04003 力,将任务分解并下放到边缘,最终实现在边缘节点上面的设计了一套智能视频推理服务。如上图所示,这套智能视频推理服务主要包括以下 4 个模块:(1)视频处理模块:提供保存、抽帧、渲染合成等常见的视频处理能力。(2)算法推理模块:提供目标检测、跟踪、人脸识别等算法推理能力(3)事件管理模块:用于接收来自算法模块的事件信息,并且提供事件查询,及第三方转发的能力。(4)Web 交互模块:为用户提供 Web 平台,控制视频推理任务,并查看事件结果。使用场景如下:(1)用户在 Web 平台上面设置了要识别的视频地址和算法。(2)视
74、频处理模块就会从视频地址获取视频,经过解码后,将抽帧出来的图片发给算法模块进行识别。算法模块识别之后,再把 39 云边端协同的智能视频方案研究 ODCC-2023-04003 图片及识别结果发给事件管理模块。(3)用户可以通过 Web 平台,在事件管理模块上查询视频的推理结果。1.1 1.1 算法推理模块算法推理模块 EdgeInfer服务是当前算法推理模块最主要的服务。该服务提供了全面的工具集,支持用户自定义模型和算法,以适应不同的推理应用场景。其主要特点包括:(1)实时性:使用了高性能的调度框架,可以快速同步地返回推理结果。(2)可配置性:服务内部支持自定义流水线,允许用户根据自己的需求,
75、自行配置需要的处理流程,包括:图像预处理、推理、事件发送等逻辑。进一步地,EdgeInfer 支持结合多个算法的推理结果,实现更复杂的推理能力。这样可以帮助用户快速构建和部署各种算法应用。(3)跨平台性:本服务支持多种不同的硬件平台,包括:Nvidia Xavier/Orin、算能、瑞芯微、昆仑芯等,以便用户能够方便地将其部署到不同的应用场景中。(4)多协议接入:EdgeInfer 支持 http 和 baidu-rpc 协议进行远程算法调用,也提供特定格式的 sdk 接口,用于嵌入式开发。40 云边端协同的智能视频方案研究 ODCC-2023-04003 EdgeInfer 内部主要的处理流
76、程如下:(1)接收请求:从 HTTP、RPC 等协议中获取要识别的图片。(2)图片解码:将 jpeg,png 等压缩后的图片解码成 RGB 格式的图片。(3)图片预处理:将原始图片并转化成推理模型需要的格式。这里包括:图像分辨率缩放、图像颜色增强等操作。(4)模型推理:调用 TensorRT、RKNN 等算法模型对图像进行推理分析,并获得目标检测、跟踪等识别结果。(5)算法后处理:根据用户需求,补全模型推理无法完成的工作,例如:格式转换、置信度过滤、特征匹配等。(6)响应请求:将推理结果通过 HTTP、RPC 等协议返回给用户。上面只是最简单的推理流程。在实际业务中,我们会遇到更加复杂的推理逻
77、辑:(1)模型并发推理 例如:在一张图片内指定一个入侵区域,在这区域内如果发现有车辆或行人,就会判定为入侵并触发告警。车辆检测和行人检测是互相独立运行的,如果进行并发处理,那可以减少推理速度。41 云边端协同的智能视频方案研究 ODCC-2023-04003 (2)模型串行推理 例如:识别图片里面所有员工。人脸特征提取模型,要求先用其他模型提取出人脸位置,再取出对应位置的人脸作为输入提取特征。这时就必须将多个模型进行串行推理,面对逐渐复杂的处理流程,EdgeInfer提供了一整套框架,方便开发者进行开发和维护。这套框架主要包括以下结构:(1)将模型推理、前后处理等逻辑拆解成互相独立的处理器。(
78、2)使用有向图将处理器连接在一起,构建出一套复杂的处理流程。(3)使用流水线调度策略:基于消息队列,对数据有序管理,实现高并发处理。42 云边端协同的智能视频方案研究 ODCC-2023-04003 EdgeInfer以处理器为器官,有向图为骨架,流水线为血管,构成一副可高性能运转的躯体,以快速处理复杂的业务需求。1.2 1.2 处理器插件化能力处理器插件化能力 作为 EdgeInfer 最重要的器官,处理器用于处理不同的工作,类型一个函数,对输入数据进行处理,然后输出结果。其基本包括以下类型:(1)图片格式转换:将 jpeg/png 图片转换成 RGB 格式,也包括将图像分辨率缩放、图像颜色
79、增强等操作。常用于推理前处理。(2)模型推理:对图片进行模型推理(3)逻辑封装:根据模型推理结果,实现用户需要的业务功能。常用于推理后处理。处理器需要处理复杂的功能,因此其需要有一个固定且较为宽松的输入和输出格式。如下面所示:每个任务都是一个字典型的结构,键是处理器的名字,值是处 43 云边端协同的智能视频方案研究 ODCC-2023-04003 理器的输出结果。每个处理器都可以获取得到当前任务的全部信息,在处理完之后,将自己的结果写入到任务中。在保证了统一的输入输出格式之后,还可以进一步地封装成动态插件。处理器插件化可以带来如下好处:1)处理器插件可以随意替换。根据不同的硬件环境,项目需求,
80、每个处理器都可能会有多种实现方式,此时只要切换不同的插件参数,就可以替换处理器的能力。2)动态插件可以扩展功能,而不需要修改主干代码。只要把逻辑封装成处理器插件,在接入到 EdgeInfer 之后,就可以运行这部分的代码,完成想要的功能。3)在编译时不需要考虑其他处理器。例如:编译图片解码处理器插件,不需要有算法模型推理的编译环境。1.3 1.3 流水线调度能力流水线调度能力 在提出处理器概念之后,接下来,就是怎么去执行他们。我们可以编写一个函数F,在里面按顺序调用三个处理器,对于大多数开发者来说都是容易的事。但处理器有时受到底层实现的影 44 云边端协同的智能视频方案研究 ODCC-2023
81、-04003 响,在处理任务时可能会有一些约束,例如:例如中间有一些处理器只能同时处理一个任务,那大多数人都会直接在函数 F 里面加上互斥锁。这时就变成如下的串行调度模式。这种模式处理逻辑简单,但因为等待解锁会有任务执行时间长的问题,容易堆积任务,严重时甚至会打满内存而崩溃。更好的方案是,我们可以将 CPU 的流水线调度技术,适用在 EdgeInfer 服务上。如下图:因为所有处理器都是互相解耦的,所以允许不同的处理器进行并行处理,极大地缩短串行处理时间。同时,考虑到有些处理器无法同时处理多个任务,所以需要在每一个处理器前面都加一个消息队列,如下图:45 云边端协同的智能视频方案研究 ODCC
82、-2023-04003 不论来了多少个任务,都会按顺序放入队列中,再慢慢被处理器进行消费。当如果消费速度小于添加速度时,会导致任务队列被打满。为避免这种情况,我们还可以对任务队列加一些处理策略,例如:按先入先出的策略终止未完成任务,或者增加处理器提高消费速度。流水线处理技术最终带来了以下优点:1)提高运算速度:将一个复杂的任务,分解成多个子任务,在同一个时间内执行多个操作,从而提高了运算速度。2)并行处理:可以通过并行处理,在每个时间步骤中同时进行多个操作,从而提高了计算效率。3)灵活性:可以动态更改并发线程的数量,合理分配硬件资源,提高计算能力,以适应不同的任务需求,具有较强的灵活性。1.4
83、 1.4 有向图表示能力有向图表示能力 在实际业务中,我们会遇到复杂的处理逻辑,要求处理好:串 46 云边端协同的智能视频方案研究 ODCC-2023-04003 行和并行需求,同步和异步限制。要写出高效、简洁的代码,非常考验开发者。此外,开发者可能为了追求高效率,代码逻辑过于特殊化,可复用性差,无法适用于其他项目。EdgeInfer使用了有向图来描述业务的处理逻辑。其中,有向图的节点就是一个个处理器,每条有向边表示了处理器的依赖关系。如上图所示,基于有向图,我们可以非常直观地看出员工着装检测算法的处理逻辑,这远比一堆代码更容易理解。接下来,我们就需要使用图式计算引擎来执行任务。这部分需要引入
84、以下组件:组件名组件名 作用作用 Source 数据源:按一定规律产生任务。比如:从 Http 协议接口接收到请求。Graph 流程图:将任务放到需要执行的处理器中,或者进行销毁。Queue 缓存队列:每个处理器的任务缓存队列。Processor 处理器:负责处理任务。比如:图片格式转换、推理、事件发送 这些组件的交互逻辑如下图:47 云边端协同的智能视频方案研究 ODCC-2023-04003 (1)数据源(Source),实时地从 Http 或者 Rtsp 协议读取到图片,并且交给有向图(Graph)决定去向。(2)有向图(Graph)会根据当前任务的状态,选择对应的处理器(Process
85、or),并且放入对应的任务队列(Queue)。(3)处理器会实时从任务队列里获取任务,再进行执行。(4)处理器处理完任务后,再次交给有向图(Graph)决定去向。(5)有向图(Graph)如果判断当前任务已经执行完时,会触发析构方法,完成结束任务。由上面流程可看出,有向图处理带来了以下优点:1)灵活性和可扩展性:可以随着应用需求的变化而动态地添加、删除顶点和边,具有较强的灵活性和可扩展性。2)易于可视化:可以用图形方式表示,使其易于理解和可视化,从而方便用户理解和分析计算过程和结果。48 云边端协同的智能视频方案研究 ODCC-2023-04003 3)处理能力强:表示复杂的依赖关系和计算流程
86、,从而可以支持各种计算任务,如串并行、同异步。4)数据交互高效:在同一个进程中,根据边的属性进行数据交互,从而实现高效的数据传输。2 2弹性调度系统弹性调度系统 除了直接在计算节点上部署算法外,端边云协同的智能视频解决方案还提供应用弹性调度能力:根据实际的 QPS 使用情况和负载情况动态调整应用的部署,在算力资源紧张的情况下,通过减少低优应用的副本数来腾出可用资源给高优应用来使用,该能力同样可使用于分组管理模式下的计算节点。49 云边端协同的智能视频方案研究 ODCC-2023-04003 2.1 2.1 系统架构系统架构 图 3.7 弹性调度系统架构 如上图所示,弹性调度系统主要由云边数据通
87、道、弹性计算调度层、统一网关等几个核心模块组成:云边数据通道:实现中心与边缘之间的数据传输,云边数据同步:根据接收来自中心的消息执行对应的操作,如创建应用部署;边侧统计数据通过通道上报到中心,由中心进行信息汇聚。50 云边端协同的智能视频方案研究 ODCC-2023-04003 弹性计算调度层:核心模块,旨在实现根据应用负载动态调整部署,确保在有限资源下最大化完成利用算力,主要实现以下功能:HPA 弹性伸缩、应用动态启停、异构加速卡的底层支持、提供 GPU 算力使用情况、应用部署情况的接口、优先级部署。该项目主要通过在此模块定义了一个 CRD 结构体(命名为 AIDeployment)来抽象表
88、达应用,记录调度模式、优先级、应用工作负载等信息,同时引入节点组能力实现云原生智能应用分组管理能力。统一网关:基于 envoy+xds 实现,网关是所有算法的访问入口,即每个应用都经过网关。网关可以根据预设的策略来完成流量调度和输入输出转换。同时每个应用的请求访问数据将会缓存下来,可用于健康监控,以及 qps 的计算,从而支持弹性计算调度层的算法调度逻辑处理。service-topology组件会为 xds 组件提供每个应用在当前节点分组下实际Endpoint 入口,这些信息再由 xds 同步回 envoy 实现代理和负载能力。2.2 2.2 系统实现系统实现 节点组粒度调度与整个集群调度的不
89、同之处在于,不同节点组的运行情况是完全隔离的,同时应用的实际访问情况也会受到一些外在因素的影响,比如地域,这些将会导致各个应用在不同节点池里的实际访问情况各不相同。有些应用在某节点池甚至可能完全没 51 云边端协同的智能视频方案研究 ODCC-2023-04003 有访问流量,或是被其他更高优的应用占去所需部署资源而导致完全没有实例在运行。(1)AIDeployment CRD 本方案定义了新 的 CRD 资源(AIDeployment),用于调度和部署应用。该 CRD 继承了 Deployment 资源的格式,并在 spec 里增加了节点部署组、应用优先级、调度策略、HPA 弹性伸缩所需 Q
90、PS 阈值和最大最小副本数、网关最大连接数等内容。AIDeployment 控制器,主要会监听 AIDeployment 的创建、更新、删除等事件,来管理算法应用所需的 Deployment、Service、HPA 资源的部署、更新和删除。此外,本方案还定义了关于节点组的 CRD 资源(NodePool)。该资源记录了节点组及其关联的一系列的边缘节点间的关系。而节点部署组则是由多个节点组组成。AIDeployment 控制器会监听NodePool 资源对象的变化,当监听到 AIDeployment 的创建后,控制器将会根据 AIDeployment 里的节点部署组信息,为每个节点组都生成实际要
91、部署 yaml 文件,yaml 里包含 Deployment、HPA 资源,最终控制器还会额外部署一个 service 资源,关联上述的 Deployment。不管有多少节点组,Service 也只会部署一份。service-topology 组件提供过滤掉非该节点组的 endpoint 列表。当 xDS 连接该 service-topology 组件后,网关便只会获取到该节点组对应的endpoint 数据,从而保证应用流量只会在同一个节点组里流入流出。52 云边端协同的智能视频方案研究 ODCC-2023-04003(2 2)弹性调度)弹性调度 由于该系统调度部署的应用,需要统一使用网关代理
92、访问。在访问网关时,需要在 host 设置上要访问的应用名和 namespace:-H host:.,则网关将会将请求代理到对应的应用实例。访问后,该节点组的应用访问次数将会加1,该值将会用于计算QPS,以便更新调度。应用的实际 QPS 指标数据是通过通过网关的metrics接口统计得到的。由于所有Deployment共用一个service,因此在创建 HPA 时,需要在 selector 里添加节点池信息,并在统一网关数据拉取时对数据来源加上节点池标记,以便区分应用在各节点池的实际 QPS 指标。每个节点池对应的 Deployment 实际的副本数将会由 HPA 根据实际 QPS 情况来调整
93、,比如当应用 A 的 QPS 阈值设置为 10 时,而实际QPS 为 100+,则将会调整应用A 的副本数为 10,而当实际 QPS 降低后,副本数也会缩回到相应的数值。这里使用的是 kubernetes 原生的扩缩容机制,期望副本数的计算公式是:期望预期副本数=ceil当前副本数*(当前指标/预期指标),计算出的期望副本数的变量需要大于10%,否则将维持原值不变,减少副本数波动。(3 3)资源监控)资源监控 资源监控模块会定时监控智能应用在各个节点池部署的 53 云边端协同的智能视频方案研究 ODCC-2023-04003 Deployment 的运行情况,并将其告知给流程调度模块,最后由流
94、程调度模块统一更新智能应用的对应的运行状态 status.state,以及在 status.nodePoolStatuses 参数里更新各节点组下 Deployment 运行状态。(4 4)流程调度)流程调度 在应用运行过程中,随着 QPS 的不断提高,应用实例也会跟着增加,这可能会导致节点池资源不足,部分实例无法正常启动。此时资源监控模块将会监听到该节点池出现的 FailedScheduling 的事件,并将该事件告知流程调度模块。流程调度模块收到通知后,将会启动低优任务抢占的工作:高级优先级任务发现算力不足可以抢占低级优先级和更低的高级优先级。低级优先级不能抢占其他任务。此时被抢占的低优先
95、级的 Deployment 可能会被自动停掉,而一旦当前高优应用 QPS 开始下降,实例数也跟着减少后,节点组可用资源又变多起来后,低优应用将开始尝试恢复。一旦节点组的可用资源充足,流程调度模块将会按优先级从大到小的顺序开始恢复被抢占的应用。流程调度模块的具体实现如下图所示:54 云边端协同的智能视频方案研究 ODCC-2023-04003 图 3.8 流程调度工作流程 组件间的工作流程如下图所示:图 3.9 工作流程图(1)流程调度模块监听 AIDeployment CRD,转化数据结构并存入数据库中(2)动态启停模块根据 NodePool 列表部署智能应用对应的资 55 云边端协同的智能视
96、频方案研究 ODCC-2023-04003 源(3)流程调度模块根据优先级、资源情况控制该应用在节点池上是否需要启停(4)动态启停模块则根据流程调度的信号进行智能应用的启动和关闭(5)应用的实际副本数受 QPS 影响,由 HPA 模块进行弹性伸缩(6)应用副本数的变化导致资源使用的变化将被资源监控模块监听,并触发对应的资源事件(7)流程调度模块接收到资源变化信号,重新判断应用是否需要启停(五)(五)视频维度视频维度 1 1端侧数据采集技术端侧数据采集技术 端侧数据采集技术是指采集算法推理所需的各种数据,以及将算法的输出结果进行收集和存储的技术。该技术包括图片、音视频以及结构化数据、元数据等各种
97、形式数据文件的搜集整理,分类归集,存储传输,以及可扩展的多维度数据汇聚分析等功能。基于以上功能,数据采集可以分为三个功能模块:图片和音视频数据原始数据采集,作为算法输入数据和事件 56 云边端协同的智能视频方案研究 ODCC-2023-04003 存证数据,支持主流图片编码格式和音视频格式;结构化数据采集,主要是指以上原始数据的元数据,推理识别结果存证数据等,由主流数据库或文件系统进行分类、处理和存储;数据传输,通过引入消息队列,传输保护等,确保数据能够上行安全及时的传输到边侧或云侧,进行集中化处理。通过对多种形式数据的搜集保存,为算法推理、结果存证、数据展示分析等提供基础能力支撑,同时通数据
98、云边端归集可以支持算法迭代和升级,不断优化和改进算法,提高算法的准确性和效率,从而支持更加复杂和精细的算法模型。2 2端侧推理任务平台端侧推理任务平台 端侧推理任务平台是指工作在端侧硬件上,主要功能为绑定视 57 云边端协同的智能视频方案研究 ODCC-2023-04003 频与算法,设定任务规则,生成算法任务的核心平台能力。该平台通过提供 API 接口及 UI 界面等方式,提供端侧核心功能的入口,可以实现推理任务的配置展示和下发。主要的框架如图:该平台能力主要包括以下几个模块:视频的感知获取,支持国标或 ONVIF 标准的视频设备的发现,主流视频格式的视频流接入和视频流展示;算法能力的感知获
99、取,主要是指算法能力的注册和发现,算法参数的声明和可配置;相关规则的绑定和参数的设定下发,主要是指视频流和算法能力的绑定,以及绑定中需要设定的视频参数和算法参数;算法任务的启动和调度,是指启动相关的算法推理任务,并按照设定的参数和软硬件环境,资源限定等外部条件,对这些任务进行编排调度,实现潮汐算力;58 云边端协同的智能视频方案研究 ODCC-2023-04003 端侧结果的展示,是指在端侧硬件平台上,将算法的识别结果通过把结构化数据,元数据等单独或与图片、视频流数据等混合在一起,进行直观展示。3 3边侧端数据接入、边侧端数据接入、AIAI 分析和关键存证数据分析和关键存证数据 边侧端数据接入
100、、AI 分析和关键存证数据是指从端侧采集数据,传输到边缘计算节点进行初步处理,进行 AI 分析,端边侧联合推理分析,并将算法结果存储分析存证的核心关键技术,其具有易运维管理、低成本、低延迟、可利旧等特点。系统结构如图:其中:端数据接入可以通过端侧主动推送、或边侧拉取的方式进行,数据形式包含图片、音视频数据和实时流,结构化数据、时序数据等,数据具有数据海量、写多读少、时序写,实时读,时效性、实时性等特点。59 云边端协同的智能视频方案研究 ODCC-2023-04003 AI 分析能力是指封装算子原子能力如数据预处理、模型训练、推理识别等,形成业务逻辑,支撑 AI 应用。在 AI 应用中,需要对
101、端侧数据进行统一 AI 推理识别,识别任务调度,能力动态负载均衡扩缩容等,通过端边侧联合的 AI 分析能力,可以实现轻量分析放端侧,重量分析放云边端,对海量数据的采集搜集,快速处理和分析,提高业务效率和准确。关键存证数据用于将上述结果进行在边侧集中式的存储分析和展示。存证数据包含多种消息处理和数据库技术,如消息队列,关系型数据库、非关系型数据库、分布式文件系统,对象存储等,可以确保数据的安全性和完整性,以确保数据可以快速存储和分析。此外,存证数据还具备数据聚合分析技术,如数据挖掘、数据仓库、数据湖等,以实现对数据的全面多维度的分析和管理,多维度展示。(六)(六)安全相关安全相关 1 1容器安全
102、容器安全 基于云原生 k8s 应用的边缘计算容器安全方案:在边缘计算场景中,容器安全是一个非常重要的问题。由于边缘计算的环境相对较为复杂,因此需要采取一些特殊的措施来确保容器的安全性。以下是基于云原生 k8s 应用的边缘计算容器安全方案的几个方面:60 云边端协同的智能视频方案研究 ODCC-2023-04003(1)使用可靠的镜像仓库:在边缘计算环境中,由于网络带宽和延迟等问题,重新下载镜像仓库中的所有镜像可能非常耗时,因此建议使用可靠的镜像仓库,以确保镜像的安全性和可用性,同时基础镜像内置在本地可以加速镜像的启动。(2)限制容器的权限:容器的权限应该被限制在最低权限级别,以避免容器内的应用
103、程序或用户拥有过多的权限。(3)使用自签名证书:在边缘计算环境中,建议使用自签名证书来验证容器的身份和完整性。我们通过在容器中安装自签名证书来实现。(4)部署容器网络:容器网络是一种将容器与外部网络隔离开的技术。在边缘计算环境中,建议使用容器网络来限制容器的网络访问权限,并避免容器之间的互相访问。(5)监控和日志记录:监控和日志记录是确保容器安全性的重要组成部分。我们使用 Prometheus 和 EFK 等工具来监控容器的性能和日志,以便及时发现并解决问题。(6)强化准入和退出机制:在边缘计算环境中,应该建立严格的准入和退出机制,确保容器在进入和退出环境时都经过安 全 检 查 和 认 证。这
104、 可 以 通 过 使 用 Kubernetes 的 admission controller 或自定义准入机制来实现。(7)利用容器安全扫描工具:使用容器安全扫描工具可以帮助发现容器中的潜在漏洞和风险。61 云边端协同的智能视频方案研究 ODCC-2023-04003 综上所述,基于云原生 k8s 应用的边缘计算容器安全方案应该从多个方面来确保容器的安全性和可用性,包括使用可靠的镜像仓库、限制容器的权限、使用自签名证书、部署容器网络、监控和日志记录、强化准入和退出机制、利用容器安全扫描工具、实施容器安全培训和意识、定期审计和更新以及建立应急响应机制等方面。2 2盒子鉴权盒子鉴权 在当今的数字化
105、时代,鉴权加密方案是保护边端固件和应用的重要手段之一。本文会部署一套边缘鉴权服务器实现边缘节点的鉴权和密钥托管能力,可用于确保设备运行的软件组件是合法的和未被篡改的。在该鉴权加密方案中,中心会为可信的边缘盒子进行预授权操作。当边缘设备需要部署应用时,中心后台服务重新更新预授权信息,并下发命令使边缘鉴权服务器重新获取鉴权信息,包含包括授权应用,授权有效期,授权应用所绑定的密钥等信息。边缘部署的应用组件集成了鉴权SDK,会在启动时向边缘鉴权服务器发送授权应用名申请验证,并由该服务器验证器授权的合法性和有效性。仅当验证通过后,应用组件才能正常运行。组件与该服务器之间的通信采用了强大的加密算法和非对称
106、密钥技术,确保了授权信息的安全性和完整性,防止信息被篡改或盗用。同时鉴权服务器还提供以下能力:62 云边端协同的智能视频方案研究 ODCC-2023-04003(1)提供的接口包括获取授权信息、验证授权信息、设置环境变量等,用于实现边缘设备的鉴权认证和管理。(2)提供日志记录和审计功能,可以记录边缘设备的操作和授权使用情况,确保设备和应用的合规性。(3)提供密钥托管功能,维护应用与相关密钥的关系。上述鉴权加密方案为边缘设备的软件组件提供了安全、可靠、高效的鉴权认证和管理功能,保障了设备运行的合法性和安全性。3 3mtlsmtls 证书证书 云边通讯均采用 MTLS 证书加密。对于边缘使用的 M
107、TLS 证书,本方案采用基于 FUSE 的解密文件系统对证书额外保护。边缘的每个证书都会使用密钥进行加密,加密后的文件会存放在边缘主机的指定的一个加密数据目录里。同时,这些密钥也会托管在 3.6.2 所描述的鉴权服务器里,并关联指定的一些业务应用,限制业务程序使用。当边缘主机安装的解密文件系统启动后,会将上述加密数据目录挂载为另一解密数据目录。业务程序对解密数据目录的 IO 请求,都会转发到解密文件系统里,由该系统进行解析。在解密文件系统打开文件请求前,会先向鉴权服务器验证业务程序是否可信,以及获取解密密钥,最终将解析后的数据返回给业务程序。对于可信进程来说,对解密文件系统的文件的读操作,读取
108、的 63 云边端协同的智能视频方案研究 ODCC-2023-04003 是明文,而对于非可信的进程,读取的则是密文。基于该解密文件系统,可以有效的在 Linux 系统中对文件进行加密和解密,并通过验证进程和索要密钥等方式来保护文件的安全性,从而为云边通讯提供了安全性保障。(七)(七)硬件平台支持技术硬件平台支持技术 硬件平台支持技术是保证云边端协同的智能视频方案能够高效运行的基础技术。该技术包括 CPU、GPU、FPGA 等硬件平台支持和优化技术,可以提高计算资源的利用效率和处理能力。同时,还包括硬件设备的稳定性、可靠性等技术,以确保整个系统的稳定性和可靠性。1 1云边协同硬件服务器介绍云边协
109、同硬件服务器介绍 随着“云-边-端”架构的快速发展,算力需要下沉到边缘侧来满足边缘对日益增长的算力需求,特别是对实时数据的处理。同时,边缘侧算力系统需要和云算力系统保持协同工作,从而可以实现各司其职,满足不同场景的需求。尽管云和边缘侧对算力的需求相同,但是由于各自所处环境也不相同。云一般采用大型数据中心来实现,处理的是巨型同构数据,因此云服务器的架构大体相同,数量众多,但是种类较少,可以快速批量生产。边缘侧的应用场景五花八门,少量多样,且所处环境恶劣,空间有限,需要针对边缘侧服务器进行特别设计。64 云边端协同的智能视频方案研究 ODCC-2023-04003 1.11.1 系统架构系统架构
110、针对云与边各自不同的特点,硬件模块化设计是一种很好地解决方案。工业富联基于ODCC-2021-04003-边缘计算小型化边缘服务器系统参考架构及技术规范规范要求进行设计,采用深度模块化架构,深度解耦计算模块和 IO 模块,实现计算模块标准化,满足不同场景的模块复用,IO 模块差异化,快速满足不同场景的定制化需求。计算模块 PCB 尺寸满足 220mm x 200mm 要求,支持上下堆叠的单/双路服务器主板设计,具有良好的可扩展性和配置灵活性,如图 3.10 所示。图 3.10 模块化计算架构示意图 以计算模块为核心,根据不同的应用场景,可以快速满足从数据中心到边缘的模块复用,如图 3.11 所
111、示。65 云边端协同的智能视频方案研究 ODCC-2023-04003 图 3.11 模块化服务器架构:满足从数据中心到边缘的模块复用 1.2 1.2 高性能室内云边服务器高性能室内云边服务器 针对室内边缘视频技术,工业富联基于模块化服务器架构概念,采用标准 2U 机构式短机箱服务器设计高性能室内云边服务器。机箱尺寸 481.6mm x 450mm x 87mm(W x L x H),采用 Intel 第四代至强可扩展处理器设计,最大支持一颗 CPU,最高可支持 TDP 250W,8 通道 8 DDR5 DIMM。计算节点和 I/O 节点深度解耦,采用高速连接器接口实现 IO 扩展,支持 80
112、L PCIe Gen5 总线。支持可插拔 BMC 管理模组,轻松实现灵活复用。系统支持 4 个 FHFL PCIe 扩展卡,可以插多路视频卡和网卡,也可以接 GPGPU 卡,快速进行视频数据传输与加速处理,最多支持 4 个 NVMe SSD,为视频处理提供高效存储。如图 3.12 所示。66 云边端协同的智能视频方案研究 ODCC-2023-04003 图 3.12 室内高性能云边服务器实物图 为支持无线视频技术,室内云边服务器可选内置 WIFI 和 4G 无线模组,支持 MEC 功能,如图 3.13 所示。图 3.13 支持 MEC 高性能室内云边服务器爆炸图 67 云边端协同的智能视频方案
113、研究 ODCC-2023-04003 1.3 1.3 高性能存储云边服务器高性能存储云边服务器 视频流数据往往需要实时存储。工业富联通过模块复用,基于Intel 第四代至强可扩展处理器设计,采用标准 2U 机构式短机箱服务器设计满足云边协同的高性能存储云边服务器。机箱尺寸481.6mm x 450mm x 87mm(W x L x H),计算节点和 I/O 节点深度解耦,采用高速连接器接口实现 IO 和 CPU 扩展,根据需要可以实现 1S 或者1S+1S 计算模组。最高可支持 CPU TDP 225W,16 通道 16 DDR5 DIMM。支持可插拔 BMC 管理模组,轻松实现灵活复用。系统
114、支持 2 个 LP PCIe 扩展卡,可以插多路视频卡和网卡,快速进行视频数据传输与处理。采用 12 个 NVMe 全闪存储,为视频数据提供高效存储。存储采用 4NVMe 模块实现,可根据具体的应用场景按需安装相应的存储模块,如图 3.14 所示。图 3.14 高性能存储云边服务器实物图 高性能存储云边服务器爆炸图如图 3.15 所示。68 云边端协同的智能视频方案研究 ODCC-2023-04003 图 3.15 高性能存储云边服务器爆炸图 1.4 1.4 室外高性能云边服务器室外高性能云边服务器 边缘视频技术除了在室内场景被应用之外,在室外场景也被广泛使用,比如智能交通、智慧灯杆、智能驾驶
115、等。相比于室内场景,室外场景更加恶劣,包括宽温高湿、粉尘、盐雾等各种情形都有可能发生。工业富联针对室外边缘场景的特点,采用模块复用的概念,基于 Intel 第四代至强可扩展处理器设计相应的高性能室外云边服务器,采用外机箱加内机箱的模式,实现算力提升的同时,满足 IP65的要求。其中,外机箱尺寸:770mm x 530mm x 190mm(W x L x H),内机箱尺寸:360mm x 450mm x87mm(W x L x H)。如图 3.16 所示。69 云边端协同的智能视频方案研究 ODCC-2023-04003 图 3.16 室外高性能云边服务器实物图(内机箱(左)、外机箱(右)计算节
116、点和 I/O 节点深度解耦,采用高速连接器接口实现 IO 扩展。最高可支持 CPU TDP 165W,8 通道 8 DDR5 DIMM。支持可插拔BMC 管理模组,轻松实现灵活复用。系统支持 1 个 LP PCIe 扩展卡,支持 T4 GPGPU 加速,支持 1 个 OCP 3.0 网卡,快速进行视频数据传输,支持 8 口 RJ 端口+2x2 光口,可以接收多路视频信号。支持5G/WIFI 等无线网路,支持 GPS 精准授时和定位,满足 MEC 功能,如图 3.17 所示。70 云边端协同的智能视频方案研究 ODCC-2023-04003 图 3.17 室外高性能云边服务器内机箱爆炸图 外机箱
117、主要用于 IP65 防护以及防尘防盐雾等功能,同时需要针对电源进行防雷防浪涌等设计,因此需要采用专门设计的PDU。具体如图 3.18 所示。图 3.18 室外高性能云边服务器外机箱爆炸图 71 云边端协同的智能视频方案研究 ODCC-2023-04003 1.5 1.5 浸没式单相液冷边缘服务器浸没式单相液冷边缘服务器 当边缘算力需求进一步提升时,或者在特别恶劣的环境,采用风冷边缘服务器将不再受欢迎。一是因为风扇属于易损元件,二是噪声问题,三是可维护性等问题。因此,采用浸没式单相液冷边缘服务器可以有效解决此问题。浸没式液冷边缘服务器系统采用自然对流为主,水冷散热为辅的方式进行散热,不需要额外配
118、置庞大的冷却塔或干冷机进行散热,可以有效节省部署空间,同时具备 IP65 防护能力、更强的恒温控制能力、更低的维护需求、提升能效。采用环保的介电液体减少对环境的污染,满足多元化系统部署的场景。针对高功耗元件,如 CPU等,采用水冷管散热,可以有效提升系统整体散热效能。图 3.19 所示为工业富联设计的浸没式单相液冷边缘服务器。图 3.19 浸没式单相液冷边缘服务器实物图(外机箱(右)、内机箱(左)72 云边端协同的智能视频方案研究 ODCC-2023-04003 浸没式单相液冷边缘服务器系统的设计目标是提供 1000W 的散热能力,采用外机箱加内机箱结合设计。外机箱尺寸为 1218.3mm x
119、 730mm x 390mm,内机箱尺寸为 481.6mm x 450mm x 870mm。在内机箱内采用模块复用的概念,基于 Intel 第四代至强可扩展处理器,最大支持 1 个 CPU,TDP 为 165W,最大支持两张 A100 GPGPU,支持 8通道 8 个 DDR5 DIMM,采用独立的 BMC 管理模块,同时支持 4 个 SATA SSD。内机箱所承载的边缘服务器系统放置在密闭的外机箱腔体内,通过对流的方式将组件的热量传递至液体,液体再将其导到腔体表面的鳍片进行系统散热,如图 3.20 所示。图 3.20 浸没式单相液冷边缘服务器散热原理示意图 为了更有效地增加系统内对流,提升系
120、统与环境间的热传能力,73 云边端协同的智能视频方案研究 ODCC-2023-04003 在系统内部将高功率或低温度规范的组件放置在底部,低功率或高温度规范的组件放置在顶部来进行布局。图 3.21 优化摆位实现最佳散热效果示意图 为了进一步加强边缘侧算力来处理视频 AI 技术,需要进一步提升边缘服务器的算力密度。工业富联设计的 2U 边缘液冷系统采用集成冷却液体对空气散热的 CDU 架构,满足最小空间要求和独立运转需求,同时可以最大支持 3KW,支持 1U 到 2U 标准“21”和“19”服务器形态,有效满足高性能边缘的应用场景,如图 3.22 所示。74 云边端协同的智能视频方案研究 ODC
121、C-2023-04003 图 3.22 2U 边缘液冷系统实物外观图 2U 边缘液冷系统具有相同的均匀流场设计和模块化可扩展功能,集成了液冷机柜、冷却分配单元(CDU)和监控系统。液冷机柜由不锈钢制成,提供防锈和防腐蚀保护。机柜的翻盖顶盖可以密封以避免冷却剂蒸发,同时满足边缘 IP65 的需求。冷却液通过 CDU 泵从液冷机柜底部进入,并流经高热设计功率(TDP)部件来带走热量。被加热的冷却液在热浮力作用的带动下向上运动并通过 CDU 泵从水箱顶部抽吸进入板式换热器与冷水机、干冷器等冷却系统进行热交换来完成整个冷却循环。系统采用标准“2U 21”机箱服务器,采用冗余的 54V PSU 供电。为
122、了进一步加强算力密度,基于灵活小巧的计算模块,实现 2U2N 设计。每个节点支持 1 个 1S+1S 计算模块,每个 CPU 支持 8 通道 8 个DDR5 内存,同时支持 1 个 x4 PCIe x16 扩展卡,可用来支持 2 张FHFL 双宽 250W GPGPU 卡或者 4 张 FHFL 单宽扩展卡,满足边缘视频场景急需的算力和 AI 加速需求。每个节点采用单独的 BMC 管理模块,可以远程轻松实现对节点的管理。通过模块化的灵活布局,实现最佳的基于热设计的摆位。监控系统提供两种操作模式,通过传感器监控液冷机柜和 CDU,实现对机箱的监控管理。如图 3.23 所示。75 云边端协同的智能视
123、频方案研究 ODCC-2023-04003 图 3.23 2U 高性能高密度浸没式单相液冷服务器实物图 综上所述,云边端协同的智能视频方案中,涉及到多种关键技术,这些技术相互协作,共同保障系统的高效稳定运行和智能视频处理能力。2 2基于基于 Intel TDXIntel TDX 的机密计算的机密计算 在计算中,数据以三种状态存在:传输中、静止和使用中。通过网络的数据是“传输中”的,存储中的数据是“静止的”,正在处理的数据是“正在使用的”。在我们不断存储、消费和共享敏感数据(从信用卡数据到医疗记录,从防火墙配置到我们的地理位置数据)的世界中,保护所有状态下的敏感数据比以往任何时候都更加重要。加密
124、现在通常用于提供数据机密性(阻止未经授权的查看)和数据完整性(防止或检测未经授权的更改)。虽然现在普遍部署保护传输中和静态数据的技术,但第三种状态-保护正在使用的数据-是新的前沿。此外,随着越来越多的数据被转移到云端,网络和物理边界安全在抵御攻击方面的能力越来越有限。虽然以前的保护措施(保护传输中和静态数据)仍然是重要组成部分,但它们已 76 云边端协同的智能视频方案研究 ODCC-2023-04003 不足以用于保护使用中的数据。机密计算通过在基于硬件、经过验证的可信执行环境中执行计算来保护使用中的数据。这些安全且隔离的环境可防止在使用应用程序和数据时对其进行未经授权的访问或修改,从而提高管
125、理敏感和受监管数据的组织的安全级别。图 3.24 机密计算保护使用中的数据 可信执行环境(TEE)通常定义为提供一定级别的数据完整性、数据机密性和代码完整性保证的环境。基于硬件的 TEE 使用硬件支持的技术为在该环境中执行代码和保护数据提供增强的安全保证。在机密计算的上下文中,未经授权的实体可能包括主机上的其他应用程序、主机操作系统和虚拟机管理程序、系统管理员、服务提供商和基础设施所有者或任何其他可以物理访问硬件的人。数据机密性意味着那些未经授权的实体无法查看在 TEE 中使用的数据。数据完整性防止未经授权的实体在 TEE 之外的任何实体处理数据时更改数据。代码完整性意味着 TEE 中的代码不
126、能被未经授权的实体替换或修改。总之,这些属性不仅保证了数据的机密性,而且还保证了所执行的计算实际上是正确的计算,从而使人们也可以信任计算结果。在不使用基于硬件的 TEE 的方法中通常缺少这种保证。77 云边端协同的智能视频方案研究 ODCC-2023-04003 2 2.1.1 英特尔信任域扩展(英特尔英特尔信任域扩展(英特尔 TDX TDX)在本文中,我们将介绍英特尔信任域扩展(英特尔 TDX)。一种体系结构技术,用于部署硬件隔离的虚拟机(VM),称为信任域(TD)。英特尔 TDX 旨在将 TD 虚拟机与主机平台上的虚拟机管理器(VMM)、虚拟机管理程序和其他非 TD 软件隔离开来。英特尔
127、TDX 可用于增强机密计算,帮助保护 TD 免受各种软件攻击,还有助于减少 TD 可信计算基础(TCB)。英特尔 TDX 旨在增强平台用户对数据安全和 IP 保护的控制。英特尔 TDX 还可以增强云服务提供商(CSP)提供托管云服务的能力,而不会将租户数据暴露给对手。英特尔 TDX 解决方案是结合使用 Intel 虚拟机扩展(VMX)指令集架构(ISA)扩展、Intel 总内存加密多密钥(英特尔 TME-MK)技术和 CPU 认证软件模块构建的。英特尔信任域扩展能够提供以下能力:内存和 CPU 状态的机密性和完整性,有助于保护敏感的 IP 和工作负载数据免受大多数基于软件的攻击和许多基于硬件的
128、攻击。有一个工具,支持从可信计算基础(TCB)中排除云平台的固件、软件、设备和操作员。工作负载可以使用此工具促进对 CPU 指令、安全性、调试和其他技术的更安全访问。工作负载现在可以具有此功能,而与用于部署工作负载的云基础结构无关。远程证明使依赖方(工作负载的所有者或工作负载提供的服务 78 云边端协同的智能视频方案研究 ODCC-2023-04003 的用户)能够在提供工作负载数据之前确定工作负载正在 TD 内支持英特尔 TDX 的平台上运行。远程证明旨在允许服务的所有者和消费者以数字方式确定他们所依赖的 TCB 版本,以帮助保护他们的数据。为了帮助执行 TD 的安全策略,引入了一种称为安全
129、仲裁模式(SEAM)的新 CPU 模式来托管英特尔提供的、经过数字签名但未加密的安全服务模块。Intel-TDX 模块托管在由 SEAM 范围寄存器(SEAMRR)标识的保留内存空间中。在这种设计下,CPU 只允许在 SEAM 内存范围内执行的软件访问 SEAM 内存范围,所有其他软件访问和从设备到该内存范围的直接内存访问(DMA)都将中止。SEAM 内存在 XTS 模式下使用 AES 提供加密机密保护,带有一个临时的 128 位内存加密密钥,并且可以在两种可用模式中的一种模式下运行以实现内存完整性保护(以启用各种内存配置)。内存完整性可以通过(默认的)密码完整性保护方案或逻辑完整性保护方案来
130、强制执行。加密完整性方案使用基于 SHA-3 的消息身份验证代码(MAC)(28 位),有助于防止主机/系统软件访问以及检测来自软件和一些硬件的状态篡改的攻击。逻辑完整性保护方案旨在仅防止主机/系统软件访问。79 云边端协同的智能视频方案研究 ODCC-2023-04003 图 3.25 英特尔 TDX 架构 英特尔 TDX 使用英特尔 64 架构(包括 VMX 架构)来帮助管理 TD 宾客虚拟机。Intel-TDX 模块旨在执行 VM 进入 SEAM-VMX,使用 VMRESUME 和 VMLAUNCHVMX 指令执行 TD 的非根操作。Intel-TDX 模块有助于确保 TD 的执行控制活
131、动不允许 VMM 或其他不受信任的实体拦截 TD 对 TD 分配的资源的访问,如控制寄存器、模型特定寄存器(MSR)、调试寄存器、性能-监控计数器、时间戳计数器等。TDX 模块旨在为 TD 实施安全策略。在创建 TD 时,该模块旨在为每个 TD 分配一个唯一的私有 KeyIDCPU 旨在禁止 Intel TDX 模块和 TD 以外的软件使用私有 KeyID 进行内存访问。尝试通过 SEAM 模式之外的软件访问私有 KeyID 会导致页面错误异常(#PF)。同样,来自使用私有 KeyID 的设备的 DMA 将被中止。共享内存用于与 TD 外部的 agent 通信,进 80 云边端协同的智能视频方
132、案研究 ODCC-2023-04003 行网络访问、存储服务、调用 hypervisor 服务等 I/O 操作。VMM 使用提供 GPA 到物理地址(PA)转换的扩展页表(EPT)帮助分配 TD 使用的内存并将其映射到 TD 的 GPA。当 TD 正在执行时,设计指定两个 EPT 将为 TD 激活:一个安全 EPT 用于提供私有 GPA 到 PA 转换,一个共享 EPT 用于提供共享 GPA 到 PA 转换。Intel-TDX 模块有助于为 VMM 提供安全 EPT 管理功能,以在安全 EPT 中添加或删除映射,并围绕这些操作实施安全策略,以保持内存布局的完整性。用于构建安全 EPT 的内存设
133、计为使用唯一的 per-TD 内存加密密钥进行加密和完整性保护。创建 TD 时,Intel TDX 模块将要求 VMM 提供一组内存页面,用于托管虚拟机控制结构(VMCS)、TD 的状态保存区等。该模块的目标是使用其页面分配跟踪器来强制这些页面未被 VMM 同时分配给其他 TD。然后,Intel-TDX 模块将使用 TD 分配的私钥初始化和配置这些结构,以帮助为 TD-CPU 状态提供加密机密性和完整性保护。TD 虚拟机中传递中断和异常的传递是基于 VMX-APIC 虚拟化和虚拟中断架构设计的。APIC 虚拟化架构旨在提供 APIC 的许多寄存器的 CPU 仿真,跟踪虚拟 APIC 的状态,并
134、提供虚拟中断。CPU 将在 VMX 非 root 操作中执行上述所有操作,而无需从 TD 退出 VM。VMX-APIC 虚拟化和虚拟中断架构的使用将有效地将中断传递到 TD(s),避免修改 TD 中的操作系统来模拟 APIC。请从 Intel Trust Domain Extensions 下载英特尔 TDX 相关 81 云边端协同的智能视频方案研究 ODCC-2023-04003 的白皮书和技术规范:图 3.26 英特尔 TDX 技术规范 2 2.2.2 英特尔英特尔 TDX TDX 的云软件套件的云软件套件 面向英特尔 TDX 的 Linux*堆栈是一个端到端的管理程序云软件套件,包括基础
135、设施即服务(IaaS)和平台即服务(PaaS)组件,可生成以下用例:(1)启动英特尔 TDX 来宾虚拟机以运行一般计算工作负载(2)在英特尔 TDX 来宾虚拟机中进行启动测量(3)在 IaaS 主机上使用基于英特尔 Software Guard Extensions(英特尔 SGX)的报价生成服务(QGS)生成的报价进行运行时证明 82 云边端协同的智能视频方案研究 ODCC-2023-04003 图 3.27 英特尔 TDX 的云软件套件 2 2.3.3 构建套件构建套件 对于端到端堆栈设置和验证,tdx-tools 提供下游补丁和构建工具,只需几个简单的步骤即可构建整个堆栈。图 3.28
136、构建英特尔 TDX 的云软件套件 83 云边端协同的智能视频方案研究 ODCC-2023-04003 成功构建包后,将生成两个存储库。一个是主机存储库,其中包括英特尔 TDX 主机内核、英特尔 TDX Qemu、英特尔 TDX Libvirt 和 TDVF。另一个存储库是包含英特尔 TDX 访客内核、grub2 和填充程序的来宾存储库。2 2.4.4 管理管理 TDXTDX 虚拟机虚拟机 与普通虚拟机一样,TD 客户机可以由 QEMU 通过命令行启动,也可以由 Libvirt 通过 XML 模板进行编排。本章介绍如何管理 TD访客的生命周期,以应对各种引导,例如安全启动、直接启动和grub 启
137、动。图 3.29 英特尔 TDX 虚拟机启动 具体的实现如下:84 云边端协同的智能视频方案研究 ODCC-2023-04003 2 2.5.5 安全启动安全启动 TD 来宾的安全启动与传统的非机密 VM 几乎相同。主要区别在于 TDVF.fd 需要静态测量到机读旅行证件中。它不允许在运行时通过 EnrollDefaultKey 等工具将安全启动密钥注册到 EFI 变量 FV(固件卷)中。相反,开发了一个来自 tdx-tools 的新工具 ovmfkeyenroll,以帮助在测量之前离线注册安全启动证书。85 云边端协同的智能视频方案研究 ODCC-2023-04003 图 3.30 英特尔
138、TDX 安全启动 2 2.6.6 英特尔英特尔 TDX TDX 的测量的测量 通常,TEE 可以提供其来源和当前状态的证据或测量值,以便另一方可以验证证据,并且可以通过编程或手动方式来决定是否信任在 TEE 中运行的代码。此类证据由制造商可以担保的硬件签名通常很重要,这样检查证据的一方就可以强有力地保证它不是由恶意软件或其他未授权方生成的。远程方在成功验证证据后允许将秘密或密钥发送到 TEE 环境。图 3.31 机密虚拟机的测量 可信计算基础(TCB)是指提供安全环境的所有系统硬件、固件和软件组件。对于机密 VM,它包括 CPU、SEAM 固件等硬件信息以及 OVMF、引导加载程序(shim/
139、grub)和内核等来宾组件。QEMU VMM 和 Orchestrator Libvirt 等其他主机软件在 TCB 之外。86 云边端协同的智能视频方案研究 ODCC-2023-04003 TCB 上的哈希链测量将扩展到一些安全寄存器,例如 TPM PCR(平台配置寄存器)。来自多个安全寄存器的值构建为一个报告,并最终通过认证密钥签署为 Quote。图 3.32 英特尔 TDX 报告 TD 有两种类型的测量寄存器MRTD 和 RTMR:MRTD(TD 测量寄存器)提供 TD 构建过程的静态测量和 TD的初始内容)RTMR(运行时测量寄存器)是英特尔 TDX 软件的一组通用测量寄存器,用于测量
140、在运行时加载到 TD 中的附加逻辑和数据。按照设计,来宾 TD 软件可以使用 RTMR 来测量启动过程 87 云边端协同的智能视频方案研究 ODCC-2023-04003 图 3.33 英特尔 TDX 启动测量过程 2 2.7.7 英特尔英特尔 TDX TDX 的认证的认证 英特尔 TDX 远程认证向依赖方展示在给定可信环境(TD 来宾)上安全运行的应用程序。这增加了远程方的信心,即该软件在给定安全级别(也称为 TCB 版本)的正版英特尔 TDX 系统上的 TD 内运行。TDX 证明重新使用英特尔 SGX 基础设施来提供对给定测量的证明。它基于 TD Quote,即在 TD Quoting E
141、nclave 中签署的 TD报告。88 云边端协同的智能视频方案研究 ODCC-2023-04003 图 3.34 英特尔 TDX 远程证明过程 步骤 1:TD 收到来自平台外挑战者的证明请求。步骤 2:TD 然后请求英特尔 TDX 模块向 TD 提供报告 步骤 3、4:Intel TDX 模块调用 SEAMREPORT 指令请求 CPU 生成 Report 结构,包括 TD 提供的数据,模块维护的 TD 的测量值,所有的 SVN(安全版本号)TDX TCB 中的元素。步骤 5、6:TD 请求 VMM 将报告转换为远程证明的报价。步骤 7、8、9:TD 报价飞地然后使用 EVERIFYREPO
142、RT2 验证报告上的 MAC,如果验证通过,则通过使用 TD 的非对称证明密钥签署报告将报告转换为报价。步骤 10:报价返回给挑战者。步骤 11、12:挑战者使用证明验证服务来执行 quote 验证。89 云边端协同的智能视频方案研究 ODCC-2023-04003 面向英特尔 TDX 的 Linux 堆栈通过集成英特尔 Software Guard Extensions Data Center Attestation Primitives(英特尔 SGX DCAP)提供端到端英特尔 TDX 认证功能。3 3比亚迪边缘视频加速服务器硬件方案比亚迪边缘视频加速服务器硬件方案 不同的上层业务对底层
143、硬件平台提出不同的技术需求,具体包括:无差别兼容上层多个 VIM 平台和 VNF 业务的需求。硬件平台应尽量采用统一的设计和部件选型。否则型号众多的服务器将带来大量的适配工作;服务器性能需求。不同网元的性能关注点有所差异,例如转发面网元对于网络带宽、转发时延和性能稳定性要求极高;时钟精度与同步要求。对于部分涉及计费功能的网元应用,服务器需要具有较高的时钟精度,对于无线接入网元应用,服务器还需同时具有较高的时间同步精度;异构计算要求。大量网元的虚拟化部署,如核心网和 RAN CU虚拟化等,需要通过配置基于 FPGA、ARM 等的网卡或其它硬件加速方案卸载部分 CPU 功能,以节约 CPU 资源并
144、提高处理效率。90 云边端协同的智能视频方案研究 ODCC-2023-04003 3 3.1.1 适应边缘机房环境挑战适应边缘机房环境挑战 边缘机房与核心机房相比条件较为恶劣,很多方面无法满足通用服务器的运行要求:机架空间有限。传输及接入机房机架多为 600mm 深,部分能够达到 800mm,通用服务器无法部署;部分机房环境温度较高。由于制冷系统的稳定性无法有效保证,机房最高温度有时会达到 45;机房空气质量欠佳;承重有限。众多边缘机房并未按照数据中心标准建设;其它还包括抗震、供电等诸多限制。边缘机房条件难以与大型数据中心等同,且数量庞大,所以单纯的改造机房并不现实,其中既有改造难度大造价高的
145、原因,也有机房作为“战略资源”,很难自由扩展空间的因素,因此对服务器进行重新设计就是必经之路。3 3.2.2 满足运维管理需求满足运维管理需求 边缘服务器承载大量电信级业务,并部署在较为恶劣的边缘机房,所以需要有强大管理运维能力保障:统一管理接口。服务器需要有统一完善的管理接口要求,统一是因为多样化的管理接口将给 VIM/PIM 对接带来大量适配 91 云边端协同的智能视频方案研究 ODCC-2023-04003 工作,完善是为了更加有效的管理服务器;运维高效。边缘服务器应尽量降低对运维人员水平的要求,提高运维效率。因此,服务器需要支持前维护,建议采用统一面板/指示灯,支持风扇热插拔等。3 3
146、.3 3 边缘计算服务器硬件方案边缘计算服务器硬件方案 服务器物理形态、供电及环境适应性 边缘服务器不但需要适应边缘机房的环境,还需要满足各类边缘业务在边缘机房的交付、部署与本地运维需求。具体包括:为适应边缘数据中心空间限制和机架深度,服务器深度推荐不超过 470mm,最多不超过 500mm;开关、指示灯、硬盘、线缆等采用前维护,以提高维护效率,减少对机架后方空间的要求;风扇能够支持热插拔,保证在线清理或更换;部分边缘应用场景,可能需要支持在更宽的温度范围(例如-5 度45 度)内运行,并可能需要满足 B 级 EMC、抗震等需求;边缘数据中心功率和承重能力有限,对服务器密度要求不高,一般计算型
147、服务器 2U 高度即可,存储型服务器可进一步放宽;但考虑边缘业务未来交付方便,可能会考虑“机框+多 92 云边端协同的智能视频方案研究 ODCC-2023-04003 节点”的整体设计形态。3 3.4.4 硬件规格及关键组件硬件规格及关键组件 边缘视频服务器宜采用 ASIC VPU(Video Processing Unit)加速卡配置,方案要求最高密度、最低成本、超低延迟、最低能耗、可计算存储架构,可直接用于现有服务器硬件接口,易使用,易维护等特性。由于采用视频加速卡方案,从功耗、空间和性能需求等多方面考虑,倾向于单路低功耗方案。同时考虑到边缘异构计算等要求,也需要预留一定的扩展插槽。在部件
148、规格方面,一是对网卡的性能、兼容性等有较高要求,可能需要推动 25G、100G 网卡的应用以及生态的不断完善,同时加强对部件的选型要求或者形成比较严格的认证部件列表;二是对于网卡加速功能要求比较迫切,需将部分功能卸载至网卡,以提高网络处理速度并降低 CPU 负载,具体功能包括网络转发、IPSec、DPI和 HQoS 等。3.5 3.5 BIOSBIOS、BMCBMC 及硬件管理及硬件管理 OTII 项目将与服务器、BMC 及 FW 厂商合作,开发统一的针对NFV场景的服务器硬件监控、远程管理功能,使上层管理平台能够无差别的与不同供应商、不同配置规格的服务器对接。93 云边端协同的智能视频方案研
149、究 ODCC-2023-04003 3 3.6.6 比亚迪边缘服务器系统方案比亚迪边缘服务器系统方案 模块化服务器简介:模块化服务器简介:比亚迪模块化设计理念是将:计算、存储、PCIe 扩展、供电单元设计为独立模块,缩小了服务器的机箱长度,可根据不同需求灵活配置,更便于边缘场景安装和维护。(1)风冷模式:模块设计以 19 英寸宽度和 435mm 深度为标准,可适应边缘场景的机房环境,可以支持在边缘网络机柜上架安装,该方案具备如下特性:可按照资源需求配置模块;94 云边端协同的智能视频方案研究 ODCC-2023-04003 模块间采用高速线缆互联;充分利用 42U 服务器机架高度;优化正面进风
150、截面积,减少散热通道风阻,更大的进风量;可支持风扇墙散热。(2)边缘浸没式:该方案采用密闭的浸没式液冷箱设计方案,具有被动散热、外壳散热、内置热交换多种散热方案,具有如下特性:边缘资源易配置,可配置异构计算、通用计算、存储资源、多种通用算力平台;隔绝外部环境,可支持户外恶劣环境;可按照场景和功耗配置不同的散热方案。VPUVPU(Video Processing UnitVideo Processing Unit)加速卡服务器方案)加速卡服务器方案 95 云边端协同的智能视频方案研究 ODCC-2023-04003 视频的高分辨率和超高清化(4K/8K),多种视频格式(H.264/H.265/V
151、P9/AV1),新应用(云游戏/AR/VR)等带来超低延时要求,使视频的处理和计算的复杂度指数级增加,采用 ASIC VPU加速卡服务器方案具备如下特性:即插即用:可用于任何带标准 PCIe U.2 插槽的服务器 最高密度、最低成本 超低延迟 最低能耗 可计算存储架构,可直接用于现有云存储服务器,易使用,易维护 四、四、案例分享案例分享 1 1百度边缘音视频案例百度边缘音视频案例 国内某泛娱乐直播龙头企业,在直播业务尤其是音视频通信方面有很强的技术积累,近年来自身的直播业务覆盖音乐、脱口秀、舞蹈、户外、体育、游戏等多个细分品类,其强大的音视频能力也 96 云边端协同的智能视频方案研究 ODCC
152、-2023-04003 对其他 ToB 企业开放,同时积极尝试采用新的技术手段优化其自身上层直播业务,进一步提升终端用户的使用体验。在音视频的业务中,对实时性有极高的要求,如游戏语音、直播等。这类业务需要对音频、视频内容的分发保证超低延,从而保证终端用户的极致体验。但是,如何能够在不增加业务成本的同时,保证用户的低延时体验,成为音视频厂商必须解决的难题。通过与百度智能云合作推进了音视频直播架构部署在 BEC 边缘节点,在更好的体验与更低的带宽成本之间实现了平衡。在进行架构升级之前,客户将音视频直播架构部署在中心云,将视频数据在中心云处理完成之后,再通过 CDN 节点分发到终端用户。基于中心云的
153、直播架构有几点劣势:带宽成本方面相对较高、分散在全国的终端用户直播体验欠佳。基于以上几点劣势,在充分了解边缘云各项优势的前提下,客户考虑将基于百度智能云 BEC 升 97 云边端协同的智能视频方案研究 ODCC-2023-04003 级音视频直播架构。客户将 BEC 作为视频源站,实现就近上传、推流、转码、渲染,面向本地用户实现就近分发,实现本地化视频链路质量保障,实现低成本、低延迟的新型视频架构。在这一案例中,百度智能云 BEC 为客户提供了遍布全国的边缘算力资源和带宽资源,帮助客户完成了音视频架构升级。客户实现了带宽成本降低,并且同时大幅提升了终端用户的使用体验,实现了较为明显的降本增效。
154、2 2边云协同的视频分析技术在智慧校园之明厨亮边云协同的视频分析技术在智慧校园之明厨亮灶中应用灶中应用 大中小学幼儿园的食品安全监管面临量大、面广、操作环节多的问题,靠现有的以上门抽检和人工视频巡查的监管方式难以实现有效的监管,迫切地需要通过视频监控、人脸识别、视频智能分析、物联感知等先进技术对餐饮后厨人员持证情况、穿戴情况、四害防治情况、卫生消毒环境等各方面进行远程智能监管,从而进一步落实学校责任和提升监管效率,最终实现食品安全状况的根本好转。98 云边端协同的智能视频方案研究 ODCC-2023-04003 图 4.1 边云协同的视频分析技术在智慧校园之明厨亮灶中应用效果 采用“云-边-端
155、”架构带动区域智慧校园系统的技术升级,根据业务需要分级处理,云边协同,为各校区、各辖区的分级管理提供信息化管理和决策支持。“云”侧:以物联网平台为基础,建设辖区智慧校园监管平台,针对校园明厨亮灶分系统提供测感知平台和视频感知平台,采用微服务架构解耦业务和数据,解决异构系统架构和数据统一管理。作为城市及地区及的智慧校园行业平台,承担各级建设的所有视频站的统一数据的接收、解析、存储与服务,实现与各级所有感知相关数据的统一汇聚接入和共享服务。物联网平台北向通过开放的 API 接口和主站应用进行对接。通 99 云边端协同的智能视频方案研究 ODCC-2023-04003 过物联网平台实现了感知层的物联
156、网设备和上层应用之间的解耦,加快了上层应用的迭代速度。业务功能软件微服务化后,多业务部门的微服务都可运行在物联网平台上,可实现充分的信息共享,打破原有业务系统的信息烟囱“边”侧:(1)边缘计算平台提供云边一体的边缘计算框架,能够快速地将业务应用部署至距离数据源头最近的边缘节点,帮助智慧校园行业客户在边缘计算设备上快速实现 视频接入及录像、存储、转发、视频录像截图上传下载;视频流字幕打印、IoT 设备数据联动;边缘智能推理分析、输出符合明厨亮灶特点的识别结果以及预测分析,如没带帽子、垃圾桶无盖、有害生物(老鼠)等;提供丰富的本地物联管理能力,包括场景联动,流式计算和消息路由等,对设备数据进行处理
157、与响应,节约运维、开发、网络带宽等成本消耗。(2)边缘硬件:开发适用于智慧校园分级建设、统一监督体系的边缘网关设备,将高带宽、低时延、本地化的业务下沉到网络边缘,解决时延过长、汇聚流量过大等问题,从而为实时性和带宽密集型业务提供良好支持。通过不同规模视频分析路数,配置不同算力的边缘网关,采取分级堆叠设计,可大大提升边缘视频分析算法 100 云边端协同的智能视频方案研究 ODCC-2023-04003 在平台上的一致性和普适性;(3)边缘智能:通过目标检测、图像分割等人工智能技术,基于海量后厨视频、图片数据,构建基于神经网络模型,结合传统图像处理等技术,构建了一套高精度、高适用、高效率的智能校园
158、食品安全监测系统。3 3智慧零智慧零售售 随着人工智能和物联网技术的不断发展,智慧零售成为零售行业的新趋势。在传统的零售模式中,实时监控和分析顾客行为是提升运营效率和优化用户体验的关键。然而,传统的中心化视频监控系统存在带宽压力、延迟高等问题,为了解决这些问题,边云协同的视频分析技术应运而生。边云协同的视频分析技术结合了边缘计算和云计算的优势,将视频分析任务在边缘设备和云端之间进行协同处理,以提供更快速、高效的视频分析服务。下面是一个智慧零售场景中的方案架构示意图:101 云边端协同的智能视频方案研究 ODCC-2023-04003 在该方案中,摄像头设备安装在零售店铺的关键位置,负责采集实时
159、视频数据。边缘设备位于店铺内部,具备一定的计算能力,能够进行部分视频分析任务,如目标检测、人脸识别等。边缘设备通过边缘计算技术对视频数据进行初步处理和筛选,并将需要进一步分析的数据传输到云平台。云平台部署了强大的视频分析算法和大数据分析能力,对传输过来的视频数据进行深度分析,如顾客行为识别、购买偏好分析等。分析结果将传回终端应用,供店铺管理人员进行实时监控和决策。(1)实时监控和安全防护:通过边云协同的视频分析技术,智慧零售店铺能够实时监控店内的顾客行为,识别异常情况,如盗窃行为或潜在安全隐患,并及时采取措施进行干预,提高店内安全性。(2)顾客行为分析和购买偏好:通过视频分析技术,智慧零售能够
160、识别顾客的行为模式和购买偏好。例如,识别出顾客在特定货架前停留的时间较长,可以判断其对该商品感兴趣,并针对性地提 102 云边端协同的智能视频方案研究 ODCC-2023-04003 供推荐或优惠活动,增加销售机会和顾客满意度。(3)店内布局和货架优化:通过视频分析技术,智慧零售可以对店内布局和货架进行优化。分析数据可以揭示热门区域、高流量区域和冷门区域,帮助店铺管理人员进行货架摆放调整,提高产品曝光度和销售效果。(4)人员管理和服务质量:通过视频分析技术,智慧零售能够实时监测店内人员活动,识别员工工作效率和服务质量。分析结果可以帮助店铺管理人员进行员工绩效评估和培训需求分析,提升服务质量和工
161、作效率。通过边云协同的视频分析技术在智慧零售中的应用,能够实现实时监控、顾客行为分析、店内布局优化、人员管理等多个方面的效果。这不仅提升了零售店铺的运营效率和安全性,还改善了顾客体验,为智慧零售行业的发展带来了巨大的潜力。五、五、总结和展望总结和展望 智能视频技术作为人工智能和物联网的重要应用领域之一,正在快速发展并在各行各业得到广泛应用。云边端协同的智能视频方案将边缘计算、云计算和视频分析技术有机结合,为各行业提供了更快速、高效、灵活的视频监控和分析解决方案。在目前的发展趋势下,云边端协同的智能视频方案有着广阔的发展前景和应用潜力。首先,云边端协同的智能视频方案将会在安防领域发挥重要作用。传
162、统的安防监控系统存在带宽压力、延迟高等问题,而云边端 103 云边端协同的智能视频方案研究 ODCC-2023-04003 协同的方案通过在边缘设备上进行部分视频分析,可以减轻云端的计算负担,降低延迟,提供更快速、实时的监控和预警能力。同时,结合人脸识别、目标检测等智能分析算法,可以提升安防系统的准确性和自动化程度,为安全防护工作提供更多有力的支持。其次,云边端协同的智能视频方案将在智慧城市建设中发挥重要作用。智慧城市需要对城市内的交通、环境、设施等进行全面监测和分析,而传统的中心化视频处理方式往往无法满足大规模数据处理的需求。通过将视频分析任务在边缘设备和云端之间进行协同处理,可以实现快速的
163、数据传输和分析,提供实时的城市监测、交通管理和环境保护等功能,为城市的可持续发展和改善居民生活质量做出贡献。此外,云边端协同的智能视频方案还将在零售、工业、医疗等领域得到广泛应用。在零售行业中,通过视频分析技术可以实现顾客行为分析、商品推荐和店铺管理优化,提升销售效果和顾客满意度。在工业领域,智能视频可以用于设备监测、安全监控和生产流程优化,提高工作效率和生产安全性。在医疗领域,智能视频可以用于病房监护、病人行为分析和医疗设备管理,提供更好的医疗服务和护理质量。展望未来,随着人工智能和物联网技术的不断发展,云边端协同的智能视频方案将会越来越成熟和普及。随着边缘设备的智能化和计算能力的提升,边缘
164、计算将能够承担更多的视频分析任务,减 104 云边端协同的智能视频方案研究 ODCC-2023-04003 少对云端的依赖。同时,随着云计算技术的进一步发展和智能算法的不断优化,云端将能够提供更强大的计算和存储能力,为边缘设备提供更多的支持和资源。在技术层面,云边端协同的智能视频方案还可以与其他技术相结合,如 5G 通信、物联网、大数据分析等,构建更智能、更高效的系统。同时,随着隐私保护和数据安全的重要性不断凸显,云边端协同的方案还需要注重隐私保护和数据安全的技术和机制,确保用户数据的合法使用和保密性。总之,云边端协同的智能视频方案具有广阔的发展前景和应用潜力。它将推动智能视频技术在各行各业的应用和发展,为社会的安全、效率和便捷性提供更多的可能性。随着技术的不断进步和应用场景的不断扩展,云边端协同的智能视频方案将继续发挥重要作用,引领智能化时代的到来。