Open Carrier Interface: An Open Source Edge Computing Framework

本文链接：https://blog.csdn.net/u014204698/article/details/102484854

开放载体接口：开源边缘计算框架

Marc Körner ∗，ICSI，koerner@icsi.berkeley.edu；Torsten M. Runge ∗，ICSI， runge@icsi.berkeley.edu；
Aurojit Panda ，NYU and ICSI，apanda@cs.nyu.edu；Sylvia Ratnasamy，UC Berkeley，sylvia@cs.berkeley.edu；
Scott Shenker，UC Berkeley and ICSI，shenker@icsi.berkeley.edu

摘要

边缘计算作为一门新兴的技术，在低延迟和高带宽需求的应用中提供了多方面的性能改进；
为了减少网络服务供应商支持边缘计算的负担，我们提出了一类中性平台（适用于绝大多数平台）的开源边缘计算架构-Open Carrier Interface。
该设计原型为网络服务供应商提供直接在网络边缘部署软件组件的机会，无需操作人员干预
详细设计和阐述该框架的接口：
- 对所有使用方是否方便简单
- 基于边缘资源管理系统和边缘服务架构提供统一的抽象层
- 可以对实现edge服务范式的应用程序产生显著的性能影响

关键字

边缘计算，计算迁移

介绍

网络流量的爆发式增长，并继续快速增长
- 归因于视频流服务，物联网应用设备
- 处理流量增长需要升级网络主干，但增加了网络服务的开销
- 传统的客户端-服务器部署限制了延迟和响应能力，所以限制了网络支持的应用种类
- 为了应对挑战，应用开发商在网络的边缘部署了一些缓存和搜索设备，并且这些设备在快速增长，因此需要进行管理
所以，提出一个网络运营商能够为应用程序供应商开放其边缘设施，供其进行边缘计算
- 举例：以销售物联网设备（家用恒温器，监控摄像头）的第三方应用服务供应商为例
- 只要设备出现在网络边缘，开启连接网络运营商和第三方应用服务供应商的软件，该软件支持边缘处理的物联网设备
- 早期的应用服务供应商，即使资金和资源匮乏，也可以和大公司获得相同的边缘支持，因此可以在相同的基础上竞争
所提系统的两个原则：灵活性和无需操作人员介入
- 按需启动，按需计费
- edge软件组件被自动输入和分配，无需人工干预
- 客户端-服务器----》客户端-边缘-服务器转变

背景和相关工作

边缘计算的推动者：NFV
- OCI的概念指的是边缘计算的范式,它利用最近的COS手段
- CO第一个网络服务供应商设备，它能够连接家庭和移动基站
- CO通常由宽带接入服务器(BRAS)连接并提供服务，该服务器为用户提供广域网(WAN)接入
- 这些设施通常由专用信号处理和网络设备主导
- 然而，最近在软件定义网络(SDN)和网络功能虚拟化(NFV)方面的发展改变了硬件和软件的部署，使它们成为使用通用服务器设备操作的小型数据中心。
  - 增大灵活性，允许网络运营商虚拟化管理设备
  - 无需中断服务，处理故障转移，更新VNF。
- 预计到2020年将近75%的公司将使用云类设备和NFV，为开源提供支持
边缘计算性能分析
- 边缘计算承诺通过使用数据局部性来提高几个应用程序的性能
- 能够（通过解决由于服务、数据量和物联网设备的增加而导致的带宽需求增加）重新激活核心网络。
- 据研究表明，在最近出现的延迟和带宽紧张可以很好的被改善，通过边缘计算；并且可以提高局部数据的处理速度
边缘计算架构
- IEEE和ETSI都为边缘计算做出了贡献
- linux基金最近启动了关于物联网边缘计算的项目EdgeX Foundry
  - 目的是通过设计边缘计算平台来提升物联网系统的硬件互通性
  - 一种该边缘计算平台是专注于通过围绕核心服务的标准化应用接口(API)为物联网设备提供便利，是一个微小的框架
  - 该方法仅限于微型服务，并且重点集中在工业物联网设备领域
  - 项目执行环境主要集中在网关、路由器等嵌入式设备。
  - 另一种嵌入式设备的物联网边缘计算平台是谱适软件架构：该平台支持基于面向物联网设备的模块化开放服务网关(OSGi)开发的边缘应用程序
  - 两种都应该部署
- 基于CDN的边缘计算方法
  - 本文介绍的方法通过进一步隔离和规范管理实体扩展了体系结构。此外，它还提供了一个开源实现。所提出的OCI架构旨在为任意边缘服务(ES)设计和底层NSP资源管理系统提供一个通用的解决方案。它可以动态地调用基于ES的应用程序上下文，并提供了一种简单而直接的多域方法。我们还主张将OCI部署在CO s中，因为CO s提供了托管数据中心服务器设备的机会和能力，并且没有嵌入式设备的限制。因此，边缘计算应用程序并不是完全的资源约束，而是必须存在于嵌入式系统中，就像典型的家庭路由器一样。这为传感器数据聚合之外的复杂处理提供了机会，比如Netflix的Open Connect设备。
- OCI是与平台无关的开源边缘计算架构，为应用服务供应商提供几乎所有可能的应用架构自由
边缘和云延迟研究
- 亚马逊网络服务在云市场中占据了主导地位。出于这个原因，我们探讨了其典型的云计算，并对其延迟和带宽性能进行了测试。
  - 延迟的测量是基于往返时间RTT，收集一个常规数字信号用户，访问传输速率为30Mbit/s。
