边缘计算：跨越传统数据中心

深入探索边缘计算的考虑因素

边缘计算的边缘指的是位于管理域的边缘，尽可能地靠近数据源或用户。这个概念同样适用于运营商网络、有众多分支机构的大企业，如零售，或者是与IoT相关的其他应用。

边缘计算的一个特点是应用与边缘的位置紧密相关。对于运营商来说，边缘指一个位置靠近用户但是却由供应商控制，潜在地在用户的设备上运行着不同种类的计算任务。对于大型企业来说，边缘指一个应用程序、服务和工作任务正在运行的位置（如，零售商店或者工厂）。对于这个定义而言，边缘不是指那些支持能够支持最小化云架构并资源有限的终端设备，如IoT或者传感设备。这是一个非常重要的考虑因素，因为很多针对边缘计算的讨论并不如此区分。

边缘计算与数据中心在如下几个方面是相似的：

• 都包含计算、存储和网络资源
• 这些资源都可以被多个用户和应用程序共享
• 都收益于虚拟化技术和资源池的抽象
• 都收益于能够利用白牌硬件的能力
• 都能够通过API来支持互操作性

边缘计算与大规模数据中的区别在于：

• 边缘节点尽可能地靠近最终用户，能够提高在高延时和不可靠连接下的用户体验。
• 边缘计算也许需要特殊的硬件，如GPU/FPGA平台来提供增强现实和虚拟现实的功能。
• 边缘计算能够扩展至非常多的站点，分布在各个不同的地点。
• 一个边缘站点的位置和它的访问认证链接是非常重要的。一个需要靠近在用户端运行的应用程序，需要处于正确的边缘部分。对于边缘计算来讲，应用程序位置的重要性是通用的。
• 多站点的所有资源池都应该是动态的。因为站点之间的物理隔离，边缘站点应该能够在某种程度上相互连接，并且能够通过广域网与核心相连。边缘站点会随时加入或离开整个基础设施资源池。
• 边缘站点一般是处于远端并且潜在地无法被操纵，因此边缘站点必须能够被远程管理。相关工具必须能够支持通过不可靠网络来访问边缘站点。
• 边缘计算应该支持巨大的差异性，如不同大小和规模的站点、大规模的数据中心或者是单个设备
• 边缘站点往往是资源受限的；这是因为空间或电源的限制导致不能随意往站点里面添加资源
• 一些用户场景需要能够在大规模的情况下实现多租户的功能
• 边缘计算与云数据中心的隔离需要通过保证“外部云”不能影响边缘计算的相关服务

边缘计算的概念必须包括边缘站点（如计算、网络和存储基础设施），和运行着的应用程序（计算任务）。边缘计算环境中的应用程序还是能够享有云计算中的各种资源，如计算、块存储、对象存储、虚拟网络、裸机或者容器。

定义和区分边缘计算和云计算的最基本特征是：

• 有能力支持由多个潜在宽泛分布的站点组成的动态资源池
• 潜在不可靠的网络连接
• 很可能在跨网络多站点的情况下碰到的难以解决的资源限制

案例

用来表征案例的方法可能会有几十种，本文因长度限制而不能够详细罗列。这里提供了一些示例以帮助梳理思绪和点明应用的机遇。

分析，合规，安全和网络功能虚拟化是受益于分布式架构的四类主要工作需求。

场景

边缘计算模式的基础特性就是将基础设施更接近于底层用户，即站点分布范围广且边缘节点由WAN网络连接。场景中进一步的验证能够帮助我们评估已应用至案例中的现有功能，同时发现其劣势和可改进的方向。

1. 供零售/金融/远程连接领域使用的"盒中云"：提供了一系列可定制于特定企业或产业应用的边缘计算环境。这类边缘计算主要由企业使用，它从根本上与分布式结构相结合来达到以下效果：降低硬件消耗，多站标准化部署，灵活更替部署在边缘侧的应用（不受硬件影响，同一应用在所有节点上一致运行），提升韧性并关注间断WAN连接。当设定为有限网络连接时，内容缓存或提供计算、存储服务以及网络服务都是边缘计算常见的使用方法。

2. 移动连接：在5G网络大规模普及前，移动网络仍保持着受限和不稳定的特性，因此移动/无线网络也可以看作是云边缘计算的常见环境要素。许多应用或多或少都依赖于移动网络，例如应用于远程修复的增强现实、远程医疗、捕捉公共设施（水力，煤气，电力，设施管理）数据的物联网设备、库存、供应链以及运输解决方案、智慧城市、智慧道路和远程安全保障应用。这些应用都受益于边缘计算就近端处理的能力。

   

