×

创建性能配置文件

您可以使用性能配置文件创建器 (PPC) 工具创建集群性能配置文件。PPC 是节点调整运算符的一个功能。

PPC 将有关集群的信息与用户提供的配置相结合,以生成适合您的硬件、拓扑结构和用例的性能配置文件。

性能配置文件仅适用于集群可以直接访问底层硬件资源的裸机环境。您可以为单节点 OpenShift 集群和多节点集群配置性能配置文件。

以下是您在集群中创建和应用性能配置文件的高级工作流程

  • 为要使用性能配置作为目标的节点创建机器配置池 (MCP)。在单节点 OpenShift 集群中,您必须使用master MCP,因为集群中只有一个节点。

  • 使用must-gather命令收集有关集群的信息。

  • 使用 PPC 工具通过以下任一方法创建性能配置文件

    • 使用 Podman 运行 PPC 工具。

    • 使用包装器脚本运行 PPC 工具。

  • 为您的用例配置性能配置文件并将性能配置文件应用于您的集群。

关于性能配置文件创建器

性能配置文件创建器 (PPC) 是一个命令行工具,随节点调整运算符一起提供,可帮助您为集群创建性能配置文件。

最初,您可以使用 PPC 工具处理must-gather数据以显示集群的关键性能配置,包括以下信息

  • 使用已分配的 CPU ID 进行 NUMA 单元分区

  • 超线程节点配置

您可以使用此信息来帮助您配置性能配置文件。

运行 PPC

向 PPC 工具指定性能配置参数以生成适合您的硬件、拓扑结构和用例的建议性能配置文件。

您可以使用以下任一方法运行 PPC

  • 使用 Podman 运行 PPC

  • 使用包装器脚本运行 PPC

使用包装器脚本将一些更细粒度的 Podman 任务抽象到可执行脚本中。例如,包装器脚本处理诸如拉取和运行所需的容器映像、将目录安装到容器以及通过 Podman 直接向容器提供参数等任务。两种方法都能达到相同的结果。

创建机器配置池以针对性能调整的节点

对于多节点集群,您可以定义一个机器配置池 (MCP) 来标识要使用性能配置文件配置的目标节点。

在单节点 OpenShift 集群中,必须使用master MCP,因为集群中只有一个节点。无需为单节点 OpenShift 集群创建单独的 MCP。

先决条件
  • 您具有cluster-admin 角色访问权限。

  • 您已安装 OpenShift CLI (oc)。

步骤
  1. 通过运行以下命令标记要配置的目标节点

    $ oc label node <node_name> node-role.kubernetes.io/worker-cnf="" (1)
    1 <node_name>替换为您的节点名称。此示例应用worker-cnf标签。
  2. 创建一个包含目标节点的MachineConfigPool资源

    1. 创建一个 YAML 文件,定义MachineConfigPool资源

      mcp-worker-cnf.yaml 文件示例
      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        name: worker-cnf (1)
        labels:
          machineconfiguration.openshift.io/role: worker-cnf (2)
      spec:
        machineConfigSelector:
          matchExpressions:
            - {
                 key: machineconfiguration.openshift.io/role,
                 operator: In,
                 values: [worker, worker-cnf],
              }
        paused: false
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/worker-cnf: "" (3)
      1 指定MachineConfigPool资源的名称。
      2 为机器配置池指定一个唯一的标签。
      3 指定您定义的目标标签的节点。
    2. 通过运行以下命令应用MachineConfigPool资源

      $ oc apply -f mcp-worker-cnf.yaml
      示例输出
      machineconfigpool.machineconfiguration.openshift.io/worker-cnf created
验证
  • 通过运行以下命令检查集群中的机器配置池

    $ oc get mcp
    示例输出
    NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
    master       rendered-master-58433c7c3c1b4ed5ffef95234d451490       True      False      False      3              3                   3                     0                      6h46m
    worker       rendered-worker-168f52b168f151e4f853259729b6azc4       True      False      False      2              2                   2                     0                      6h46m
    worker-cnf   rendered-worker-cnf-168f52b168f151e4f853259729b6azc4   True      False      False      1              1                   1                     0                      73s

使用 must-gather 收集集群数据 (用于 PPC)

性能配置文件创建器 (PPC) 工具需要must-gather数据。作为集群管理员,运行must-gather命令来捕获有关集群的信息。

先决条件
  • 以具有cluster-admin角色的用户身份访问集群。

  • 您已安装 OpenShift CLI (oc)。

  • 您已标识要使用性能配置文件配置的目标 MCP。

步骤
  1. 导航到要存储must-gather数据的目录。

  2. 通过运行以下命令收集集群信息

    $ oc adm must-gather

    该命令会在您的本地目录中创建一个包含must-gather数据的文件夹,命名格式类似于以下格式:must-gather.local.1971646453781853027

  3. 可选:从must-gather目录创建一个压缩文件

    $ tar cvaf must-gather.tar.gz <must_gather_folder> (1)
    1 替换为must-gather数据文件夹的名称。

    如果您运行性能配置文件创建器包装器脚本,则需要压缩输出。

其他资源

使用 Podman 运行性能配置文件创建器

作为集群管理员,您可以将 Podman 与性能配置文件创建器 (PPC) 一起使用来创建性能配置文件。

有关 PPC 参数的更多信息,请参阅“性能配置文件创建器参数”部分。

PPC 使用来自您集群的must-gather数据来创建性能配置文件。如果您对集群进行了任何更改,例如重新标记目标性能配置的节点,则必须在再次运行 PPC 之前重新创建must-gather数据。

先决条件
  • 以具有cluster-admin角色的用户身份访问集群。

  • 安装在裸机硬件上的集群。

  • 您已安装podman和 OpenShift CLI (oc)。

  • 访问节点调整操作符镜像。

  • 您已标识包含目标配置节点的机器配置池。

  • 您可以访问集群的must-gather数据。

