PCI NUMA 策略¶

https://blueprints.launchpad.net/nova/+spec/share-pci-between-numa-nodes

在 Juno 版本中，实现了“基于 I/O 的 NUMA 调度”规范 [1]。这修改了调度算法，使得用户只能在与 PCI 设备关联的至少一个 NUMA 节点上启动实例，或者如果 PCI 设备没有关于 NUMA 节点的任何信息以及 PCI 设备亲和性。此前，nova 会在不检查 NUMA 亲和性的情况下启动带有 PCI 设备的实例。然而，这种硬编码的行为如果并非每个 NUMA 节点都有自己的 PCI 设备，就会导致问题。在这种情况下，nova 不允许在没有 PCI 设备的 NUMA 节点上启动实例。

问题描述¶

在当前迭代中，nova 会在与这些 PCI 设备关联的相同 NUMA 节点上启动带有 PCI 设备的实例。这对于性能来说是好的，因为它确保了有限的跨 NUMA 节点内存流量。然而，如果用户有一个带有两个 NUMA 节点和仅一个 PCI 设备（例如，与第一个 NUMA 节点关联的 SR-IOV 卡）的环境，他们将能够启动一个只在第一个 NUMA 节点上具有一个 NUMA 节点和 SR-IOV 端口的实例。在这种情况下，用户无法使用一半的 CPU 和 RAM，因为这些资源位于第二个 NUMA 节点上。用户应该能够启动不同 NUMA 节点上的实例，即使这会降低性能。

此外，当前行为并不总是提供最佳的性能解决方案，因为如果关于此 PCI 设备与 NUMA 节点的亲和性没有信息，则实例可以使用 PCI 设备。这可能导致 PCI 设备不在 CPU 和 RAM 所在的 NUMA 节点上。调度机制应该更加灵活。用户应该能够在最大性能行为和成功启动实例的最大可能性之间进行选择。

当然，这种能力应该是可配置的，并且当前的调度行为必须保持为默认值。

用例¶

作为关心从我的 PCI 设备获得最大性能的运营商，我想确保我的 PCI 设备始终具有 NUMA 亲和性，即使这导致资源利用率降低。
作为关心资源最大利用率的运营商，我想确保实例有最佳的成功调度机会，即使这会导致某些实例的性能略有下降。
作为部署了混合了 NUMA 感知和非 NUMA 感知主机的运营商，我想确保我的 PCI 设备始终具有 NUMA 亲和性如果可用 NUMA 信息。但是，我仍然希望能够调度非 NUMA 感知主机的实例。

或者，作为使用 PCI 设备的现有部署的运营商，我不想让 nova 突然拒绝调度到没有 NUMA 信息的主机，而之前是可以的。

提议的变更¶

需要此规范来确定实例使用的 PCI 设备的亲和性。为此，我们将向 numa_policy 添加一个新键到 [pci] alias JSON 配置选项。此选项可以具有以下三个值之一。

required

此值将意味着 nova 仅在至少一个 NUMA 节点与这些 PCI 设备关联时才会启动带有 PCI 设备的实例。这意味着如果无法确定某些 PCI 设备的 NUMA 节点信息，则这些 PCI 设备将无法被实例使用。这提供了最大性能。

preferred

此值将意味着 nova-scheduler 将选择计算主机，在考虑 PCI 设备的 NUMA 亲和性方面考虑最少。 nova-compute 将尝试基于 NUMA 亲和性选择 PCI 设备，但如果这不可能，则 nova-compute 将回退到在与 PCI 设备不关联的 NUMA 节点上进行调度。

请注意，即使 NUMATopologyFilter 不会考虑 NUMA 亲和性，在 Reserve NUMA Nodes with PCI Devices Attached 规范中提出的 weigher [2] 可用于最大化所选主机具有 NUMA 亲和 PCI 设备的可能性。

legacy

这是默认值，它描述了当前的 nova 行为。通常，我们有关于 PCI 设备与 NUMA 节点关联的信息。但是，某些 PCI 设备不提供此类信息。 legacy 值将意味着 nova 将在以下情况下启动带有 PCI 设备的实例

