具有资源请求的端口的服务器迁移操作

https://blueprints.launchpad.net/nova/+spec/support-move-ops-with-qos-ports

问题描述

自从 微版本 2.72 以来，nova 支持使用 neutron 端口创建具有资源请求的服务器。但是，由于 nova 中缺少资源处理实现，因此无法迁移这些服务器。

用例

所有者或管理员需要能够调整大小、迁移、实时迁移、撤离并在卸载后恢复具有资源请求端口的服务器。

在 Stein 之前，服务器可以使用具有 QoS 最小带宽策略规则的 SRIOV 端口创建，并且在调度期间，Placement 中不会强制执行资源分配。在实施此规范后，管理员将能够迁移这些服务器，并且迁移将修复 Placement 中缺失的端口分配。

提议的变更

《带宽资源提供程序规范》的实施引入了 requested_resources 字段到 RequestSpec 版本化对象中。在服务器创建期间，此字段基于 neutron 端口的资源请求填充。nova 调度程序会生成分配候选查询，其中包括来自 requested_resources 字段的请求组。

但是，此字段不会有意持久化到数据库中，因为端口资源请求由 neutron 拥有和持久化。因此，在创建现有服务器的新分配的任何操作期间，需要从 neutron 查询端口资源请求，并在将新的分配候选查询发送到 Placement 之前，在 RequestSpec 中填充 requested_resources。

在 Placement 中创建新的分配后，需要更新 neutron 端口的 binding:profile 中的 allocation 键，以指向为端口提供资源的新的资源提供程序。为了确定在给定分配中哪个资源提供程序满足哪个端口的资源请求，可以重用已经引入的映射代码。

这些迁移操作如下

  • 调整大小

  • 迁移

  • 实时迁移

  • 撤离

  • 在服务器卸载后恢复

通用步骤如下

  • 服务器迁移请求到达 Conductor

  • Conductor 调用查询绑定到服务器的 neutron 端口

  • Conductor 根据端口的资源请求更新 RequestSpec.requested_resources 字段

  • Conductor 请求调度程序进行 select_destination

  • 调度程序根据 RequestSpec.requested_resources 将 allocation_candidate 查询发送到 Placement，然后选择并分配一个候选者

  • Conductor 根据从调度程序返回的 Selection 对象，更新 RequestSpec 中的端口 - 资源提供程序映射

  • Conductor 根据 Selection 对象，向 Compute 请求迁移操作。

  • 目标 Compute 更新 neutron 中的端口绑定。根据 RequestSpec 中的映射，也会更新 binding:profile 中的 allocation 键。

在调整大小和迁移期间，Compute 管理器的 finish_resize 调用执行端口绑定更新。但是，RequestSpec 未传递给此调用。因此，需要使用新的 request_spec 参数扩展 RPC API。从源主机的 resize_instance 调用调用 finish_resize，该调用也没有获得 RequestSpec，因此也需要扩展此 RPC 调用。幸运的是，目标主机的 prep_resize 调用已经获得了 RequestSpec，因此它可以将额外的参数传递给 resize_instance。

在确认调整大小（和迁移）期间，就像今天一样，会删除源分配，无需额外步骤。

在撤销调整大小（和迁移）期间，分配将在目标主机上删除，并且源主机的分配将从 migration_uuid 作为消费者移回 instance_uuid。这里不需要额外步骤。但是，需要将端口重新绑定到源主机，并且在此绑定期间，还需要恢复 binding:profile 的 allocation 键。这意味着需要根据恢复的分配和来自 Placement 的数据重新计算映射。或者，我们可以在 MigrationContext 中存储旧映射，或者开始使用多端口绑定 API，并在旧绑定中保留旧映射。这些替代方案都给解决方案带来了额外的复杂性。

在调整大小到同一主机期间，今天的分配在 Placement 中会加倍。端口相关的分配也是如此。

在撤离期间，Compute 管理器的 rebuild_instance 调用执行端口绑定更新。此调用具有 request_spec 参数，因此不需要扩展此 RPC API。

在卸载实例后恢复时，Compute 管理器的 unshelve_instance 调用执行端口绑定更新，并且需要使用新的 request_spec 参数扩展 RPC API。

