解决联合边缘资源面临的挑战

2.1 引言

目前的研究主要集中在将资源从集中的云数据中心分散到网络边缘，并利用这些资源来提高应用程序的性能。边缘资源以Ad Hoc方式配置，且一个应用程序或应用程序的集合可私有地使用它们。

Ad Hoc：点对点 来自拉丁语

联合边缘部署中两个关键挑战——组网和管理。

组网挑战的关键问题是：“如何创建一个足够动态的组网环境，与联合设置中预见的边缘计算场景相兼容？”动态性是由组网资源的可编程性提供的，这些资源在当今的环境中可通过软件定义网络（SDN）获得。具有北向编程接口的SDN是边缘资源编排的理想候选者。本地边缘部署与联合基础架构之间的协调是至关重要的，因为可能从竞争的角度来看，系统的两个视图将基于相同的网络资源。

北向编程接口：向上提供的接口，是控制层与上层（应用层）交互的接口。

南向编程接口：向下（基础设置层）发流表，指导这些设备的包转发行为。

SDN本质上是实现控制、管理、转发之间的分离，提高网络控制与管理的效率，弹性响应也会更好。

与任何大规模计算基础架构一样，解决管理挑战成为提供无缝服务的关键。未来的互联网架构需要考虑如何根据需求将服务从一个节点快速迁移到另一个节点。由于高开销和对资源受限环境（例如边缘）的适用性的缺乏，当前实现这一目标的技术范围有限。我们将对管理问题（基准测试、供应、发现、扩展和迁移）进行讨论，并提供解决这些问题的研究方向。

尽管有许多参考架构可用于基于边缘的系统，但我们还没有看到这些系统的实际实现。硬件解决方案是针对特定的应用程序定制的，并在很大程度上带来难以桥接的异构性。将边缘集成到云计算生态系统中会导致互联网架构发生根本性的变化。许多部署可以在模拟器中建模，这些模拟器具有实验可重复性的优点，最大程度地降低了实验测试台的硬件成本，并在受控环境中进行测试。

术语“边缘”来指通过分散数据中心资源以使计算资源更接近最终用户的技术集合。移动云计算（MCC）、微云、雾计算和多接入边缘计算（MEC）都可以被视为边缘计算的实例。

2.2 组网挑战

网络基础设施需要确保所部署应用程序和服务的QoS不受影响。促进边缘计算的活动协调必须是无缝的并且对最终用户是隐藏的。一般的组网挑战在于如何应对预期的边缘的高度动态环境。这将直接影响用户的移动性。当计算资源靠近流量源时，服务就变得上下文相关。这导致需要处理从一个边缘节点到另一个边缘节点的应用层切换。根据用户所在位置以及请求模式的形式方式，服务的位置可能随时发生变化。

2.2.1 联合边缘环境中的组网挑战

联合边缘资源会带来很多与可扩展性相关的组网挑战。不同管理域之间的全球同步需要在联合边缘中维护。单个边缘部署将具有不同的特征，需要从多个域进行不同的服务卸载，并且需要跨联合部署同步进行。

• 以服务为中心的模型

  在边缘实现以服务为中心的模型，传统的以主机为中心的模型遵循“给定地理位置的服务器”模型，该模型在许多方面具有限制性。在全球边缘部署中，重点需要放在“什么”而不是“在哪里”上，这样就可以在事先不知道其地理位置的情况下请求服务。服务可以具有唯一的标识符，可以在多个区域中被复制，并且可以进行协调。

• 可靠性和服务移动性

  确保可靠性和服务移动性。用户设备和边缘节点可以立即与互联网连接和断开，这可能导致不可靠的环境。临时终端用户设备可能期望通过即插即用功能实现无缝服务以从边缘获得服务。但不可靠的网络可能导致延迟。实现可靠性的一种机制是复制服务或促进服务从一个节点到另一个节点的迁移（在管理挑战中考虑）。这里的关键挑战是将开销保持在最低限度，这样应用程序的QoS就不会受到任何影响。