3. Network-as-a-Service （网络即服务）：由于需要在各异环境中提供特定的网络服务应用经验，NaaS用例不仅只能占用位于边缘上小部分的分布式平台，而且需要强大的，可跨接不稳定或受限WAN网络的集中式管理工具来支持外围边缘侧的服务。该场景的主要特征包括：硬件资源占用量小，移动（更改网络连接）及频繁更替工作，数据和应用混合安置。这也是基础平台需要支持微型节点（在非传统包（冷却数据中心内不都是19英寸机架）内进行少量计算）的案例之一。NaaS需要由上千或上万个边缘侧节点支持。同时，它还必须支持网状和/或层次式结构以及按需响应的站点（可能在需要时进行运转而在完成后关闭）。APIs和GUIs将会不断变化来映射安置于不同位置而非是同一数据中心内的大量计算节点。

   

4. 通用用户驻地设备（uCPE）:该场景现已部署完成，需要占用产品大小的硬件资源。其特点为：网络连接有限，工作量较为稳定但需确保可用性高。于此同时，它也需要一种方法来支持跨上百至上千节点的数据应用混合安置，而拓展现有uCPE部署也将成为一项新要求。

   而这点非常适用于NFV应用，尤其当不同站点可能需要不同系列的服务链应用，或是区域内一系列不同的应用需要统一协作时。由于本地资源的利用以及必须满足在间断的网络连接下进行存储和进行数据处理，我们可需要支持网状或层次式的结构。自我修复以及与远程节点管理相结合的自我管理都是必须条件。

5. 卫星通信（SATCOM）：该场景以大量可用的终端设备分布于最偏远和恶劣的环境为特征。同时，将这些分散的平台用于提供托管服务也是极为合理的，尤其是当考虑到极高的延时，有限的带宽以及跨卫星通讯的费用。具体事例可能包括船舶（从渔船到油轮），飞机，石油钻井，采矿作业或军事基础设施。

   

挑战

虽然当前有非常多边缘计算的实例正在部署，但若要推广的话，还是需要解决新涌现出和早就存在的各种挑战与局限。

我们已搭建起的边缘计算平台，比起传统的集中化数据中心云平台，从设计之初，不管是硬件的配置还是支持应用程序生命周期管理的系统服务，就加强了容错性和鲁棒性。我们还是不能假定这样的边缘计算实例能够满足标准数据中心基础设施在可维护性和支持设施上的要求。在这种场景下，所有的基础设施与平台系统栈需满足以下几项至关重要的需求：零干预系统预置，自动化，和自治的编排。

但是还要考虑其他几个挑战。

其一，针对一个可运维并依靠WAN互联达成的跨地域IaaS设施系统，边缘计算资源管理系统应当提供一组高层机制可以组合输出。换言之，这里的挑战是如何修订（而且如需要时进行扩展）IaaS层的核心服务，以处理如上所述边缘计算的特定需求 - 如网络断联/带宽，计算和存储设备有限的功能，缺乏管理的部署，等等。

可预期的需求包括：

• 一个统一管理虚拟机/容器/裸机生命周期的管理器（包括配置，调度，部署，休眠/唤醒，和关机）
• 一个管理模版文件（即虚拟机和容器的镜像）的镜像管理器
• 一个负责基础设施联通的网络管理器，包括虚拟网络和用户外部访问的管理
• 一个存储管理器，可以给边缘应用提供存储服务
• 可以运维和使用这些分散资源的管理员工具

上述这些需求明显相关，而且很可能利用和适配现有的项目就可以了。但其他一些边缘计算的需求就更加有难度，包括并不限于以下所列：

• 解决WAN网络中存储延迟问题
• 加强边缘计算的安全 - 监控每个节点中硬件和应用的完整性，并能够必要时自主采取修正的操作
• 同时检测所有节点中资源的使用情况
• 能够管理和协调多边缘节点和负载的编排工具，有潜力发展为一个对等控制平面或"自组织边缘计算"
• 必须探索多边缘计算平台（或多云之云）的联合编排技术，并引入到IaaS软件核心组件中
  • 自动进行边缘计算调试/停用操作，包括初始软件部署和资源管理系统组件的升级。
  • 自动化数据和工作负载重定位 - 跨地域分布式硬件的负载平衡。
• 基础设施的"核心"应该需要抽象状态传播的某种形式的同步，以应对不连续的网络链路。
• 需要新方法以解决由于连接受限导致的处理网络分区问题 - 应对短暂断开和长时间断开连接。
• 边缘应用生命周期的管理工具，包括：
  • 高级安置定位约束的定义，以便处理应用程序组件的延迟需求
  • 应用程序预置和调度应当满足安置的需求（初始安置）
  • 根据内部/外部事件（移动用例，故障，性能考虑等）迁移数据和工作负载
• 集成位置感知：并非所有的边缘计算部署都需要同一时间使用同一个程序。 可能需要支持位置和需求感知。
• 在设计宏观层面的整体架构和管理工具时，需要考虑资源有限、远程扩展能力有限的离散硬件。 能够根据需要从其他站点（无论是Mesh网络上的邻居还是分层网络中的核心元素）获取远程资源的概念，指的是本地需求的波动不会导致硬件部署的低效。