Nova - Cyborg 交互

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

本文档描述了 Nova 与 Cyborg 交互以创建和管理带有加速器的实例所需的内容，以及为实现这一目标 Nova 需要进行的更改。

问题描述

范围

Nova 和 Cyborg 需要在许多方面进行交互，以处理带有加速器的实例。虽然本文档涵盖了所有方面，但其他文档中会详细介绍特定领域。我们将在下面列出所有领域，确定其他文档涵盖的具体部分，并描述本文档涵盖的内容。

  • 表示：Cyborg 应将设备表示为计算节点下的嵌套资源提供者（可能不包括分离式服务器），将加速器类型表示为资源类，将加速器表示为 Placement 中的库存。用于调度的属性表示为特征。这在 1 中有说明。本文档不会深入探讨此主题。

  • 发现和更新：在主机中发现的设备中，Cyborg 打算仅声明未包含在 PCI 白名单机制中的那些设备。Cyborg 应以与 virt 驱动程序更新 Placement 兼容的方式更新 Placement。这些方面分别在 与 PCI 白名单共存 和 Placement 更新 部分中介绍。

  • 加速器用户请求：用户通常通过 flavor 请求计算资源。但是，由于设备请求可能差异很大，将它们放在 flavor 中可能会导致 flavor 爆炸。我们通过在设备配置文件 2 中表达设备请求来避免这种情况。设备配置文件与 flavor 之间的关系在第 用户请求 节中探讨。

    当发出实例创建（启动）请求时，设备配置文件的内容应转换为请求规范中的请求组；请求组中的语法在第 更新请求规范 节中介绍。

  • 实例调度：Nova 应使用 Cyborg 填充的 Placement 数据来调度实例。本文档不会深入探讨此主题。

  • 加速器分配：我们在第 加速器请求 节中引入了加速器请求 (ARQ) 对象的概念。创建和使用它们的工作流程在第 Nova 分配工作流程的更改 节中总结。同一节还重点介绍了 Nova 需要进行的更改。

  • 实例操作：关于所有标准实例操作的加速器行为在 3 中定义。本文档不会深入探讨此主题。

用例

  • 用户请求将一个或多个不同类型的加速器分配给实例。

  • 操作员可以在同一集群中为用户提供设备即服务或加速功能即服务 (1)。

以下用例在本版本中未解决，但具有长期兴趣

  • 用户请求将一个或多个加速器添加到现有实例。

  • 带有加速器的实时迁移。

提议的变更

与 PCI 白名单共存

操作员通过配置 PCI 白名单机制告诉 Nova 要声明和使用的 PCI 设备。此外，操作员在计算节点中安装 Cyborg 驱动程序并配置/启用它们。这些驱动程序然后可以发现并报告一些 PCI 设备。操作员必须确保这两种配置兼容。

理想情况下，应该有一种方法让操作员识别 Nova 和 Cyborg 应该声明的 PCI 设备。在确定这一点之前，操作员应使用 Cyborg 的配置文件来指定启用了哪些 Cyborg 驱动程序。由于每个驱动程序声明特定的 PCI ID，因此操作员可以并且必须确保这些 PCI ID 中没有一个包含在 Nova 的 PCI 白名单中。

Placement 更新

Cyborg 应直接调用 Placement API 来表示设备和加速器。API 调用的一些预期用例是

  • 在计算节点 RP 下创建或删除子 RP。

  • 创建或删除自定义 RC 和自定义特征。

  • 将特征与 RP 关联或删除此类关联。

  • 更新 RP 库存。

Cyborg 不应修改由其他组件（例如 Nova virt 驱动程序）创建的 RP。

用户请求

用户对加速器的请求封装在设备配置文件 2 中，该配置文件由管理员通过 Cyborg API 创建和管理。

设备配置文件可以看作是“设备的 flavor”。因此，实例请求应同时包含 flavor 和设备配置文件。但是，这需要更改 Nova 的实例创建 API。为了减轻此类更改对用户和操作员的影响，我们建议分阶段进行此操作。

在初始阶段，Nova API 保持不变。设备配置文件作为额外的规范折叠到 flavor 中，如下所示

openstack flavor set --property 'accel:device_profile=<profile_name>' flavor

因此，可以使用标准的 Nova API 创建仅包含 flavor（不含设备配置文件）的实例，如下所示

openstack server create --flavor f ....  # instance creation

将来，设备配置文件本身可用于指定实例创建 API 的加速器资源。

更新请求规范

当用户提交实例创建请求（如第 用户请求 节所述）时，Nova 需要调用 Cyborg API，以获取设备配置文件中的资源请求组，并将它们合并到请求规范中。（这类似于 Neutron 提出的方案 4。）

