Cyborg-Nova 交互

https://blueprints.launchpad.net/cyborg/+spec/cyborg-nova-interaction

Cyborg 作为一种管理任何类型加速器的服务，需要与 Nova 在两个层面进行协作：Cyborg 应该能够通过 placement API[1] 向 Nova 提供资源信息，以便调度器可以将用户对特定功能的请求转化为使用具备加速器的资源提供商分配特定资源，其次，Cyborg 应该能够提供 Nova 计算节点如何将特定资源附加到 VM 的信息。

简而言之，这个蓝图将定义 Nova 和 Cyborg 之间如何交换信息。

问题描述

目前在 OpenStack 中，对非标准加速器硬件的支持体现在许多核心服务器中都存在允许分配、直通并最终使用这些资源的功能。

然而，仍然存在一个挑战，即缺乏集成的工作流程；在没有大量手动操作和违反易用、稳定和灵活云目标的的服务中断的情况下，无法配置许多加速器功能。

Cyborg 旨在将这些分散的努力整合到一个更标准化的工作流程中。虽然此工作流程的许多组件已经存在，但有些则不存在，并且需要专门为此目标编写。

用例

所有可能的使用案例都在 backlog Nova spec [2] 中简要描述。可以区分两种主要的使用案例组，加速器可能用于这些组

  • 加速器可以附加到 VM，其中工作负载需要加速。这可以通过直通整个 PCI 设备、传递来自 /dev/ 文件系统的特定主机设备、传递虚拟功能等方式实现。

  • 加速器可以被基础设施利用，例如加速虚拟交换机（例如 Open vSwitch），然后通过适当的服务（例如 Neutron）利用。

提议的工作流程

使用与此提案无关的方法，Cyborg Agent 检查硬件并找到它感兴趣的用于设置的加速器。

这些加速器注册到 Cyborg 数据库，Cyborg Conductor 现在负责使用 Nova placement API 创建相应的 traits 和资源。

Cyborg Conductor 的主要职责之一是使 placement API 与现实保持同步。例如，如果有一个具有虚拟功能或具有给定程序的 FPGA，Cyborg 可能被要求更改 NIC 上的虚拟功能或 FPGA 上的程序。此时，先前指定的 traits 和资源需要更新。同样，Cyborg 将监视 Nova 的实例，以确保这样做不会从分配的实例下撤出资源。

从高层来看，我们需要能够做到以下几点

  1. 实时将 PCI 设备添加到 Nova 的白名单（仅配置 / 需要实现）

  2. 将有关此设备的信息添加到 placement API（现有 / 正在进行中）

  3. 热插拔和拔出实例的 PCI 设备（现有 / 不确定维护得如何）

备选方案

不使用 Cyborg，自己挣扎着进行服务重启和 grub 配置更改。

数据模型影响

N/A

REST API 影响

N/A

安全影响

N/A

通知影响

N/A

其他最终用户影响

N/A

性能影响

N/A

其他部署者影响

N/A

开发者影响

N/A

实现

负责人

主要负责人

无

工作项

  • Cyborg 服务实现

  • Cyborg agent 实现

  • Nova 更改的蓝图

  • 实现 POC，展示 Cyborg 和 Nova 之间的功能和互操作性

依赖项

此设计取决于 Nova 项目中可能接受或不接受的更改。除此之外，Placement API 中正在进行嵌套资源提供商的工作：https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/nested-resource-providers.html 这将是 Placement API 中的一项基本功能，Cyborg 将利用它。

测试

需要提供另一个 gate，为测试提供加速器。

文档影响

  • 记录新的 nova api 用于白名单

  • 记录开发人员和用户与工作流程的交互

  • 记录 placement api 标准标识符

参考资料

历史记录

修订版

发布名称

描述

Queens

引入