• 多个管理域

  管理多个管理域。网络基础设施需要能够跟踪网络、边缘服务器和部署在其上的服务的最新状态。与场景无关，网络应将请求转发给服务器并将响应返回给最终用户。在此过程中，数据报可以通过多种传输技术跨多个不同的域传输。考虑到这种异构性，用户体验不能受到影响，而技术细节可能需要隐藏在用户设备中。

解决上述挑战需要一种能够同时继承集中式和分布式系统特性的解决方案。为了实现网络的全球视图并在不同的管理域之间保持同步，网络编排器需要遵循集中式结构。但是，需要分发用于协调私有域的内部操作的控制操作。网络的控制应该分布在网络上，但是应该放在逻辑上集中的上下文中。

2.2.2 解决组网挑战

SDN作为解决组网挑战的方案。SDN的关键概念是将控制平面与数据平面分开，并将核心逻辑集中在基于软件的控制器上。控制器通过其逻辑集中式结构维护底层网络资源的总体视图。这简化了网络的管理、增强了资源的容量，并通过更有效地利用资源降低了复杂度障碍。SDN通过随时监控网络状态，促进动态环境中的即时决策。

控制平面通过OpenFlow协议与底层网络节点通信，该协议被视为SDN南向接口的事实标准。定义网络行为的应用程序通过北向接口与控制器通信，尽管它仍然需要被标准化。可编程控制平面可以是集中的或物理分布的。SDN和OpenFlow的初始方案考虑了校园环境，并且假设控制通道能够处理典型的覆盖区域，设计标准基于单个控制器。为了使边缘部署可被公开访问并在边缘构建全球计算资源池，应分布控制平面以便与多个控制实例协调。

控制平面的逻辑集中方案是通过简化已连接设备和资源的管理来管理用户移动性的关键特征。当新设备连接到网络或由于移动性而在另一个网络中进行身份验证时，网络应尽快响应并提供即插即用的功能。OpenFlow发现（OFDP）协议授予SDN控制器拓扑发现功能。一旦终端用户的状态发生变化，控制器就会立即更新相应的流规则。通过作为北向应用程序实现的模块，可以频繁地检查拓扑，并且可以在拓扑视图上更新任何新添加、断开连接或已修改的节点。节点可以是最终用户设备、计算资源或交换机。控制器可以在更新拓扑视图的同时处理每种类型组件的集成。这种方法还支持应用层切换，这是由服务卸载期间的移动性触发的。

利用基于OpenFlow的交换机（如OpenSwitch）和SDN控制器作为整个系统的保护伞，通过更好的管理解决方案提高了控制的有效性。考虑到用户定义的策略描述网络行为的北向应用程序，网络可以是被动的或主动的。通过交换OpenFlow消息从数据平面元素收集统计信息（例如由某个节点或链路转发的业务负载），SDN控制器可以指定流规则，从而在网络中获得近乎最优的解决方案。在边缘计算的情况下，多租户共享资源并且应用程序实例在延迟方面强制执行严格的QoS标准，如果边缘服务器负载过高或有出现拥塞的可能性，则SDN控制器可以修改网络边缘的流规则。SDN控制器不仅监控网络节点和链路的状态，还可以通过北向应用程序与服务器监控功能集成。

联合边缘资源创建了一个全球可访问的基础架构，但也使环境更具有动态性。管理单个域内的移动性、处理同一附近服务器之间的应用层切换，以及对由于一组用户引起的改变做出相应可以通过单个控制平面组件加以利用。单个控制平面无法满足各种类型的设备和管理域的全球管理。SDN和OpenFlow的发展允许逻辑上集中但物理上分散的控制平面。数据流量可以通过属于不同服务提供商的至少两个不同域转发。可以部署控制器来处理单个域内的操作。可以将控制平面组织为分层结构或平面结构。在分层结构中，主平面提供域之间的同步，较低级别的控制器负责其自己的域。如果在域内发生事件，则相应的控制器可以通过通知主控制器来更新其他控制器。当采用平面结构时，控制器彼此直接通信并通过其东西接口实现同步。

