亲和性策略因并行请求而失效

问题

针对亲和性或反亲和性的并行服务器创建请求最终停留在同一宿主机上，并且服务器进入 ACTIVE 状态，即使亲和性或反亲和性策略已被违反。

解决方案

有两种方法可以避免多个服务器创建请求之间的反亲和/亲和性策略冲突。

将多个服务器作为一个请求创建

使用 多创建 API，并将 min_count 参数设置为所需服务器数量，或者使用 多创建 CLI，并将 --min 选项设置为所需服务器数量。

这是因为当请求批次同时对 nova-scheduler 可见作为一个组时，它将能够选择满足反亲和/亲和性约束的计算宿主机，并相应地将它们发送到相同的宿主机或不同的宿主机。

调整 Nova 配置设置

当请求单独发出，并且调度器无法将请求批次同时作为一个组进行考虑时，反亲和/亲和性竞争由 nova-compute 中的所谓“后期亲和性检查”处理。一旦服务器停留在计算宿主机上，如果请求涉及服务器组，nova-compute 将通过 nova-conductor 联系 API 数据库以检索服务器组，然后检查亲和性策略是否已被违反。如果策略已被违反，nova-compute 将启动服务器创建请求的重新调度。请注意，这意味着部署必须将 scheduler.max_attempts 设置为大于 1（默认值为 3）以处理竞争。

对于多单元格部署而言，理想的配置将最大限度地减少从单元格到 API 数据库的 upcalls。例如，devstack 在 CI 网关中的配置就是如此。单元格 conductor 不设置 api_database.connection，并且 nova-compute 将 workarounds.disable_group_policy_check_upcall 设置为 True。

但是，如果部署需要处理竞争的亲和性请求，则需要配置单元格 conductor 以便访问 API 数据库，例如

[api_database]
connection = mysql+pymysql://root:a@127.0.0.1/nova_api?charset=utf8

部署还需要配置 nova-compute 服务，不要禁用组策略检查 upcall，方法是不设置（使用默认值）workarounds.disable_group_policy_check_upcall 或将其设置为 False，例如

[workarounds]
disable_group_policy_check_upcall = False

使用这些设置，即使并行服务器创建请求存在竞争，也应该不会违反反亲和/亲和性策略。

未来需要对放置服务添加反亲和/亲和性支持，以消除对 nova-compute 中后期亲和性检查的需求。