- co比其他云计算架构延迟低

架构

OCI是在BSD允许下的一个开源的边缘计算架构解决方案，为ASPs在NSP'S提供部署边缘应用的能力。

目的：实现简单自动化的部署，以及生命周期管理，不需要与NSP进行直接交互或协商

优点：OCI能够利用现有NFV基础设施，同时提高QoS。支持OCI的应用程序的QOE也得到了改进，称为ES

全球OCI协调器
- 它的主要任务是在没有操作员干预和网络知识的情况下，跨多个网络边缘和域分发ASP的第三方ES,因此包含了多个接口
  - NSP interface
    - 指定配置文件（JSON）
    - 向GOCIC提供同一域中所有LOCIC的IP地址，以及它们的元数据信息(如地理编码位置)
    - 另外，该文件还可以包含关于同级的OCI域及其GOCIC的IP地址和元数据的信息。
  - LOCIC interface
    - 将ESAP分发给locic
    - 收集当前oci使用情况信息，做出管理决策
    - ES的弹性、故障排除和可伸缩性。
  - ASP interface
    - reset接口，用来分发ES
    - 可以向Gocic上传ESAP，根据包含的信息，GOCIC在LOCIC的边缘以及其他同级的域分发ESAP
  - inter-domain interface
    - 域间接口同步OCI域和ESAP与其他不同域进行交换
本地OCI协调器
- LOCIC是OCI的边缘实体管理
- 作用：通过与GOCIC、RnOMA和客户沟通，来维护所有ES的列表、名称、IP地址、生命周期状态、注册秘钥，以及可能潜在的鼓掌转移信息
  - 其中注册秘钥是在注册新的ES时由LOCIC生成的
    - 一种访问控制机制·，用于注销ES或操作其信息
    - 是一种保护机制，只有拥有秘钥，才能对其操作
资源和编排管理适配器
- RnOMA作为底层实际资源和编制管理器的驱动程序
- NSP用它来管理边缘计算、存储和网络资源
- RnOMA提供了一个通用接口来适应任意的资源管理API
OCI库
- OCIlib包含应用程序开发人员使用CES范式和OCI框架构建客户机-边缘-服务器(CES)应用程序的方法和模板。
- 它为客户机应用程序提供了通过LOCIC查找获得ES IP地址的方法。
- 它还提供了额外的edge服务模板，以简化基于OCI的CES应用程序的开发，并支持OCI生态系统内的集成，如动态生命周期管理和基于组件的拼接。
边缘服务架构
- OCI ES可以是应用程序体系结构的一部分，位于客户端和服务器组件之间
- 它可以由一个分布式结构和几个使用发现服务的微服务组成
- 在OCI边缘处执行任务，可以实现应用程序级的负载均衡
边缘服务应用包
- ESAP是ES的编译和绑定形式。
- 它是一个zip压缩文件，文件扩展名为esap，内部文件夹结构如下:bin、lib、template和meta。
- bin文件夹包含edge服务包含的所有二进制文件。
- 元文件夹包含一个描述ES元数据信息的JSON文件。
多域支持

OCI多域支持支持多个GOCIC之间的ESAP域间交换，如图3。域间ESAP交换基本上可以以主动或被动的方式实现。
- 主动：定期同步不同域的GOCIC之间的ESAP。如，基于特定的时间间隔实现，也可以由新ESAP的上传触发。
- 被动：由客户端ES请求触发。如果可用请求涉及其他域或不可用的服务，LOCIC可以通知GOCIC。因此，请求一直委托到GOCIC和其他域，以便检索相应的ESAP
反应性方法需要在LOCIC - GOCIC和/或GOCIC - GOCIC之间进行额外的通信。
- 当前的即时应用程序使用内建的主动交换，这也是当前用于ESAP分发到LOCIC的。
- 交换ESAP的多个GOCIC实例之间的联系可以用多种方式组织。
- 例如，他们可能会使用一个覆盖网格网络(如点对点(P2P))或分层部署。
- 在介绍了实现了技术的概念,并没有考虑任何帐单或SLA实施规划的年代。
- 因为这个问题是多方面的,这种方法只处理一般技术可行性和P2P机制用于还分发一个ESAP LOCIC。

评估

实验平台
- 两台服务器
- 2x4核Intel Xeon CPU，128GB DDR4 RAM, 10千兆网卡 82599ES
- Debian Linux 操作系统，4.12.0-1-adm64 kernel
- 所有节点都通过千兆级别的交换机互联
边缘服务查找时间
- 在最坏的情况下，LOCIC能为所有预定了CO的客户端提供服务；根据客户端请求,在不同条件下获取随机的查找时间，作为我们衡量的参数
- 单程查询查找时间
  - 1000个样本，1.5-2.5间随机查找
  - 测量时，增加暂停，迫使系统处于空闲状态，这样向缓存这样的操作不会影响测量结果
  - 1K个条目进行查找时，平均时间到0.9毫秒，1k-2k个条目足够使用，无需更大
- 基于负载的查找时间
  - 在不同负载情况下进行查找时间的测量
  - 每个查找请求在被LOCIC处理之前经历相同的平均等待时间