在联合边缘设置中，分布式控制平面将在解决可伸缩性和一致性问题方面发挥重要作用。考虑到以服务为中心的环境，多个控制器应同时处理协调服务复制和跟踪其位置。如果没有SDN和可编程网络提供的灵活性，则需要额外的努力来实现以服务为中心的设计。由于SDN可以内在地检索底层网络的最新视图，因此控制器可以跟踪服务位置。将服务标识符映射到位置列表的北向应用程序为将以服务为中心的模型嵌入到全球边缘设置中铺平了道路。每当用户通过指定其标识符来卸载服务时，负责该域的控制器可以检查该信息并检索可能的目标列表。借助相邻的负载平衡北向应用程序，网络可以确定最可行的服务器并通过修改数据报的头字段来转发请求。如果目的地部署在另一个区域，则转发操作要求数据包在多个域上路由，并且由分布式控制平面的协同工作处理。如果在区域内部署新服务或创建服务复制，则负责的控制器首先更新其数据库并创建一个事件，以通知其他控制器保持同步。通过东西接口交换的OpenFlow消息在事件发生时提供全球同步。

创建、迁移和复制服务必须在边缘完成，以处理不同的流量模式和负载均衡。由于SDN确定了可能的目标节点，以及可用于迁移服务以使性能受到的影响最小（阻止拥塞）的路径，SDN再次成为一个候选解决方案。SDN以管理和处理异质性良好而著称。从网络角度来看，联合边缘环境通常是异构的，因为除了不同的流量模式之外，它们还包括不同的网络类型。控制平面可以为边缘服务器和终端用户设备提供一个可互操作的网络环境，该环境包括不同提供商的多个域。不同网络设备之间的供应商依赖性和兼容性问题也被消除了。

2.2.3 未来研究方向

• 无线组网和SDN实施

  现有的研究和实际实施通过SDN实现网络虚拟化。但是，重点通常是有线网络中SDN控制器的虚拟化和管理。我们相信SDN和当前标准（如OpenFlow）的优势必须通过无线网络充分利用，以便联合边缘节点，而这些节点在未来主要服务于移动社区。

• 可操作性接口的标准化

  OpenFlow目前是南向接口的事实标准。北向通信并没有公认的标准（尽管北向标准的开放网络基金会（ONF）组织了一个工作组）。缺乏标准化会妨碍在同一控制器上运行的北向应用程序之间的互操作性。现有的基于SDN的场景不依赖于东西接口，并且该领域的研究很少。相邻控制器之间的通信需要变得更加可靠和有效，以免给控制信道带来负担。专注于这一领域的将会为边缘联合计算资源池提供机会。

• 增强现有标准和接口的可编程性

  最新版本的OpenFlow（v1.5.1）仅在网络中提供部分可编程性。需要进一步研究以增强标准和接口的可编程性。

• 覆盖更广泛地理区域的SDN平面的可扩展性

  需要分布式SDN控制平面与相邻控制器通信。需要进一步研究SDN平面的扩展性。因为没有适用于东西接口的标准，而这需要应用于控制器间的通信。

2.3 管理挑战

在云和用户设备之间增加单层边缘节点会带来显著的管理开销，当边缘节点的集群需要从不同的地理位置联合以创建全球架构时，这将更具有挑战性。

2.3.1 联合边缘环境中的管理挑战

• 发现边缘资源

  与在个体层面和集合层面发现边缘资源有关。在个体层面，提供计算的潜在边缘节点需要在网络中可见，在用户设备上运行的应用程序及其各自的云服务器。在集合层面，给定地理位置（或任何其他粒度）的边缘节点集合将需要对其他边缘节点集合可见。边缘节点是自发起的并导致松散耦合的集合，由外部监控器发起并导致紧密耦合的集合，或者是两者的组合。

• 部署服务和应用程序

  在边缘上部署服务和应用程序有关。通常，需要将可以从用户设备提供请求的服务卸载到一个或一组边缘节点上，如果不了解目标边缘的功能并将它们与服务或应用程序的需求（例如预期的负载和所需资源量）相匹配，这将是不可能的。在同一地理位置可能有多个边缘节点集群可用，同时对多个边缘节点（或多个集合）进行基准测试对于满足服务目标至关重要。

