12.2. 성능 프로필을 사용하여 짧은 대기 시간을 실현하도록 노드 튜닝
클러스터 성능 프로필을 사용하여 짧은 대기 시간을 위해 노드를 조정합니다. 인프라 및 애플리케이션 컨테이너의 CPU를 제한하고, 대규모 페이지, 하이퍼 스레딩을 구성하고, 대기 시간에 민감한 프로세스를 위해 CPU 파티션을 구성할 수 있습니다.
추가 리소스
12.2.1. 성능 프로파일 작성
Performance Profile Creator(PPC)와 이를 사용하여 성능 프로필을 만드는 방법을 설명합니다.
Telco에서 PerformanceProfile
을 사용하여 짧은 대기 시간, 실시간 및 DPDK(Data Plane Development Kit) 워크로드를 사용하는 클러스터는 cgroup v2 지원 부족으로 인해 cgroups v1로 자동으로 되돌립니다. PerformanceProfile
을 사용하는 경우 cgroup v2를 활성화하는 것은 지원되지 않습니다.
12.2.1.1. 성능 프로파일 작성툴 정보
PPC(Performance Profile Creator)는 성능 프로필을 생성하는 데 사용되는 Node Tuning Operator와 함께 제공되는 명령줄 툴입니다. 이 툴은 클러스터의 must-gather
데이터와 여러 사용자가 제공하는 프로필 인수를 사용합니다. PPC는 하드웨어 및 토폴로지에 적합한 성능 프로필을 생성합니다.
툴은 다음 방법 중 하나로 실행됩니다.
-
podman
호출 - 래퍼 스크립트 호출
12.2.1.2. must-gather 명령을 사용하여 클러스터에 대한 데이터 수집
PPC(Performance Profile creator) 툴에는 must-gather
데이터가 필요합니다. 클러스터 관리자는 must-gather
명령을 실행하여 클러스터에 대한 정보를 캡처합니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc
)가 설치되어 있습니다.
프로세스
선택 사항: 라벨이 있는 일치하는 머신 구성 풀이 있는지 확인합니다.
$ oc describe mcp/worker-rt
출력 예
Name: worker-rt Namespace: Labels: machineconfiguration.openshift.io/role=worker-rt
일치하는 라벨이 없는 경우 MCP 이름과 일치하는 MCP(Machine config pool)의 레이블을 추가합니다.
$ oc label mcp <mcp_name> machineconfiguration.openshift.io/role=<mcp_name>
-
must-gather
데이터를 저장하려는 디렉터리로 이동합니다. 다음 명령을 실행하여 클러스터 정보를 수집합니다.
$ oc adm must-gather
선택 사항:
must-gather
디렉터리에서 압축 파일을 생성합니다.$ tar cvaf must-gather.tar.gz must-gather/
참고Performance Profile Creator 래퍼 스크립트를 실행하는 경우 압축 출력이 필요합니다.
12.2.1.3. Podman을 사용하여 Performance Profile Creator 실행
클러스터 관리자는 podman
및 Performance Profile Creator를 실행하여 성능 프로필을 만들 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - 클러스터가 베어 메탈 하드웨어에 설치되어 있어야 합니다.
-
podman
및 OpenShift CLI(oc
)가 설치된 노드가 있습니다. - Node Tuning Operator 이미지에 액세스할 수 있습니다.
프로세스
머신 구성 풀을 확인합니다.
$ oc get mcp
출력 예
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-acd1358917e9f98cbdb599aea622d78b True False False 3 3 3 0 22h worker-cnf rendered-worker-cnf-1d871ac76e1951d32b2fe92369879826 False True False 2 1 1 0 22h
Podman을 사용하여
registry.redhat.io
에 인증합니다.$ podman login registry.redhat.io
Username: <username> Password: <password>
선택 사항: PPC 툴에 대한 도움말을 표시합니다.
$ podman run --rm --entrypoint performance-profile-creator registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v4.15 -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
검색 모드에서 Performance Profile Creator 툴을 실행합니다.
참고검색 모드는
must-gather
의 출력을 사용하여 클러스터를 검사합니다. 생성된 출력에는 다음 조건에 대한 정보가 포함됩니다.- 할당된 CPU ID로 NUMA 셀 파티셔닝
- Hyper-Threading 사용 여부
이 정보를 사용하여 Performance Profile Creator 툴에 제공된 일부 인수에 대해 적절한 값을 설정할 수 있습니다.
$ podman run --entrypoint performance-profile-creator -v <path_to_must-gather>/must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v4.15 --info log --must-gather-dir-path /must-gather
참고이 명령은 Performance Profile Creator 툴을
podman
의 새 진입점으로 사용합니다. 호스트의must-gather
데이터를 컨테이너 이미지에 매핑하고 필요한 사용자 제공 프로필 인수를 호출하여my-performance-profile.yaml
파일을 생성합니다.-v
옵션은 다음 구성 요소 중 하나에 대한 경로일 수 있습니다.-
must-gather
출력 디렉터리 -
must-gather
압축 해제된 .tar 파일이 포함된 기존 디렉터리
info
옵션에는 출력 형식을 지정하는 값이 필요합니다. 가능한 값은 log 및 JSON입니다. JSON 형식은 디버깅을 위해 예약되어 있습니다.podman
을 실행합니다.$ podman run --entrypoint performance-profile-creator -v /must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v4.15 --mcp-name=worker-cnf --reserved-cpu-count=4 --rt-kernel=true --split-reserved-cpus-across-numa=false --must-gather-dir-path /must-gather --power-consumption-mode=ultra-low-latency --offlined-cpu-count=6 > my-performance-profile.yaml
참고Performance Profile Creator 인수는 Performance Profile Creator 인수 테이블에 표시됩니다. 다음 인수가 필요합니다.
-
reserved-cpu-count
-
mcp-name
-
rt-kernel
이 예제의
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-39,48-79 offlined: 42-47 reserved: 0-1,40-41 machineConfigPoolSelector: machineconfiguration.openshift.io/role: worker-cnf nodeSelector: node-role.kubernetes.io/worker-cnf: "" numa: topologyPolicy: restricted realTimeKernel: enabled: true workloadHints: highPowerConsumption: true realTime: true
생성된 프로필을 적용합니다.
$ oc apply -f my-performance-profile.yaml
추가 리소스
-
must-gather
툴에 대한 자세한 내용은 클러스터에 대한 데이터 수집을 참조하십시오.
12.2.1.3.1. podman을 실행하여 성능 프로파일을 만드는 방법
다음 예제에서는 podman
을 실행하여 NUMA 노드 간에 분할될 예약된 20개의 CPU가 있는 성능 프로필을 생성하는 방법을 보여줍니다.
노드 하드웨어 구성:
- 80 CPU
- 하이퍼 스레딩 활성화
- 두 개의 NUMA 노드
- 짝수 번호의 CPU는 NUMA 노드 0에서 실행되고 홀수 번호의 CPU는 NUMA 노드 1에서 실행
podman
을 실행하여 성능 프로필을 생성합니다.
$ podman run --entrypoint performance-profile-creator -v /must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v4.15 --mcp-name=worker-cnf --reserved-cpu-count=20 --rt-kernel=true --split-reserved-cpus-across-numa=true --must-gather-dir-path /must-gather > my-performance-profile.yaml
생성된 프로필은 다음 YAML에 설명되어 있습니다.
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: cpu: isolated: 10-39,50-79 reserved: 0-9,40-49 nodeSelector: node-role.kubernetes.io/worker-cnf: "" numa: topologyPolicy: restricted realTimeKernel: enabled: true
이 경우 NUMA 노드 0에 CPU 10개가 예약되고 NUMA 노드 1에 CPU 10개가 예약됩니다.
12.2.1.3.2. Performance Profile Creator 래퍼 스크립트 실행
성능 프로필 래퍼 스크립트는 PPC(Performance Profile Creator) 툴의 실행을 간소화합니다. podman
실행과 관련된 복잡성을 숨기고 매핑 디렉터리를 지정하면 성능 프로필을 만들 수 있습니다.
사전 요구 사항
- 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-operator:v4.15" 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
선택 사항:
run-perf-profile-creator.sh
명령 사용을 표시합니다.$ ./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 1 -t path to a must-gather tarball 2 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
참고두 가지 유형의 인수가 있습니다.
-
래퍼 인수 즉
-h
,-p
및-t
- PPC 인수
-
래퍼 인수 즉
검색 모드에서 performance profile creator 툴을 실행합니다.
참고검색 모드는
must-gather
의 출력을 사용하여 클러스터를 검사합니다. 생성된 출력에는 다음에 대한 정보가 포함됩니다.- 할당된 CPU ID로 NUMA 셀 파티션을 분할
- 하이퍼스레딩 활성화 여부
이 정보를 사용하여 Performance Profile Creator 툴에 제공된 일부 인수에 대해 적절한 값을 설정할 수 있습니다.
$ ./run-perf-profile-creator.sh -t /must-gather/must-gather.tar.gz -- --info=log
참고info
옵션에는 출력 형식을 지정하는 값이 필요합니다. 가능한 값은 log 및 JSON입니다. JSON 형식은 디버깅을 위해 예약되어 있습니다.머신 구성 풀을 확인합니다.
$ oc get mcp
출력 예
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-acd1358917e9f98cbdb599aea622d78b True False False 3 3 3 0 22h worker-cnf rendered-worker-cnf-1d871ac76e1951d32b2fe92369879826 False True False 2 1 1 0 22h
성능 프로파일을 생성합니다.
$ ./run-perf-profile-creator.sh -t /must-gather/must-gather.tar.gz -- --mcp-name=worker-cnf --reserved-cpu-count=2 --rt-kernel=true > my-performance-profile.yaml
참고Performance Profile Creator 인수는 Performance Profile Creator 인수 테이블에 표시됩니다. 다음 인수가 필요합니다.
-
reserved-cpu-count
-
mcp-name
-
rt-kernel
이 예제의
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: 1-39,41-79 reserved: 0,40 nodeSelector: node-role.kubernetes.io/worker-cnf: "" numa: topologyPolicy: restricted realTimeKernel: enabled: false
생성된 프로필을 적용합니다.
참고프로필을 적용하기 전에 Node Tuning Operator를 설치합니다.
$ oc apply -f my-performance-profile.yaml
12.2.1.3.3. Performance Profile Creator 인수
인수 | 설명 |
---|---|
| 하이퍼스레딩을 비활성화합니다.
가능한 값:
기본값: 주의
이 인수가 |
|
이는 클러스터 정보를 캡처하며 검색 모드에서만 사용됩니다. 검색 모드에서는 가능한 값은 다음과 같습니다.
기본값: |
|
대상 머신에 해당하는 MCP 이름 (예: |
| 디렉터리 경로를 수집해야 합니다. 이 매개 변수는 필수입니다.
사용자가 래퍼 스크립트 |
| 오프라인 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 전원 관리당 활성화.
가능한 값:
기본값: |
|
생성할 성능 프로파일의 이름입니다. 기본값: |
| 예약된 CPU 수입니다. 이 매개 변수는 필수입니다. 참고 이것은 자연수여야 합니다. 0 값은 허용되지 않습니다. |
| 실시간 커널을 활성화합니다. 이 매개 변수는 필수입니다.
가능한 값: |
| NUMA 노드에서 예약된 CPU를 분할합니다.
가능한 값:
기본값: |
| 생성할 성능 프로필의 Kubelet Topology Manager 정책입니다. 가능한 값은 다음과 같습니다.
기본값: |
| DPDK(사용자 수준 네트워킹)가 활성화된 상태에서 실행합니다.
가능한 값:
기본값: |
12.2.1.4. 성능 프로필 참조
다음 참조 성능 프로필을 기반으로 사용하여 고유한 사용자 지정 프로필을 개발할 수 있습니다.
12.2.1.4.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
키에 대한 구성에 적합한 값을 삽입합니다.
12.2.1.4.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
12.2.1.4.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
12.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를 사용하여 변환됩니다.
12.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
입니다.
전력 소비와 실시간 설정의 조합이 대기 시간에 미치는 영향에 대한 자세한 내용은 워크로드 팁 이해를 참조하십시오.
12.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.15 \ --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는 코어가 완전히 비어 있을 때 모든 코어가 실행되는 빈도입니다.
12.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.15 이상 버전에서 워크로드는 선택적으로 민감한 것으로 레이블을 지정할 수 있습니다.
예약 및 격리된 파티션에 사용해야 하는 특정 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: ""
12.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" 상황을 방지해야 합니다. 자세한 내용은 정적 정책 옵션을 참조하십시오.
12.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를 사용합니다.
12.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에서 장치 인터럽트를 비활성화하지 않습니다.
12.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를 대상으로 하는 경우에도 관리 인터럽트의 유사성을 변경할 수 없습니다.
12.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 제한"을 참조하십시오.
12.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-###: ###
12.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
12.2.9. Node Tuning Operator를 사용하여 NIC 대기열 감소
Node Tuning Operator를 사용하면 성능 향상을 위해 NIC 대기열을 줄일 수 있습니다. 성능 프로필을 사용하여 조정되므로 다양한 네트워크 장치에 대한 대기열을 사용자 지정할 수 있습니다.
12.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
추가 리소스
12.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로 설정됩니다.
12.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