검색

12.3. 실시간 및 짧은 대기 시간 워크로드 프로비저닝

download PDF

많은 조직에서는 특히 금융 및 통신 업계에서 고성능 컴퓨팅과 낮은 예측 가능한 대기 시간이 필요합니다.

OpenShift Container Platform에서는 Node Tuning Operator에서 자동 튜닝을 구현하여 대기 시간이 짧은 성능과 OpenShift Container Platform 애플리케이션의 응답 시간을 일관되게 유지할 수 있습니다. 성능 프로필 구성을 사용하여 이러한 변경을 수행합니다. 커널을 kernel-rt로 업데이트하고, Pod 인프라 컨테이너를 포함하여 클러스터 및 운영 체제 하우스키핑 작업을 위해 CPU를 예약하고, 애플리케이션 컨테이너의 CPU를 분리하고, 사용되지 않는 CPU를 비활성화하여 전력 소비를 줄일 수 있습니다.

참고

애플리케이션을 작성할 때 RHEL for Real Time 프로세스 및 스레드에 설명된 일반적인 권장 사항을 따르십시오.

12.3.1. 실시간 기능이 있는 작업자에 짧은 대기 시간 워크로드 예약

실시간 기능을 구성하는 성능 프로필이 적용되는 작업자 노드에 대기 시간이 짧은 워크로드를 예약할 수 있습니다.

참고

특정 노드에 워크로드를 예약하려면 Pod CR(사용자 정의 리소스)의 라벨 선택기를 사용합니다. 라벨 선택기는 Node Tuning Operator에 의해 짧은 대기 시간을 위해 구성된 머신 구성 풀에 연결된 노드와 일치해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • 대기 시간이 짧은 워크로드를 위해 작업자 노드를 조정하는 클러스터에 성능 프로필을 적용했습니다.

프로세스

  1. 대기 시간이 짧은 워크로드에 대한 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.15"
        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
    # ...

    1
    Pod 런타임 시 CPU를 완전히 공정 스케줄러(CFS) 할당량을 비활성화합니다.
    2
    CPU 부하 분산을 비활성화합니다.
    3
    노드에서 Pod를 중단하지 않도록 설정합니다.
    4
    nodeSelector 레이블은 Node CR에 지정한 라벨과 일치해야 합니다.
    5
    runtimeClassName 은 클러스터에 구성된 성능 프로필의 이름과 일치해야 합니다.
  2. performance-<profile_name> 형식으로 Pod runtimeClassName 을 입력합니다. 여기서 <profile_name>은 PerformanceProfile YAML의 이름입니다. 이전 예에서 이름은 performance-dynamic-low-latency-profile 입니다.
  3. 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

  4. 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

검증

노드 구성이 올바르게 적용되었는지 확인합니다.

  1. 노드에 로그인하여 구성을 확인합니다.

    $ oc debug node/<node-name>
  2. 노드 파일 시스템을 사용할 수 있는지 확인합니다.

    sh-4.4# chroot /host

    예상 출력

    sh-4.4#

  3. 기본 시스템 CPU 선호도 마스크에 dynamic-Low-latency-pod CPU(예: CPU 2 및 3)가 포함되어 있지 않은지 확인합니다.

    sh-4.4# cat /proc/irq/default_smp_affinity

    출력 예

    33

  4. 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가 필요한 애플리케이션과 함께 실행 프로브를 사용하면 대기 시간이 급증할 수 있습니다. 대안으로 올바르게 구성된 네트워크 프로브 세트와 같은 다른 프로브를 사용합니다.

12.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]
  1. Pod를 생성합니다.

    $ oc  apply -f qos-pod.yaml --namespace=qos-example
  2. 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 요청을 자동으로 할당합니다.

12.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
참고

현재 cgroup v2에서는 CPU 부하 분산 비활성화가 지원되지 않습니다.

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 부하 분산을 비활성화하면 클러스터에 있는 다른 컨테이너의 성능에 영향을 미칠 수 있습니다.

12.3.4. 우선순위가 높은 Pod의 전원 저장 모드 비활성화

워크로드가 실행되는 노드에 대한 절전을 구성할 때 우선 순위가 높은 워크로드가 영향을 받지 않도록 Pod를 구성할 수 있습니다.

절전 구성으로 노드를 구성할 때 Pod 수준에서 성능 구성으로 높은 우선 순위 워크로드를 구성해야 합니다. 즉, 구성이 Pod에서 사용하는 모든 코어에 적용됩니다.

Pod 수준에서 P-state 및 C-state를 비활성화하면 최상의 성능과 짧은 대기 시간을 위해 높은 우선 순위의 워크로드를 구성할 수 있습니다.

표 12.4. 우선 순위가 높은 워크로드 구성
주석가능한 값설명

cpu-c-states.crio.io:

  • "enable"
  • "disable"
  • "max_latency:microseconds"

이 주석을 사용하면 각 CPU에 대해 C-state를 활성화하거나 비활성화할 수 있습니다. 또는 C 상태에 대해 최대 대기 시간을 microseconds로 지정할 수도 있습니다. 예를 들어 cpu-c-states.crio.io:"max_latency:10" 을 설정하여 최대 대기 시간이 10microseconds인 C-states를 활성화합니다. Pod에 최상의 성능을 제공하려면 값을 "비활성화" 로 설정합니다.

cpu-freq-governor.crio.io:

지원되는 모든 cpufreq governor.

각 CPU에 cpufreq governor를 설정합니다. 높은 우선 순위의 워크로드에는 "performance" governor를 사용하는 것이 좋습니다.

사전 요구 사항

  • 우선 순위가 높은 워크로드 Pod가 예약된 노드의 성능 프로필에 절전을 구성했습니다.

프로세스

  1. 우선순위가 높은 워크로드 Pod에 필요한 주석을 추가합니다. 주석은 기본 설정을 재정의합니다.

    우선순위가 높은 워크로드 주석의 예

    apiVersion: v1
    kind: Pod
    metadata:
      #...
      annotations:
        #...
        cpu-c-states.crio.io: "disable"
        cpu-freq-governor.crio.io: "performance"
        #...
      #...
    spec:
      #...
      runtimeClassName: performance-<profile_name>
      #...

  2. Pod를 다시 시작하여 주석을 적용합니다.

12.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 할당량을 비활성화하면 클러스터의 다른 컨테이너 성능에 영향을 미칠 수 있습니다.

12.3.6. 고정된 컨테이너가 실행 중인 CPU에 대한 인터럽트 처리 비활성화

워크로드의 대기 시간을 단축하기 위해 일부 컨테이너에서는 장치 인터럽트를 처리하지 않도록 고정된 CPU가 필요합니다. pod 주석 irq-load-balancing.crio.io 는 고정된 컨테이너가 실행 중인 CPU에서 장치 인터럽트가 처리되었는지 여부를 정의하는 데 사용됩니다. CRI-O를 설정하면 Pod 컨테이너가 실행 중인 장치 인터럽트를 비활성화합니다.

개별 Pod에 속하는 컨테이너가 고정된 CPU의 인터럽트 처리를 비활성화하려면 성능 프로필에서 globallyDisableIrqLoadBalancingfalse 로 설정되어 있는지 확인합니다. 그런 다음 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>
...
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.