步骤
  1. 通过运行以下命令检查机器配置池

    $ oc get mcp
    示例输出
    NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
    master       rendered-master-58433c8c3c0b4ed5feef95434d455490       True      False      False      3              3                   3                     0                      8h
    worker       rendered-worker-668f56a164f151e4a853229729b6adc4       True      False      False      2              2                   2                     0                      8h
    worker-cnf   rendered-worker-cnf-668f56a164f151e4a853229729b6adc4   True      False      False      1              1                   1                     0                      79m
  2. 通过运行以下命令使用 Podman 认证到registry.redhat.io

    $ podman login registry.redhat.io
    Username: <user_name>
    Password: <password>
  3. 可选:通过运行以下命令显示 PPC 工具的帮助信息

    $ podman run --rm --entrypoint performance-profile-creator registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.17 -h
    示例输出
    A tool that automates creation of Performance Profiles
    
    Usage:
      performance-profile-creator [flags]
    
    Flags:
          --disable-ht                        Disable Hyperthreading
      -h, --help                              help for performance-profile-creator
          --info string                       Show cluster information; requires --must-gather-dir-path, ignore the other arguments. [Valid values: log, json] (default "log")
          --mcp-name string                   MCP name corresponding to the target machines (required)
          --must-gather-dir-path string       Must gather directory path (default "must-gather")
          --offlined-cpu-count int            Number of offlined CPUs
          --per-pod-power-management          Enable Per Pod Power Management
          --power-consumption-mode string     The power consumption mode.  [Valid values: default, low-latency, ultra-low-latency] (default "default")
          --profile-name string               Name of the performance profile to be created (default "performance")
          --reserved-cpu-count int            Number of reserved CPUs (required)
          --rt-kernel                         Enable Real Time Kernel (required)
          --split-reserved-cpus-across-numa   Split the Reserved CPUs across NUMA nodes
          --topology-manager-policy string    Kubelet Topology Manager Policy of the performance profile to be created. [Valid values: single-numa-node, best-effort, restricted] (default "restricted")
          --user-level-networking             Run with User level Networking(DPDK) enabled
  4. 要显示有关集群的信息,请使用log参数运行 PPC 工具,方法是运行以下命令

    $ podman run --entrypoint performance-profile-creator -v <path_to_must_gather>:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.17 --info log --must-gather-dir-path /must-gather
    • --entrypoint performance-profile-creator 将性能配置文件创建器定义为podman的新入口点。

    • -v <path_to_must_gather>指定以下任一组件的路径

      • 包含must-gather数据的目录。

      • 包含must-gather解压缩 .tar 文件的现有目录。

    • --info log指定输出格式的值。

      示例输出
      level=info msg="Cluster info:"
      level=info msg="MCP 'master' nodes:"
      level=info msg=---
      level=info msg="MCP 'worker' nodes:"
      level=info msg="Node: host.example.com (NUMA cells: 1, HT: true)"
      level=info msg="NUMA cell 0 : [0 1 2 3]"
      level=info msg="CPU(s): 4"
      level=info msg="Node: host1.example.com (NUMA cells: 1, HT: true)"
      level=info msg="NUMA cell 0 : [0 1 2 3]"
      level=info msg="CPU(s): 4"
      level=info msg=---
      level=info msg="MCP 'worker-cnf' nodes:"
      level=info msg="Node: host2.example.com (NUMA cells: 1, HT: true)"
      level=info msg="NUMA cell 0 : [0 1 2 3]"
      level=info msg="CPU(s): 4"
      level=info msg=---
  5. 运行以下命令创建性能配置文件。此示例使用示例 PPC 参数和值

    $ podman run --entrypoint performance-profile-creator -v <path_to_must_gather>:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.17 --mcp-name=worker-cnf --reserved-cpu-count=1 --rt-kernel=true --split-reserved-cpus-across-numa=false --must-gather-dir-path /must-gather --power-consumption-mode=ultra-low-latency --offlined-cpu-count=1 > my-performance-profile.yaml
    • -v <path_to_must_gather>指定以下任一组件的路径

      • 包含must-gather数据的目录。

      • 包含must-gather解压缩 .tar 文件的目录。

    • --mcp-name=worker-cnf指定worker-=cnf机器配置池。

    • --reserved-cpu-count=1指定一个保留的 CPU。

    • --rt-kernel=true启用实时内核。

    • --split-reserved-cpus-across-numa=false禁用跨 NUMA 节点拆分保留的 CPU。

    • --power-consumption-mode=ultra-low-latency指定最小延迟,代价是功耗增加。

    • --offlined-cpu-count=1指定一个离线 CPU。

      此示例中的mcp-name参数根据命令oc get mcp的输出设置为worker-cnf。对于单节点 OpenShift,请使用--mcp-name=master

      示例输出
      level=info msg="Nodes targeted by worker-cnf MCP are: [worker-2]"
      level=info msg="NUMA cell(s): 1"
      level=info msg="NUMA cell 0 : [0 1 2 3]"
      level=info msg="CPU(s): 4"
      level=info msg="1 reserved CPUs allocated: 0 "
      level=info msg="2 isolated CPUs allocated: 2-3"
      level=info msg="Additional Kernel Args based on configuration: []"
  6. 通过运行以下命令查看已创建的 YAML 文件

    $ cat my-performance-profile.yaml
    示例输出
    ---
    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: performance
    spec:
      cpu:
        isolated: 2-3
        offlined: "1"
        reserved: "0"
      machineConfigPoolSelector:
        machineconfiguration.openshift.io/role: worker-cnf
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
      numa:
        topologyPolicy: restricted
      realTimeKernel:
        enabled: true
      workloadHints:
        highPowerConsumption: true
        perPodPowerManagement: false
        realTime: true
  7. 应用生成的配置文件

    $ oc apply -f my-performance-profile.yaml
    示例输出
    performanceprofile.performance.openshift.io/performance created

运行性能配置文件创建器包装器脚本

包装器脚本简化了使用性能配置文件创建器 (PPC) 工具创建性能配置文件的过程。该脚本处理诸如提取和运行所需容器镜像、将目录挂载到容器以及通过 Podman 直接向容器提供参数等任务。

有关性能配置文件创建器参数的更多信息,请参阅“性能配置文件创建器参数”部分。

PPC 使用来自您集群的must-gather数据来创建性能配置文件。如果您对集群进行了任何更改,例如重新标记目标性能配置的节点,则必须在再次运行 PPC 之前重新创建must-gather数据。

先决条件
  • 以具有cluster-admin角色的用户身份访问集群。

  • 安装在裸机硬件上的集群。

  • 您已安装podman和 OpenShift CLI (oc)。

  • 访问节点调整操作符镜像。

  • 您已标识包含目标配置节点的机器配置池。

  • 访问must-gathertarball。