此调用（以及 Nova 将要对 Cyborg API 进行的所有其他调用）通过基于 Keystone 的适配器完成，该适配器将定位 Cyborg 服务，类似于 Nova 调用 Placement 的方式。将添加一个新的 Cyborg 客户端模块到 Nova 中，以封装此类调用并提供 Cyborg 特定的功能。

Glance 中的 VM 镜像可能与镜像属性（不包括镜像特征）相关联，例如该镜像所需的位流/功能 ID。因此，Nova 应将请求规范中的 VM 镜像 UUID 传递给 Cyborg。这还有待确定。

设备配置文件中的组由 Cyborg 编号。合并到请求规范中的请求组由 Nova 编号。这些编号通常不相同，即，第 N 个设备配置文件组可能不对应于请求规范中的第 N 个请求组。

当将设备配置文件请求组添加到 flavor 中的其他请求组时，flavor 的 group_policy 应控制所有请求组的总体语义。

加速器请求

加速器请求 (ARQ) 是表示分配给实例的加速器请求状态的对象。ARQ 的创建和管理由 Cyborg 处理，ARQ 存储在 Cyborg 数据库中。

ARQ 按照定义，表示对单个加速器的请求。用户请求中的设备配置文件可能包含 N 个请求组，每个请求组请求 M 个加速器；那么，对于该设备配置文件将创建 N * M 个 ARQ。

当 Cyborg 创建 ARQ 时，它尚未与特定的主机名或设备资源提供者关联。因此，它处于未绑定状态。随后，Nova 调用 Cyborg 将 ARQ 绑定到主机名、设备 RP UUID 和实例 UUID。如果实例启动失败，Nova 将在不删除 ARQ 的情况下解绑 ARQ。在实例终止时，Nova 将在解绑 ARQ 后删除它们。

每个 ARQ 需要与 Nova 选择的分配候选对象中的特定 RP 匹配，然后才能绑定 ARQ。当前 Nova 代码将请求组映射到 RP，而 Nova 中的 Cyborg 客户端模块 (cyborg-client-module) 将 ARQ 匹配到请求组。匹配使用 RequestGroup 对象中的 requester_id 字段完成，如下所示

  • 设备配置文件中的组的顺序不重要，但由 Cyborg 保持不变。因此，每个设备配置文件请求组都有一个唯一的索引。

  • 当 Cyborg 返回的设备配置文件请求组添加到请求规范中时，requester_id 字段设置为 ‘device_profile_<N>’，其中 N 是第 N 个设备配置文件请求组（从零开始）。设备配置文件名称无需在此处包含，因为每个请求规范只有一个设备配置文件。

  • 当 Cyborg 为设备配置文件创建 ARQ 时，它会在将 ARQ 返回给 Nova 之前将设备配置文件请求组索引嵌入到 ARQ 中。

  • 匹配分两个步骤完成

    • 每个 ARQ 都使用 requester_id 字段映射到请求规范中的特定请求组。

    • 每个请求组都使用与 Neutron 带宽提供程序相同的逻辑映射到特定的 RP (5)。

Nova 分配工作流程的更改

本节总结了第 1 阶段的工作流程细节。所需的 Nova 更改用 NEW 标记。

NEW：添加了一个 Cyborg 客户端模块到 nova (cyborg-client-module)。所有 Cyborg API 调用都通过它路由。

  1. Nova API 服务器接收带有包含设备配置文件名称的 flavor 的 POST /servers API 请求。

  2. NEW：Nova API 服务器调用 Cyborg API GET /v2/device_profiles?name=$device_profile_name 并获取设备配置文件。设备配置文件中的请求组被添加到请求规范中。

  3. Nova 调度程序调用 Placement 并获取分配候选对象列表。它选择其中一个候选对象并在 Placement 中进行声明。然后，Nova conductor 向 Nova compute manager 发送 RPC 消息 build_and_run_instances。

  4. NEW：Nova compute manager 调用 Cyborg API POST /v2/accelerator_requests 并提供设备配置文件名称。Cyborg 为该设备配置文件创建一组未绑定的 ARQ，并将它们返回给 Nova。（调用可能来自 Nova conductor 或 compute manager；将在代码审查中确定。）

  5. NEW：Nova 中的 Cyborg 客户端将每个 ARQ 匹配到为该加速器选择的资源提供者。请参阅 match-rp。

  6. NEW：Nova compute manager 调用 Cyborg API PATCH /v2/accelerator_requests 将 ARQ 与主机名、设备的 RP UUID 和实例 UUID 绑定。这是一个异步调用，它会在后台准备或重新配置设备。

  7. NEW：Cyborg 在完成绑定（成功或失败）后，调用 Nova 的 POST /os-server-external-events API，并提供

    {
   "events": [
      { "name": "accelerator-requests-bound",
        "tag": $device_profile_name,
        "server_uuid": $instance_uuid,
        "status": "completed" # or "failed"
      },
      ...
   ]
}

  8. NEW：Nova compute manager 等待通知，受第 其他部署者影响 节中提到的超时限制。然后，它调用 Cyborg REST API GET /v2/accelerator_requests?instance=<uuid>&bind_state=resolved。

  9. NEW：Nova virt 驱动程序使用从 Cyborg 调用返回的 attach handles 将 PCI 直通设备组合到 VM 的定义中。

  10. NEW：如果在绑定启动后发生任何错误，Nova 必须通过调用 Cyborg API 解绑相关的 ARQ。然后，它可以尝试在另一个主机上或删除实例的（未绑定的）ARQ。

