迁移分配

https://blueprints.launchpad.net/nova/+spec/migration-allocations

在 Pike 版本中，我们意识到在处理实例迁移操作期间的资源分配方式存在差距。为了避免释放源节点上的资源以在目标节点上声明资源，我们需要一个占位符或临时所有者。目前，我们通过对实例在源节点和目标节点上都进行分配来解决这个问题，这看起来像是实例同时正在使用两个节点上的资源。虽然这可行，但它使得在成功和失败场景下确定哪个节点负责释放这“双重”分配的另一半变得更加困难。同主机迁移的可能性进一步增加了复杂性。

问题描述

目前存在的问题是调度器必须知道我们正在执行迁移操作，并且必须在目标节点上为实例添加一个分配，同时保留源节点上的现有分配。在迁移成功或失败后，其中一个计算节点必须清理“双重”分配的正确一半，以避免实例继续占用超过一个资源槽位。

用例

作为操作员，我希望在迁移操作期间进行适当的资源核算，以确保计算节点在实例移动时不会过度提交。

作为 Nova 开发人员，我希望在 Placement 中有明确的分配责任，以便为实例分配和释放资源的的代码简单明了。

提议的变更

整体建议的更改是让迁移操作本身（由数据库中的迁移记录标识）“拥有”为预留资源所需的两个分配中的一个。与其尝试让实例成为涉及的两个节点（源节点和目标节点）的两个分配集的消费者，我们可以让实例拥有一个分配，而让迁移拥有另一个分配。

为了做到这一点，迁移记录必须具有一个 UUID 标识符，这是需要进行的第一项更改。

一旦我们有了这个 UUID，我们将更改现有的迁移代码，将实例在源节点上拥有的分配替换为具有迁移作为所有者的相同分配。接下来，我们为实例（如果正在调整大小，则为新的 flavor）在目标节点上分配资源。如果迁移成功，我们可以简单地删除迁移在源节点上拥有的分配，并在操作完成（或确认）时。如果迁移失败，我们执行相反的操作，删除目标分配，并将源分配替换为实例拥有的分配。

这里的优势在于，我们不再尝试为实例进行双重分配，然后在成功时从该分配中减去源节点/flavor。我们可以简单地以原子方式（即创建/删除）操作分配，就像设计意图的那样。这使得单主机和多主机迁移操作的数学和机制相同，并避免了一个计算节点操作另一个节点的分配。

当前代码中还存在另一个主要问题，即在单主机调整大小时。Placement 对给定资源有一个 max_unit 的概念，它定义了任何一个消费者可以分配的该资源的上限。如果我们的 VCPU 分配超过了 max_unit 的一半，那么单主机调整大小将尝试分配超过 max_unit 的资源，并会失败。建议的更改将使迁移拥有原始分配，而实例拥有新的分配，这将有效，因为它们是单独的分配。

备选方案

当我们发现这个问题时，是在 Pike 版本的后期，我们实施了主要的替代方案，因为它破坏性较小。该选项是在操作期间用一个针对源节点和目标节点的分配替换实例在源节点上的分配。这仍然是一个选项，但在实践中，数学（尤其是对于单主机迁移）是模糊和不精确的，并且每个计算节点的所有权责任不明确。

数据模型影响

这里的主要影响是向迁移对象添加一个 UUID，该 UUID 可以用作 Placement 中源分配的消费者。

REST API 影响

没有直接的 API 影响

安全影响

无。

通知影响

无。

其他最终用户影响

如果开发了自定义工具来从 Placement 读取使用信息，那么在 pike 和 queens 之间可能会出现一些用户可见的更改。这将在 pike 部署显示一个大型中间分配/使用量，除非该工具考虑了迁移拥有的分配，否则在 queens 版本之后不会发生这种情况。

性能影响

无。

其他部署者影响

如上所述，如果部署者针对 Placement 编写了自定义工具来收集数据，他们可能会看到一些影响。但是，目前看来可能性不大。

开发人员影响

开发人员的影响将是压倒性的积极的，一旦处理了将“pike 方式”迁移到“queens 方式”的初始复杂性。分配的所有权将清晰简洁，并且迁移后清理所需的代码将大大简化。

实现

负责人

主要负责人

danms

工作项

• 向迁移记录添加一个 UUID

• 迁移现有/未完成的迁移记录，赋予它们一个 UUID

• 使计算节点代码能够处理双重分配策略（pike）或拆分分配策略（queens）

• 使调度器使用确定部署中是否存在 pike 节点来创建使用任一策略的分配

依赖项

• 为了优化我们的行为，我们需要在 Placement 中添加一个额外的 API，以允许我们以原子方式提交针对不同消费者的多个分配。有关相关工作，请参阅 https://blueprints.launchpad.net/nova/+spec/post-allocations。

• 理想情况下，我们应该从 os-migrations API 中公开迁移 UUID，以防管理员需要能够将实例与其迁移分配相关联，以便进行外部工具或审计。

测试

作为 Pike 版本的末尾的火速演练的一部分，我们现在拥有一套相当全面的功能测试，可以验证迁移过程中的分配行为。这些应该概述我们需要覆盖的内容，尽管在每个点上的预期行为将不同。这些测试可以轻松地复制和保留以用于测试 pike 行为，然后可以修改原始测试以验证 queens 行为。一旦我们完成了 queens 版本，我们就可以在删除该代码时删除 pike 行为测试。

文档影响

由于这应该理想情况下对外部不可见，因此预计没有文档影响。

参考资料

参见 Pike 版本中的混乱情况。

历史

修订版

发布名称	描述
Queens	引入