Ironic Shards

https://blueprints.launchpad.net/nova/+spec/ironic-shards

注意

该系列功能已经实现，但最终由于后期发现的一些错误而被回滚。预计在下一个版本中，即 2024.1 中再次合并。也就是说，我们保留了 [ironic]\peer_list 配置选项的弃用，如下面的 配置更改和弃用 中所述。

问题描述

Nova 的 Ironic 驱动程序涉及单个 nova-compute 服务管理许多计算节点，其中每个计算节点记录都映射到 Ironic 节点。一些部署支持数千个 Ironic 节点，但单个 nova-compute 服务无法管理数千个节点和数千个实例。

目前，我们支持设置分区键，其中 nova-compute 仅关心与特定 conductor 组关联的一组 Ironic 节点。但是，有些 conductor 组可能非常大，由许多 ironic-conductor 服务提供支持。

为了解决这个问题，Nova 尝试将 Ironic 节点动态地分布到一组 nova-compute 对等节点之间。虽然这项工作有时有效，但存在一些主要限制

  • 当一个 nova-compute 宕机时，只有未分配的 Ironic 节点才能移动到另一个 nova-compute 服务

  • 例如，当一个 nova-compute 宕机时，所有与宕机的 nova-compute 服务关联的 Ironic 节点都无法管理，例如，重启将失败

  • 此外，当旧的 nova-compute 启动时，这可能需要一些时间，由于哈希环缓慢地重新平衡，会出现很多错误。部分原因是每个 nova-compute 都获取所有节点，在足够大的云环境中，这可能需要超过 24 小时。

本规范是关于调整我们分片 Ironic 计算节点的方式。我们需要停止违反计算管理器代码中的深层假设，转而采用更静态的 Ironic 节点分区。

用例

使用 ironic 驱动程序的任何用户，如果每个 conductor 组有多个 nova-compute 服务，都应切换到主动-被动故障转移模式。

新的静态分片对于 ironic conductor 组大于大约 1000 个裸机节点的环境尤其重要。

提议的变更

我们添加一个新的配置选项

  • [ironic] shard_key

默认情况下，将不会设置 shard_key，我们将继续暴露来自单个 nova-compute 进程的所有 Ironic 节点。主要是为了保持较小部署的简单性，例如，当您拥有少于 500 个 Ironic 节点时。

当操作员设置 shard_key 时，compute-node 进程将在查询 Ironic 中的节点列表时使用 shard_key。当配置中定义了 Ironic shard key 时，我们绝不能尝试列出所有 Ironic 节点。

当通过节点 uuid 或实例 uuid 查找特定的 Ironic 节点时，我们不应将其限制为 shard key 或 conductor 组。

类似于在执行操作之前检查实例 uuid 是否仍然存在于 Ironic 节点上，或者在配置之前确保没有实例 uuid，我们还应在对该 Ironic 节点执行任何操作之前检查节点是否在正确的分片（和 conductor 组）中。

配置更改和弃用

我们将保留针对特定 conductor 组的选项，但该选项将从 partition_key 重命名为 conductor_group。这与上面的 shard_key 相加，目标 Ironic 节点同时存在于正确的 shard_key 和正确的 conductor_group 中，当两者都配置时。

我们将弃用 peer_list 的使用。当使用哈希环时，即哈希环中添加了多个成员时，我们应该记录一个警告。

此外，我们需要尝试移动 Compute 节点，除非 peer_list 大于一个，否则永远无法工作的逻辑。更多细节请参见数据模型影响部分。

在删除 ComputeNode 对象时，我们需要让驱动程序确认是否安全。对于 Ironic，我们将检查配置的 Ironic 是否具有该 uuid 的节点，跨所有 conductor 组和所有 shard key 进行搜索。如果 ComputeNode 对象未被删除，我们不应删除 placement 中的条目。

nova-manage 移动 ironic 节点

我们将创建一个新的 nova-manage 命令

nova-manage ironic-compute-node-move <ironic-node-uuid> \
    --service <destination-service>