步骤
  1. 在本地机器上创建一个文件,例如命名为run-perf-profile-creator.sh

    $ vi run-perf-profile-creator.sh
  2. 将以下代码粘贴到文件中

    #!/bin/bash
    
    readonly CONTAINER_RUNTIME=${CONTAINER_RUNTIME:-podman}
    readonly CURRENT_SCRIPT=$(basename "$0")
    readonly CMD="${CONTAINER_RUNTIME} run --entrypoint performance-profile-creator"
    readonly IMG_EXISTS_CMD="${CONTAINER_RUNTIME} image exists"
    readonly IMG_PULL_CMD="${CONTAINER_RUNTIME} image pull"
    readonly MUST_GATHER_VOL="/must-gather"
    
    NTO_IMG="registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.17"
    MG_TARBALL=""
    DATA_DIR=""
    
    usage() {
      print "Wrapper usage:"
      print "  ${CURRENT_SCRIPT} [-h] [-p image][-t path] -- [performance-profile-creator flags]"
      print ""
      print "Options:"
      print "   -h                 help for ${CURRENT_SCRIPT}"
      print "   -p                 Node Tuning Operator image"
      print "   -t                 path to a must-gather tarball"
    
      ${IMG_EXISTS_CMD} "${NTO_IMG}" && ${CMD} "${NTO_IMG}" -h
    }
    
    function cleanup {
      [ -d "${DATA_DIR}" ] && rm -rf "${DATA_DIR}"
    }
    trap cleanup EXIT
    
    exit_error() {
      print "error: $*"
      usage
      exit 1
    }
    
    print() {
      echo  "$*" >&2
    }
    
    check_requirements() {
      ${IMG_EXISTS_CMD} "${NTO_IMG}" || ${IMG_PULL_CMD} "${NTO_IMG}" || \
          exit_error "Node Tuning Operator image not found"
    
      [ -n "${MG_TARBALL}" ] || exit_error "Must-gather tarball file path is mandatory"
      [ -f "${MG_TARBALL}" ] || exit_error "Must-gather tarball file not found"
    
      DATA_DIR=$(mktemp -d -t "${CURRENT_SCRIPT}XXXX") || exit_error "Cannot create the data directory"
      tar -zxf "${MG_TARBALL}" --directory "${DATA_DIR}" || exit_error "Cannot decompress the must-gather tarball"
      chmod a+rx "${DATA_DIR}"
    
      return 0
    }
    
    main() {
      while getopts ':hp:t:' OPT; do
        case "${OPT}" in
          h)
            usage
            exit 0
            ;;
          p)
            NTO_IMG="${OPTARG}"
            ;;
          t)
            MG_TARBALL="${OPTARG}"
            ;;
          ?)
            exit_error "invalid argument: ${OPTARG}"
            ;;
        esac
      done
      shift $((OPTIND - 1))
    
      check_requirements || exit 1
    
      ${CMD} -v "${DATA_DIR}:${MUST_GATHER_VOL}:z" "${NTO_IMG}" "$@" --must-gather-dir-path "${MUST_GATHER_VOL}"
      echo "" 1>&2
    }
    
    main "$@"
  3. 为该脚本上的所有人添加执行权限

    $ chmod a+x run-perf-profile-creator.sh
  4. 通过运行以下命令使用 Podman 认证到registry.redhat.io

    $ podman login registry.redhat.io
    Username: <user_name>
    Password: <password>
  5. 可选:通过运行以下命令显示 PPC 工具的帮助信息

    $ ./run-perf-profile-creator.sh -h
    示例输出
    Wrapper usage:
      run-perf-profile-creator.sh [-h] [-p image][-t path] -- [performance-profile-creator flags]
    
    Options:
       -h                 help for run-perf-profile-creator.sh
       -p                 Node Tuning Operator image
       -t                 path to a must-gather tarball
    A tool that automates creation of Performance Profiles
    
    Usage:
      performance-profile-creator [flags]
    
    Flags:
          --disable-ht                        Disable Hyperthreading
      -h, --help                              help for performance-profile-creator
          --info string                       Show cluster information; requires --must-gather-dir-path, ignore the other arguments. [Valid values: log, json] (default "log")
          --mcp-name string                   MCP name corresponding to the target machines (required)
          --must-gather-dir-path string       Must gather directory path (default "must-gather")
          --offlined-cpu-count int            Number of offlined CPUs
          --per-pod-power-management          Enable Per Pod Power Management
          --power-consumption-mode string     The power consumption mode.  [Valid values: default, low-latency, ultra-low-latency] (default "default")
          --profile-name string               Name of the performance profile to be created (default "performance")
          --reserved-cpu-count int            Number of reserved CPUs (required)
          --rt-kernel                         Enable Real Time Kernel (required)
          --split-reserved-cpus-across-numa   Split the Reserved CPUs across NUMA nodes
          --topology-manager-policy string    Kubelet Topology Manager Policy of the performance profile to be created. [Valid values: single-numa-node, best-effort, restricted] (default "restricted")
          --user-level-networking             Run with User level Networking(DPDK) enabled
          --enable-hardware-tuning            Enable setting maximum CPU frequencies

    您可以使用-p选项可选地设置节点调整操作符镜像的路径。如果未设置路径,则包装器脚本将使用默认镜像:registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.17

  6. 要显示有关集群的信息,请使用log参数运行 PPC 工具,方法是运行以下命令

    $ ./run-perf-profile-creator.sh -t /<path_to_must_gather_dir>/must-gather.tar.gz -- --info=log
    • -t /<path_to_must_gather_dir>/must-gather.tar.gz指定包含 must-gather tarball 的目录的路径。这是包装器脚本的必需参数。

      示例输出
      level=info msg="Cluster info:"
      level=info msg="MCP 'master' nodes:"
      level=info msg=---
      level=info msg="MCP 'worker' nodes:"
      level=info msg="Node: host.example.com (NUMA cells: 1, HT: true)"
      level=info msg="NUMA cell 0 : [0 1 2 3]"
      level=info msg="CPU(s): 4"
      level=info msg="Node: host1.example.com (NUMA cells: 1, HT: true)"
      level=info msg="NUMA cell 0 : [0 1 2 3]"
      level=info msg="CPU(s): 4"
      level=info msg=---
      level=info msg="MCP 'worker-cnf' nodes:"
      level=info msg="Node: host2.example.com (NUMA cells: 1, HT: true)"
      level=info msg="NUMA cell 0 : [0 1 2 3]"
      level=info msg="CPU(s): 4"
      level=info msg=---
  7. 运行以下命令创建性能配置文件。

    $ ./run-perf-profile-creator.sh -t /path-to-must-gather/must-gather.tar.gz -- --mcp-name=worker-cnf --reserved-cpu-count=1 --rt-kernel=true --split-reserved-cpus-across-numa=false --power-consumption-mode=ultra-low-latency --offlined-cpu-count=1 > my-performance-profile.yaml

    此示例使用示例 PPC 参数和值。

    • --mcp-name=worker-cnf指定worker-=cnf机器配置池。

    • --reserved-cpu-count=1指定一个保留的 CPU。

    • --rt-kernel=true启用实时内核。

    • --split-reserved-cpus-across-numa=false禁用跨 NUMA 节点拆分保留的 CPU。

    • --power-consumption-mode=ultra-low-latency指定最小延迟,代价是功耗增加。

    • --offlined-cpu-count=1指定一个离线 CPU。

      此示例中的mcp-name参数根据命令oc get mcp的输出设置为worker-cnf。对于单节点 OpenShift,请使用--mcp-name=master

  8. 通过运行以下命令查看已创建的 YAML 文件

    $ cat my-performance-profile.yaml
    示例输出
    ---
    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: performance
    spec:
      cpu:
        isolated: 2-3
        offlined: "1"
        reserved: "0"
      machineConfigPoolSelector:
        machineconfiguration.openshift.io/role: worker-cnf
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
      numa:
        topologyPolicy: restricted
      realTimeKernel:
        enabled: true
      workloadHints:
        highPowerConsumption: true
        perPodPowerManagement: false
        realTime: true
  9. 应用生成的配置文件

    $ oc apply -f my-performance-profile.yaml
    示例输出
    performanceprofile.performance.openshift.io/performance created

性能配置文件创建器参数

表 1. 必需的性能配置文件创建器参数
参数 描述

mcp-name

MCP 的名称;例如,对应于目标机器的worker-cnf

must-gather-dir-path

must-gather 目录的路径。

仅当您使用 Podman 运行 PPC 工具时,才需要此参数。如果您使用包装器脚本使用 PPC,请勿使用此参数。而是使用包装器脚本的-t选项指定must-gathertarball 的目录路径。

reserved-cpu-count

保留的 CPU 数量。使用大于零的自然数。

rt-kernel

启用实时内核。

可能的值:truefalse

表 2. 可选的性能配置文件创建器参数
参数 描述

disable-ht

禁用超线程。

可能的值:truefalse

默认值:false

如果将此参数设置为true,则不应在 BIOS 中禁用超线程。禁用超线程是通过内核命令行参数实现的。

enable-hardware-tuning

启用最大 CPU 频率设置。

