This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.15.3. 성능 프로필을 사용하여 짧은 대기 시간을 실현하도록 노드 튜닝
성능 프로필을 사용하면 특정 머신 구성 풀에 속한 노드의 대기 시간 튜닝 측면을 제어할 수 있습니다. 설정을 지정하면 PerformanceProfile
오브젝트가 실제 노드 수준 튜닝을 수행하는 여러 오브젝트로 컴파일됩니다.
-
MachineConfig
파일은 노드를 조작합니다. -
KubeletConfig
파일은 토폴로지 관리자, CPU 관리자 및 OpenShift Container Platform 노드를 구성합니다. - Tuned 프로필은 Node Tuning Operator를 구성합니다.
성능 프로필을 사용하여 커널을 kernel-rt로 업데이트할지 여부를 지정하고, 대규모 페이지를 할당하고, CPU를 분할하여 하우스키핑 작업 수행 또는 워크로드 실행에 사용할 CPU를 분할할 수 있습니다.
PerformanceProfile
오브젝트를 수동으로 생성하거나 Performance Profile Creator(PPC)를 사용하여 성능 프로필을 생성할 수 있습니다. PPC에 대한 자세한 내용은 아래 추가 리소스를 참조하십시오.
성능 프로파일의 예
- 1
- 이 필드를 사용하여 워크로드의 애플리케이션 컨테이너와 함께 사용할 특정 CPU를 분리합니다. 하이퍼 스레딩이 활성화된 경우 오류 없이 Pod를 실행할 수 있도록 분리된 CPU 수를 설정합니다.
- 2
- 이 필드를 사용하여 하우스키핑을 위해 인프라 컨테이너와 함께 사용할 특정 CPU를 예약합니다.
- 3
- 이 필드를 사용하여 노드에 실시간 커널을 설치합니다. 유효한 값은
true
또는false
입니다.true
값을 설정하면 실시간 커널이 설치됩니다. - 4
- 이 필드를 사용하여 토폴로지 관리자 정책을 구성합니다. 유효한 값은
none
(기본값),best-effort
,restricted
및single-numa-node
입니다. 자세한 내용은 토폴로지 관리자 정책을 참조하십시오. - 5
- 이 필드를 사용하여 특정 노드에 성능 프로파일을 적용할 노드 선택기를 지정합니다.
15.3.1. 대규모 페이지 구성 링크 복사링크가 클립보드에 복사되었습니다!
노드는 OpenShift Container Platform 클러스터에서 사용되는 대규모 페이지를 사전 할당해야 합니다. Node Tuning Operator를 사용하여 특정 노드에 대규모 페이지를 할당합니다.
OpenShift Container Platform에서는 대규모 페이지를 생성하고 할당하는 방법을 제공합니다. Node Tuning Operator는 성능 프로필을 사용하여 이 작업을 더 쉽게 수행할 수 있는 방법을 제공합니다.
예를 들어 성능 프로필의 hugepages
pages
섹션에서 size
, count
및 node
(선택사항)로 된 여러 블록을 지정할 수 있습니다.
- 1
node
는 대규모 페이지가 할당된 NUMA 노드입니다.node
를 생략하면 페이지가 모든 NUMA 노드에 균등하게 분산됩니다.
관련 머신 구성 풀 상태에 업데이트가 완료된 것으로 나타날 때까지 기다립니다.
대규모 페이지를 할당하기 위해 수행해야 하는 구성 단계는 이것이 전부입니다.
검증
구성을 검증하려면 노드의
/proc/meminfo
파일을 참조하십시오.oc debug node/ip-10-0-141-105.ec2.internal
$ oc debug node/ip-10-0-141-105.ec2.internal
Copy to Clipboard Copied! Toggle word wrap Toggle overflow grep -i huge /proc/meminfo
# grep -i huge /proc/meminfo
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc describe
를 사용하여 새 크기를 보고합니다.oc describe node worker-0.ocp4poc.example.com | grep -i huge
$ oc describe node worker-0.ocp4poc.example.com | grep -i huge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
hugepages-1g=true hugepages-###: ### hugepages-###: ###
hugepages-1g=true hugepages-###: ### hugepages-###: ###
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.3.2. 여러 대규모 페이지 크기 할당 링크 복사링크가 클립보드에 복사되었습니다!
동일한 컨테이너에서 다양한 크기의 대규모 페이지를 요청할 수 있습니다. 이 경우 다양한 대규모 페이지 크기 요구사항이 있는 컨테이너로 구성된 더 복잡한 Pod를 정의할 수 있습니다.
예를 들어 1G
및 2M
크기를 정의할 수 있으며 Node Tuning Operator는 다음과 같이 노드에서 두 크기를 모두 구성합니다.
15.3.3. IRQ 동적 로드 밸런싱을 위한 노드 구성 링크 복사링크가 클립보드에 복사되었습니다!
IRQ 동적 로드 밸런싱을 처리하도록 클러스터 노드를 구성하려면 다음을 수행합니다.
- cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.
-
performance.openshift.io/v2
를 사용하도록 성능 프로파일의apiVersion
을 설정합니다. -
globallyDisableIrqLoadBalancing
필드를 삭제제거하거나false
로 설정합니다. 적절한 분리 및 예약된 CPU를 설정합니다. 다음 스니펫에서는 두 개의 CPU를 예약하는 프로파일을 보여줍니다.
isolated
CPU 세트에서 실행되는 Pod에 대해 IRQ 로드 밸런싱이 활성화됩니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고예약 및 분리된 CPU를 구성하면 Pod의 인프라 컨테이너는 예약된 CPU를 사용하고 애플리케이션 컨테이너는 분리된 CPU를 사용합니다.
전용 CPU를 사용하는 pod를 생성하고
irq-load-balancing.crio.io
및cpu-quota.crio.io
주석을disable
로 설정합니다. 예를 들어 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
performance-<profile_name> 형식으로 pod
runtimeClassName
을 입력합니다. 여기서<profile_name>은PerformanceProfile
YAML의name
입니다 (예:performance- dynamic-irq-profile
). - 노드 선택기를 cnf-worker 을 대상으로 설정합니다.
Pod가 올바르게 실행되고 있는지 확인합니다. 상태가
running
이어야 하며 올바른 cnf-worker 노드를 설정해야 합니다.oc get pod -o wide
$ oc get pod -o wide
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES dynamic-irq-pod 1/1 Running 0 5h33m <ip-address> <node-name> <none> <none>
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES dynamic-irq-pod 1/1 Running 0 5h33m <ip-address> <node-name> <none> <none>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow IRQ 동적 로드 밸런싱을 위해 구성된 Pod가 실행되는 CPU를 가져옵니다.
oc exec -it dynamic-irq-pod -- /bin/bash -c "grep Cpus_allowed_list /proc/self/status | awk '{print $2}'"
$ oc exec -it dynamic-irq-pod -- /bin/bash -c "grep Cpus_allowed_list /proc/self/status | awk '{print $2}'"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력
Cpus_allowed_list: 2-3
Cpus_allowed_list: 2-3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 노드 구성이 올바르게 적용되었는지 확인합니다. 구성을 확인하려면 노드에 SSH를 실행합니다.
oc debug node/<node-name>
$ oc debug node/<node-name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 노드 파일 시스템을 사용할 수 있는지 확인합니다.
chroot /host
sh-4.4# chroot /host
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력
sh-4.4#
sh-4.4#
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 기본 시스템 CPU 선호도 마스크에
dynamic-irq-pod
CPU (예: CPU 2 및 3)가 포함되지 않도록 합니다.cat /proc/irq/default_smp_affinity
$ cat /proc/irq/default_smp_affinity
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
33
33
Copy to Clipboard Copied! Toggle word wrap Toggle overflow IRQ가
dynamic-irq-pod
CPU에서 실행되도록 구성되어 있지 않은지 확인합니다.find /proc/irq/ -name smp_affinity_list -exec sh -c 'i="$1"; mask=$(cat $i); file=$(echo $i); echo $file: $mask' _ {} \;
find /proc/irq/ -name smp_affinity_list -exec sh -c 'i="$1"; mask=$(cat $i); file=$(echo $i); echo $file: $mask' _ {} \;
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
일부 IRQ 컨트롤러는 IRQ 재조정을 지원하지 않으며 항상 모든 온라인 CPU를 IRQ 마스크로 공개합니다. 이러한 IRQ 컨트롤러는 CPU 0에서 효과적으로 실행됩니다. 호스트 구성에 대한 보다 자세한 내용은 호스트로 SSH를 실행하고 <irq-num>
을 쿼리할 CPU 번호를 입력하여 다음을 실행합니다.
cat /proc/irq/<irq-num>/effective_affinity
$ cat /proc/irq/<irq-num>/effective_affinity
15.3.4. 클러스터의 하이퍼 스레딩 구성 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 클러스터의 하이퍼 스레딩을 구성하려면 성능 프로파일의 CPU 스레드를 예약 또는 분리된 CPU 풀에 구성된 동일한 코어로 설정합니다.
성능 프로파일을 구성하고 호스트의 하이퍼 스레딩 구성을 변경하는 경우 PerformanceProfile
YAML의 CPU isolated
및 reserved
필드를 새 구성과 일치하도록 업데이트해야 합니다.
이전에 활성화된 호스트 하이퍼 스레딩 구성을 비활성화하면 PerformanceProfile
YAML에 나열된 CPU 코어 ID가 올바르지 않을 수 있습니다. 이렇게 잘못된 구성으로 인해 나열된 CPU를 더 이상 찾을 수 없으므로 노드를 사용할 수 없게 될 가능성이 있습니다.
사전 요구 사항
-
cluster-admin
역할을 가진 사용자로 클러스터에 액세스합니다. - OpenShift CLI(oc)를 설치합니다.
프로세스
구성할 호스트의 모든 CPU에서 실행중인 스레드를 확인합니다.
클러스터에 로그인하고 다음 명령을 실행하여 호스트 CPU에서 실행중인 스레드를 볼 수 있습니다.
lscpu --all --extended
$ lscpu --all --extended
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 예에서는 4개의 물리적 CPU 코어에서 실행 중인 논리 CPU 코어가 8개 있습니다. CPU0 및 CPU4는 물리적 Core0에서 실행되고 CPU1 및 CPU5는 물리적 Core 1에서 실행되고 있습니다.
또는 특정 물리적 CPU 코어(다음 예에서는
cpu0
)에 설정된 스레드를 보려면 명령 프롬프트를 열고 다음을 실행합니다.cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list
$ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
0-4
0-4
Copy to Clipboard Copied! Toggle word wrap Toggle overflow PerformanceProfile
YAML에서 분리 및 예약된 CPU를 적용합니다. 예를 들어 논리 코어 CPU0 및 CPU4를분리된
로, 논리 코어 CPU1을 CPU3으로, CPU5를 CPU7으로 설정할 수있습니다
. 예약 및 분리된 CPU를 구성하면 Pod의 인프라 컨테이너는 예약된 CPU를 사용하고 애플리케이션 컨테이너는 분리된 CPU를 사용합니다.... cpu: isolated: 0,4 reserved: 1-3,5-7 ...
... cpu: isolated: 0,4 reserved: 1-3,5-7 ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고예약 및 격리된 CPU 풀이 겹치지 않아야 하며 작업자 노드에서 사용 가능한 모든 코어에 걸쳐 있어야 합니다.
하이퍼 스레딩은 대부분의 Intel 프로세서에서 기본적으로 활성화되어 있습니다. 하이퍼 스레딩을 활성화하면 특정 코어에서 처리되는 모든 스레드를 동일한 코어에서 분리하거나 처리해야 합니다.
15.3.4.1. 지연 시간이 짧은 애플리케이션의 하이퍼 스레딩 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
지연 시간이 짧은 프로세스를 위해 클러스터를 구성할 때 클러스터를 배포하기 전에 하이퍼 스레딩을 비활성화할지 여부를 고려하십시오. 하이퍼 스레딩을 비활성화하려면 다음을 수행합니다.
- 하드웨어 및 토폴로지에 적합한 성능 프로필을 생성합니다.
nosmt
를 추가 커널 인수로 설정합니다. 다음 성능 프로파일 예에서는 이 설정에 대해 설명합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고예약 및 분리된 CPU를 구성하면 Pod의 인프라 컨테이너는 예약된 CPU를 사용하고 애플리케이션 컨테이너는 분리된 CPU를 사용합니다.
15.3.5. 워크로드 팁 이해 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에서는 전력 소비와 실시간 설정이 대기 시간에 미치는 영향에 대해 설명합니다.
다음 워크로드 힌트를 수동으로 구성할 수 있습니다. Performance Profile Creator를 사용하여 워크로드 힌트를 사용할 수도 있습니다. 성능 프로필에 대한 자세한 내용은 "성능 프로필 생성" 섹션을 참조하십시오. 워크로드 힌트가 수동으로 구성되고 realTime
워크로드 힌트가 명시적으로 설정되지 않은 경우 기본값은 true
입니다.
Performance Profile Creator 설정 | 힌트 | 환경 | 설명 |
---|---|---|---|
기본값 |
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당 전원 관리를 허용합니다. |
15.3.6. 워크로드 힌트 수동 구성 링크 복사링크가 클립보드에 복사되었습니다!
절차
-
"Works workload hints"의 표에 설명된 대로 환경의 하드웨어 및 토폴로지에 적합한
PerformanceProfile
을 생성합니다. 예상 워크로드와 일치하도록 프로필을 조정합니다. 이 예에서는 가능한 가장 짧은 대기 시간을 튜닝합니다. highPowerConsumption
및realTime
워크로드 힌트를 추가합니다. 둘 다true
로 설정되어 있습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
성능 프로파일에서 realTime
워크로드 힌트 플래그가 true
로 설정된 경우 고정 CPU가 있는 보장된 모든 Pod에 cpu-quota.crio.io: disable
주석을 추가합니다. 이 주석은 Pod 내에서 프로세스 성능이 저하되지 않도록 하는 데 필요합니다. realTime
워크로드 힌트가 명시적으로 설정되지 않은 경우 기본값은 true
입니다.
15.3.7. 인프라 및 애플리케이션 컨테이너의 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개의 코어를 할당합니다. 클러스터 관리자는 BestEffort
또는 Burstable
Pod에 대해 QoS가 보장된
Pod 및 25개의 코어를 25개에 할당합니다. 이는 격리된 풀의 용량과 일치합니다.
예시 2
노드에는 100개의 코어 용량이 있습니다. 클러스터 관리자는 성능 프로필을 사용하여 분리된 풀에 50개의 코어를 할당하고 예약된 풀에 50개의 코어를 할당합니다. 클러스터 관리자는 QoS가 보장된
Pod에 50개의 코어를 할당하고 BestEffort
또는 Burstable
Pod의 코어 1개를 할당합니다. 이는 하나의 코어로 격리된 풀의 용량을 초과합니다. CPU 용량이 부족하여 Pod 예약에 실패합니다.
사용할 정확한 파티션 패턴은 하드웨어, 워크로드 특성 및 예상되는 시스템 로드와 같은 여러 요인에 따라 달라집니다. 일부 샘플 사용 사례는 다음과 같습니다.
- 대기 시간에 민감한 워크로드에서 NIC(네트워크 인터페이스 컨트롤러)와 같은 특정 하드웨어를 사용하는 경우 분리된 풀의 CPU가 이 하드웨어에 최대한 가깝게 있는지 확인합니다. 최소한 동일한 NUMA(Non-Uniform Memory Access) 노드에 워크로드를 배치해야 합니다.
- 예약된 풀은 모든 인터럽트를 처리하는 데 사용됩니다. 시스템 네트워킹에 따른 경우 충분한 크기의 예약 풀을 할당하여 들어오는 모든 패킷 인터럽트를 처리합니다. 4.11 이상 버전에서 워크로드는 선택적으로 중요로 레이블을 지정할 수 있습니다.
예약 및 분리된 파티션에 사용할 특정 CPU에 대한 결정에는 자세한 분석과 측정이 필요합니다. 장치 및 메모리의 NUMA 선호도와 같은 요인은 역할을 합니다. 선택 사항은 워크로드 아키텍처 및 특정 사용 사례에 따라 달라집니다.
예약 및 격리된 CPU 풀이 겹치지 않아야 하며 작업자 노드에서 사용 가능한 모든 코어에 걸쳐 있어야 합니다.
하우스키핑 작업 및 워크로드가 서로 간섭하지 않도록 성능 프로파일의 spec
섹션에 두 개의 CPU 그룹을 지정합니다.
-
isolated
- 애플리케이션 컨테이너 워크로드의 CPU를 지정합니다. 이러한 CPU는 대기 시간이 가장 짧습니다. 이 그룹의 프로세스에는 중단이 발생하지 않으므로 예를 들어 프로세스가 훨씬 더 높은 DPDK 제로 패킷 손실 대역폭에 도달할 수 있습니다. -
reserved
- 클러스터 및 운영 체제 하우스키핑 작업의 CPU를 지정합니다.예약
그룹의 스레드는 종종 사용 중입니다.예약된
그룹에서 대기 시간에 민감한 애플리케이션을 실행하지 마십시오. 대기 시간에 민감한 애플리케이션은격리된
그룹에서 실행됩니다.
절차
- 환경 하드웨어 및 토폴로지에 적합한 성능 프로필을 생성합니다.
인프라 및 애플리케이션 컨테이너에 대해
reserved
및isolated
하려는 CPU와 함께 예약 및 격리된 매개변수를 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow