14.2. 使用性能配置集调整节点以实现低延迟


使用集群性能配置集调整节点以实现低延迟。您可以限制 infra 和应用程序容器的 CPU,配置巨页、Hyper-Threading,并为对延迟敏感的进程配置 CPU 分区。

14.2.1. 创建性能配置集

您可以使用 Performance Profile Creator (PPC) 工具创建集群性能配置集。PPC 是 Node Tuning Operator 的功能。

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

注意

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

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

  • 为您要使用性能配置为目标的节点创建机器配置池 (MCP)。在单节点 OpenShift 集群中,您必须使用 master MCP,因为集群中只有一个节点。
  • 使用 must-gather 命令收集有关集群的信息。
  • 使用 PPC 工具使用以下方法之一创建性能配置集:

    • 使用 Podman 运行 PPC 工具。
    • 使用 wrapper 脚本运行 PPC 工具。
  • 为您的用例配置性能配置集,并将性能配置集应用到集群。

14.2.1.1. 关于性能配置集创建器

Performance Profile Creator (PPC) 是一个命令行工具,由 Node Tuning Operator 提供,它可帮助您为集群创建性能配置集。

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

  • 使用分配的 CPU ID 进行 NUMA 单元分区
  • 超线程节点配置

您可以使用这些信息来帮助配置性能配置集。

运行 PPC

为 PPC 工具指定性能配置参数,以生成适合您的硬件、拓扑和用例的推荐性能配置集。

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

  • 使用 Podman 运行 PPC
  • 使用 wrapper 脚本运行 PPC
注意

使用 wrapper 脚本将一些更精细的 Podman 任务抽象到可执行脚本中。例如,wrapper 脚本处理诸如拉取和运行所需容器镜像、将目录挂载到容器等任务,并通过 Podman 直接向容器提供参数。两种方法都获得相同的结果。

14.2.1.2. 为性能调整创建机器配置池到目标节点

