推导 TripleO 参数¶

https://blueprints.launchpad.net/tripleo/+spec/tripleo-derive-parameters

本规范提出了一种通用的接口，用于自动填充包含从公式推导出的参数的环境文件；这些公式的输入来自内省硬件数据、工作负载类型和部署类型。它还提供了具体的示例，说明如何使用该接口来改进到 DPDK 或 HCI 用例中部署的超云。最后，它提出了如何共享和扩展此通用接口，以便操作员可以选择指定某些参数，从而将未来的系统调优专业知识集成到 TripleO 中。

问题描述¶

操作员必须为部署填充参数，这些参数可能特定于硬件和部署类型。一旦完成节点的内省，节点硬件信息将对操作员可用。但是，当前流程要求操作员手动读取内省数据，根据该数据做出决策，然后更新环境文件中的参数。这使得部署准备不必要地复杂。

例如，在部署 DPDK 时，操作员必须提供应分配给 DPDK 轮询模式驱动程序 (PMD) 的 CPU 列表，并且这些 CPU 应来自与 DPDK 接口位于同一 NUMA 节点。为了提供正确的参数，操作员必须交叉检查所有这些细节。

另一个例子是 HCI 超云的部署，它在同一节点上运行 Nova 计算和 Ceph OSD 服务。为了防止计算和存储服务之间的争用，操作员可以手动应用由性能调优专家提供的公式，这些公式会考虑可用的硬件、工作负载类型和部署类型，然后在根据这些公式计算出适当的参数后，手动将其存储在环境文件中。

除了 DPDK 或 HCI 用例的复杂性之外，了解如何将 CPU 分配给 DPDK 轮询模式驱动程序或隔离 HCI 的计算和存储资源本身就是另一个问题。与其记录该过程并期望操作员遵循它，不如以高级语言捕获该过程，并提供一个通用接口，以便性能调优专家可以轻松地与操作员共享针对其他用例的新类似流程。

提议的变更¶

本规范旨在对 TripleO 进行以下三个更改，如下面所述。

Mistral 工作流以推导参数¶

将添加一组 Mistral 工作流，用于确定部署参数复杂的特性。像 DPDK、SR-IOV 和 HCI 这样的特性需要从内省数据中获取输入进行分析，以计算部署参数。此推导参数工作流将通过分析内省数据提供一组默认的计算公式。因此，此工作流成功执行将对节点内省产生硬依赖性。

在最初的迭代中，将分析部署中的所有角色，以查找与该角色关联的服务，该服务需要参数推导。在下面 Workflow Association with Services 部分讨论了使用此方法的各种选项以及当前迭代的最终选择。

此工作流假定一个角色中的所有节点都具有同构的硬件规范，并且将使用第一个节点的内省数据来处理整个角色的参数。这将在后续迭代中重新评估，具体取决于对特定于节点的推导的需求。该工作流将考虑 flavor-profile 关联和 nova 放置调度器，以识别与角色关联的节点。

特定于角色的参数是此工作流的重要要求。如果多个角色启用了相同的服务（特性），则从此工作流推导出的参数仅应用于相应的角色。

这些工作流的输入源是 ironic 数据库和存储在 Swift 中的 ironic 内省数据，以及存储在 Swift 中的部署计划。在 Mistral 工作流中完成的参数推导计算将使用 YAQL 实现。这些计算将基于每个特性的单独工作流，以便可以自定义公式。如果操作员需要修改默认公式，他或她只需要使用自定义公式更新此工作流。

将推导出的参数应用于超云¶

为了将结果参数应用于超云，将使用 Mistral tripleo.parameters.update 操作或类似操作修改存储在 undercloud 的 Swift 上的部署计划。

提供推导输入和更新推导输出参数的方法应与部署计划管理规范 [1] 一致。此规范相对于设置和获取参数的接口的实现可能会随着更新而更改。但是，基本工作流应保持不变。

使用 TripleO 触发 Mistral 工作流¶

假设工作流已到位，可以推导参数并更新部署计划，如前两个部分所述，操作员可以通过在 plan- environment.yaml 中启用它来利用此可选功能。将向 plan-environments.yaml 文件添加一个新部分 workflow_parameters，以容纳执行工作流所需的其他参数。通过此附加部分，我们可以确保工作流特定的参数仅提供给工作流，而不会污染 heat 环境。同时，也可以提供多个计划环境文件，这些文件将在 CLI 中创建计划之前合并。

这些附加参数将直接从合并的 plan-environment.yaml 文件（存储在 Swift 中）由推导参数工作流读取。

可以在推导参数工作流执行后修改创建的计划或修改 profile-node 关联。目前，我们假设没有进行此类更改，但将在初始迭代后扩展，以通过一些验证来使部署失败。