要启用此功能,请为在隔离和保留 CPU 上运行的应用程序设置以下两个字段的最大频率

  • spec.hardwareTuning.isolatedCpuFreq

  • spec.hardwareTuning.reservedCpuFreq

这是一个高级功能。如果配置了硬件调整,则生成的PerformanceProfile将包含有关如何设置频率设置的警告和指南。

info

这会捕获集群信息。此参数还需要must-gather-dir-path参数。如果设置了任何其他参数,则会忽略它们。

可能的值

  • log

  • JSON

默认值:log

offlined-cpu-count

已下线的 CPU 数量。

使用大于零的自然数。如果下线的逻辑处理器数量不足,则会记录错误消息。消息为:

Error: failed to compute the reserved and isolated CPUs: please ensure that reserved-cpu-count plus offlined-cpu-count should be in the range [0,1]
Error: failed to compute the reserved and isolated CPUs: please specify the offlined CPU count in the range [0,1]

power-consumption-mode

功耗模式。

可能的值

  • default:仅通过 CPU 分区实现的性能。

  • low-latency:增强措施以提高延迟。

  • ultra-low-latency:优先考虑最佳延迟,以牺牲电源管理为代价。

默认值:default

per-pod-power-management

启用每个 Pod 的电源管理。如果将ultra-low-latency配置为功耗模式,则不能使用此参数。

可能的值:truefalse

默认值:false

profile-name

要创建的性能配置文件的名称。

默认值:performance

split-reserved-cpus-across-numa

将保留的 CPU 分散到 NUMA 节点上。

可能的值:truefalse

默认值:false

topology-manager-policy

要创建的性能配置文件的 Kubelet Topology Manager 策略。

可能的值

  • single-numa-node

  • best-effort

  • restricted

默认值:restricted

user-level-networking

启用用户级网络 (DPDK) 后运行。

可能的值:truefalse

默认值:false

参考性能配置文件

使用以下参考性能配置文件作为开发您自己的自定义配置文件的基础。

使用 OVS-DPDK 的 OpenStack 集群的性能配置文件模板

为了最大限度地提高在 Red Hat OpenStack Platform (RHOSP) 上使用数据平面开发套件 (OVS-DPDK) 的 Open vSwitch 的集群中的机器性能,您可以使用性能配置文件。

您可以使用以下性能配置文件模板为您的部署创建配置文件。

使用 OVS-DPDK 的集群的性能配置文件模板
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: cnf-performanceprofile
spec:
  additionalKernelArgs:
    - nmi_watchdog=0
    - audit=0
    - mce=off
    - processor.max_cstate=1
    - idle=poll
    - intel_idle.max_cstate=0
    - default_hugepagesz=1GB
    - hugepagesz=1G
    - intel_iommu=on
  cpu:
    isolated: <CPU_ISOLATED>
    reserved: <CPU_RESERVED>
  hugepages:
    defaultHugepagesSize: 1G
    pages:
      - count: <HUGEPAGES_COUNT>
        node: 0
        size: 1G
  nodeSelector:
    node-role.kubernetes.io/worker: ''
  realTimeKernel:
    enabled: false
    globallyDisableIrqLoadBalancing: true

CPU_ISOLATEDCPU_RESERVEDHUGEPAGES_COUNT键插入适合您配置的值。

电信 RAN DU 参考设计性能配置文件

以下性能配置文件配置商品硬件上 OpenShift Container Platform 集群的节点级性能设置,以承载电信 RAN DU 工作负载。

电信 RAN DU 参考设计性能配置文件
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  # if you change this name make sure the 'include' line in TunedPerformancePatch.yaml
  # matches this name: include=openshift-node-performance-${PerformanceProfile.metadata.name}
  # Also in file 'validatorCRs/informDuValidator.yaml': 
  # name: 50-performance-${PerformanceProfile.metadata.name}
  name: openshift-node-performance-profile
  annotations:
    ran.openshift.io/reference-configuration: "ran-du.redhat.com"
spec:
  additionalKernelArgs:
    - "rcupdate.rcu_normal_after_boot=0"
    - "efi=runtime"
    - "vfio_pci.enable_sriov=1"
    - "vfio_pci.disable_idle_d3=1"
    - "module_blacklist=irdma"
  cpu:
    isolated: $isolated
    reserved: $reserved
  hugepages:
    defaultHugepagesSize: $defaultHugepagesSize
    pages:
      - size: $size
        count: $count
        node: $node
  machineConfigPoolSelector:
    pools.operator.machineconfiguration.openshift.io/$mcp: ""
  nodeSelector:
    node-role.kubernetes.io/$mcp: ''
  numa:
    topologyPolicy: "restricted"
  # To use the standard (non-realtime) kernel, set enabled to false
  realTimeKernel:
    enabled: true
  workloadHints:
    # WorkloadHints defines the set of upper level flags for different type of workloads.
    # See https://github.com/openshift/cluster-node-tuning-operator/blob/master/docs/performanceprofile/performance_profile.md#workloadhints
    # for detailed descriptions of each item.
    # The configuration below is set for a low latency, performance mode.
    realTime: true
    highPowerConsumption: false
    perPodPowerManagement: false

电信核心参考设计性能配置文件

以下性能配置文件配置商品硬件上 OpenShift Container Platform 集群的节点级性能设置,以承载电信核心工作负载。

电信核心参考设计性能配置文件
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  # if you change this name make sure the 'include' line in TunedPerformancePatch.yaml
  # matches this name: include=openshift-node-performance-${PerformanceProfile.metadata.name}
  # Also in file 'validatorCRs/informDuValidator.yaml': 
  # name: 50-performance-${PerformanceProfile.metadata.name}
  name: openshift-node-performance-profile
  annotations:
    ran.openshift.io/reference-configuration: "ran-du.redhat.com"
spec:
  additionalKernelArgs:
    - "rcupdate.rcu_normal_after_boot=0"
    - "efi=runtime"
    - "vfio_pci.enable_sriov=1"
    - "vfio_pci.disable_idle_d3=1"
    - "module_blacklist=irdma"
  cpu:
    isolated: $isolated
    reserved: $reserved
  hugepages:
    defaultHugepagesSize: $defaultHugepagesSize
    pages:
      - size: $size
        count: $count
        node: $node
  machineConfigPoolSelector:
    pools.operator.machineconfiguration.openshift.io/$mcp: ""
  nodeSelector:
    node-role.kubernetes.io/$mcp: ''
  numa:
    topologyPolicy: "restricted"
  # To use the standard (non-realtime) kernel, set enabled to false
  realTimeKernel:
    enabled: true
  workloadHints:
    # WorkloadHints defines the set of upper level flags for different type of workloads.
    # See https://github.com/openshift/cluster-node-tuning-operator/blob/master/docs/performanceprofile/performance_profile.md#workloadhints
    # for detailed descriptions of each item.
    # The configuration below is set for a low latency, performance mode.
    realTime: true
    highPowerConsumption: false
    perPodPowerManagement: false

支持的性能配置文件 API 版本

节点调整操作符支持性能配置文件apiVersion字段的v2v1v1alpha1。v1 和 v1alpha1 API 是相同的。v2 API 包含一个可选的布尔字段globallyDisableIrqLoadBalancing,其默认值为false

将性能配置文件升级为使用设备中断处理