该命令将执行以下操作

  • 查找此 ironic-node-uuid 的 ComputeNode 对象

  • 如果 ComputeNode 类型与 ironic 驱动程序不匹配，则报错。

  • 查找上述 ComputeNode 相关的 Service 对象（即主机）

  • 如果服务对象未报告为宕机，并且未也置于维护状态，则报错。我们不需要强制宕机，因为我们可能只是在移动与此 nova-compute 服务关联的一组节点。

  • 检查目标服务主机的 Service 对象是否存在

  • 查找此 (host,node) 的所有未删除的实例

  • 如果找到超过 1 个未删除的实例，则报错。如果找到零个或 1 个实例，则可以。

  • 在一个 DB 事务中：将 ComputeNode 对象移动到目标服务主机，并将 Instance（如果存在）移动到目标服务主机

预计上述工具将用作从旧 peer_list 迁移到新 shard key 的更广泛过程的一部分。有两个关键场景（尽管该工具可能还有助于操作员从其他问题中恢复）

  • 从 peer_list 迁移到单个 nova-compute

  • 从 peer_list 迁移到 shard_key，同时保持多个 nova-compute 进程（对于单个 conductor 组）

从 peer_list 迁移到单个 nova-compute

建议小型部署（例如，少于 500 个 Ironic 节点）从 peer_list（例如，三个 nova-compute 服务）迁移到单个 nova-compute 服务。如果 nova-compute 服务发生故障，操作员可以手动在新主机上启动进程，或使用自动主动-被动 HA 方案。

流程如下

  • ironic 和 nova 都默认使用空 shard key，因此所有 ironic 节点都位于同一个默认分片中

  • 启动一个新的 nova-compute 服务，运行 ironic 驱动程序，理想情况下，为 [DEFAULT]host 设置一个合成值，例如 ironic。这将记录有关使用 nova-compute 迁移工具的警告，然后才能管理任何节点

  • 停止所有现有的 nova-compute 服务

  • 通过 API 将它们标记为强制宕机

  • 现在循环遍历所有 ironic 节点并调用此命令，假设您的 nova-compute 服务具有主机值 ironic：nova_manage ironic-compute-node-move <uuid> –service ironic

新的 nova-compute 服务中的周期性任务将逐渐获取新的 ComputeNodes，并开始能够接收所有已移动实例的命令，例如重启。

虽然可以在迁移所有 ironic 计算节点后启动新的 nova-compute 服务，但这会导致迁移期间的停机时间更长。

从 peer_list 迁移到 shard_key

从基于哈希键的 peer_list 迁移到静态 shard_key 的过程与上述过程非常相似

  • 在所有 ironic 节点上设置 shard_key，以便可以将节点分布到 nova-compute 进程之间。

  • 启动新的 nova compute 进程，每个 shard_key 一个，可能设置一个与 my_shard_key 匹配的合成 [DEFAULT]host 值。

  • 关闭所有设置了 [ironic]peer_list 的旧 nova-compute 进程

  • 通过 Nova API 将这些旧服务标记为维护中

  • 对于 Ironic 中的每个 shard_key，确定您已将每个 shard 映射到哪个服务主机，然后为 shard 中的每个 ironic 节点 uuid 运行此命令：nova_manage ironic-compute-node-move <uuid> –service my_shard_key

  • 通过 Nova API 删除旧服务，因为这些服务上没有实例或计算节点

虽然可以在迁移后启动新的 nova-compute 服务，但这会导致稍长的停机时间。

添加新的计算节点

通常，在将节点添加到现有分片时，不会发生变化。

同样，您可以为新的分片添加一个新的 nova-compute 进程，然后开始用节点填充它。

在分片之间移动 ironic 节点

在删除 ironic 节点以结束其生命周期时，或添加大量新节点时，您可能需要重新平衡分片。

要移动一些 ironic 节点，您需要以与特定 nova-compute 进程关联的组的形式移动节点。对于每个 nova-compute 和您想要移动到不同分片的关联的 ironic 节点，您需要

  • 关闭受影响的 nova-compute 进程

  • 将 nova-compute 服务置于维护状态

  • 在 Ironic API 中更新 Ironic 节点上的 shard key

  • 现在将每个 ironic 节点移动到与它移动到的 shard key 对应的新的 nova-compute 进程：nova_manage ironic-compute-node-move <uuid> –service my_shard_key

  • 现在取消 nova-compute 的维护模式，并启动该服务

在 nova-compute 服务之间移动分片

要将分片在 nova-compute 服务之间移动，您需要用一个新的 nova-compute 进程替换现有的 nova-compute 进程

  • 确保目标 nova-compute 已配置您想要移动的分片，并且正在运行

  • 停止当前提供分片的 nova-compute 进程

  • 通过 API 强制宕机该服务

  • 对于分片中的每个 ironic 节点 uuid，调用 nova-manage 将其移动到新的 nova-compute 进程