• 跨边缘迁移服务

  现有技术允许使用虚拟机（VM）、容器和单核技术部署应用程序和服务。可以部署应用程序并跨数据中心迁移它们。还需要考虑网络中用于将服务从边缘节点迁移到另一个节点的最短路径。

• 负载均衡

  在边缘有大量服务订阅，则需要管理单个边缘节点或集合中单个服务的资源分配。如果与边缘处休眠的其他服务相比，有一个服务订阅量很大，那么分配给订阅量很大的服务的资源将需要进行扩展。需要建立机制来扩展一个服务（可能是大量订阅）的资源，同时从休眠服务中解除分配的资源。监控和扩展机制都需要确保完整性，这样工作负载才能相当平衡。

2.3.2 目前的研究

用于发现边缘节点的现有技术可以基于它们是否在多租户环境（例如，边缘节点上可以承载多个服务）中操作来分类。FocusStack在单租户环境中发现边缘节点，而ParaDrop和边缘即服务（EaaS）在多租户边缘环境中运行。在联合多个边缘节点集合时，还需要解决一些额外的挑战以实现发现。

部署服务的研究主要集中在部署前资源供应（在部署应用程序之前将应用程序的需求与可用资源匹配）。由于边缘上预期的工作负载的可变性（需要在边缘节点的集合上托管更多的应用程序），因此在单个边缘节点和联合边缘资源的环境中，后期部署变得更加重要。在分布式集群上运行的工作负载部署服务专注于大型作业，例如Hadoop或MapReduce。但是，联合边缘资源将需要适用于更细粒度工作负载的后期部署技术。

通过虚拟机跨集群迁移服务是可能的，但实际上有很大的时间开销。虽然是可能的（尽管迁移需要花费几分钟），但使用现有策略进行实时使用仍然具有挑战性。需要研究替代的轻量级技术，如容器，以及如何将它们用于迁移边缘工作负载，并且需要将支持这些技术的策略整合到容器技术中。

监控边缘资源是实现负载平衡的关键要求。需要监控性能指标来实现弹性伸缩方法以平衡边缘上的工作负载，现有的分布式系统的监控系统要么没有扩展，要么消耗资源，不适用于大规模资源受限的边缘部署。目前用于自动扩展资源的机制仅限于单边节点，并采用轻量级监控。

2.3.3 解决管理挑战

四个研究挑战中的三个（发现、部署和负载平衡）是在EaaS平台和ENORM框架上的贝尔法斯特（Belfast）的各个边缘节点的背景下解决的。

• 边缘即服务平台

  EaaS平台以发现挑战为目标，并为同构边缘资源集合（Raspberry Pi）实现轻量级发现协议。EaaS平台在三层环境中运行——顶层是云，底层包含用户设备，中间层包含边缘节点。该平台需要一个主节点，该主节点可以是计算可用的网络设备或专用节点，并且执行与边缘节点通信的管理器进程。主节点管理器与潜在的边缘节点通信，并在边缘节点上安装管理器以执行命令。主节点上提供管理控制面板以监视各个边缘节点。一旦EaaS平台发现边缘节点，就可以部署Docker或LXD容器。该平台在类似于流行的《精灵宝可梦Go》的在线游戏环境中进行了测试，以提高应用程序的整体性能。

  该平台的好处是实现的发现协议是轻量级的，并且启动、开始、停止或终止容器的开销是几秒钟。其在单个边缘节点上启动了多达50个具有在线游戏工作负载的容器。这是在单个边缘节点集合的环境中执行的。在联合边缘环境中使用这种模型还需要进一步的研究。EaaS平台的主要缺点是它假设了一个可以与所有潜在边缘节点通信的集中主节点。该研究还假设可以查询边缘节点，并且可以通过所有者在公共市场中获得边缘节点。尚未考虑主节点在边缘节点上安装管理器和在边缘节点上执行命令的相关安全影响。