当您将节点调整操作符性能配置文件自定义资源定义 (CRD) 从 v1 或 v1alpha1 升级到 v2 时,globallyDisableIrqLoadBalancing在现有配置文件中设置为true

globallyDisableIrqLoadBalancing切换是否将为隔离的 CPU 集禁用 IRQ 负载均衡。当该选项设置为true时,它会禁用隔离的 CPU 集的 IRQ 负载均衡。将选项设置为false允许 IRQ 在所有 CPU 上均衡。

将节点调整操作符 API 从 v1alpha1 升级到 v1

将节点调整操作符 API 版本从 v1alpha1 升级到 v1 时,v1alpha1 性能配置文件将使用“无”转换策略动态转换,并以 API 版本 v1 提供给节点调整操作符。

将节点调整操作符 API 从 v1alpha1 或 v1 升级到 v2

从较旧的节点调整操作符 API 版本升级时,现有 v1 和 v1alpha1 性能配置文件将使用注入值为truegloballyDisableIrqLoadBalancing字段的转换 Webhook 进行转换。

使用工作负载提示配置节点功耗和实时处理

步骤
  • 使用性能配置文件创建器 (PPC) 工具创建适合环境硬件和拓扑结构的PerformanceProfile。下表描述了为与 PPC 工具关联的power-consumption-mode标志设置的可能值以及应用的工作负载提示。

表 3. 功耗和实时设置组合对延迟的影响
性能配置文件创建器设置 提示 环境 描述

默认

workloadHints:
highPowerConsumption: false
realTime: false

无需延迟要求的高吞吐量集群

仅通过 CPU 分区实现的性能。

低延迟

workloadHints:
highPowerConsumption: false
realTime: true

区域数据中心

既需要节能又需要低延迟:在电源管理、延迟和吞吐量之间进行折衷。

超低延迟

workloadHints:
highPowerConsumption: true
realTime: true

远端边缘集群,延迟关键型工作负载

针对绝对最小的延迟和最大的确定性进行了优化,但会增加功耗。

每个 Pod 的电源管理

workloadHints:
realTime: true
highPowerConsumption: false
perPodPowerManagement: true

关键和非关键工作负载

允许每个 Pod 进行电源管理。

示例

以下配置通常用于电信 RAN DU 部署中。

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: workload-hints
    spec:
      ...
      workloadHints:
        realTime: true
        highPowerConsumption: false
        perPodPowerManagement: false (1)
1 禁用一些可能会影响系统延迟的调试和监控功能。

当在性能配置文件中将realTime工作负载提示标志设置为true时,请向每个具有固定 CPU 的保证型 Pod 添加cpu-quota.crio.io: disable注释。此注释对于防止 Pod 内进程性能下降是必要的。如果未显式设置realTime工作负载提示,则默认为true

有关功耗和实时设置组合如何影响延迟的更多信息,请参见了解工作负载提示

为运行协同定位的高优先级和低优先级工作负载的节点配置节能

您可以为具有与高优先级工作负载协同定位的低优先级工作负载的节点启用节能,而不会影响高优先级工作负载的延迟或吞吐量。无需修改工作负载本身即可实现节能。

此功能在英特尔 Ice Lake 和更高版本的英特尔 CPU 上受支持。处理器的功能可能会影响高优先级工作负载的延迟和吞吐量。

先决条件
  • 您已在 BIOS 中启用 C 状态和操作系统控制的 P 状态

步骤
  1. 使用设置为trueper-pod-power-management参数生成PerformanceProfile

    $ podman run --entrypoint performance-profile-creator -v \
    /must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v4.17 \
    --mcp-name=worker-cnf --reserved-cpu-count=20 --rt-kernel=true \
    --split-reserved-cpus-across-numa=false --topology-manager-policy=single-numa-node \
    --must-gather-dir-path /must-gather --power-consumption-mode=low-latency \ (1)
    --per-pod-power-management=true > my-performance-profile.yaml
    1 per-pod-power-management参数设置为true时,power-consumption-mode参数必须为defaultlow-latency
    包含perPodPowerManagement的示例PerformanceProfile
    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
         name: performance
    spec:
        [.....]
        workloadHints:
            realTime: true
            highPowerConsumption: false
            perPodPowerManagement: true
  2. PerformanceProfile自定义资源 (CR) 中,设置默认的cpufreq 调节器作为额外的内核参数。

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
         name: performance
    spec:
        ...
        additionalKernelArgs:
        - cpufreq.default_governor=schedutil (1)
    1 建议使用schedutil 调节器,但是,您也可以使用其他调节器,例如ondemandpowersave 调节器。
  3. TunedPerformancePatch CR 中设置最大 CPU 频率。

    spec:
      profile:
      - data: |
          [sysfs]
          /sys/devices/system/cpu/intel_pstate/max_perf_pct = <x> (1)
    1 max_perf_pct 控制cpufreq驱动程序允许设置的最大频率,该频率以最大支持的 CPU 频率的百分比表示。此值适用于所有 CPU。您可以在/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq中检查最大支持频率。作为起点,您可以使用一个百分比,将所有 CPU 的频率限制在“所有核心 Turbo”频率。 “所有核心 Turbo”频率是指所有核心完全占用时所有核心运行的频率。

限制基础设施和应用程序容器的 CPU 使用

通用的维护和工作负载任务使用 CPU 的方式可能会影响对延迟敏感的进程。默认情况下,容器运行时使用所有在线 CPU 来同时运行所有容器,这可能会导致上下文切换和延迟峰值。通过将这些进程彼此分离,CPU 分区可以防止有干扰的进程干扰对延迟敏感的进程。

表 4. 进程的 CPU 分配
进程类型 详情

BurstableBestEffort Pod

运行在除低延迟工作负载运行的 CPU 之外的任何 CPU 上。

基础设施 Pod

运行在除低延迟工作负载运行的 CPU 之外的任何 CPU 上。

中断

重定向到保留的 CPU(在 OpenShift Container Platform 4.7 及更高版本中可选)。

内核进程

固定到保留的 CPU。

对延迟敏感的工作负载 Pod

固定到隔离池中的一组特定的专用 CPU。

OS 进程/systemd 服务

固定到保留的 CPU。

节点上所有 QoS 进程类型(BurstableBestEffortGuaranteed)的 Pod 的可分配核心容量等于隔离池的容量。保留池的容量从节点的总核心容量中移除,供集群和操作系统维护任务使用。

示例 1

一个节点的容量为 100 个核心。使用性能配置文件,集群管理员将 50 个核心分配给隔离池,50 个核心分配给保留池。集群管理员将 25 个核心分配给 QoS Guaranteed Pod,25 个核心分配给 BestEffortBurstable Pod。这与隔离池的容量相匹配。

示例 2

一个节点的容量为 100 个核心。使用性能配置文件,集群管理员将 50 个核心分配给隔离池,50 个核心分配给保留池。集群管理员将 50 个核心分配给 QoS Guaranteed Pod,一个核心分配给 BestEffortBurstable Pod。这比隔离池的容量多了一个核心。由于 CPU 容量不足,Pod 调度失败。

