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

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

问题描述¶

自从微版本 2.72 起，nova 支持使用 neutron 端口创建具有资源请求的服务器。从 Train 版本开始，nova 还支持此类服务器的冷迁移和调整大小。然而，其他迁移操作，即，实时迁移、撤离和卸载后恢复，由于 nova 中缺少资源处理实现，仍然是不可能的。

用例¶

管理员需要能够为这些服务器请求与其他服务器相同的生命周期操作。

提议的变更¶

为了支持实时迁移、撤离和卸载后恢复，我们将遵循在 Train 规范中描述的实现模式，并在 Train 版本的冷迁移和调整大小期间实现该模式。

在 Train 实现期间，compute RPC API 方法通过必要的 RequestSpec 参数扩展了每个迁移操作。因此，在实现此规范期间，预计不需要进一步的 RPC 更改。

在撤离和卸载后恢复操作期间，compute 管理器负责更新 neutron 中的端口绑定。这些代码路径将被扩展，以便根据目标主机上的分配更新端口绑定中的分配密钥。

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

在尚未支持的迁移操作中，只有实时迁移具有重新调度循环。它在 super conductor 中的 LiveMigrationTask 中处理。在重新调度期间，需要根据在新选择的目标主机上的新分配更新 neutron 端口的端口绑定的分配密钥。

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

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

备选方案¶

无

数据模型影响¶

无

REST API 影响¶

在 Train PTG 上，我们同意将迁移操作的支持作为 bug 修复来实现，而无需任何新的微版本。在实施完成后，当前拒绝迁移操作的代码将从 API 中删除，nova 将使用任何微版本接受和支持这些操作。

我们对 Train 中的冷迁移和调整大小做了同样的事情，并将遵循在 Ussuri 中的相同模式。

安全影响¶

无

通知影响¶

无

其他最终用户影响¶

无

性能影响¶

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

其他部署者影响¶

无

开发人员影响¶

无

升级影响¶

由于解决方案依赖于最小的 RPC 版本，并且需要 compute 管理器更改，因此只有在源主机和目标主机都升级后才能支持迁移操作。因此，conductor 需要确保两个 compute 的服务版本都足够高。但是，如果 conductor 配置为 [upgrade_levels]compute=auto（例如，滚动升级），或者手动固定 compute RPC，即使源主机和目标主机都足够新，目标主机仍然可能无法获得执行端口绑定更新所需的必要信息。因此，需要基于实际用于目标 compute 的 RPC 版本进行额外的检查。这些检查将类似于为冷迁移实施的检查。

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

通常建议运营商在可能的情况下使用 heal_allocations CLI 来修复不完整的端口分配，以最大限度地减少所需的服务器迁移操作数量。

实现¶

负责人¶

主要负责人: balazs-gibizer
其他贡献者: 无

功能联络人¶

功能联络人: mriedem

工作项¶

对于每个迁移操作

在调度之前，从 neutron 收集请求的资源，并相应地更新 RequestSpec
在调度器选择迁移操作的目标后，计算资源提供者 - 请求组映射，并根据目标分配更新 neutron 端口绑定。这发生在撤离和卸载后恢复的 compute 端，但仍然发生在实时迁移的 conductor 中。
如果涉及 SRIOV 接口，请更新 InstancePciRequest，以驱动目标 compute 上的 PCI 资源声明，以从与端口资源分配相同的 PF 消耗 VFs。

对于实时迁移，还需在 super conductor 中处理重新调度。

依赖项¶

无

测试¶

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

对于实时迁移，重新调度也需要用功能测试覆盖。

当源 compute 恢复时，compute 管理器会清理撤离的实例。我们需要测试覆盖，以确保带宽分配从源主机清理，但 neutron 端口绑定不会更改，因为预计它已经指向目标主机分配。

文档影响¶

API 指南使用具有资源请求的端口将相应更新。此外，neutron 管理指南的限制部分服务质量保证最小带宽需要更新。

参考资料¶

历史¶

修订版¶
发布名称	描述
Train	引入
Ussuri	更新以显示 Ussuri 剩余的范围。

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