PCI 设备与实例将要启动的至少一个 NUMA 节点关联

没有关于 PCI-NUMA 亲和性的信息

这是必需的，因为配置选项将全局应用于一个实例，该实例可能具有多个附加设备，并且这些设备中的并非所有设备都可能具有 NUMA 亲和性。这种设备的示例是在最近的 Intel Xeon 芯片的芯片上集成的 FPGA，它们连接到 QPI 总线，因此没有 NUMA 亲和性 [3]。

最终结果将是一个类似于以下内容的选项

[pci]
alias = '{
  "name": "QuickAssist",
  "product_id": "0443",
  "vendor_id": "8086",
  "device_type": "type-PCI",
  "numa_policy": "legacy"
}'

备选方案¶

更改放置行为，不要在具有 PCI 设备的 NUMA 节点上启动不需要 PCI 设备的实例。这将最大化需要 PCI 设备的实例可以找到合适的启动主机的可能性。但是，这将严重限制我们的灵活性，因为尝试启动许多没有 PCI 设备的实例将导致大量未使用的、具有 PCI 设备的宿主机。此外，一旦所有没有 PCI 设备的 NUMA 节点饱和，部署不需要 PCI 设备的实例将会失败。
更改放置行为，避免在具有 PCI 设备的 NUMA 节点上启动没有 PCI 设备的实例如果可能。这是第一个替代方案的较软版本，实际上已经通过“reserve-numa-with-pci”规范解决了 [4]。
将 PCI NUMA 严格性作为设备请求的一部分。这种粒度级别可能就足够了，但它确实需要额外的 flavor 额外规范和镜像元数据选项。这不是我们想要的。

数据模型影响¶

将添加一个新字段 numa_policy 到 InstancePCIRequest 对象。由于此对象作为 JSON blob 存储在数据库中，因此无需迁移数据库即可将新字段添加到此对象。

REST API 影响¶

无

安全影响¶

无

通知影响¶

无

其他最终用户影响¶

无

性能影响¶

如果选择了 required 策略，则在存在非 NUMA 感知计算主机的情况下，具有 PCI 设备的实例的性能将更加一致。这是因为 nova 将不再使用这些主机。但是，这也会导致可用于调度实例的主机数量减少。如果所有主机都正确提供 NUMA 信息，则性能将保持不变。

如果选择了 preferred 策略，则具有 PCI 设备的某些实例的性能可能会更差。这是因为 nova 现在可以在没有 NUMA 亲和 PCI 设备的宿主机上调度实例。但是，这也会导致可用于调度实例的主机数量增加，从而最大限度地提高运营商的灵活性，而无需最大性能。在 Reserve NUMA Nodes with PCI Devices Attached 中提出的 PCI weigher [2] 可用于最大程度地降低性能影响的风险。

如果选择了 legacy 策略，将保留现有的 nova 行为，性能将保持不变。

从调度角度来看，如果选择了 required 策略并且有大量没有报告 NUMA 亲和性的 PCI 设备的主机，则可能会引入延迟。另一方面，使用 preferred 策略将提高性能，因为调度能力不再与与 PCI 设备关联的 NUMA 节点上可用空闲 CPU 相关联。

其他部署者影响¶

无

开发人员影响¶

无

实现¶

负责人¶

主要负责人: Stephen Finucane (stephenfinucane)
其他贡献者: Sergey Nikitin (snikitin)

工作项¶

向 [pci] alias 选项添加新字段
向 InstancePCIRequest 对象添加新字段
更改 NUMA 节点选择过程，考虑新的策略
更新用户文档

依赖项¶

无

测试¶

将添加场景测试以验证这些修改。

文档影响¶

此功能不会添加新的调度过滤器，但它会更改 NUMATopologyFilter 的行为。我们应该添加文档来描述 [pci] alias 选项的新键。

参考资料¶

历史¶

修订¶
发布名称	描述
Queens	引入

PCI NUMA 策略