此流程由以下序列图捕获，其中 Nova conductor 和 scheduler 组合表示为 Nova 控制器。

blockdiag - OpenStack 规范 Nova Controller Placement Cyborg Nova Compute GET /v2/device_profiles?name=mydp {"device_profiles": $device_profile} Merge request grou ps into request_sp ec Get /allocation_candidates allocation candidates with ne sted RPs Select a candidate build_and_run_instances() POST /v2/accelerator_requests {"arqs": [$arq, ...] PATCH /v2/accelerator_request s {"arqs": [$arq, ...] POST /os-server-external-events Wait for notific ation from Cybor g GET /v2/accelerator_requests? instance=$uuid&bind_state=res olved {"arqs": [$arq, ....]}

备选方案

有可能让外部代理通过调用 Cyborg 从设备配置文件创建 ARQ，然后将预创建的 ARQ 馈送到 Nova 实例创建 API，类似于 Neutron 端口。我们目前不采用这种方法，因为它需要更改 Nova 实例创建 API。

有可能让 Nova virt 驱动程序轮询 Cyborg ARQ 绑定完成情况。这不是首选方法，部分原因是它不是与其他服务（如 Neutron）交互的模式。

数据模型影响

无

REST API 影响

无。将一个新的 extra_spec 键 accel:device_profile_name 添加到 flavor，但未修改任何 API。

安全影响

无

通知影响

Nova 可能会选择为 Cyborg API 调用添加额外的通知。

其他最终用户影响

无

性能影响

对 Cyborg REST API 的额外调用可能会影响 Nova conductor/scheduler 的吞吐量。通过将一些关键的 Cyborg 操作作为异步任务来缓解了这一点。

其他部署者影响

部署者需要设置 clouds.yaml 文件，以便 Nova 可以调用 Cyborg REST API。

部署者需要在 nova-cpu.conf 中配置一个新的可调参数

* arq_binding_timeout (integer): Time in seconds for Nova compute
  manager to wait for Cyborg to notify that ARQ binding is done.
  Timeout is fatal, i.e., VM startup is aborted with an exception.
  Default: 300.

开发者影响

资源类 FPGA 和 PGPU 已经标准化。但是，随着提出新的设备类型，它们将首先表示为自定义 RC，但以后可能会标准化。这种标准化需要更改 os-resource-classes。

为了使用 tempest 进行端到端测试，Cyborg 应提供一个模拟驱动程序，该驱动程序返回类型为 TEST_PCI 的 attach handles。Nova virt 驱动程序应忽略此类 attach handles，并创建好像不存在此类 ARQ 的 VM。

升级影响

无

实现

负责人

Sundar Nadathur

工作项

请参阅第 Nova 分配工作流程的更改 节中标记为 NEW 的步骤。

依赖项

无

测试

需要对 Nova 更改进行单元测试和功能测试。具体来说，需要一个模拟 Cyborg API 调用的功能测试工具。

需要针对端到端流程进行风暴测试，包括故障模式。这些风暴测试应针对一个假的驱动程序（除了任何真实硬件）进行，并与 Nova Zuul 网关关联。

文档影响

设备配置文件的创建需要在 Cyborg 中记录，如 2 中所述。

需要记录操作员将设备配置文件折叠到 flavor 中的需求。

参考资料

1(1,2)

Cyborg Nova 放置交互规范

2(1,2,3)

设备配置文件规范

3

使用加速器的实例操作规范

4

在 RequestSpec 中存储 RequestGroup 对象

5

将请求组映射到资源提供者

6

Cyborg API 版本 2 规范

历史记录

修订历史

发布名称

描述

队列

引入

Train

重新提出