对于多节点集群,您可以定义机器配置池 (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. 创建定义 MachineConfigPool 资源的 YAML 文件:

      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

14.2.1.3. 为 PPC 收集集群数据

Performance Profile Creator(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 数据文件夹的名称替换。
    注意

    如果您正在运行性能配置集 Creator wrapper 脚本,则需要压缩输出。

其他资源

14.2.1.4. 使用 Podman 运行 Performance Profile Creator

作为集群管理员,您可以使用带有 Performance Profile Creator (PPC) 的 Podman 来创建性能配置集。

有关 PPC 参数的更多信息,请参阅 "Performance Profile Creator 参数" 部分。

重要

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

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。
  • 在裸机硬件上安装的集群。
  • 已安装 podman 和 OpenShift CLI (oc)。
  • 访问 Node Tuning Operator 镜像。
  • 您识别包含用于配置的目标节点的机器配置池。
  • 您可以访问集群的 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.16 -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.16 --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.16 --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

14.2.1.5. 运行性能配置集 Creator wrapper 脚本

wrapper 脚本简化了使用 Performance Profile Creator (PPC) 工具创建性能配置集的过程。脚本处理诸如拉取和运行所需容器镜像、将目录挂载到容器等任务,并通过 Podman 直接向容器提供参数。

有关 Performance Profile Creator 参数的更多信息,请参阅 "Performance Profile Creator 参数" 部分。

重要

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

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。
  • 在裸机硬件上安装的集群。
  • 已安装 podman 和 OpenShift CLI (oc)。
  • 访问 Node Tuning Operator 镜像。
  • 您识别包含用于配置的目标节点的机器配置池。
  • 访问 must-gather tarball。

流程

  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.16"
    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 选项为 Node Tuning Operator 镜像设置路径。如果您没有设置路径,wrapper 脚本使用默认镜像:registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.16

  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 的目录的路径。这是 wrapper 脚本的必要参数。

      输出示例

      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

14.2.1.6. Performance Profile Creator 参数

表 14.1. 所需的 Performance Profile Creator 参数
参数描述

mcp-name

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

must-gather-dir-path

must gather 目录的路径。

只有在使用 Podman 运行 PPC 工具时才需要此参数。如果您将 PPC 与 wrapper 脚本搭配使用,请不要使用此参数。反之,使用 wrapper 脚本的 -t 选项指定 must-gather tarball 的目录路径。

reserved-cpu-count

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

rt-kernel

启用实时内核。

可能的值: truefalse

表 14.2. 可选的 Performance Profile Creator 参数
参数描述

disable-ht

禁用超线程。

可能的值: truefalse

默认值: false

警告

如果此参数设为 true,则不应在 BIOS 中禁用 Hyper-Threading。禁用超线程通过内核命令行参数来完成。

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

14.2.1.7. 参考性能配置集

使用以下引用性能配置集作为开发您自己的自定义配置集的基础。

14.2.1.7.1. 在 OpenStack 上使用 OVS-DPDK 的集群的性能配置集模板

要最大化使用 Open vSwitch 和 Red Hat OpenStack Platform(RHOSP)上的 Data Plane Development Kit(OVS-DPDK)的机器性能,您可以使用性能配置集。

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

使用 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 密钥的配置的值。

14.2.1.7.2. Telco RAN DU 参考设计性能配置集

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

Telco 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

14.2.1.7.3. 电信核心参考设计性能配置集

以下性能配置集在商业硬件上为 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

14.2.2. 支持的性能配置集 API 版本

Node Tuning Operator 在性能配置集 apiVersion 字段中支持 v2v1v1alpha1。v1 和 v1alpha1 API 相同。v2 API 包括一个可选的布尔值项 globallyDisableIrqLoadBalancing,默认值为 false

升级性能配置集以使用设备中断处理

当您将 Node Tuning Operator 性能配置集自定义资源定义(CRD)从 v1 或 v1alpha1 升级到 v2 时,现有配置集会将 globallyDisableIrqLoadBalancing 设置为 true

注意

globallyDisableIrqLoadBalancing 切换用于 Isolated CPU 集是否禁用了 IRQ 负载均衡。当选项设置为 true 时,它会禁用 Isolated CPU 集的 IRQ 负载均衡。将选项设置为 false 允许在所有 CPU 之间平衡 IRQ。

将 Node Tuning Operator API 从 v1alpha1 升级到 v1

当将 Node Tuning Operator API 版本从 v1alpha1 升级到 v1 时,,v1alpha1 性能配置集会通过"None" Conversion 策略自行转换,并提供给带有 API 版本 v1 的 Performance Addon Operator。

将 Node Tuning Operator API 从 v1alpha1 或 v1 升级到 v2

当从旧的 Node Tuning Operator API 版本升级时,现有的 v1 和 v1alpha1 性能配置集将使用转换 Webhook 转换,它将注入 globallyDisableIrqLoadBalancing 字段,值为 true

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

流程

  • 使用 Performance Profile Creator (PPC) 工具创建适合环境的硬件和拓扑的 PerformanceProfile。下表描述了为与 PPC 工具关联的 power-consumption-mode 标志设置的可能值,以及应用的工作负载提示。
表 14.3. 节能和实时设置对延迟的影响
性能配置集创建器设置提示环境描述

Default(默认)

workloadHints:
highPowerConsumption: false
realTime: false

没有延迟要求的高吞吐量集群

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

Low-latency

workloadHints:
highPowerConsumption: false
realTime: true

地区数据中心

节能和低延迟都需要考虑的:在电源管理、延迟和吞吐量之间进行妥当调节。

Ultra-low-latency

workloadHints:
highPowerConsumption: true
realTime: true

对于远边缘集群,对延迟非常敏感的工作负载

实现最小延迟和最大确定性会增加电源消耗的成本。

每个 pod 电源管理

workloadHints:
realTime: true
highPowerConsumption: false
perPodPowerManagement: true

关键和非关键工作负载

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

Example

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

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

当在性能配置集中将 realTime 工作负载 hint 标志设置为 true 时,将 cpu-quota.crio.io: disable 注解添加到带有固定 CPU 的每个保证 pod。此注解是防止 pod 中进程性能降级所必需的。如果没有明确设置 realTime 工作负载提示,则默认为 true

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

14.2.4. 为运行 colocated 高和低优先级工作负载的节点配置节能

您可以为带有低优先级工作负载的节点实现节能,而不影响高优先级工作负载的延迟或吞吐量。无需修改工作负载本身即可进行节能。

重要

Intel Ice Lake 及更新的 Intel CPU 支持该功能。处理器的功能可能会影响高优先级工作负载的延迟和吞吐量。

先决条件

  • 您在 BIOS 中启用了 C-states 和操作系统控制的 P-states

流程

  1. per-pod-power-management 参数设置为 true 来生成 PerformanceProfile

    $ podman run --entrypoint performance-profile-creator -v \
    /must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v4.16 \
    --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

    带有 perPodPowerManagementPerformanceProfile 示例

    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 governors。
  3. Tuned PerformancePatch 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 中的最大支持频率。作为起点,您可以使用以 All Cores Turbo 频率封装所有 CPU 的百分比。All Cores Turbo 频率是所有内核在运行的频率,当内核完全占用时。

14.2.5. 为 infra 和应用程序容器限制 CPU

通用内务处理和工作负载任务使用 CPU 的方式可能会影响对延迟敏感的进程。默认情况下,容器运行时使用所有在线 CPU 一起运行所有容器,这可能导致上下文切换和延迟激增。对 CPU 进行分区可防止无状态进程通过相互分离来干扰对延迟敏感的进程。下表描述了在使用 Node Tuning Operator 调整节点后在 CPU 上运行的进程:

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

BurstableBestEffort pod

在除了运行低延迟工作负载外的任意 CPU 上运行

基础架构 pod

在除了运行低延迟工作负载外的任意 CPU 上运行

中断

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

内核进程

固定保留的 CPU

对延迟敏感的工作负载 pod

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

OS 进程/systemd 服务

固定保留的 CPU

在一个节点上的对于所有 QoS 进程类型( BurstableBestEffortGuaranteed )的 pod 的可分配容量等于隔离池的容量。保留池的容量已从节点的总内核容量中删除,供集群和操作系统日常任务使用。

示例 1

节点具有 100 个内核的容量。通过使用性能配置集,集群管理员将 50 个内核分配给隔离池,将 50 个内核分配给保留池。集群管理员为 QoS 为 BestEffortBurstable 的 pod 分配 25 个内核,为 Guaranteed 的 pod 分配 25 个内核。这与隔离池的容量匹配。

示例 2

节点具有 100 个内核的容量。通过使用性能配置集,集群管理员将 50 个内核分配给隔离池,将 50 个内核分配给保留池。集群管理员为 QoS 为 BestEffortBurstable 的 pod 分配一个内核,为 Guaranteed 的 pod 分配 50 个内核。这超过了隔离池容量一个内核。Pod 调度因为 CPU 容量不足而失败。

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

  • 如果对延迟敏感的工作负载使用特定的硬件,如网络接口控制器(NIC),请确保隔离池中的 CPU 尽可能地与这个硬件接近。至少,您应该将工作负载放在同一个非统一内存访问 (NUMA) 节点中。
  • 保留的池用于处理所有中断。根据系统网络,分配一个足够大小的保留池来处理所有传入的数据包中断。在 4.16 及更高版本中,工作负载可以选择性地被标记为敏感版本。

在决定哪些特定 CPU 用于保留和隔离分区时,需要详细分析和测量。设备和内存的 NUMA 紧密度等因素扮演了角色。选择也取决于工作负载架构和具体的用例。

重要

保留和隔离的 CPU 池不得重叠,并且必须一起跨越 worker 节点中的所有可用内核。

为确保内务处理任务和工作负载不会相互干扰,请在性能配置集的 spec 部分指定两组 CPU。

  • isolated - 指定应用程序容器工作负载的 CPU。这些 CPU 的延迟最低。这个组中的进程没有中断,例如,可以达到更高的 DPDK 零数据包丢失带宽。
  • reserved - 为集群和操作系统日常任务指定 CPU。reserved 组中的线程经常会比较繁忙。不要在 reserved 组中运行对延迟敏感的应用程序。对延迟敏感的应用程序在 isolated 组中运行。

流程

  1. 创建适合环境硬件和拓扑的性能配置集。
  2. 使用您想要为 infra 和应用程序容器保留和隔离的 CPU 添加 reservedisolated 参数:

    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
    指定 infra 容器用于执行集群和操作系统日常任务的 CPU。
    2
    指定应用程序容器运行工作负载的 CPU。
    3
    可选:指定一个节点选择器,以将性能配置集应用到特定的节点。

14.2.6. 为集群配置超线程

要为 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 在物理 Core0 中运行,CPU1 和 CPU5 在物理 Core 1 中运行,以此类推。

    另外要查看为特定物理 CPU 内核设定的线程(以下示例中的cpu0 ),打开命令提示符并运行以下命令:

    $ 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 中的 infra 容器将使用保留的 CPU,应用程序容器则使用隔离的 CPU。

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

    保留和隔离的 CPU 池不得重叠,并且必须一起跨越 worker 节点中的所有可用内核。

重要

大多数 Intel 处理器上默认启用超线程。如果启用超线程,特定内核处理的所有线程都必须被隔离或者在同一个内核中处理。

启用超线程后,所有保证的 pod 都必须使用多个 SMT (simultaneous multi-threading)级别,以避免造成 "noisy neighbor" 的情况并导致 pod 失败。如需更多信息,请参阅静态策略选项

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

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

  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 中的 infra 容器将使用保留的 CPU,应用程序容器则使用隔离的 CPU。

14.2.7. 管理设备中断处理保证 pod 隔离 CPU

Node Tuning Operator 可以通过将主机 CPU 划分为保留的 CPU 来管理主机 CPU,以进行集群和操作系统日常任务(包括 pod infra 容器),以及用于应用程序容器运行工作负载的隔离 CPU。这可让您将低延迟工作负载的 CPU 设置为隔离状态。

设备中断在所有隔离和保留 CPU 之间平衡负载,以避免出现 CPU 超载问题,但运行有保证 pod 的 CPU 除外。当为 pod 设置相关注解时,保证 pod CPU 无法处理设备中断。

在性能配置集中,globallyDisableIrqLoadBalancing 用于管理设备中断是否被处理。对于某些工作负载,保留 CPU 并不总是足以处理设备中断,因此不会在隔离的 CPU 上禁用设备中断。默认情况下,Node Tuning Operator 不会禁用隔离 CPU 上的设备中断。

14.2.7.1. 为节点查找有效的 IRQ 关联性设置

有些 IRQ 控制器缺少对 IRQ 关联性设置的支持,并将始终将所有在线 CPU 公开为 IRQ 掩码。这些 IRQ 控制器在 CPU 0 上运行。

以下是红帽了解对 IRQ 关联性设置的支持的驱动程序和硬件示例。以下是相关的列表(并没有包括所有):

  • 一些 RAID 控制器驱动程序,如 megaraid_sas
  • 许多非易失性内存表达 (NVMe) 驱动程序
  • 主板 (LOM) 网络控制器上的一些 LAN
  • 驱动程序使用 managed_irqs
注意

不支持 IRQ 关联性设置的原因可能与主板中的处理器类型、IRI 控制器或断路器连接等因素相关。

如果任何 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

14.2.7.2. 配置节点中断关联性

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

先决条件

  • 对于内核隔离,所有服务器硬件组件都必须支持 IRQ 关联性。要检查服务器的硬件组件是否支持 IRQ 关联性,请查看服务器的硬件规格或联系您的硬件供应商。

流程

  1. 以具有 cluster-admin 权限的用户身份登录 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、操作系统进程、内核进程和 systemd 服务在保留 CPU 上运行时。基础架构 pod 在任何 CPU 上运行,但运行低延迟工作负载除外。低延迟工作负载 pod 在隔离池中的专用 CPU 上运行。如需更多信息,请参阅"为 infra 和应用程序容器限制 CPU"。

14.2.8. 配置巨页

节点必须预先分配在 OpenShift Container Platform 集群中使用的巨页。使用 Node Tuning Operator 在特定节点中分配巨页。

OpenShift Container Platform 提供了创建和分配巨页的方法。Node Tuning Operator 提供了一种更易于使用性能配置集的方法。

例如,在性能配置集的 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-###:  ###

14.2.8.1. 分配多个巨页大小

您可以在同一容器下请求具有不同大小的巨页。这样,您可以定义由具有不同巨页大小的容器组成的更复杂的 pod。

例如,您可以把大小定义为 1G2M,Node Tuning Operator 会在节点上配置这两个大小,如下所示:

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

14.2.9. 使用 Node Tuning Operator 减少 NIC 队列

Node Tuning Operator 有助于减少 NIC 队列以提高性能。使用性能配置集进行调整,允许为不同的网络设备自定义队列。

14.2.9.1. 使用性能配置集调整 NIC 队列

通过性能配置集,您可以调整每个网络设备的队列计数。

支持的网络设备:

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

不支持的网络设备:

  • 纯软件网络接口
  • 块设备
  • Intel DPDK 虚拟功能

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。
  • 安装 OpenShift CLI(oc)。

流程

  1. 以具有 cluster-admin 权限的用户身份登录运行 Node Tuning Operator 的 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:网络设备供应商 ID,以带有 0x 前缀的 16 位十六进制数字代表。
      • deviceID:网络设备 ID(model),以带有 0x 前缀的 16 位十六进制数字代表。

        注意

        当指定 deviceID 时,还必须定义 vendorID。与设备条目 interfaceNamevendorIDvendorIDdeviceID 中指定的所有设备标识符相匹配的设备会被视为一个网络设备。然后,此网络设备的 net 队列数设置为保留的 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 数设置为保留的 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. 使用这个示例性能配置集。将所有设备的队列数设置为保留的 CPU 计数,该接口具有 eno1 以外的任何接口:

    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

其他资源

14.2.9.2. 验证队列状态

在这一部分中,一些示例演示了不同的性能配置集以及如何验证是否应用了更改。

示例 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。例如,如果存在另一个网络设备 ens2,其 vendorID=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。例如,如果存在另一个带有 vendorID=0x1af4 的网络设备 ens2,则其总子网队列也将设置为 2。类似地,interfaceName 等于 eth0 的设备会将总网络队列设置为 2。

14.2.9.3. 与调整 NIC 队列关联的日志记录

详细说明所分配设备的日志消息记录在相应的 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
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.