要使用的确切分区模式取决于许多因素,例如硬件、工作负载特性和预期的系统负载。以下是一些示例用例:

  • 如果对延迟敏感的工作负载使用特定的硬件,例如网络接口控制器 (NIC),请确保隔离池中的 CPU 尽可能靠近此硬件。至少,您应该将工作负载放在同一个非一致性内存访问 (NUMA) 节点中。

  • 保留池用于处理所有中断。当依赖系统网络时,请分配一个足够大的保留池来处理所有传入的数据包中断。在 4.17 和更高版本中,工作负载可以选择性地标记为敏感。

关于哪些特定的 CPU 应该用于保留和隔离分区,需要进行详细的分析和测量。设备和内存的 NUMA 亲和性等因素起着作用。选择还取决于工作负载架构和具体的用例。

保留和隔离的 CPU 池不能重叠,并且必须共同涵盖工作节点中的所有可用核心。

为了确保维护任务和工作负载不会相互干扰,请在性能配置文件的spec部分中指定两组 CPU。

  • isolated - 指定应用程序容器工作负载的 CPU。这些 CPU 的延迟最低。此组中的进程没有中断,例如,可以达到更高的 DPDK 零丢包带宽。

  • reserved - 指定集群和操作系统维护任务的 CPU。reserved组中的线程通常很繁忙。不要在reserved组中运行对延迟敏感的应用程序。对延迟敏感的应用程序应在isolated组中运行。

步骤
  1. 创建适合环境硬件和拓扑结构的性能配置文件。

  2. 添加reservedisolated参数,以及您希望为基础设施和应用程序容器保留和隔离的 CPU。

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: infra-cpus
    spec:
      cpu:
        reserved: "0-4,9" (1)
        isolated: "5-8" (2)
      nodeSelector: (3)
        node-role.kubernetes.io/worker: ""
    1 指定哪些 CPU 用于基础设施容器执行集群和操作系统维护任务。
    2 指定哪些 CPU 用于应用程序容器运行工作负载。
    3 可选:指定节点选择器以将性能配置文件应用于特定节点。

为集群配置超线程

要为 OpenShift Container Platform 集群配置超线程,请在性能配置文件中将 CPU 线程设置为与为保留或隔离 CPU 池配置的内核相同的内核。

如果您配置了性能配置文件,随后又更改了主机的超线程配置,请确保更新PerformanceProfile YAML 中的 CPU isolatedreserved 字段以匹配新的配置。

禁用先前启用的主机超线程配置可能会导致PerformanceProfile YAML 中列出的 CPU 核心 ID 不正确。此不正确的配置可能会导致节点不可用,因为无法再找到列出的 CPU。

先决条件
  • 以具有cluster-admin角色的用户身份访问集群。

  • 安装 OpenShift CLI (oc)。

步骤
  1. 确定您要配置的主机上哪些线程正在哪些 CPU 上运行。

    您可以通过登录到集群并运行以下命令来查看哪些线程正在主机 CPU 上运行:

    $ lscpu --all --extended
    示例输出
    CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ    MINMHZ
    0   0    0      0    0:0:0:0       yes    4800.0000 400.0000
    1   0    0      1    1:1:1:0       yes    4800.0000 400.0000
    2   0    0      2    2:2:2:0       yes    4800.0000 400.0000
    3   0    0      3    3:3:3:0       yes    4800.0000 400.0000
    4   0    0      0    0:0:0:0       yes    4800.0000 400.0000
    5   0    0      1    1:1:1:0       yes    4800.0000 400.0000
    6   0    0      2    2:2:2:0       yes    4800.0000 400.0000
    7   0    0      3    3:3:3:0       yes    4800.0000 400.0000

    在此示例中,有八个逻辑 CPU 核心在四个物理 CPU 核心上运行。CPU0 和 CPU4 在物理核心 0 上运行,CPU1 和 CPU5 在物理核心 1 上运行,依此类推。

    或者,要查看为特定物理 CPU 核心(以下示例中的cpu0)设置的线程,请打开 shell 提示符并运行以下命令:

    $ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list
    示例输出
    0-4
  2. PerformanceProfile YAML 中应用隔离和保留的 CPU。例如,您可以将逻辑核心 CPU0 和 CPU4 设置为isolated,将逻辑核心 CPU1 到 CPU3 和 CPU5 到 CPU7 设置为reserved。当您配置保留和隔离的 CPU 时,Pod 中的基础设施容器将使用保留的 CPU,而应用程序容器将使用隔离的 CPU。

    ...
      cpu:
        isolated: 0,4
        reserved: 1-3,5-7
    ...

    保留和隔离的 CPU 池不能重叠,并且必须共同涵盖工作节点中的所有可用核心。

大多数英特尔处理器默认启用超线程。如果启用超线程,则特定核心处理的所有线程都必须在同一核心上被隔离或处理。

启用超线程后,所有保证型 Pod 必须使用同步多线程 (SMT) 级别倍数,以避免可能导致 Pod 失败的“嘈杂邻居”情况。有关详细信息,请参阅静态策略选项

为低延迟应用程序禁用超线程

为低延迟处理配置集群时,请考虑在部署集群之前是否要禁用超线程。要禁用超线程,请执行以下步骤:

  1. 创建一个适合您的硬件和拓扑结构的性能配置文件。

  2. nosmt设置为额外的内核参数。以下性能配置文件示例说明了此设置:

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: example-performanceprofile
    spec:
      additionalKernelArgs:
        - nmi_watchdog=0
        - audit=0
        - mce=off
        - processor.max_cstate=1
        - idle=poll
        - intel_idle.max_cstate=0
        - nosmt
      cpu:
        isolated: 2-3
        reserved: 0-1
      hugepages:
        defaultHugepagesSize: 1G
        pages:
          - count: 2
            node: 0
            size: 1G
      nodeSelector:
        node-role.kubernetes.io/performance: ''
      realTimeKernel:
        enabled: true

    当您配置保留和隔离的 CPU 时,Pod 中的基础设施容器将使用保留的 CPU,而应用程序容器将使用隔离的 CPU。

管理保证 Pod 隔离 CPU 的设备中断处理

节点调优操作符 (Node Tuning Operator) 可以管理主机 CPU,将其划分为集群和操作系统维护任务(包括 Pod 基础设施容器)的保留 CPU 和应用程序容器运行工作负载的隔离 CPU。这允许您将 CPU 设置为低延迟工作负载的隔离 CPU。

设备中断在所有隔离的和保留的 CPU 之间进行负载均衡,以避免 CPU 过载,但运行保证型 Pod 的 CPU 除外。当为 Pod 设置相关的注释时,将阻止保证型 Pod CPU 处理设备中断。

在性能配置文件中,globallyDisableIrqLoadBalancing 用于管理是否处理设备中断。对于某些工作负载,保留的 CPU 并不总是足以处理设备中断,因此,不会全局禁用隔离 CPU 上的设备中断。默认情况下,节点调优操作符不会禁用隔离 CPU 上的设备中断。

查找节点的有效 IRQ 亲缘性设置

某些 IRQ 控制器缺乏对 IRQ 亲缘性设置的支持,并将始终公开所有在线 CPU 作为 IRQ 掩码。这些 IRQ 控制器实际上在 CPU 0 上运行。

以下是 Red Hat 已知缺乏 IRQ 亲缘性设置支持的驱动程序和硬件示例。此列表并非详尽无遗。

  • 某些 RAID 控制器驱动程序,例如 megaraid_sas

  • 许多非易失性内存高速 (NVMe) 驱动程序

  • 某些主板上的局域网 (LOM) 网络控制器

  • 驱动程序使用 managed_irqs