操作员应该能够在不进行部署的情况下推导和查看参数；例如“生成部署计划”。如果计算是计划创建的一部分，那么可以预览计算出的值。或者，工作流可以独立于超云部署运行，但如何将其与 UI 工作流结合使用需要确定。

用例 1：推导 DPDK 参数¶

使用 YAQL 基于内省数据（包括 NUMA [2]）推导 DPDK 参数的 Mistral 工作流的一部分存在，并且可以在 GitHub 上看到 [3]。

用例 2：推导 HCI 配置¶

此用例使用 HCI，在同一节点上运行 Ceph OSD 和 Nova 计算。HCI 推导参数工作流使用一组默认配置来分类角色将承载的工作负载类型。将提供一个选项，以便通过 plan- environment.yaml 使用部署特定的配置来覆盖默认配置。

在 HCI 部署的情况下，用于部署的附加计划环境如下所示

workflow_parameters:
  tripleo.workflows.v1.derive_parameters:
    # HCI Derive Parameters
    HciProfile: nfv-default
    HciProfileConfig:
      default:
        average_guest_memory_size_in_mb: 2048
        average_guest_CPU_utilization_percentage: 50
      many_small_vms:
        average_guest_memory_size_in_mb: 1024
        average_guest_CPU_utilization_percentage: 20
      few_large_vms:
        average_guest_memory_size_in_mb: 4096
        average_guest_CPU_utilization_percentage: 80
      nfv_default:
        average_guest_memory_size_in_mb: 8192
        average_guest_CPU_utilization_percentage: 90

在上面的示例中，workflow_parameters 部分用于提供工作流的输入参数，以便在最大化不同类型客户机工作负载的性能的同时隔离 Nova 和 Ceph 资源。在 GitHub 上的 nova_mem_cpu_calc.py [4] 中提供了使用这些输入完成的推导示例。

TripleO 中参数推导的其他集成¶

用户仍然可以覆盖参数¶

如果工作流推导出一个参数，例如 cpu_allocation_ratio，但操作员在其超云部署中指定了 cpu_allocation_ratio，那么操作员提供的值优先于推导出的值。这在操作员想要获得所有推导出的值但只想覆盖其中一些参数的情况下可能很有用。

处理跨依赖资源¶

多个工作流最终可能会根据相同的资源（如 CPU）推导参数。当发生这种情况时，重要的是要考虑到优先级，以特定的顺序运行工作流。

例如，让我们考虑资源 CPU 以及如何在 DPDK 和 HCI 之间使用它。DPDK 需要一组专用于轮询模式驱动程序 (NeutronDpdkCoreList) 的 CPU，这些 CPU 不应用于主机进程 (ComputeHostCpusList) 和客户机 VM (NovaVcpuPinSet)。HCI 需要根据可用于客户机 VM (NovaVcpuPinSet) 的 CPU 数量推导 CPU 分配比率。DPDK 具有优先级，其次是 HOST 参数，然后是 HCI 参数。在这种情况下，工作流执行从 CPU 池开始，然后

DPDK：分配 NeutronDpdkCoreList
HOST：分配 ComputeHostCpusList
HOST：分配 NovaVcpuPinSet
HCI：基于 NovaVcpuPinSet 修复 CPU 分配比率

针对特定服务或角色的推导参数¶

如果操作员只想配置增强的放置感知 (EPA) 功能，如 CPU 引脚或大页，这些功能不与 DPDK 或 HCI 等任何功能关联，那么它应该仅与计算服务关联。

工作流与服务的关联¶

将推导参数工作流与服务关联的最佳方法是通过预览 Heat 堆栈来获取给定角色上启用的服务列表。由于 Heat 的当前限制，无法获取角色上启用的服务列表。因此，将向与推导参数工作流关联的服务引入一个新参数。如果此参数在特定角色的 Heat 资源树中引用，则将调用相应的推导参数工作流。例如，DPDK 服务将具有一个新参数“EnableDpdkDerivation”以启用 DPDK 特定的工作流。

TripleO UI 的未来集成¶

如果实施并合并此规范，那么 TripleO UI 可以为部署（例如 HCI）提供一个菜单项，操作员可以在其中选择推导配置文件，然后使用该推导配置文件部署超云。

UI 可以通过允许部署程序使用图形滑块来改变现有的推导配置文件，然后以新名称保存该推导配置文件来更好地与此功能集成。部署程序可以使用以下循环来调优超云。

选择部署，例如 HCI
选择 HCI 配置文件，例如 many_small_vms
运行部署
在部署的超云上基准测试计划的工作负载
使用滑块更改推导配置文件的各个方面
更新部署并重新运行基准测试
根据需要重复
将新的推导配置文件保存为要在现场部署的配置文件

实施此规范将使 TripleO UI 支持上述内容。

替代方案¶

