Virt 驱动客户机 NUMA 节点放置与拓扑

https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement

此功能旨在增强 libvirt 驱动程序，使其能够为客户机进行智能 NUMA 节点放置。这将提高计算资源的有效利用率，并通过避免客户机跨节点内存访问来降低延迟。

问题描述

用于虚拟化计算节点的大多数硬件都将表现出 NUMA 特性。在 NUMA 主机上运行工作负载时，重要的是执行进程的 CPU 与所用内存位于同一节点上。这可确保所有内存访问都位于 NUMA 节点本地，从而不会消耗非常有限的跨节点内存带宽，这会增加内存访问的延迟。PCI 设备直接与特定的 NUMA 节点关联，以进行 DMA 目的，因此在使用 PCI 设备分配时，也希望将客户机放置在与分配给它的任何 PCI 设备相同的 NUMA 节点上。

目前，libvirt 驱动程序不会尝试任何 NUMA 放置；客户机可以自由地浮动到任何主机 pCPU，并且它们的内存从任何 NUMA 节点分配。这会浪费计算资源，并增加内存访问延迟，这对于 NFV 用例有害。

如果与风味关联的内存/vCPU 大于任何单个 NUMA 节点，则重要的是向客户机公开 NUMA 拓扑，以便客户机中的操作系统可以智能地调度它运行的工作负载。为此，客户机 NUMA 节点必须直接与主机 NUMA 节点关联。

一些客户机工作负载对内存访问延迟和/或带宽有非常高的要求，超过了单个 NUMA 节点可用的范围。对于此类工作负载，即使客户机内存/vCPU 在理论上可以适应单个 NUMA 节点，将其跨多个主机 NUMA 节点展开也会是有益的。

为了最大限度地提高与实时迁移一起使用的目标主机的选择，提前规划也可能导致管理员更喜欢将客户机拆分到多个节点上，即使它可能能够适应某些主机上的单个节点。

出于这两个原因，希望能够显式指示在客户机中设置多少个 NUMA 节点，并指定将多少内存或多少 vCPU 放置在每个节点中。

提议的变更

libvirt 驱动程序将得到增强，以便它查看每个 NUMA 节点中可用的资源，并确定哪个最适合运行客户机。在启动客户机时，它将告诉 libvirt 将客户机限制到所选 NUMA 节点。

计算驱动程序主机状态数据将扩展为包含有关主机 NUMA 拓扑和节点中资源可用性的信息。

调度程序将得到增强，以便在选择要调度的主机时可以考虑 NUMA 资源的可用性。调度程序用于确定主机是否可以运行的算法需要与 libvirt 驱动程序本身使用的算法紧密匹配（如果不是相同）。这将涉及创建新的调度程序过滤器，以将风味/镜像配置规范与计算主机报告的 NUMA 资源可用性进行匹配。

风味附加规格将支持指定客户机 NUMA 拓扑。当与风味关联的内存/vCPU 计数大于计算主机中的任何单个 NUMA 节点时，这很重要，通过允许跨 NUMA 节点的客户机实例来实现。计算驱动程序将确保客户机 NUMA 节点直接映射到主机 NUMA 节点。预计默认设置是不列出任何 NUMA 属性，而只是让计算主机和调度程序应用合理的默认放置逻辑。仅在需要对 NUMA 拓扑/拟合特性进行更精确控制的子集中场景中才需要设置这些属性。

  • hw:numa_nodes=NN - 向客户机公开的 NUMA 节点数。

  • hw:numa_cpus.NN=<cpu-list> - 将客户机 vCPU 映射到给定的客户机 NUMA 节点。

  • hw:numa_mem.NN=<ram-size> - 将客户机 MB 内存映射到给定的客户机 NUMA 节点。

重要

上述 NUMA 节点、CPU 和内存是指客户机 NUMA 节点、客户机 CPU 和客户机内存。不可能定义应该分配给客户机的特定主机节点、CPU 或内存。

最常见的情况是管理员仅设置 hw:numa_nodes，然后风味 vCPU 和内存将平均分配到 NUMA 节点。当 NUMA 策略生效时，除了被 hw:numa_mem.NN 覆盖之外，实例的内存分配必须来自绑定到的 NUMA 节点。

只有在应将客户机 NUMA 节点不对称分配 CPU 和内存时，才需要使用 hw:numa_cpus.N 和 hw:numa_mem.N 设置。这对于某些 NFV 工作负载很重要，但通常这些将是很少使用的可调参数。如果提供了 hw:numa_cpus 或 hw:numa_mem 设置，并且其值加起来不等于总 vcpu 计数/内存大小，则认为这是一个配置错误。计算驱动程序在尝试启动实例时将引发异常。作为增强功能，有可能在 API 级别验证一些数据，以便更早地向用户报告错误。但是，这种检查不是这项工作的功能先决条件，因此可以在开发工作之外完成。

如果仅设置了 hw:numa_nodes=NNN 属性，则将合成 hw:numa_cpus.NN 和 hw:numa_mem.NN 属性，以便将风味分配平均分配到所需的 NUMA 节点数。这将发生两次：一次在调度时，以确保客户机将适合主机，另一次在声明时，实际分配资源。这两个过程都将考虑主机上的可用 NUMA 资源，以找到一个完全匹配客户机要求的资源。

  • vcpus=8

  • mem=4

  • hw:numa_nodes=2

  • hw:numa_cpus.0=0,1,2,3,4,5

  • hw:numa_cpus.1=6,7

  • hw:numa_mem.0=3072

  • hw:numa_mem.1=1024