备选方案

我们可以要求 nova-compute 进程在允许 nova-manage 移动 ironic 节点之前被显式强制宕机，类似于 evacuate。但这在尝试重新平衡分片时会产生问题，因为您正在删除生命周期结束的节点。

我们可以考虑一个 shard key 列表，而不是每个 nova-compute 的单个 shard key。但对于这个第一个版本，我们选择了似乎限制较少的更简单的路径。

我们可以尝试继续修复 ironic 驱动程序中的哈希环恢复，但由于对 nova-compute 进程所做的所有深层假设，很难确定接下来会发生什么错误。具体的假设包括

  • 当 nova-compute 发生故障时，通常是超visor 硬件发生故障，这包括运行在该硬件上的所有 nova 服务器。

  • nova 服务器对象的所有锁定和管理都由当前分配的 nova-compute 节点完成，并且这仅通过显式移动操作（例如调整大小、迁移、实时迁移和撤离）更改。因此，我们可以使用简单的本地锁定来确保并发操作不冲突，以及 DB 状态检查。

数据模型影响

我们需要确保 ComputeNode 对象仅在旧的哈希环模式下才能自动在服务对象之间移动。目前，这仅发生在未分配的 ComputeNodes 上。

在这种新的显式分片模式下，只有 nova-manage 才能移动 ComputeNode 对象。此外，nova-manage 还会移动关联的实例。但是，类似于撤离，只有当当前关联的服务被强制宕机时才允许这样做。

请注意，当 nova-compute 找到一个它应该拥有的 ComputeNode 时，但 Nova 数据库显示它已经由不同的服务拥有时，这适用。在这种情况下，我们应该记录一个警告给操作员，以确保他们已从旧位置迁移该 ComputeNode，然后此 nova-compute 服务才能管理它。

此外，我们应该确保仅当驱动程序显式声明可以安全删除时才删除 ComputeNode 对象。对于 Ironic 驱动程序，我们应该确保该节点不再存在于 Ironic 中，并确保跨所有分片进行搜索。

这与此规范有关，该规范旨在使 Compute Node 和 Service 对象关系更加健壮：https://review.opendev.org/c/openstack/nova-specs/+/853837

REST API 影响

无

安全影响

无

通知影响

无

其他最终用户影响

用户将体验到更可靠的 Ironic 和 Nova 集成。

性能影响

它应该帮助用户更轻松地支持与 Nova 集成的大型 ironic 部署。

其他部署者影响

我们将把“partition_key”配置重命名为显式“conductor_group”。

我们将弃用 peer list key。当我们启动并看到任何内容设置时，我们会省略有关使用此旧的自动分片中的错误的警告，并建议迁移到显式分片。

有一个新的 shard_key 配置，如上所述。

有一个新的 nova_manage CLI 命令，用于将强制宕机的 nova-compute 服务上的 Ironic 计算节点移动到新的服务。

开发人员影响

无

升级影响

对于当前使用 peer_list 的用户，我们需要记录他们如何迁移到新的分片方法。

实现

负责人

主要负责人

JayF

其他贡献者

johnthetubaguy

功能联络人

功能联络人：无

工作项

  • 重命名 conductor 组分区键配置

  • 弃用 peer_list 配置，并记录警告消息

  • 添加计算节点移动和删除保护，当不使用 peer_list 时

  • 添加新的 shard_key 配置，使用 shard_key 限制 ironic 节点列表

  • 添加 nova-manage 工具以在计算服务之间移动 ironic 节点

  • 记录关于上述 nova-manage 工具的操作流程

依赖项

peer list 的弃用可以立即进行。

但新的分片依赖于 Ironic 分片键的添加： https://review.opendev.org/c/openstack/ironic-specs/+/861803

理想情况下，在 compute node 稳定后将此功能添加到 Nova： https://review.opendev.org/c/openstack/nova/+/842478

测试

我们需要一些功能测试来测试 nova-manage 命令，以确保所有安全防护措施按预期工作。

文档影响

需要大量文档来描述 Ironic 驱动程序关于 shard_key 的操作规程。

参考资料

无

历史

修订版

发布名称

描述

2023.1 Antelope

引入

2023.2 Bobcat

重新提出