Libvirt 实时实例

https://blueprints.launchpad.net/nova/+spec/libvirt-real-time

CPU pinning 特性增加了将客户机虚拟 CPU 分配给专用宿主机 CPU 的能力，从而为 CPU 时间提供保证，并改善 CPU 调度中的最坏情况延迟。实时特性在此基础上构建，为 vCPU 的最坏情况调度器延迟提供更强的保证。

问题描述

CPU pinning 特性允许将客户机 vCPU 给予对单个宿主机 pCPU 的专用访问权限。这意味着虚拟机将不再遭受“steal time”（被抢占时间），即其 vCPU 被抢占以运行属于另一个客户机的 vCPU。消除过度承诺消除了客户机 vCPU 饥饿的高层原因，但客户机 vCPU 仍然容易受到内核各个区域的延迟峰值影响。

例如，各种内核任务在宿主机 CPU 上运行，例如中断处理，这可能会抢占客户机 vCPU。QEMU 本身由于其巨大的全局互斥锁，存在许多延迟来源。各种设备模型具有次优的特性，这会导致 QEMU 中的延迟峰值，以及底层宿主机硬件。避免这些问题需要以特定方式配置宿主机内核和操作系统，以及仔细选择要使用的 QEMU 功能。它还需要为客户机 vCPU 配置合适的调度器策略。

将 huge pages 分配给客户机可确保客户机 RAM 不会在宿主机上交换出去，但 QEMU 模拟器仍然存在其他任意内存分配。如果 QEMU 的某些部分交换到磁盘，则可能会影响实时客户机的性能。

启用实时并非没有代价。为了满足 CPU 延迟的严格最坏情况要求，必须必然地牺牲系统的整体吞吐量。因此，不应无条件地为 OpenStack 部署启用实时特性。它必须是一种选择加入机制，仅在客户机工作负载实际需要时使用。

作为实时优势和权衡的指标，考虑一些实际性能数据是有用的。使用裸机和专用 CPU 但非实时调度器策略时，最坏情况延迟约为 150 微秒，平均延迟约为 2 微秒。使用 KVM 和专用 CPU 以及实时调度器策略时，最坏情况延迟为 14 微秒，平均延迟小于 10 微秒。这表明虽然实时在最坏情况延迟方面带来了显著的好处，但平均延迟仍然明显高于使用非实时策略的裸机实现的延迟。这进一步强化了实时并非无条件使用的观点，它仅适用于需要延迟保证的特定工作负载。许多应用程序会发现仅使用专用 CPU 就足以满足其需求。

用例

希望运行 CPU 执行延迟重要的工作负载的租户需要具有实时 KVM 客户机配置提供的保证。电信社区中常用的 NFV 设备就是一个用例，但还有许多其他潜在用户。例如，股票市场交易应用程序非常关心调度延迟，科学处理工作负载也可能如此。

预计此功能主要在私有云部署中使用。除了实时计算保证外，租户通常还需要云和其通信的服务/系统之间的网络层中相应的保证。通过互联网使用远程公共云很难实现这种网络保证。

提议的变更

目标是在先前为启用 NUMA 节点放置策略、专用 CPU pinning 和 huge page 支持的客户机 RAM 的工作基础上构建。

主要要求是必须有一种机制来指示是否必须为实例启用实时。由于实时对宿主机操作系统设置有严格的先决条件，因此云管理员通常不希望允许对此功能的任意使用。实时工作负载可能只占整体云使用情况的一小部分，因此预计将会有混合的计算主机，只有其中一些提供实时功能。

因此，管理员需要使用主机聚合将他们的计算主机划分为支持实时和不支持实时的主机。

然后需要在 flavor 上提供一个属性

  • hw:cpu_realtime=yes|no

这将指示使用该 flavor 启动的实例将使用实时策略运行。将此属性设置为“yes”的 flavor 需要与包含支持实时的主机的聚合主机关联。

在 flavor 上启用实时功能的先决条件是，它还必须将“hw:cpu_policy”设置为“dedicated”。即，所有实时客户机都必须分配给它们专用的 pCPU。您不能将实时策略赋予容易受到过度承诺影响的 vCPU，因为这会导致该 pCPU 上其他客户机的饥饿，以及降低延迟保证。

超visor 驱动程序在启用实时时配置客户机的具体操作由实现定义。不同的超visor 将具有不同的配置步骤，但共同点是它们都将为 vCPU 提供比非实时实例更好的最坏情况延迟保证。租户用户不需要知道如何满足要求，而只需知道云可以支持必要的延迟保证。

对于使用 KVM 超visor 的 libvirt 驱动程序，预计设置实时 flavor 将导致以下客户机配置更改

  • 整个 QEMU 和客户机 RAM 将被锁定到内存中

  • 所有 vCPU 都将获得固定的实时调度器优先级

除了 vCPU 工作负载外，大多数超visor 还在控制平面中运行一个或多个其他线程，这些线程代表虚拟机执行工作。大多数超visor 会隐藏此细节，但 QEMU/KVM 超visor 通过模拟器线程的概念将其暴露出来。在最初支持专用 CPU 时，Nova 被设置为将模拟器线程限制为在与客户机 vCPU 放置在同一组 pCPU 上运行。这在实时的情况下是不可取的，因为这些模拟器线程将执行可能影响延迟保证的工作。因此，需要以更精细的方式放置模拟器线程。

