调度器演进¶

调度器与 nova 的其余部分紧密耦合，限制了其功能、准确性、灵活性和可维护性。调度器演进的目标是实现调度功能与 nova 其余部分之间更好的关注点分离。

一旦这项工作完成，nova-scheduler 可能会成为一个独立的 git 仓库，位于 nova 之外但位于计算项目之内。这不是当前的重点。

问题用例¶

许多用户希望对调度器进行更高级的操作，但当前架构尚未准备好以可维护的方式支持这些用例。一些示例将有助于说明调度器存在哪些不足

在从卷启动时，使用靠近共享存储的计算节点是可取的，因为该卷位于共享存储中。同样，为了提高性能，使用与预创建端口位于特定位置的计算节点是可取的。

对于某些用例，与过滤器调度器相比，截然不同的调度器可能表现更好。我们不应该阻止这种创新。假设单个调度器适用于所有用例是不合理的。

然而，为了以可维护的方式实现这种创新，需要一个强大的调度器接口。

有很多关于新调度器的有趣想法，例如求解器调度器，以及频繁请求向调度系统添加新过滤器和权重的请求。当前的 nova 团队没有带宽来处理所有这些请求。专门的调度器团队可以独立于 nova 的其余部分处理这些项目。

当前存在的紧密耦合使得无法隔离地处理调度器。在代码拆分之前，需要一个稳定的接口。

在这里，我们从高层次讨论了作为调度器演进工作的一部分正在解决的领域。

在 kilo 开始时，调度器通过版本化的 RPC 接口传递一组字典。这些字典可能会给实时升级所需的向后兼容性带来问题。

幸运的是，我们已经拥有 oslo.versionedobjects 基础设施，可以使用它以可以跨版本建模数据的方式。

这项工作主要集中在 request_spec 周围。例如，请参见此规范。

定期 nova-compute 会更新数据库中存储的调度器状态。

我们需要一种好的方法来建模从计算节点发送到调度器的数据，以便随着时间的推移，调度器可以迁移到拥有自己的数据库。

这与资源跟踪器的工作相关联。

随着时间的推移，我们可能需要发送 cinder 和 neutron 数据，以便调度器可以使用这些数据来帮助选择 nova-compute 主机。

最近添加对 NUMA 和 PCI 直通的支持的工作表明，我们没有好的模式来扩展资源跟踪器。理想情况下，我们希望将创新保留在 nova 树中，但我们也需要使其更容易。

这与我们重新思考如何建模资源的工作密切相关，如资源提供程序中讨论的那样。

nova-scheduler 的当前设计非常容易出现竞争条件，并且可能导致在找到正确的宿主机之前出现过多的构建重试次数。最近的 NUMA 功能尤其受到调度器工作方式的影响。所有这些都导致许多人运行仅配置为使用非常小的 greenthread 池的单个 nova-scheduler 进程。

cells v2 的工作意味着我们很快需要调度器能够扩展到更大的问题。当前的调度器在小于 1k 个节点的情况下效果最好，但我们需要调度器能够处理至少 10k 个节点。

已经讨论了各种想法来减少在运行多个 nova-scheduler 进程时出现的竞争条件。一个想法是使用类似于两阶段提交的资源跟踪器声明。另一个想法涉及使用增量更新，使其更有效地保持调度器的状态最新，可能使用 Kafka。

有关更多详细信息，请参见积压规范，其中描述了有关此问题的更多详细信息。