在边缘实现自主工作负载管理要考虑什么？

据估计，未来三到五年，全球联网设备的数量将达到惊人的500亿。

这个数字听起来有些夸张，但不可否认的是，硅技术的进步（例如计算和传感器组件的缩小）以及5G网络的发展必将推动边缘设备的兴起，并创造更多相关的用例。

鉴于这种情况，在谈及支撑技术时，需要先确定和解决若干挑战。

最近的OpenDev会议旨在提高意识和促进这一领域的合作。自主工作负载管理的议题是其中之一。

当应用程序/工作负载必须在边缘编排时，侧重点是技术限制、要求和操作考虑。主要假设是由于连接约束、延迟、成本等原因，几个边缘计算用例（例如机顶盒，终端等微边缘/移动边缘）将要求高度自主的行为。边缘基础设施的规模也可能驱动边缘平台的这种自主行为，而对所有这些边缘设备实现集中管理将是一项巨大的任务。为此，讨论了如下几个操作考虑。

工作负载编排

当涉及在边缘自主工作负载管理时，有效的编排是最重要的问题。无论是裸机、虚拟机还是应用程序容器，都需要自动化和使用软件定义的方法。

在现在的NFVi世界中，用模型驱动的声明方法（如TOSCA）来解决编排问题是一个明确的趋势。理想情况是，边缘平台应该包括一个功能组件，不仅负责资源（例如VM或容器）的编排和管理，还负责运行应用程序或VNF。这样的实体负责运行时恢复和扩展以及配置（边缘或集中触发）。

即使目标是工作负载编排的自主操作，仍预计会有一些中心编排实体（或区域管理）会保留对边缘状态的参考或驱动边缘配置。网状边缘网络的绝对自主行为在短期内难以实现，至少大规模的如此。

状态和策略管理

自主的工作负载编排也意味着自主状态管理。为了有效地编排状态，不仅必须捕获托管平台（例如，虚拟机或容器），而且还应监视服务或应用程序状态。

现在，大部分状态管理操作都是由编排组件（资源层面）和应用程序/ VNF供应商自己处理的。然而，状态的组合视图的缺失导致故障处理相当原始：当工作负载的状态出现故障时，则重启整个资源。此外，服务功能链（SFC）或应用程序的微服务范式引入了可能需要考虑的可组合状态概念。

状态抽象也是重要的：区域编排器可能不需要保持SFC所有组件的状态，而只需整个SFC的抽象状态。另一方面，边缘编排器必须知道链中每个服务的状态。策略执行也应遵循与状态传播相同的模式。

总而言之，需要一个更强大的状态管理结构来解决这些新的要求。现有的编排器能否负责这些功能或者是否需要创造新的模块和/或协议值得讨论。

管理本地存储库的包

边缘工作负载编排的自主操作需要镜像和软件包的本地存储库。假设边缘设备与核心网络的连接不可靠或非常弱，只有控制平面操作才能通过空中传输。有人建议，编排系统应该探索缓存或本地存储库，这些存储库将应一些中心组件的需求同步。还应考虑将更新推送到边缘存储库的组播功能，特别是如果边缘设备的规模呈指数增长。

即使这里讨论的大多数问题和想法并不新颖，我们也不能假设为数据中心运营开发的技术和系统可以直接解决边缘计算用例。也许最好的方式是以崭新的视角来看待这个问题，并尝试构建一个可以为所有用例（从微的到大的边缘）提供服务的边缘计算平台，在合适的时候、合适的地方利用现有技术，同时也投资于新的技术。

编译：Karen Lee

作者：Gregory Katsaros

来源：http://superuser.openstack.org/articles/autonomous-workload-management-edge/

阅读推荐：

OpenStack能拯救混合云吗？

5大容器典型用例

投稿邮箱：openstackcn@sina.cn