13.2. 성능 프로필을 사용하여 짧은 대기 시간을 실현하도록 노드 튜닝
클러스터 성능 프로필을 사용하여 짧은 대기 시간을 위해 노드를 조정합니다. 인프라 및 애플리케이션 컨테이너의 CPU를 제한하고, 대규모 페이지, 하이퍼 스레딩을 구성하고, 대기 시간에 민감한 프로세스를 위해 CPU 파티션을 구성할 수 있습니다.
13.2.1. 성능 프로파일 작성
PPC(Performance Profile Creator) 툴을 사용하여 클러스터 성능 프로필을 생성할 수 있습니다. PPC는 Node Tuning Operator의 기능입니다.
PPC는 사용자 제공 구성과 클러스터에 대한 정보를 결합하여 하드웨어, 토폴로지 및 사용 사례에 적합한 성능 프로필을 생성합니다.
성능 프로필은 클러스터가 기본 하드웨어 리소스에 직접 액세스할 수 있는 베어 메탈 환경에만 적용됩니다. 단일 노드 OpenShift 및 다중 노드 클러스터 모두에 대해 성능 프로필을 구성할 수 있습니다.
다음은 클러스터에서 성능 프로필을 생성하고 적용하기 위한 고급 워크플로입니다.
-
성능 구성으로 대상으로 지정할 노드의 MCP(머신 구성 풀)를 생성합니다. 단일 노드 OpenShift 클러스터에서는 클러스터에 노드가 하나뿐이므로
마스터
MCP를 사용해야 합니다. -
must-gather
명령을 사용하여 클러스터에 대한 정보를 수집합니다. PPC 툴을 사용하여 다음 방법 중 하나를 사용하여 성능 프로필을 생성합니다.
- Podman을 사용하여 PPC 툴을 실행합니다.
- 래퍼 스크립트를 사용하여 PPC 툴을 실행합니다.
- 사용 사례에 대한 성능 프로필을 구성하고 클러스터에 성능 프로필을 적용합니다.
13.2.1.1. 성능 프로파일 작성툴 정보
PPC(Performance Profile Creator)는 Node Tuning Operator와 함께 제공되는 명령줄 툴로, 클러스터에 대한 성능 프로필을 생성하는 데 도움이 될 수 있습니다.
처음에 PPC 툴을 사용하여 must-gather
데이터를 처리하여 다음 정보를 포함하여 클러스터의 주요 성능 구성을 표시할 수 있습니다.
- 할당된 CPU ID로 NUMA 셀 파티셔닝
- 하이퍼 스레딩 노드 구성
이 정보를 사용하여 성능 프로필을 구성할 수 있습니다.
PPC 실행
PPC 툴에 대한 성능 구성 인수를 지정하여 하드웨어, 토폴로지 및 사용 사례에 적합한 제안된 성능 프로필을 생성합니다.
다음 방법 중 하나를 사용하여 PPC를 실행할 수 있습니다.
- Podman을 사용하여 PPC 실행
- 래퍼 스크립트를 사용하여 PPC 실행
래퍼 스크립트를 사용하면 일부 작업은 더 세분화된 Podman 작업을 실행 가능한 스크립트로 추상화합니다. 예를 들어 래퍼 스크립트는 필요한 컨테이너 이미지 가져오기 및 실행, 디렉터리를 컨테이너에 마운트하고 Podman을 통해 컨테이너에 직접 매개 변수를 제공하는 등의 작업을 처리합니다. 두 방법 모두 동일한 결과를 얻을 수 있습니다.
13.2.1.2. 성능 튜닝을 위해 노드를 대상으로 하는 머신 구성 풀 생성
다중 노드 클러스터의 경우 MCP(Machine config pool)를 정의하여 성능 프로필로 구성할 대상 노드를 식별할 수 있습니다.
단일 노드 OpenShift 클러스터에서는 클러스터에 노드가 하나뿐이므로 마스터
MCP를 사용해야 합니다. 단일 노드 OpenShift 클러스터에 대해 별도의 MCP를 생성할 필요가 없습니다.
사전 요구 사항
-
cluster-admin
역할 액세스 권한이 있어야 합니다. -
OpenShift CLI(
oc
)를 설치합니다.
프로세스
다음 명령을 실행하여 구성의 대상 노드에 레이블을 지정합니다.
$ oc label node <node_name> node-role.kubernetes.io/worker-cnf="" 1
- 1
- &
lt;node_name
>을 노드 이름으로 바꿉니다. 이 예제에서는worker-cnf
레이블을 적용합니다.
대상 노드가 포함된
MachineConfigPool
리소스를 생성합니다.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
다음 명령을 실행하여
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
13.2.1.3. PPC용 클러스터에 대한 데이터 수집
PPC(Performance Profile creator) 툴에는 must-gather
데이터가 필요합니다. 클러스터 관리자는 must-gather
명령을 실행하여 클러스터에 대한 정보를 캡처합니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc
)를 설치합니다. - 성능 프로필을 사용하여 구성할 대상 MCP를 확인했습니다.
프로세스
-
must-gather
데이터를 저장하려는 디렉터리로 이동합니다. 다음 명령을 실행하여 클러스터 정보를 수집합니다.
$ oc adm must-gather
이 명령은
must-gather
.local.1971646453781853027선택 사항:
must-gather
디렉터리에서 압축 파일을 생성합니다.$ tar cvaf must-gather.tar.gz <must_gather_folder> 1
- 1
must-gather
데이터 폴더의 이름으로 바꿉니다.
참고Performance Profile Creator 래퍼 스크립트를 실행하는 경우 압축 출력이 필요합니다.
추가 리소스
-
must-gather
툴에 대한 자세한 내용은 클러스터에 대한 데이터 수집을 참조하십시오.
13.2.1.4. Podman을 사용하여 Performance Profile Creator 실행
클러스터 관리자는 PPC(Performance Profile Creator)와 함께 Podman을 사용하여 성능 프로필을 생성할 수 있습니다.
PPC 인수에 대한 자세한 내용은 "Performance Profile Creator arguments" 섹션을 참조하십시오.
PPC는 클러스터의 must-gather
데이터를 사용하여 성능 프로필을 생성합니다. 성능 구성을 대상으로 하는 노드 레이블을 다시 지정하는 등 클러스터를 변경하는 경우 PPC를 다시 실행하기 전에 must-gather
데이터를 다시 생성해야 합니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - 클러스터가 베어 메탈 하드웨어에 설치되어 있어야 합니다.
-
podman
및 OpenShift CLI(oc
)를 설치했습니다. - Node Tuning Operator 이미지에 액세스할 수 있습니다.
- 구성을 위한 대상 노드가 포함된 머신 구성 풀을 확인했습니다.
-
클러스터의
must-gather
데이터에 액세스할 수 있습니다.
프로세스
다음 명령을 실행하여 머신 구성 풀을 확인합니다.
$ 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
다음 명령을 실행하여
registry.redhat.io
에 인증하려면 Podman을 사용합니다.$ podman login registry.redhat.io
Username: <user_name> Password: <password>
선택 사항: 다음 명령을 실행하여 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
클러스터에 대한 정보를 표시하려면 다음 명령을 실행하여
로그
인수와 함께 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=---
-
다음 명령을 실행하여 성능 프로필을 생성합니다. 예에서는 샘플 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 1개를 지정합니다. -
--RT-kernel=true
는 실시간 커널을 활성화합니다. -
--split-reserved-cpus-across-numa=false
는 NUMA 노드 간에 예약된 CPU 분할을 비활성화합니다. -
--power-consumption-mode=ultra-low-latency
는 전력 소비 증가 시 대기 시간을 최소화합니다. --offlined-cpu-count=1
은 오프라인 CPU 1개를 지정합니다.참고이 예제의
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: []"
다음 명령을 실행하여 생성된 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
생성된 프로필을 적용합니다.
$ oc apply -f my-performance-profile.yaml
출력 예
performanceprofile.performance.openshift.io/performance created
13.2.1.5. Performance Profile Creator 래퍼 스크립트 실행
래퍼 스크립트는 PPC(Performance Profile Creator) 툴을 사용하여 성능 프로필을 생성하는 프로세스를 간소화합니다. 이 스크립트는 필요한 컨테이너 이미지 가져오기 및 실행, 디렉터리를 컨테이너에 마운트하고 Podman을 통해 컨테이너에 직접 매개변수를 제공하는 등의 작업을 처리합니다.
Performance Profile Creator 인수에 대한 자세한 내용은 "Performance Profile Creator arguments" 섹션을 참조하십시오.
PPC는 클러스터의 must-gather
데이터를 사용하여 성능 프로필을 생성합니다. 성능 구성을 대상으로 하는 노드 레이블을 다시 지정하는 등 클러스터를 변경하는 경우 PPC를 다시 실행하기 전에 must-gather
데이터를 다시 생성해야 합니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - 클러스터가 베어 메탈 하드웨어에 설치되어 있어야 합니다.
-
podman
및 OpenShift CLI(oc
)를 설치했습니다. - Node Tuning Operator 이미지에 액세스할 수 있습니다.
- 구성을 위한 대상 노드가 포함된 머신 구성 풀을 확인했습니다.
-
must-gather
tarball에 액세스합니다.
프로세스
예를 들어 다음과 같이
run-perf-profile-creator.sh
라는 이름의 파일을 로컬 시스템에 생성합니다$ vi run-perf-profile-creator.sh
다음 코드를 파일에 붙여넣습니다.
#!/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 "$@"
이 스크립트에 모든 사용자에 대한 실행 권한을 추가합니다.
$ chmod a+x run-perf-profile-creator.sh
다음 명령을 실행하여
registry.redhat.io
에 인증하려면 Podman을 사용합니다.$ podman login registry.redhat.io
Username: <user_name> Password: <password>
선택 사항: 다음 명령을 실행하여 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 이미지의 경로를 설정할 수 있습니다. 경로를 설정하지 않으면 래퍼 스크립트는 기본 이미지registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.17
을 사용합니다.클러스터에 대한 정보를 표시하려면 다음 명령을 실행하여
로그
인수와 함께 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=---
다음 명령을 실행하여 성능 프로필을 생성합니다.
$ ./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 1개를 지정합니다. -
--RT-kernel=true
는 실시간 커널을 활성화합니다. -
--split-reserved-cpus-across-numa=false
는 NUMA 노드 간에 예약된 CPU 분할을 비활성화합니다. -
--power-consumption-mode=ultra-low-latency
는 전력 소비 증가 시 대기 시간을 최소화합니다. --offlined-cpu-count=1
은 오프라인 CPU 1개를 지정합니다.참고이 예제의
mcp-name
인수는oc get mcp
명령의 출력에 따라worker-cnf
로 설정됩니다. 단일 노드 OpenShift의 경우--mcp-name=master
를 사용합니다.
-
다음 명령을 실행하여 생성된 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
생성된 프로필을 적용합니다.
$ oc apply -f my-performance-profile.yaml
출력 예
performanceprofile.performance.openshift.io/performance created
13.2.1.6. Performance Profile Creator 인수
인수 | 설명 |
---|---|
|
MCP의 이름(예: 대상 머신에 해당하는 |
| 의 경로는 디렉터리를 수집해야 합니다.
이 인수는 Podman을 사용하여 PPC 툴을 실행하는 경우에만 필요합니다. 래퍼 스크립트와 함께 PPC를 사용하는 경우 이 인수를 사용하지 마십시오. 대신 래퍼 스크립트에 |
| 예약된 CPU 수입니다. 0보다 큰 자연수를 사용합니다. |
| 실시간 커널을 활성화합니다.
가능한 값: |
인수 | 설명 |
---|---|
| 하이퍼 스레딩을 비활성화합니다.
가능한 값:
기본값: 주의
이 인수가 |
enable-hardware-tuning | 최대 CPU 빈도 설정을 활성화합니다. 이 기능을 활성화하려면 다음 두 필드에 대해 분리된 CPU 및 예약된 CPU에서 실행되는 애플리케이션의 최대 빈도를 설정합니다.
이는 고급 기능입니다. 하드웨어 튜닝을 구성하는 경우 생성된 |
|
이는 클러스터 정보를 캡처합니다. 이 인수에는 가능한 값은 다음과 같습니다.
기본값: |
| 오프라인 CPU 수입니다. 참고 0보다 큰 자연수를 사용합니다. 논리 프로세서가 충분하지 않으면 오류 메시지가 기록됩니다. 메시지는 다음과 같습니다. 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] |
| 전력 소비 모드입니다. 가능한 값은 다음과 같습니다.
기본값: |
|
Pod 전원 관리당 활성화.
가능한 값:
기본값: |
| 생성할 성능 프로파일의 이름입니다.
기본값: |
| NUMA 노드에서 예약된 CPU를 분할합니다.
가능한 값:
기본값: |
| 생성할 성능 프로필의 Kubelet Topology Manager 정책입니다. 가능한 값은 다음과 같습니다.
기본값: |
| DPDK(사용자 수준 네트워킹)가 활성화된 상태에서 실행합니다.
가능한 값:
기본값: |
13.2.1.7. 성능 프로필 참조
다음 참조 성능 프로필을 기반으로 사용하여 고유한 사용자 지정 프로필을 개발할 수 있습니다.
13.2.1.7.1. OpenStack에서 OVS-DPDK를 사용하는 클러스터의 성능 프로필 템플릿
RHOSP(Red Hat OpenStack Platform)에서 OVS-DPDK(Data Plane Development Kit)를 사용하여 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_ISOLATED
,CPU_RESERVED
및 HUGEPAGES_COUNT
키에 대한 구성에 적합한 값을 삽입합니다.
13.2.1.7.2. Telco RAN DU 참조 성능 프로파일
다음 성능 프로필은 상용 하드웨어에서 OpenShift Container Platform 클러스터에 대한 노드 수준 성능 설정을 구성하여 Telco 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
13.2.1.7.3. Telco 코어 참조 성능 프로파일
다음 성능 프로필은 상용 하드웨어에서 OpenShift Container Platform 클러스터에 대한 노드 수준 성능 설정을 구성하여 통신 핵심 워크로드를 호스팅합니다.
Telco 코어 참조 성능 프로파일
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
13.2.2. 지원되는 성능 프로필 API 버전
Node Tuning Operator는 성능 프로필 apiVersion
필드에 대해 v2
,v1
, v1alpha1
을 지원합니다. v1 및 v1alpha1 API는 동일합니다. v2 API에는 기본값인 false
값을 사용하여 선택적 부울 필드 loballyDisableIrqLoadBalancing
이 포함됩니다.
장치 인터럽트 처리를 사용하기 위해 성능 프로파일을 업그레이드
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로 업그레이드할 때 "None" 변환 전략을 사용하여 v1alpha1 성능 프로파일이 즉시 변환되고 API 버전 v1을 사용하여 Node Tuning Operator에 제공됩니다.
Node Tuning Operator API를 v1alpha1 또는 v1에서 v2로 업그레이드
이전 Node Tuning Operator API 버전에서 업그레이드할 때 기존 v1 및 v1alpha1 성능 프로파일은 true 값이 true
인 globallyDisableIrqLoadBalancing
필드를 삽입하는 변환 Webhook를 사용하여 변환됩니다.
13.2.3. 워크로드 힌트를 사용하여 노드 전력 소비 및 실시간 처리 구성
프로세스
-
PPC(
Performance Profile
Creator) 툴을 사용하여 환경 하드웨어 및 토폴로지에 적합한 PerformanceProfile을 생성합니다. 다음 표에서는 PPC 툴과 관련된power-consumption-mode
플래그 및 적용된 워크로드 팁에 대해 설정된 가능한 값을 설명합니다.
Performance Profile creator 설정 | 팁 | 환경 | 설명 |
---|---|---|---|
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당 전원 관리를 허용합니다. |
예제
다음 구성은 일반적으로 telco 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
입니다.
전력 소비와 실시간 설정의 조합이 대기 시간에 미치는 영향에 대한 자세한 내용은 워크로드 팁 이해를 참조하십시오.
13.2.4. 공동 배치된 높은 우선 순위 워크로드 및 낮은 우선 순위 워크로드를 실행하는 노드에 대한 전원 저장 구성
우선 순위가 높은 워크로드가 높은 노드의 대기 시간 또는 처리량에 영향을 미치지 않고 우선 순위가 높은 워크로드가 낮은 노드에 대한 전원을 절약할 수 있습니다. 워크로드 자체를 수정하지 않고도 전력 절감이 가능합니다.
이 기능은 Intel Ice Lake 이상 세대의 Intel CPU에서 지원됩니다. 프로세서의 기능은 높은 우선 순위 워크로드의 대기 시간 및 처리량에 영향을 미칠 수 있습니다.
사전 요구 사항
- BIOS에서 C-states 및 운영 체제를 활성화했습니다.
프로세스
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.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
인수는default
또는low-latency
여야 합니다.
perPodPowerManagement
가 있는PerformanceProfile
의 예apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: [.....] workloadHints: realTime: true highPowerConsumption: false perPodPowerManagement: true
PerformanceProfile
CR(사용자 정의 리소스)에서 기본cpufreq
governor를 추가 커널 인수로 설정합니다.apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: ... additionalKernelArgs: - cpufreq.default_governor=schedutil 1
- 1
- 그러나
schedutil
governor를 사용하는 것이 좋습니다. 그러나온디맨드
또는전원 세이저와 같은 다른 governor를 사용할 수
있습니다.
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를 모든코어
frequency로 제한하는 백분율로 사용할 수 있습니다.모든 코어의
frequency는 코어가 완전히 비어 있을 때 모든 코어가 실행되는 빈도입니다.
13.2.5. 인프라 및 애플리케이션 컨테이너의 CPU 제한
일반 하우스키핑 및 워크로드 작업에서는 대기 시간에 민감한 프로세스에 영향을 줄 수 있는 방식으로 CPU를 사용합니다. 기본적으로 컨테이너 런타임은 모든 온라인 CPU를 사용하여 모든 컨테이너를 함께 실행하여 컨텍스트 스위치와 대기 시간이 급증할 수 있습니다. CPU를 파티셔닝하면 noisy 프로세스에서 서로 분리하여 대기 시간에 민감한 프로세스를 방해하지 않습니다. 다음 표에서는 Node Tuning Operator를 사용하여 노드를 조정한 후 CPU에서 프로세스가 실행되는 방법을 설명합니다.
프로세스 유형 | 세부 정보 |
---|---|
| 대기 시간이 짧은 워크로드가 실행 중인 경우를 제외하고 모든 CPU에서 실행 |
인프라 Pod | 대기 시간이 짧은 워크로드가 실행 중인 경우를 제외하고 모든 CPU에서 실행 |
인터럽트 | 예약된 CPU로 리디렉션(OpenShift Container Platform 4.7 이상에서 선택 사항) |
커널 프로세스 | 예약된 CPU에 핀 |
대기 시간에 민감한 워크로드 Pod | 격리된 풀에서 특정 전용 CPU 세트에 고정 |
OS 프로세스/systemd 서비스 | 예약된 CPU에 핀 |
모든 QoS 프로세스 유형, Burstable
,BestEffort
또는 Guaranteed
의 Pod의 노드에 있는 코어의 할당 가능한 용량은 격리된 풀의 용량과 동일합니다. 예약된 풀의 용량은 클러스터 및 운영 체제 하우스키핑 작업에서 사용할 수 있는 노드의 총 코어 용량에서 제거됩니다.
예시 1
노드에는 100개의 코어 용량이 있습니다. 클러스터 관리자는 성능 프로필을 사용하여 분리된 풀에 50개의 코어와 예약된 풀에 50개의 코어를 할당합니다. 클러스터 관리자는 QoS 보장된
Pod에 25개의 코어를 할당하고 BestEffort
또는 Burstable
Pod의 경우 25개의 코어를 할당합니다. 이는 격리된 풀의 용량과 일치합니다.
예시 2
노드에는 100개의 코어 용량이 있습니다. 클러스터 관리자는 성능 프로필을 사용하여 분리된 풀에 50개의 코어와 예약된 풀에 50개의 코어를 할당합니다. 클러스터 관리자는 QoS 보장된
Pod에 50개의 코어를 할당하고 BestEffort
또는 Burstable
Pod의 코어 1개를 할당합니다. 이렇게 하면 격리된 풀의 용량을 하나의 코어로 초과합니다. CPU 용량이 부족하여 Pod 예약이 실패합니다.
사용할 정확한 파티셔닝 패턴은 하드웨어, 워크로드 특성 및 예상되는 시스템 로드와 같은 여러 요인에 따라 다릅니다. 일부 샘플 사용 사례는 다음과 같습니다.
- 대기 시간에 민감한 워크로드가 NIC(네트워크 인터페이스 컨트롤러)와 같은 특정 하드웨어를 사용하는 경우 격리된 풀의 CPU가 이 하드웨어에 최대한 가까운지 확인합니다. 최소한 동일한 NUMA(Non-Uniform Memory Access) 노드에 워크로드를 배치해야 합니다.
- 예약된 풀은 모든 인터럽트를 처리하는 데 사용됩니다. 시스템 네트워킹에 따라 들어오는 모든 패킷 인터럽트를 처리하기 위해 충분히 크기의 예비 풀을 할당합니다. 4.17 이상 버전에서 워크로드는 선택적으로 민감한 것으로 레이블을 지정할 수 있습니다.
예약 및 격리된 파티션에 사용해야 하는 특정 CPU에 대한 결정에는 자세한 분석과 측정이 필요합니다. 장치 및 메모리의 NUMA 선호도와 같은 요소가 역할을 합니다. 선택 사항은 워크로드 아키텍처 및 특정 사용 사례에 따라 다릅니다.
예약 및 격리된 CPU 풀은 겹치지 않아야 하며 작업자 노드에서 사용 가능한 모든 코어에 걸쳐 있어야 합니다.
하우스키핑 작업과 워크로드가 서로 방해하지 않도록 하려면 성능 프로필의 spec
섹션에 두 개의 CPU 그룹을 지정합니다.
-
isolated
- 애플리케이션 컨테이너 워크로드에 대한 CPU를 지정합니다. 이러한 CPU는 대기 시간이 가장 짧습니다. 이 그룹의 프로세스에는 중단이 발생하지 않으므로 예를 들어 프로세스가 훨씬 더 높은 DPDK 제로 패킷 손실 대역폭에 도달할 수 있습니다. -
reserved
- 클러스터 및 운영 체제 하우스키핑 작업의 CPU를 지정합니다.예약된
그룹의 스레드는 종종 사용 중입니다.예약된
그룹에서 대기 시간에 민감한 애플리케이션을 실행하지 마십시오. 대기 시간에 민감한 애플리케이션은격리된
그룹에서 실행됩니다.
프로세스
- 환경의 하드웨어 및 토폴로지에 적합한 성능 프로필을 만듭니다.
인프라 및 애플리케이션 컨테이너에 대해
reserved
및isolated
하려는 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: ""
13.2.6. 클러스터의 하이퍼 스레딩 구성
OpenShift Container Platform 클러스터에 대한 Hyper-Threading을 구성하려면 성능 프로필의 CPU 스레드를 예약 또는 분리된 CPU 풀에 대해 구성된 동일한 코어로 설정합니다.
성능 프로필을 구성하고 호스트의 Hyper-Threading 구성을 변경하는 경우 PerformanceProfile
YAML에서 CPU isolated
및 reserved
필드를 새 구성과 일치하도록 업데이트해야 합니다.
이전에 활성화된 호스트 Hyper-Threading 구성을 비활성화하면 PerformanceProfile
YAML에 나열된 CPU 코어 ID가 올바르지 않을 수 있습니다. 이렇게 잘못된 구성으로 인해 나열된 CPU를 더 이상 찾을 수 없으므로 노드를 사용할 수 없게 될 가능성이 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - OpenShift CLI(oc)를 설치합니다.
프로세스
구성할 호스트의 모든 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
이 예에서는 4개의 물리적 CPU 코어에서 실행 중인 논리 CPU 코어가 8개 있습니다. CPU0 및 CPU4는 물리적 Core0에서 실행되고 CPU1 및 CPU5는 물리적 Core 1에서 실행되고 있습니다.
또는 특정 물리적 CPU 코어(아래 예제에서
cpu0)
에 설정된 스레드를 보려면 쉘 프롬프트를 열고 다음을 실행합니다.$ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list
출력 예
0-4
PerformanceProfile
YAML에서 분리 및 예약된 CPU를 적용합니다. 예를 들어 논리 코어 CPU0 및 CPU4를isolated
로, 논리 코어 CPU1을 CPU3으로, CPU5를예약된
CPU7으로 설정할 수 있습니다. 예약 및 분리된 CPU를 구성하면 Pod의 인프라 컨테이너는 예약된 CPU를 사용하고 애플리케이션 컨테이너는 분리된 CPU를 사용합니다.... cpu: isolated: 0,4 reserved: 1-3,5-7 ...
참고예약 및 격리된 CPU 풀은 겹치지 않아야 하며 작업자 노드에서 사용 가능한 모든 코어에 걸쳐 있어야 합니다.
Hyper-Threading은 대부분의 Intel 프로세서에서 기본적으로 활성화되어 있습니다. Hyper-Threading을 활성화하면 특정 코어에서 처리되는 모든 스레드를 동일한 코어에서 분리하거나 처리해야 합니다.
하이퍼 스레딩을 활성화하면 모든 보장된 Pod에서 동시 멀티 스레딩(SMT) 수준의 여러 개를 사용하여 Pod가 실패할 수 있는 "noisy neighbor" 상황을 방지해야 합니다. 자세한 내용은 정적 정책 옵션을 참조하십시오.
13.2.6.1. 짧은 대기 시간 애플리케이션의 하이퍼 스레딩 비활성화
대기 시간이 짧은 처리를 위해 클러스터를 구성할 때 클러스터를 배포하기 전에 Hyper-Threading을 비활성화할지 여부를 고려하십시오. 하이퍼 스레딩을 비활성화하려면 다음 단계를 수행합니다.
- 하드웨어 및 토폴로지에 적합한 성능 프로필을 생성합니다.
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를 사용합니다.
13.2.7. 보장된 pod 분리 CPU의 장치 중단 처리 관리
Node Tuning Operator는 호스트 CPU를 Pod 인프라 컨테이너를 포함하여 클러스터 및 운영 체제 하우스키핑 작업을 위해 예약된 CPU와 워크로드를 실행하기 위해 애플리케이션 컨테이너의 분리된 CPU로 나누어 호스트 CPU를 관리할 수 있습니다. 이를 통해 대기 시간이 짧은 워크로드의 CPU를 분리된 상태로 설정할 수 있습니다.
장치 중단은 보장된 pod가 실행 중인 CPU를 제외하고 CPU의 과부하를 방지하기 위해 모든 분리된 CPU와 예약된 CPU 간에 균형을 유지합니다. pod에 관련 주석이 설정되어 있으면 보장된 Pod CPU가 장치 인터럽트를 처리하지 못합니다.
새로운 성능 프로파일 필드 globallyDisableIrqLoadBalancing
은 장치 중단을 처리할지 여부를 관리하는 데 사용할 수 있습니다. 특정 워크로드의 경우 예약된 CPU가 장치 인터럽트를 처리하기에 충분하지 않으며, 이러한 이유로 장치 인터럽트는 분리된 CPU에서 전역적으로 비활성화되지 않습니다. 기본적으로 Node Tuning Operator는 분리된 CPU에서 장치 인터럽트를 비활성화하지 않습니다.
13.2.7.1. 노드의 유효한 IRQ 선호도 설정 찾기
일부 IRQ 컨트롤러는 IRQ 선호도 설정을 지원하지 않으며 항상 모든 온라인 CPU를 IRQ 마스크로 노출합니다. 이러한 IRQ 컨트롤러는 CPU 0에서 효과적으로 실행됩니다.
다음은 IRQ 선호도 설정에 대한 지원이 부족한 드라이버 및 하드웨어의 예입니다. 목록은 전혀 완전하지 않습니다.
-
megaraid_sas
와 같은 일부 RAID 컨트롤러 드라이버 - 많은 비휘발성 메모리 표현(NVMe) 드라이버
- 마더보드(LOM) 네트워크 컨트롤러의 일부 LAN
-
드라이버는
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를 대상으로 하는 경우에도 관리 인터럽트의 유사성을 변경할 수 없습니다.
13.2.7.2. 노드 인터럽트 유사성 구성
IRQ(장치 인터럽트 요청)를 수신할 수 있는 코어를 제어하도록 IRQ 동적 로드 밸런싱 클러스터 노드를 구성합니다.
사전 요구 사항
- 코어 격리의 경우 모든 서버 하드웨어 구성 요소에서 IRQ 선호도를 지원해야 합니다. 서버의 하드웨어 구성 요소가 IRQ 선호도를 지원하는지 확인하려면 서버의 하드웨어 사양을 보거나 하드웨어 공급자에게 문의하십시오.
프로세스
- cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.
-
performance.openshift.io/v2
를 사용하도록 성능 프로파일의apiVersion
을 설정합니다. -
globallyDisableIrqLoadBalancing
필드를 삭제제거하거나false
로 설정합니다. 적절한 분리 및 예약된 CPU를 설정합니다. 다음 스니펫에서는 두 개의 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에서 실행됩니다. 자세한 내용은 "인프라 및 애플리케이션 컨테이너용 CPU 제한"을 참조하십시오.
13.2.8. 대규모 페이지 구성
노드는 OpenShift Container Platform 클러스터에서 사용되는 대규모 페이지를 사전 할당해야 합니다. Node Tuning Operator를 사용하여 특정 노드에 대규모 페이지를 할당합니다.
OpenShift Container Platform에서는 대규모 페이지를 생성하고 할당하는 방법을 제공합니다. Node Tuning Operator는 성능 프로필을 사용하여 이 작업을 더 쉽게 수행할 수 있는 방법을 제공합니다.
예를 들어 성능 프로필의 hugepages
pages
섹션에서 size
, count
및 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-###: ###
13.2.8.1. 여러 대규모 페이지 크기 할당
동일한 컨테이너에서 다양한 크기의 대규모 페이지를 요청할 수 있습니다. 이 경우 다양한 대규모 페이지 크기 요구사항이 있는 컨테이너로 구성된 더 복잡한 Pod를 정의할 수 있습니다.
예를 들어 1G
및 2M
크기를 정의할 수 있으며 Node Tuning Operator는 다음과 같이 노드에서 크기를 둘 다 구성합니다.
spec: hugepages: defaultHugepagesSize: 1G pages: - count: 1024 node: 0 size: 2M - count: 4 node: 1 size: 1G
13.2.9. Node Tuning Operator를 사용하여 NIC 대기열 감소
Node Tuning Operator를 사용하면 성능 향상을 위해 NIC 대기열을 줄일 수 있습니다. 성능 프로필을 사용하여 조정되므로 다양한 네트워크 장치에 대한 대기열을 사용자 지정할 수 있습니다.
13.2.9.1. 성능 프로파일을 사용하여 NIC 큐 조정
성능 프로파일을 사용하면 각 네트워크 장치의 대기열 수를 조정할 수 있습니다.
지원되는 네트워크 장치는 다음과 같습니다.
- 비가상 네트워크 장치
- 멀티 큐(채널)를 지원하는 네트워크 장치
지원되지 않는 네트워크 장치는 다음과 같습니다.
- Pure Software 네트워크 인터페이스
- 블록 장치
- Intel DPDK 가상 기능
사전 요구 사항
-
cluster-admin
역할을 가진 사용자로 클러스터에 액세스합니다. -
OpenShift CLI(
oc
)를 설치합니다.
프로세스
-
cluster-admin
권한이 있는 사용자로 Node Tuning Operator를 실행하는 OpenShift Container Platform 클러스터에 로그인합니다. - 하드웨어 및 토폴로지에 적합한 성능 프로파일을 만들고 적용합니다. 프로파일 생성에 대한 지침은 "성능 프로파일 생성" 섹션을 참조하십시오.
생성된 성능 프로파일을 편집합니다.
$ oc edit -f <your_profile_name>.yaml
spec
필드를net
오브젝트로 채웁니다. 오브젝트 목록에는 다음 두 개의 필드가 포함될 수 있습니다.-
userLevelNetworking
은 부울 플래그로 지정된 필수 필드입니다.userLevelNetworking
이true
인 경우 지원되는 모든 장치에 대해 대기열 수가 예약된 CPU 수로 설정됩니다. 기본값은false
입니다. devices
는 예약된 CPU 수로 큐를 설정할 장치 목록을 지정하는 선택적 필드입니다. 장치 목록이 비어 있으면 구성이 모든 네트워크 장치에 적용됩니다. 구성은 다음과 같습니다.interfacename
: 이 필드는 인터페이스 이름을 지정하고, 양수 또는 음수일 수 있는 쉘 스타일 와일드카드를 지원합니다.-
와일드카드 구문의 예는 다음과 같습니다.
<string> .*
-
음수 규칙 앞에는 느낌표가 붙습니다. 제외된 목록이 아닌 모든 장치에 넷 큐 변경 사항을 적용하려면
!<device>
를 사용합니다(예:!eno1
).
-
와일드카드 구문의 예는 다음과 같습니다.
-
vendorID
: 접두사가0x
인 16비트 16진수로 표시되는 네트워크 장치 공급업체 ID입니다. deviceID
:0x
접두사가 있는 16비트 16진수로 표시되는 네트워크 장치 ID(모델)입니다.참고deviceID
가 지정되어 있는 경우vendorID
도 정의해야 합니다. 장치 항목interfaceName
,vendorID
,vendorID
및deviceID
의 쌍에 지정된 모든 장치 식별자와 일치하는 장치는 네트워크 장치로 간주됩니다. 그러면 이 네트워크 장치의 네트워크 대기열 수가 예약된 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 nodeSelector: node-role.kubernetes.io/worker-cnf: ""
다음 예제 성능 프로필을 사용하여 정의된 장치 식별자와 일치하는 모든 장치에 대해 대기열 수를 예약된 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: ""
다음 예제 성능 프로필을 사용하여 인터페이스 이름
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: ""
이 예제 성능 프로필을 사용하여 이름이
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: ""
인터페이스 이름
eth0
,0x1af4
의vendorID
및0x1000
의deviceID
는 모든 장치에 대해 대기열 수를 예약된 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: ""
업데이트된 성능 프로필을 적용합니다.
$ oc apply -f <your_profile_name>.yaml
추가 리소스
13.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입니다. 예를 들어vendorID=0x1af4
가 있는 다른 네트워크 장치ens2
가 별도로 존재하는 경우 총 네트워크 대기열 수는 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로 설정됩니다.
13.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