• 边缘节点资源管理框架

  边缘节点资源管理（ENORM）框架主要解决各个边缘节点上的部署和负载平衡挑战。与EaaS平台类似，ENORM在三层环境中运行，但主控制器不控制边缘节点。假设它们对想要利用边缘的云服务器是可见的。该框架允许对云服务器进行分区并将其卸载到边缘节点，以提高应用程序的整体QoS。该框架以用于将工作负载从云服务器部署到边缘服务器的供应机制为基础，云和边缘服务器通过握手建立连接，以确保有足够的资源满足将被卸载到边缘的服务器的请求，供应机制满足应用程序服务器的整个生命周期，从通过容器将其卸载到边缘，直到它终止并通知云服务器。

  单个边缘节点上的负载平衡是通过弹性伸缩算法实现的，假设边缘节点可以是流量路由节点，例如路由器或移动基站，因此卸载的服务不应该损害在节点上执行的基本服务（流量路由）的QoS。在边缘节点上执行的每个应用程序服务器都具有优先级，每台边缘服务器都受到监控（从网络和系统性能两方面考虑），并估计是否可以满足QoS。如果具有较高优先级的边缘服务器无法满足其QoS，则会缩放应用程序的资源。如果在边缘上无法满足应用程序的资源需求，则会将其移回卸载它的云服务器。ENORM框架也在在线游戏用例和EaaS平台上得到了验证。值得注意的是，应用程序延迟可以减少20%到80%，并且针对此用例传输到云的整体数据减少了高达95%。

2.3.4 未来研究方向

EaaS平台和ENORM框架都具有局限性，它们没有假设联合边缘资源。

• 协调多个边缘集合的异构节点之间的管理任务

  联合边缘资源不可避免地需要将异构边缘节点（路由器、基站、交换机和专用低功率计算设备）集合在一起。虽然管理同类资源本身可能具有挑战性，但协调多个异构资源集合将更加复杂。这里的挑战是通过标准协议实现所需的协调，以便在地理位置不同、具有不同CPU架构的设备之间进行管理，并且设备本身可以用于网络流量路由。

• 为联合边缘资源开发实时基准测试服务

  边缘节点的计算能力和（通过节点的流量的）工作负载不同，云服务器需要对边缘节点组合进行可靠的基准测试。该组合可以来自不同的地理位置，如果需要在边缘上部署分区工作负载，则通过基准测试，应用程序服务器可以识别可满足服务级目标（SLO）的边缘节点。

• 促进联合边缘资源之间的快速迁移

  迁移技术在尝试从一个节点迁移到另一个节点时，通常至少会有几分钟的开销。这一开销明显会随着地理距离增加而增加。当前的迁移机制在边缘节点上获取虚拟机或容器的快照，然后将其传输到另一个节点。为了便于快速迁移，可能需要开发其他虚拟化技术，以允许迁移更抽象的实体（如函数或程序）。这项技术也可用于未来的无服务器计算平台，以开发跨联合边缘资源的互操作平台。

• 使用弹性伸缩调查用于负载平衡的细粒度资源分配/解除分配

  当前的弹性伸缩方法在边缘上添加或移除离散的预定义资源单位以进行弹性伸缩。这种弹性伸缩在资源受限的环境中是有限的，因为资源可能被过度供应。需要研究代替机制，这些代替机制可以根据特定的应用程序要求获得需要分配/解除的资源量，以满足SLO而不会影响边缘环境的稳定性。

2.4 其他挑战

2.4.1 资源挑战

• 定义边缘节点

  第一个资源挑战与部署边缘节点有关。目前尚不清楚边缘节点是否可能是以下三者之一：流量路由节点，例如路由器、交换机、网关和通过其上的CPU集成通用计算的移动基站；具有低功率计算设备的专用计算节点，在这些设备上可以实现通用计算，例如微云；前两者的混合。