最简单的替代方案是操作员通过测试或阅读文档确定适当的调优，然后在适当的 Heat 环境文件中实施这些调优。例如，在 HCI 场景中，操作员可以运行 nova_mem_cpu_calc.py [4]，然后创建如下所示的 Heat 环境文件，其中包含其输出，然后部署超云并直接引用此文件

parameter_defaults:
  ExtraConfig:
    nova::compute::reserved_host_memory: 75000
    nova::cpu_allocation_ratio: 8.2

这可能会转化为需要操作员主动性的各种覆盖。

另一种替代方案是编写单独的工具，这些工具生成所需的 Heat 模板，但不将其与 TripleO 集成。例如，nova_mem_cpu_calc.py 和类似工具将生成一组 Heat 环境文件作为输出，操作员将使用这些文件代替包含以下内容的文件

nova.conf reserved_host_memory_mb = 75000 MB
nova.conf cpu_allocation_ratio = 8.214286

在评估上述内容时，请记住，这里仅提供两个参数用于 CPU 分配和内存，作为示例，但经过调整的部署可能包含更多参数。

安全影响¶

此更改不会产生安全影响，因为它位于更高级别，通过 Mistral 和 Heat 自动化已经存在的特性。

其他最终用户影响¶

操作员无需根据内省或硬件规格数据手动推导部署参数，因为这些参数将使用预定义的公式自动推导。

性能影响¶

如果操作员使用此功能，则 overcloud 的部署和更新可能会稍长一些，因为需要运行额外的 Mistral 工作流来执行一些分析，然后再应用配置更新。但是，overcloud 的性能将会得到改善，因为该提案旨在使调整 overcloud 以获得最佳性能更加容易。

其他部署者影响¶

正在添加一个新的配置选项，但必须显式启用，因此在合并后不会立即生效。但是，如果部署者选择使用它并且其中存在错误，则可能会影响 overcloud 部署。如果部署者使用此新选项，并且在部署中直接设置了一个参数，例如 Nova cpu_allocation_ratio，那么该参数可能会被特定的调优配置文件覆盖。因此，部署者在使用此提议的功能时应注意这一点。

添加的配置选项将附带各种默认值，这些默认值基于在实验室中负载测试的部署。主要思想是提供在这些条件下生成的不同默认值集合。本提案中讨论的示例，并在完成时提供，可以扩展。

开发人员影响¶

本规范建议修改部署计划，如果存在错误，可能会给部署带来问题。但是，由于新功能完全是可选的，开发人员可以轻松地禁用它。

实现¶

负责人¶

主要负责人: skramaja fultonj
其他贡献者: jpalanis abishop shardy gfidente

工作项¶

启动工作流以查找角色列表 Derive Params
为每个角色运行工作流以获取内省数据并触发单个特性工作流
工作流，用于识别与特性工作流关联的服务是否在角色中启用
DPDK 工作流：分析并确定输入数据的格式 (jpalanis)
DPDK 工作流：参数推导工作流 (jpalanis)
HCI 工作流：运行一个计算参数的工作流 (abishop)
SR-IOV 工作流
EPA 特性工作流
从 CLI 运行推导参数工作流
添加 CI 场景测试，以验证是否生成了预期的输出

依赖项¶

内省数据中的 NUMA 拓扑 (ironic-python-agent) [5]

测试¶

在 TripleO CI 中创建一个新场景，使用可用选项中的所有选项进行部署，这些选项位于名为 all-derivation-options 的推导配置文件中。需要添加一个 CI 测试来测试此新功能，方法如下

将使用 all-derivation-options 配置文件进行部署
将检查部署，以确保已进行所有配置
如果配置更改到位，则测试通过
否则测试失败

将上述内容与 HCI 用例关联起来，测试可以验证以下两个选项之一

使用以下语法有效的 Heat 创建 Heat 环境文件

parameter_defaults:
  ExtraConfig:
    nova::compute::reserved_host_memory: 75000
    nova::cpu_allocation_ratio: 8.2

计算节点部署后，以下命令应返回类似以下内容

[root@overcloud-osd-compute-0 ~]# grep reserved_host_memory /etc/nova/nova.conf
reserved_host_memory_mb=75000
[root@overcloud-osd-compute-0 ~]# grep cpu_allocation_ratio /etc/nova/nova.conf
cpu_allocation_ratio=8.2
[root@overcloud-osd-compute-0 ~]#

选项 1 会减少 CI 基础设施上的负载并产生更快的测试，但选项 2 会测试完整场景。

如果添加了新的推导参数选项，则需要更新 all-derivation-options 配置文件，并且需要更新测试以验证是否设置了新选项。

文档影响¶

将在 TripleO 文档中添加一个新章节，介绍使用推导配置文件的部署。

派生 TripleO 参数