它们不支持 IRQ 亲缘性设置的原因可能与处理器类型、IRQ 控制器或主板中的电路连接等因素有关。

如果任何 IRQ 的有效亲缘性设置为隔离的 CPU,则可能表明某些硬件或驱动程序不支持 IRQ 亲缘性设置。要查找有效亲缘性,请登录到主机并运行以下命令:

$ find /proc/irq -name effective_affinity -printf "%p: " -exec cat {} \;
示例输出
/proc/irq/0/effective_affinity: 1
/proc/irq/1/effective_affinity: 8
/proc/irq/2/effective_affinity: 0
/proc/irq/3/effective_affinity: 1
/proc/irq/4/effective_affinity: 2
/proc/irq/5/effective_affinity: 1
/proc/irq/6/effective_affinity: 1
/proc/irq/7/effective_affinity: 1
/proc/irq/8/effective_affinity: 1
/proc/irq/9/effective_affinity: 2
/proc/irq/10/effective_affinity: 1
/proc/irq/11/effective_affinity: 1
/proc/irq/12/effective_affinity: 4
/proc/irq/13/effective_affinity: 1
/proc/irq/14/effective_affinity: 1
/proc/irq/15/effective_affinity: 1
/proc/irq/24/effective_affinity: 2
/proc/irq/25/effective_affinity: 4
/proc/irq/26/effective_affinity: 2
/proc/irq/27/effective_affinity: 1
/proc/irq/28/effective_affinity: 8
/proc/irq/29/effective_affinity: 4
/proc/irq/30/effective_affinity: 4
/proc/irq/31/effective_affinity: 8
/proc/irq/32/effective_affinity: 8
/proc/irq/33/effective_affinity: 1
/proc/irq/34/effective_affinity: 2

某些驱动程序使用 managed_irqs,其亲缘性由内核内部管理,用户空间无法更改亲缘性。在某些情况下,这些 IRQ 可能分配给隔离的 CPU。有关 managed_irqs 的更多信息,请参见 即使管理中断的目标是隔离的 CPU,也无法更改其亲缘性

配置节点中断亲缘性

配置集群节点以进行 IRQ 动态负载均衡,以控制哪些核心可以接收设备中断请求 (IRQ)。

先决条件
  • 对于核心隔离,所有服务器硬件组件都必须支持 IRQ 亲缘性。要检查服务器的硬件组件是否支持 IRQ 亲缘性,请查看服务器的硬件规格或联系您的硬件提供商。

步骤
  1. 以具有集群管理员权限的用户身份登录到 OpenShift Container Platform 集群。

  2. 将性能配置文件 apiVersion 设置为使用 performance.openshift.io/v2

  3. 移除 globallyDisableIrqLoadBalancing 字段或将其设置为 false

  4. 设置适当的隔离 CPU 和保留 CPU。以下代码段说明了一个保留 2 个 CPU 的配置文件。为在 isolated CPU 集上运行的 Pod 启用了 IRQ 负载均衡。

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: dynamic-irq-profile
    spec:
      cpu:
        isolated: 2-5
        reserved: 0-1
    ...

    配置保留 CPU 和隔离 CPU 后,操作系统进程、内核进程和 systemd 服务将在保留 CPU 上运行。基础设施 Pod 将在任何 CPU 上运行,低延迟工作负载运行的 CPU 除外。低延迟工作负载 Pod 将在隔离池中的专用 CPU 上运行。有关更多信息,请参见“限制基础设施和应用程序容器的 CPU”。

配置巨页

节点必须预分配在 OpenShift Container Platform 集群中使用的巨页。使用节点调优操作符在特定节点上分配巨页。

OpenShift Container Platform 提供了一种创建和分配巨页的方法。节点调优操作符提供了一种更简单的方法,可以使用性能配置文件来完成此操作。

例如,在性能配置文件的 hugepages pages 部分中,您可以指定多个 sizecount 块,以及可选的 node

hugepages:
   defaultHugepagesSize: "1G"
   pages:
   - size:  "1G"
     count:  4
     node:  0 (1)
1 node 是分配巨页的 NUMA 节点。如果省略 node,则页面将均匀地分布在所有 NUMA 节点上。

等待相关机器配置池状态指示更新已完成。

这些是您需要执行的唯一配置步骤才能分配巨页。

验证
  • 要验证配置,请查看节点上的 /proc/meminfo 文件。

    $ oc debug node/ip-10-0-141-105.ec2.internal
    # grep -i huge /proc/meminfo
    示例输出
    AnonHugePages:    ###### ##
    ShmemHugePages:        0 kB
    HugePages_Total:       2
    HugePages_Free:        2
    HugePages_Rsvd:        0
    HugePages_Surp:        0
    Hugepagesize:       #### ##
    Hugetlb:            #### ##
  • 使用 oc describe 报告新的大小。

    $ oc describe node worker-0.ocp4poc.example.com | grep -i huge
    示例输出
                                       hugepages-1g=true
     hugepages-###:  ###
     hugepages-###:  ###

分配多个巨页大小

您可以在同一个容器下请求不同大小的巨页。这允许您定义更复杂的 Pod,这些 Pod 由具有不同巨页大小需求的容器组成。

例如,您可以定义大小 1G2M,节点调优操作符将在节点上配置这两种大小,如下所示:

spec:
  hugepages:
    defaultHugepagesSize: 1G
    pages:
    - count: 1024
      node: 0
      size: 2M
    - count: 4
      node: 1
      size: 1G

使用节点调优操作符减少 NIC 队列

节点调优操作符有助于减少 NIC 队列以提高性能。调整是使用性能配置文件进行的,允许自定义不同网络设备的队列。

使用性能配置文件调整 NIC 队列

性能配置文件允许您调整每个网络设备的队列计数。

支持的网络设备

  • 非虚拟网络设备

  • 支持多个队列(通道)的网络设备

不支持的网络设备

  • 纯软件网络接口

  • 块设备

  • Intel DPDK 虚拟函数

先决条件
  • 以具有cluster-admin角色的用户身份访问集群。

  • 安装 OpenShift CLI (oc)。