• 考虑异构性的统一架构

  从软件、中间件和硬件的角度来看，将具有不同性能和计算资源的不同类型的基于边缘的节点作为一个连贯的单层或多层可能具有挑战性。鉴于从小型家庭路由器到微型云设备的各种边缘计算选项，联合它们将需要在所有节点上开发统一的可互操作标准。在云中，大量计算资源具有相同的底层架构。需要以对基础硬件无关的方式执行应用程序和服务。目前通过虚拟化或容器化实现这一目标的研究并不适用，并且无法用于所有硬件架构。

• 边缘节点的公共可用性

  第三个资源挑战与边缘节点的公共可用性有关。无论边缘层被如何启用，预计它都可以被访问，既可以用于使云端的计算更接近用户设备，也可以用于服务用户设备的请求，或者在将数据发送到云端之前处理大量传感收集的数据。这引发几个问题：

  • 如何审核边缘节点？
  • 使用哪个接口使其可被公开访问？
  • 需要哪种计费模式？
  • 边缘需要采取哪些安全和隐私措施？

• 与通信网络的互操作性

  第四个资源挑战与未来通信网络的互操作性有关。资源管理策略应该考虑网络资源以及使用边缘系统有效运行的计算资源。在触觉互联网层面提供的QoS使得5G系统成为边缘接入的强有力的替代方案。考虑到边缘系统的潜力，欧洲电信标准协会（ETSI）与电信行业的许多贡献者一起开始了多接入边缘计算（MEC）标准化工作。MEC是一种边缘计算架构，被视为5G系统的固有组件。对于5G的实际部署，边缘计算服务是否依赖MEC功能，或者它是否将利用高带宽5G网络功能并将自己定位为”顶层“（OTT）尚不清楚，这将取决于成本和开放性等参数。ETSI-MEC凭借其在5G架构中的固有地位，将紧密耦合总体上的边缘系统以及它与电信运营商对整个网络的运营联合。

• 边缘系统的网络切片

  第五个资源挑战与调整边缘系统的网络切片有关。预计切片是未来网络将提供的另一个重要机遇。网络切片被定义为覆盖在物理或虚拟网络上的逻辑网络，可以使用一组参数按需构建。切片将允许网络运营商满足特定一个服务或一组服务的QoS。尽管切片不是边缘计算特有的方法，但它会显著影响边缘系统的操作和性能。专用于一个边缘服务器上的每个服务的端到端切片是有益的。与边缘计算相关的切片需要考虑边缘服务器和云服务器之间的交互量。一种简单的方法是为每个边缘部署分配切片，并期望边缘编排系统在边缘系统内分配额外的资源。在联合设置中，可以将有限容量的资源分配给一组独立边缘系统，并且可以在考虑资源使用模式的同时全局调整单个边缘系统的整体切片。

2.4.2 建模挑战

Living Edge Lab就是一个实验测试平台。模拟器的核心是一个捕捉环境的复杂数学模型。

• 计算资源建模

  边缘服务器将通过虚拟化技术（如虚拟机和容器）为其用户提供计算能力。此环境中的模拟环境应支持虚拟资源的创建、大小调整和迁移，并在不同粒度级别（进程、应用程序和整个节点）上模拟CPU、内存和网络资源消耗。

• 需求建模

  能够对边缘计算系统上的负载建模，需要对个体用户（或用户集合）引起的边缘资源的需求进行建模。移动设备的异构性和各种应用程序产生的流量的解释是复杂的。需要考虑需求的分布和边缘流量到达时间。

• 移动性建模

  移动性是需要考虑的关键组件，用于准确地建模边缘上的时变需求。模拟环境应该允许设计实际上捕获各种形式的移动性的实验。

• 网络建模

  网络的性能和行为模式对于边缘系统的整体操作至关重要。这种要求是由于前面描述的切片方法而产生的，其中需要在网络中建模多个网络切片。

• 模拟器效率

  模拟器需要具有可伸缩性、可扩展以适应不断变化的基础架构要求，并且易于使用。考虑到即将到来的物联网和及其对机器通信，考虑到联合边缘资源的模拟器的时间复杂性应该为大量设备和用户的连接建模。

参考文献：《雾计算与边缘计算 原理及范式》