13.3. 실시간 및 짧은 대기 시간 워크로드 프로비저닝
많은 조직에서는 특히 금융 및 통신 업계에서 고성능 컴퓨팅과 낮은 예측 가능한 대기 시간이 필요합니다.
OpenShift Container Platform에서는 Node Tuning Operator에서 자동 튜닝을 구현하여 대기 시간이 짧은 성능과 OpenShift Container Platform 애플리케이션의 응답 시간을 일관되게 유지할 수 있습니다. 성능 프로필 구성을 사용하여 이러한 변경을 수행합니다. 커널을 kernel-rt로 업데이트하고, Pod 인프라 컨테이너를 포함하여 클러스터 및 운영 체제 하우스키핑 작업을 위해 CPU를 예약하고, 애플리케이션 컨테이너의 CPU를 분리하고, 사용되지 않는 CPU를 비활성화하여 전력 소비를 줄일 수 있습니다.
애플리케이션을 작성할 때 RHEL for Real Time 프로세스 및 스레드에 설명된 일반적인 권장 사항을 따르십시오.
추가 리소스
13.3.1. 실시간 기능이 있는 작업자에 짧은 대기 시간 워크로드 예약
실시간 기능을 구성하는 성능 프로필이 적용되는 작업자 노드에 대기 시간이 짧은 워크로드를 예약할 수 있습니다.
특정 노드에 워크로드를 예약하려면 Pod
CR(사용자 정의 리소스)의 라벨 선택기를 사용합니다. 라벨 선택기는 Node Tuning Operator에 의해 짧은 대기 시간을 위해 구성된 머신 구성 풀에 연결된 노드와 일치해야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 로그인했습니다. - 대기 시간이 짧은 워크로드를 위해 작업자 노드를 조정하는 클러스터에 성능 프로필을 적용했습니다.
프로세스
대기 시간이 짧은 워크로드에 대한
Pod
CR을 생성하고 클러스터에 적용합니다. 예를 들면 다음과 같습니다.실시간 처리를 사용하도록 구성된
Pod
사양의 예apiVersion: v1 kind: Pod metadata: name: dynamic-low-latency-pod annotations: cpu-quota.crio.io: "disable" 1 cpu-load-balancing.crio.io: "disable" 2 irq-load-balancing.crio.io: "disable" 3 spec: securityContext: runAsNonRoot: true seccompProfile: type: RuntimeDefault containers: - name: dynamic-low-latency-pod image: "registry.redhat.io/openshift4/cnf-tests-rhel8:v4.17" command: ["sleep", "10h"] resources: requests: cpu: 2 memory: "200M" limits: cpu: 2 memory: "200M" securityContext: allowPrivilegeEscalation: false capabilities: drop: [ALL] nodeSelector: node-role.kubernetes.io/worker-cnf: "" 4 runtimeClassName: performance-dynamic-low-latency-profile 5 # ...
-
performance-<profile_name> 형식으로 Pod
runtimeClassName
을 입력합니다. 여기서 <profile_name>은PerformanceProfile
YAML의이름입니다
. 이전 예에서이름은
performance-dynamic-low-latency-profile
입니다. Pod가 올바르게 실행되고 있는지 확인합니다. 상태가
running
이어야 하며 올바른 cnf-worker 노드를 설정해야 합니다.$ oc get pod -o wide
예상 출력
NAME READY STATUS RESTARTS AGE IP NODE dynamic-low-latency-pod 1/1 Running 0 5h33m 10.131.0.10 cnf-worker.example.com
IRQ 동적 로드 밸런싱을 위해 구성된 Pod가 실행되는 CPU를 가져옵니다.
$ oc exec -it dynamic-low-latency-pod -- /bin/bash -c "grep Cpus_allowed_list /proc/self/status | awk '{print $2}'"
예상 출력
Cpus_allowed_list: 2-3
검증
노드 구성이 올바르게 적용되었는지 확인합니다.
노드에 로그인하여 구성을 확인합니다.
$ oc debug node/<node-name>
노드 파일 시스템을 사용할 수 있는지 확인합니다.
sh-4.4# chroot /host
예상 출력
sh-4.4#
기본 시스템 CPU 선호도 마스크에
dynamic-Low-latency-pod
CPU(예: CPU 2 및 3)가 포함되어 있지 않은지 확인합니다.sh-4.4# cat /proc/irq/default_smp_affinity
출력 예
33
IRQ가
dynamic-low-latency-pod
CPU에서 실행되도록 구성되어 있지 않은지 확인합니다.sh-4.4# find /proc/irq/ -name smp_affinity_list -exec sh -c 'i="$1"; mask=$(cat $i); file=$(echo $i); echo $file: $mask' _ {} \;
출력 예
/proc/irq/0/smp_affinity_list: 0-5 /proc/irq/1/smp_affinity_list: 5 /proc/irq/2/smp_affinity_list: 0-5 /proc/irq/3/smp_affinity_list: 0-5 /proc/irq/4/smp_affinity_list: 0 /proc/irq/5/smp_affinity_list: 0-5 /proc/irq/6/smp_affinity_list: 0-5 /proc/irq/7/smp_affinity_list: 0-5 /proc/irq/8/smp_affinity_list: 4 /proc/irq/9/smp_affinity_list: 4 /proc/irq/10/smp_affinity_list: 0-5 /proc/irq/11/smp_affinity_list: 0 /proc/irq/12/smp_affinity_list: 1 /proc/irq/13/smp_affinity_list: 0-5 /proc/irq/14/smp_affinity_list: 1 /proc/irq/15/smp_affinity_list: 0 /proc/irq/24/smp_affinity_list: 1 /proc/irq/25/smp_affinity_list: 1 /proc/irq/26/smp_affinity_list: 1 /proc/irq/27/smp_affinity_list: 5 /proc/irq/28/smp_affinity_list: 1 /proc/irq/29/smp_affinity_list: 0 /proc/irq/30/smp_affinity_list: 0-5
짧은 대기 시간을 위해 노드를 튜닝하면 보장된 CPU가 필요한 애플리케이션과 함께 실행 프로브를 사용하면 대기 시간이 급증할 수 있습니다. 대안으로 올바르게 구성된 네트워크 프로브 세트와 같은 다른 프로브를 사용합니다.
13.3.2. 보장된 QoS 클래스를 사용하여 Pod 생성
QoS 클래스가 Guaranteed
로 지정된 Pod를 생성하는 경우 다음 사항에 유의하십시오.
- Pod의 모든 컨테이너에는 메모리 제한과 메모리 요청이 있어야 하며 동일해야 합니다.
- Pod의 모든 컨테이너에는 CPU 제한과 CPU 요청이 있어야 하며 동일해야 합니다.
다음 예에서는 컨테이너가 하나인 Pod의 구성 파일을 보여줍니다. 이 컨테이너에는 메모리 제한과 메모리 요청이 있으며 둘 다 200MiB입니다. 이 컨테이너에는 CPU 제한과 CPU 요청이 있으며 둘 다 CPU 1개입니다.
apiVersion: v1 kind: Pod metadata: name: qos-demo namespace: qos-example spec: securityContext: runAsNonRoot: true seccompProfile: type: RuntimeDefault containers: - name: qos-demo-ctr image: <image-pull-spec> resources: limits: memory: "200Mi" cpu: "1" requests: memory: "200Mi" cpu: "1" securityContext: allowPrivilegeEscalation: false capabilities: drop: [ALL]
Pod를 생성합니다.
$ oc apply -f qos-pod.yaml --namespace=qos-example
Pod에 대한 자세한 정보를 봅니다.
$ oc get pod qos-demo --namespace=qos-example --output=yaml
출력 예
spec: containers: ... status: qosClass: Guaranteed
참고컨테이너에 메모리 제한을 지정하고 메모리 요청을 지정하지 않으면 OpenShift Container Platform에서 제한과 일치하는 메모리 요청을 자동으로 할당합니다. 마찬가지로 컨테이너의 CPU 제한을 지정하고 CPU 요청을 지정하지 않으면 OpenShift Container Platform에서 제한과 일치하는 CPU 요청을 자동으로 할당합니다.
13.3.3. Pod에서 CPU 로드 밸런싱 비활성화
CPU 부하 분산을 비활성화하거나 활성화하는 기능은 CRI-O 수준에서 구현됩니다. CRI-O 아래의 코드는 다음 요구사항이 충족되는 경우에만 CPU 부하 분산을 비활성화하거나 활성화합니다.
Pod는
performance-<profile-name>
런타임 클래스를 사용해야 합니다. 다음과 같이 성능 프로필의 상태를 보고 적절한 이름을 가져올 수 있습니다.apiVersion: performance.openshift.io/v2 kind: PerformanceProfile ... status: ... runtimeClass: performance-manual
Node Tuning Operator는 관련 노드 아래에 고성능 런타임 처리기 구성 스니펫을 생성하고 클러스터 아래에 고성능 런타임 클래스를 생성합니다. CPU 부하 분산 구성 기능을 활성화하는 것을 제외하고는 기본 런타임 처리기와 동일한 콘텐츠가 있습니다.
Pod에 대해 CPU 부하 분산을 비활성화하려면 Pod
사양에 다음 필드가 포함되어야 합니다.
apiVersion: v1 kind: Pod metadata: #... annotations: #... cpu-load-balancing.crio.io: "disable" #... #... spec: #... runtimeClassName: performance-<profile_name> #...
CPU 관리자 static 정책이 활성화되어 있는 경우 전체 CPU를 사용하는 guaranteed QoS가 있는 Pod에 대해서만 CPU 부하 분산을 비활성화하십시오. 그렇지 않은 경우 CPU 부하 분산을 비활성화하면 클러스터에 있는 다른 컨테이너의 성능에 영향을 미칠 수 있습니다.
13.3.4. 우선순위가 높은 Pod의 전원 저장 모드 비활성화
워크로드가 실행되는 노드에 대한 절전을 구성할 때 우선 순위가 높은 워크로드가 영향을 받지 않도록 Pod를 구성할 수 있습니다.
절전 구성으로 노드를 구성할 때 Pod 수준에서 성능 구성으로 높은 우선 순위 워크로드를 구성해야 합니다. 즉, 구성이 Pod에서 사용하는 모든 코어에 적용됩니다.
Pod 수준에서 P-state 및 C-state를 비활성화하면 최상의 성능과 짧은 대기 시간을 위해 높은 우선 순위의 워크로드를 구성할 수 있습니다.
주석 | 가능한 값 | 설명 |
---|---|---|
|
|
이 주석을 사용하면 각 CPU에 대해 C-state를 활성화하거나 비활성화할 수 있습니다. 또는 C 상태에 대해 최대 대기 시간을 microseconds로 지정할 수도 있습니다. 예를 들어 |
|
지원되는 모든 |
각 CPU에 |
사전 요구 사항
- 우선 순위가 높은 워크로드 Pod가 예약된 노드의 성능 프로필에 절전을 구성했습니다.
프로세스
우선순위가 높은 워크로드 Pod에 필요한 주석을 추가합니다. 주석은
기본
설정을 재정의합니다.우선순위가 높은 워크로드 주석의 예
apiVersion: v1 kind: Pod metadata: #... annotations: #... cpu-c-states.crio.io: "disable" cpu-freq-governor.crio.io: "performance" #... #... spec: #... runtimeClassName: performance-<profile_name> #...
- Pod를 다시 시작하여 주석을 적용합니다.
13.3.5. CPU CFS 할당량 비활성화
고정 Pod의 CPU 제한을 제거하려면 cpu-quota.crio.io: "disable"
주석이 있는 Pod를 생성합니다. 이 주석은 Pod가 실행될 때 CPU를 완전히 공정 스케줄러(CFS) 할당량을 비활성화합니다.
cpu-quota.crio.io
가 비활성화된 Pod 사양의 예
apiVersion: v1 kind: Pod metadata: annotations: cpu-quota.crio.io: "disable" spec: runtimeClassName: performance-<profile_name> #...
CPU 관리자 정적 정책이 활성화된 경우 CPU CFS 할당량과 전체 CPU를 사용하는 보장된 QoS가 있는 Pod에만 CPU CFS 할당량을 비활성화합니다. 예를 들어 CPU 고정 컨테이너가 포함된 Pod입니다. 그렇지 않으면 CPU CFS 할당량을 비활성화하면 클러스터의 다른 컨테이너 성능에 영향을 미칠 수 있습니다.
추가 리소스
13.3.6. 고정된 컨테이너가 실행 중인 CPU에 대한 인터럽트 처리 비활성화
워크로드의 대기 시간을 단축하기 위해 일부 컨테이너에서는 장치 인터럽트를 처리하지 않도록 고정된 CPU가 필요합니다. pod 주석 irq-load-balancing.crio.io
는 고정된 컨테이너가 실행 중인 CPU에서 장치 인터럽트가 처리되었는지 여부를 정의하는 데 사용됩니다. CRI-O를 설정하면 Pod 컨테이너가 실행 중인 장치 인터럽트를 비활성화합니다.
개별 Pod에 속하는 컨테이너가 고정된 CPU의 인터럽트 처리를 비활성화하려면 성능 프로필에서 globallyDisableIrqLoadBalancing
이 false
로 설정되어 있는지 확인합니다. 그런 다음 Pod 사양에서 irq-load-balancing.crio.io
Pod 주석을 비활성화하도록 설정합니다
.
다음 Pod 사양에는 이 주석이 포함되어 있습니다.
apiVersion: performance.openshift.io/v2 kind: Pod metadata: annotations: irq-load-balancing.crio.io: "disable" spec: runtimeClassName: performance-<profile_name> ...
추가 리소스