调度程序将查找具有 2 个 NUMA 节点的宿主机，这些节点能够在一个节点上运行 6 个 CPU + 3 GB 内存，在另一个节点上运行 2 个 CPU + 1 GB 内存。如果主机具有单个 NUMA 节点，该节点能够运行 8 个 CPU 和 4 GB 内存，则不会将其视为有效匹配。

描述风味的所有属性也可以设置为镜像，将前导“:”替换为“_”，这是镜像属性命名约定所要求的。

  • hw_numa_nodes=NN - 向客户机公开的 NUMA 节点数。

  • hw_numa_cpus.NN=<cpu-list> - 将客户机 vCPU 映射到给定的客户机 NUMA 节点。

  • hw_numa_mem.NN=<ram-size> - 将客户机 MB 内存映射到给定的客户机 NUMA 节点。

如果镜像中的应用程序需要非常特定的 NUMA 拓扑特性，这将很有用，预计这将经常与 NFV 镜像一起使用。但是，如果未在风味上设置属性，则只能在镜像上设置属性。例如，如果风味设置 hw:numa_nodes=2 但未设置任何 hw:numa_cpus 或 hw:numa_mem 值，则镜像可以选择性地设置这些值。但是，如果风味已经设置了特定属性，则镜像无法覆盖该属性。这允许风味管理员严格锁定允许的内容（如果需要）。他们可以通过在风味上设置 hw:numa_nodes=1 来强制非 NUMA 拓扑。

备选方案

Libvirt 支持与名为 numad 的守护程序集成。可以向此守护程序提供内存大小 + vCPU 计数，它会告诉 libvirt 在哪个 NUMA 节点上放置客户机。它还能够重新平衡利用率，在 NUMA 节点之间移动正在运行的客户机。这对于 Nova 来说是不够的，因为它需要在调度程序中具有智能性来选择主机。然后计算驱动程序需要能够在实际启动客户机时使用相同的逻辑。numad 系统不能移植到其他计算虚拟机管理程序。它无法解决跨 NUMA 节点放置客户机的问题。最后，它没有解决 NFV 工作负载的需求，这些工作负载需要保证 NUMA 拓扑和放置策略，而不仅仅是动态的最佳努力。

另一种选择是像今天一样什么都不做，并依赖于增强的 Linux 内核调度程序，以自动将客户机放置在适当的 NUMA 节点上并按需重新平衡它们。这与使用 NUMA 共享大多数问题。

数据模型影响

没有影响。

NUMA 拓扑报告将集成到用于主机状态报告的现有数据结构中。由于它支持任意字段，因此预计此部分不需要更改数据模型。这将显示为结构化数据

hw_numa = {
   nodes = [
       {
          id = 0
          cpus = 0, 2, 4, 6
          mem = {
             total = 10737418240
             free = 3221225472
          },
          distances = [ 10, 20],
       },
       {
          id = 1
          cpus = 1, 3, 5, 7
          mem = {
             total = 10737418240
             free = 5368709120
          },
          distances = [ 20, 10],
       }
   ],
}

REST API 影响

没有影响。

主机状态报告的 API 已经支持任意数据字段，因此从该角度来看，预计不会发生变化。不需要新的 API 调用。

安全影响

没有影响。

没有涉及新的 API，这会暗示新的安全风险。

通知影响

没有影响。

不需要使用通知系统。

其他最终用户影响

根据选择的风味，客户机操作系统可能会看到为其内存分配提供支持的 NUMA 节点。

在设置 NUMA 策略或使用方面，没有最终用户交互。

云管理员将获得在风味上设置策略的能力。

性能影响

新的调度程序功能将意味着在确定主机是否能够适应风味的内存和 vCPU 需求时，性能开销会增加。例如，当前仅检查 vCPU 计数和内存需求与主机可用内存的逻辑需要考虑特定 NUMA 节点上的资源可用性。

其他部署者影响

如果部署具有内存 + vCPU 分配大于计算主机中 NUMA 节点大小的风味，则云管理员应强烈考虑在风味中定义客户机 NUMA 节点。这将使计算主机具有更好的 NUMA 利用率并提高客户机操作系统的性能。

开发人员影响

新的风味属性可以由任何全虚拟机虚拟机管理程序使用，但是，它们不必这样做。

实现

负责人

主要负责人

berrange

其他贡献者

ndipanov

工作项

  • 增强 libvirt 驱动程序以报告 NUMA 节点资源和可用性

  • 增强 libvirt 驱动程序以支持设置客户机 NUMA 节点。

  • 增强 libvirt 驱动程序以查看 NUMA 节点可用性，并在启动客户机实例时将所有客户机固定到最佳 NUMA 节点

  • 向调度程序添加支持，以便基于 NUMA 可用性而不是仅仅考虑总内存/vCPU 可用性来选择主机。

依赖项

测试

工作中有各种离散的部分，可以使用单元测试有效地单独测试。

单元测试可能不足的的主要领域是调度程序集成，其中性能/可扩展性将是一个问题。但是，在 tempest 中测试调度程序的扩展性是不切实际的，因为问题只有在许多计算主机和许多客户机时才会变得明显，即超过 tempest 设置的规模。

文档影响

云管理员文档需要描述新的风味参数并提出有关如何有效使用它们的建议。

需要让最终用户了解某些风味会导致客户机操作系统看到 NUMA 拓扑。

参考资料

当前关于 CPU 和内存资源利用率和放置主题的“大图景”研究和设计。 vCPU 拓扑是这项工作的一个子集

OpenStack NFV 团队