在实时迁移期间，nova 使用 neutron 的多绑定 API 以并行方式管理源主机和目标主机上的绑定。Conductor 在 neutron 上创建新的非活动绑定，并根据 RequestSpec 在新的绑定中添加 allocation 键。当实时迁移完成后，源端口绑定将与源主机分配一起删除。如果实时迁移回滚，源主机绑定仍然具有正确的 allocation 键设置。

如果端口具有资源请求，则无法关闭 neutron 的多绑定 API 扩展，因此 nova 可能会在实时迁移操作失败时失败。

如果服务器具有附加的具有资源请求的端口，则 nova 当前会拒绝这些迁移操作。在实施上述更改后，将允许这些操作。我们将在 REST API 影响 部分中描述如何发出 nova 能够支持这些操作的信号。

备选方案

有关 REST API 更改的替代方案，请参阅 REST API 影响 部分。

一种替代实施方案可以依赖于 neutron 的所有迁移操作的多端口绑定 API。在这种解决方案中，不需要将 RequestSpec 对象传递到每个迁移操作中的 nova-compute，因为可以在 Conductor 中使用必要的分配信息创建非活动绑定。但是，此解决方案仍然会导致 nova-compute 影响，以激活绑定进行迁移，而不是像今天一样创建新绑定。

数据模型影响

无

REST API 影响

有两种不同的方法来发出 nova 可以处理这些服务器的迁移操作的信号

  • 引入一个新的微版本。如果使用旧的微版本请求这些服务器的迁移操作，则请求将被拒绝，就像今天一样。如果使用新的（或更新的）微版本请求迁移操作，则请求将被接受并正确处理。

  • 将缺少对这些操作的支持视为错误。以错误修复的形式实施上述建议的更改，而无需任何新的微版本。实施完成后，使用任何微版本请求此类迁移操作都将被接受并正确处理。

有关这些选项的背景信息，请参阅 ML 线程。在 Train PTG 上，我们 同意使用错误修复方法。

安全影响

无

通知影响

无

其他最终用户影响

无

性能影响

在迁移操作期间，Conductor 需要查询 neutron 以获取附加到服务器的端口的资源请求。此外，在调度后，需要重新计算请求组 - 资源提供程序映射，并在 neutron 中更新端口的 binding:profile。

其他部署者影响

无

开发人员影响

无

升级影响

由于该解决方案需要 RPC 更改，因此只有在源主机和目标主机都升级后才能支持迁移操作。因此，Conductor 需要确保两个 Compute 的服务版本都足够高。这与 Conductor 在实时迁移期间检查服务版本的方式 类似。但是，如果 Conductor 配置为 [upgrade_levels]compute=auto（例如，滚动升级），即使源主机和目标主机都足够新，但系统中存在较旧的 Compute，也会使用较旧的 RPC 版本，并且 RequestSpec 将从调用中剥离。因此，需要进行额外的检查。nova-compute 需要检查实例是否具有需要映射的端口，如果调用中未提供 RequestSpec，则需要使操作失败。

支持迁移操作可以修复缺失或不一致的端口分配，因为在迁移期间会重新计算请求的资源，并在 Placement 中相应地创建新的分配。这将补充 nova-manage placement heal_allocations CLI 的端口分配修复功能，该功能在这方面具有多个限制。

通常，具有不完整端口分配的运营商建议尝试使用就地 heal_allocations CLI 来修复，以尽量减少所需的服务器迁移操作数量。

实现

负责人

主要负责人

balazs-gibizer

其他贡献者

无

工作项

  • 以单一步骤将 RequestSpec 添加到 Compute RPC 调用中。

  • 将对每个迁移操作的支持作为单独的任务实施。

依赖项

无

测试

每个迁移操作都将具有一个功能测试，该测试断言迁移后存在正确的分配，删除了旧分配，并且 neutron 中的端口绑定引用了适当的资源提供程序。

文档影响

API 指南 使用具有资源请求的端口 将相应更新。Neutron 管理指南 服务质量保证最小带宽 也需要更新。

参考资料

历史

修订版

发布名称

描述

Train

引入