步骤
  1. 以具有 cluster-admin 权限的用户身份登录到运行节点调优操作符的 OpenShift Container Platform 集群。

  2. 创建并应用适合您的硬件和拓扑的性能配置文件。有关创建配置文件的指导,请参见“创建性能配置文件”部分。

  3. 编辑此创建的性能配置文件。

    $ oc edit -f <your_profile_name>.yaml
  4. 使用 net 对象填充 spec 字段。对象列表可以包含两个字段:

    • userLevelNetworking 是一个必需字段,指定为布尔标志。如果 userLevelNetworkingtrue,则队列计数将设置为所有受支持设备的保留 CPU 计数。默认为 false

    • devices 是一个可选字段,指定将队列设置为保留 CPU 计数的设备列表。如果设备列表为空,则配置将应用于所有网络设备。配置如下:

      • interfaceName:此字段指定接口名称,它支持 shell 风格的通配符,可以是正数或负数。

        • 通配符语法示例如下:<string> .*

        • 负规则以感叹号为前缀。要将网络队列更改应用于除排除列表之外的所有设备,请使用 !<device>,例如 !eno1

      • vendorID:以 16 位十六进制数表示的网络设备厂商 ID,带有 0x 前缀。

      • deviceID:以 16 位十六进制数表示的网络设备 ID(型号),带有 0x 前缀。

        如果指定了deviceID,则也必须定义vendorID。与设备条目中指定的设备标识符(interfaceNamevendorIDvendorIDdeviceID对)完全匹配的设备,符合网络设备的条件。然后,此网络设备的网络队列计数将设置为预留的CPU计数。

        如果指定了两个或多个设备,则网络队列计数将设置为与其中一个设备匹配的任何网络设备的计数。

  5. 使用此示例性能配置文件,将所有设备的队列计数设置为预留的CPU计数。

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: manual
    spec:
      cpu:
        isolated: 3-51,55-103
        reserved: 0-2,52-54
      net:
        userLevelNetworking: true
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
  6. 使用此示例性能配置文件,将所有与任何已定义设备标识符匹配的设备的队列计数设置为预留的CPU计数。

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: manual
    spec:
      cpu:
        isolated: 3-51,55-103
        reserved: 0-2,52-54
      net:
        userLevelNetworking: true
        devices:
        - interfaceName: "eth0"
        - interfaceName: "eth1"
        - vendorID: "0x1af4"
          deviceID: "0x1000"
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
  7. 使用此示例性能配置文件,将所有接口名称以eth开头的设备的队列计数设置为预留的CPU计数。

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: manual
    spec:
      cpu:
        isolated: 3-51,55-103
        reserved: 0-2,52-54
      net:
        userLevelNetworking: true
        devices:
        - interfaceName: "eth*"
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
  8. 使用此示例性能配置文件,将所有接口名称不是eno1的设备的队列计数设置为预留的CPU计数。

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: manual
    spec:
      cpu:
        isolated: 3-51,55-103
        reserved: 0-2,52-54
      net:
        userLevelNetworking: true
        devices:
        - interfaceName: "!eno1"
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
  9. 使用此示例性能配置文件,将所有接口名称为eth0vendorID0x1af4deviceID0x1000的设备的队列计数设置为预留的CPU计数。

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: manual
    spec:
      cpu:
        isolated: 3-51,55-103
        reserved: 0-2,52-54
      net:
        userLevelNetworking: true
        devices:
        - interfaceName: "eth0"
        - vendorID: "0x1af4"
          deviceID: "0x1000"
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
  10. 应用更新后的性能配置文件。

    $ oc apply -f <your_profile_name>.yaml
其他资源

验证队列状态

在本节中,一些示例说明了不同的性能配置文件以及如何验证更改是否已应用。

示例 1

在此示例中,所有支持的设备的网络队列计数均设置为预留的CPU计数(2)。

性能配置文件中的相关部分是

apiVersion: performance.openshift.io/v2
metadata:
  name: performance
spec:
  kind: PerformanceProfile
  spec:
    cpu:
      reserved: 0-1  #total = 2
      isolated: 2-8
    net:
      userLevelNetworking: true
# ...
  • 使用以下命令显示与设备关联的队列的状态

    在应用性能配置文件的节点上运行此命令。

    $ ethtool -l <device>
  • 验证应用配置文件之前队列的状态

    $ ethtool -l ens4
    示例输出
    Channel parameters for ens4:
    Pre-set maximums:
    RX:         0
    TX:         0
    Other:      0
    Combined:   4
    Current hardware settings:
    RX:         0
    TX:         0
    Other:      0
    Combined:   4
  • 验证应用配置文件之后队列的状态

    $ ethtool -l ens4
    示例输出
    Channel parameters for ens4:
    Pre-set maximums:
    RX:         0
    TX:         0
    Other:      0
    Combined:   4
    Current hardware settings:
    RX:         0
    TX:         0
    Other:      0
    Combined:   2 (1)
    
1 组合通道显示所有支持设备的预留CPU总数为2。这与性能配置文件中配置的内容相匹配。
示例 2

在此示例中,所有支持的具有特定vendorID的网络设备的网络队列计数均设置为预留的CPU计数(2)。

性能配置文件中的相关部分是

apiVersion: performance.openshift.io/v2
metadata:
  name: performance
spec:
  kind: PerformanceProfile
  spec:
    cpu:
      reserved: 0-1  #total = 2
      isolated: 2-8
    net:
      userLevelNetworking: true
      devices:
      - vendorID = 0x1af4
# ...
  • 使用以下命令显示与设备关联的队列的状态

    在应用性能配置文件的节点上运行此命令。

    $ ethtool -l <device>
  • 验证应用配置文件之后队列的状态

    $ ethtool -l ens4
    示例输出
    Channel parameters for ens4:
    Pre-set maximums:
    RX:         0
    TX:         0
    Other:      0
    Combined:   4
    Current hardware settings:
    RX:         0
    TX:         0
    Other:      0
    Combined:   2 (1)
    
1 所有具有vendorID=0x1af4的支持设备的预留CPU总数为2。例如,如果另一个网络设备ens2vendorID=0x1af4,则其总网络队列数也为2。这与性能配置文件中配置的内容相匹配。
示例3

在此示例中,所有支持的与任何已定义设备标识符匹配的网络设备的网络队列计数均设置为预留的CPU计数(2)。

命令udevadm info提供有关设备的详细报告。在此示例中,设备为

# udevadm info -p /sys/class/net/ens4
...
E: ID_MODEL_ID=0x1000
E: ID_VENDOR_ID=0x1af4
E: INTERFACE=ens4
...
# udevadm info -p /sys/class/net/eth0
...
E: ID_MODEL_ID=0x1002
E: ID_VENDOR_ID=0x1001
E: INTERFACE=eth0
...
  • 使用以下性能配置文件,将interfaceName等于eth0的设备以及所有vendorID=0x1af4的设备的网络队列设置为2。

    apiVersion: performance.openshift.io/v2
    metadata:
      name: performance
    spec:
      kind: PerformanceProfile
        spec:
          cpu:
            reserved: 0-1  #total = 2
            isolated: 2-8
          net:
            userLevelNetworking: true
            devices:
            - interfaceName = eth0
            - vendorID = 0x1af4
    ...
  • 验证应用配置文件之后队列的状态

    $ ethtool -l ens4
    示例输出
    Channel parameters for ens4:
    Pre-set maximums:
    RX:         0
    TX:         0
    Other:      0
    Combined:   4
    Current hardware settings:
    RX:         0
    TX:         0
    Other:      0
    Combined:   2 (1)
    
    1 所有具有vendorID=0x1af4的支持设备的预留CPU总数设置为2。例如,如果另一个网络设备ens2vendorID=0x1af4,则其总网络队列数也设置为2。同样,interfaceName等于eth0的设备的总网络队列数也将设置为2。

调整网卡队列相关的日志记录

详细说明已分配设备的日志消息记录在相应的Tuned守护进程日志中。以下消息可能会记录到/var/log/tuned/tuned.log文件中

  • 一条INFO消息记录了成功分配的设备的详细信息。

    INFO tuned.plugins.base: instance net_test (net): assigning devices ens1, ens2, ens3
  • 如果无法分配任何设备,则会记录一条WARNING消息。

    WARNING  tuned.plugins.base: instance net_test: no matching devices available