大多数客户机操作系统将使用多个 vCPU 并且至少有一个 vCPU 专门用于运行非实时维护任务。鉴于此，目标是将模拟器线程与正在运行非实时任务的 vCPU 放置在同一位置。这反过来需要另一个可调参数，可以设置在 flavor 上，也可以设置在镜像上。这将指示哪些 vCPU 将启用实时策略

  • hw:cpu_realtime_mask=^0-1

这表示除 vCPU 0 和 1 之外的所有 vCPU 都将具有实时策略。即 vCPU 0 和 1 将保持非实时状态。具有非实时策略的 vCPU 也将用于运行模拟器线程。必须保留至少一个 vCPU 用于非实时工作负载，将所有 vCPU 配置为实时状态是一个错误。如果未设置该属性，则默认行为是为非实时任务保留 vCPU 0。该属性也可以通过 hw_cpu_realtime_mask 属性在镜像上覆盖。

将来，可能希望允许模拟器线程在与运行 vCPU 完全分离的宿主机 pCPU 上运行。例如，这将允许运行客户机操作系统，其中所有 vCPU 必须能够实时运行，因此无法为实时任务保留 vCPU。这将需要调度器将模拟器线程视为本身是一种虚拟 CPU。这种增强功能不在此蓝图的范围内，以消除对调度器修改的任何依赖性。它将在新的蓝图中处理。

所需工作的重要部分是记录所需的计算主机和客户机操作系统设置，因为 Nova 本身无法自动执行其中许多设置。预计各种 OpenStack 部署工具的开发人员将使用文档来扩展他们的工具，以便能够部署启用实时的计算主机。这超出了此蓝图的范围，该蓝图将仅记录核心要求。构建磁盘镜像的租户还需要使用此文档来确定如何配置其客户机操作系统。

备选方案

一种选择是，当客户机使用专用 CPU pinning 时，始终启用实时调度器策略，并且当客户机具有 huge pages 时，始终启用内存锁定。如问题描述中所述，这种方法是不可取的。只有通过降低系统的整体吞吐量才能实现实时保证。因此，无条件地为不需要它的主机/客户机启用实时将显着浪费潜在的计算资源。因此，必须有一种选择加入机制来启用实时。

什么都不做始终是一个选项。如果什么都不做，即使使用专用 pCPU，客户机也必须忍受非实时调度的固有延迟。可以通过仔细的宿主机操作系统配置进一步减轻这些延迟，但广泛的性能测试表明，即使使用精心配置的宿主机和专用 CPU，非实时任务的最坏情况延迟也至少比启用实时时差 x10。因此，不支持 OpenStack 中的实时客户机将排除 Nova 在各种场景中的使用，迫使用户部署替代的非 OpenStack 解决方案，或者要求 OpenStack 供应商分叉代码并交付他们自己的自定义实时解决方案。这些选项对于 OpenStack 用户或供应商来说都不是有吸引力的，因为它们要么会失去用户份额，要么会使 OpenStack 生态系统碎片化。

数据模型影响

不需要

REST API 影响

不需要

安全影响

启用实时将仅影响分配给客户机的 pCPU。因此，如果操作员已经允许租户使用专用 pCPU，则启用实时不会暗示任何进一步的权限。因此，实时不被认为会引入任何新的安全问题。

通知影响

无

其他最终用户影响

租户将能够通过镜像属性请求实时。他们需要仔细构建他们的客户机操作系统镜像以利用实时特性。他们需要从其云提供商处获取有关其部署能够满足的最坏情况延迟的信息，以确保其能够满足其工作负载的要求。

性能影响

Nova 作为一个整体不会产生新的性能影响。这是在现有的 CPU pinning 和 huge pages 功能的基础上构建的，因此调度器逻辑已经到位。同样，对主机的冲击仅限于已经分配给客户机的 pCPU。

其他部署者影响

操作员可以通过设置 flavor 额外的 spec 属性来定义实时 flavor。

操作员可能希望使用主机聚合来分配一组特定的计算节点与 huge pages 和 CPU pinning 结合使用。这是这些功能预先存在的影响，实时不会改变它。

开发人员影响

其他 virt 驱动程序可能希望支持 flavor/image 属性，以启用其实例的实时调度，如果其超visor 具有此功能。

实现

负责人

主要负责人

sahid

其他贡献者

berrange

工作项

主要工作项目是

  • 将“hw_cpu_realtime_mask”字段添加到 ImageMetaProps 对象

  • 当存在实时 flavor 或镜像属性时，更新 libvirt 客户机 XML 配置

  • 更新 Nova 部署文档，概述为了充分利用实时功能，需要哪些宿主机操作系统设置步骤

依赖项

  • libvirt 项目需要添加对 XML 功能的支持，以启用客户机的实时调度器优先级。已合并到 1.2.13 版本。

  • KVM/kernel 项目需要提供有关最佳宿主机操作系统设置的建议。部分完成 - 请参阅 KVM Forum 演讲。在开发期间将进行持续协作，以生成 Nova 文档。

如果实施了 libvirt 模拟器线程策略蓝图，则可以取消实时客户机必须是 SMP 的限制，以允许 UP 实时客户机。但这并不是严格的先决条件，而只是允许在更广泛的场景中使用实时的补充工作。

测试

当前 OpenStack 社区测试套件不会检查由 Nova 部署的客户机的性能特征，这是验证此功能所需要的。

关键的功能测试要求围绕着现有 Nova CPU pinning 和 huge pages 功能及其调度器集成是否正确运行。这超出了此蓝图的范围。

文档影响

需要更新部署文档，以描述如何设置主机和客户机以利用实时调度器优先级。由于这需要对系统进行非常详细的了解，预计功能开发人员将编写大部分文档内容，因为不能期望文档团队学习所需细节。

参考资料