8.5. NUMA 인식 스케줄링 문제 해결

NUMA 인식 Pod 예약으로 일반적인 문제를 해결하려면 다음 단계를 수행합니다.

사전 요구 사항

OpenShift Container Platform CLI (oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.
NUMA Resources Operator를 설치하고 NUMA 인식 보조 스케줄러를 배포합니다.

절차

다음 명령을 실행하여 noderesourcetop 의 CRD가 클러스터에 배포되었는지 확인합니다.

$ oc get crd | grep noderesourcetopologies

출력 예

NAME                                                              CREATED AT
noderesourcetopologies.topology.node.k8s.io                       2022-01-18T08:28:06Z

다음 명령을 실행하여 NUMA 인식 스케줄러 이름이 NUMA 인식 워크로드에 지정된 이름과 일치하는지 확인합니다.
```
$ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'
```
출력 예
```
topo-aware-scheduler
```
NUMA 인식 가능 노드에 noderesourcetopologies CR이 적용되는지 확인합니다. 다음 명령을 실행합니다.
```
$ oc get noderesourcetopologies.topology.node.k8s.io
```
출력 예
```
NAME                    AGE
compute-0.example.com   17h
compute-1.example.com   17h
```
참고
노드 수는mcp(머신 구성 풀) 작업자 정의에 의해 구성된 작업자 노드 수와 같아야 합니다.

다음 명령을 실행하여 예약 가능한 모든 노드에 대한 NUMA 영역 단위를 확인합니다.

$ oc get noderesourcetopologies.topology.node.k8s.io -o yaml

출력 예

apiVersion: v1
items:
- apiVersion: topology.node.k8s.io/v1
  kind: NodeResourceTopology
  metadata:
    annotations:
      k8stopoawareschedwg/rte-update: periodic
    creationTimestamp: "2022-06-16T08:55:38Z"
    generation: 63760
    name: worker-0
    resourceVersion: "8450223"
    uid: 8b77be46-08c0-4074-927b-d49361471590
  topologyPolicies:
  - SingleNUMANodeContainerLevel
  zones:
  - costs:
    - name: node-0
      value: 10
    - name: node-1
      value: 21
    name: node-0
    resources:
    - allocatable: "38"
      available: "38"
      capacity: "40"
      name: cpu
    - allocatable: "134217728"
      available: "134217728"
      capacity: "134217728"
      name: hugepages-2Mi
    - allocatable: "262352048128"
      available: "262352048128"
      capacity: "270107316224"
      name: memory
    - allocatable: "6442450944"
      available: "6442450944"
      capacity: "6442450944"
      name: hugepages-1Gi
    type: Node
  - costs:
    - name: node-0
      value: 21
    - name: node-1
      value: 10
    name: node-1
    resources:
    - allocatable: "268435456"
      available: "268435456"
      capacity: "268435456"
      name: hugepages-2Mi
    - allocatable: "269231067136"
      available: "269231067136"
      capacity: "270573244416"
      name: memory
    - allocatable: "40"
      available: "40"
      capacity: "40"
      name: cpu
    - allocatable: "1073741824"
      available: "1073741824"
      capacity: "1073741824"
      name: hugepages-1Gi
    type: Node
- apiVersion: topology.node.k8s.io/v1
  kind: NodeResourceTopology
  metadata:
    annotations:
      k8stopoawareschedwg/rte-update: periodic
    creationTimestamp: "2022-06-16T08:55:37Z"
    generation: 62061
    name: worker-1
    resourceVersion: "8450129"
    uid: e8659390-6f8d-4e67-9a51-1ea34bba1cc3
  topologyPolicies:
  - SingleNUMANodeContainerLevel
  zones: 1
  - costs:
    - name: node-0
      value: 10
    - name: node-1
      value: 21
    name: node-0
    resources: 2
    - allocatable: "38"
      available: "38"
      capacity: "40"
      name: cpu
    - allocatable: "6442450944"
      available: "6442450944"
      capacity: "6442450944"
      name: hugepages-1Gi
    - allocatable: "134217728"
      available: "134217728"
      capacity: "134217728"
      name: hugepages-2Mi
    - allocatable: "262391033856"
      available: "262391033856"
      capacity: "270146301952"
      name: memory
    type: Node
  - costs:
    - name: node-0
      value: 21
    - name: node-1
      value: 10
    name: node-1
    resources:
    - allocatable: "40"
      available: "40"
      capacity: "40"
      name: cpu
    - allocatable: "1073741824"
      available: "1073741824"
      capacity: "1073741824"
      name: hugepages-1Gi
    - allocatable: "268435456"
      available: "268435456"
      capacity: "268435456"
      name: hugepages-2Mi
    - allocatable: "269192085504"
      available: "269192085504"
      capacity: "270534262784"
      name: memory
    type: Node
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

1: zones 아래의 각 스탠자는 단일 NUMA 영역의 리소스를 설명합니다.
2: resources 는 NUMA 영역 리소스의 현재 상태를 설명합니다. items.zones.resources.available 아래에 나열된 리소스가 보장된 각 Pod에 할당된 전용 NUMA 영역 리소스에 해당하는지 확인합니다.

8.5.1. 보다 정확한 리소스 가용성 보고

cacheResyncPeriod 사양을 활성화하여 노드에서 보류 중인 리소스를 모니터링하고 이 정보를 정의된 간격으로 스케줄러 캐시에서 동기화하여 NUMA 리소스 가용성을 보다 정확하게 보고할 수 있습니다. 또한 최적의 스케줄링 결정으로 인해 토폴로지 선호도 오류 오류를 최소화하는 데 도움이 됩니다. 간격이 낮으면 네트워크가 더 많이 로드됩니다. cacheResyncPeriod 사양은 기본적으로 비활성화되어 있습니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

현재 실행 중인 NUMAResourcesScheduler 리소스를 삭제합니다.
1. 다음 명령을 실행하여 활성 NUMAResourcesScheduler 를 가져옵니다.
```
$ oc get NUMAResourcesScheduler
```
  출력 예
```
NAME                     AGE
numaresourcesscheduler   92m
```
2. 다음 명령을 실행하여 보조 스케줄러 리소스를 삭제합니다.
```
$ oc delete NUMAResourcesScheduler numaresourcesscheduler
```
  출력 예
```
numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
```
nro-scheduler-cacheresync.yaml 파일에 다음 YAML을 저장합니다. 이 예제에서는 로그 수준을 Debug 로 변경합니다.
```
apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesScheduler
metadata:
  name: numaresourcesscheduler
spec:
  imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.13"
  cacheResyncPeriod: "5s" 1
```
1
스케줄러 캐시의 동기화를 위해 간격 값(초)을 입력합니다. 대부분의 구현에서 값은 일반적인 5s 입니다.

다음 명령을 실행하여 업데이트된 NUMAResourcesScheduler 리소스를 만듭니다.

$ oc create -f nro-scheduler-cacheresync.yaml

출력 예

numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created

검증 단계

NUMA 인식 스케줄러가 성공적으로 배포되었는지 확인합니다.

다음 명령을 실행하여 CRD가 성공적으로 생성되었는지 확인합니다.

$ oc get crd | grep numaresourcesschedulers

출력 예

NAME                                                              CREATED AT
numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z

다음 명령을 실행하여 새 사용자 정의 스케줄러를 사용할 수 있는지 확인합니다.

$ oc get numaresourcesschedulers.nodetopology.openshift.io

출력 예

NAME                     AGE
numaresourcesscheduler   3h26m

스케줄러의 로그에 증가된 로그 수준이 표시되는지 확인합니다.

다음 명령을 실행하여 openshift-numaresources 네임스페이스에서 실행 중인 Pod 목록을 가져옵니다.

$ oc get pods -n openshift-numaresources

출력 예

NAME                                               READY   STATUS    RESTARTS   AGE
numaresources-controller-manager-d87d79587-76mrm   1/1     Running   0          46h
numaresourcesoperator-worker-5wm2k                 2/2     Running   0          45h
numaresourcesoperator-worker-pb75c                 2/2     Running   0          45h
secondary-scheduler-7976c4d466-qm4sc               1/1     Running   0          21m

다음 명령을 실행하여 보조 스케줄러 Pod의 로그를 가져옵니다.

$ oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources

출력 예

...
I0223 11:04:55.614788       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.Namespace total 11 items received
I0223 11:04:56.609114       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.ReplicationController total 10 items received
I0223 11:05:22.626818       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.StorageClass total 7 items received
I0223 11:05:31.610356       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.PodDisruptionBudget total 7 items received
I0223 11:05:31.713032       1 eventhandlers.go:186] "Add event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"
I0223 11:05:53.461016       1 eventhandlers.go:244] "Delete event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"

8.5.2. NUMA 인식 스케줄러 로그 확인

로그를 검토하여 NUMA 인식 스케줄러의 문제를 해결합니다. 필요한 경우 NUMAResourcesScheduler 리소스의 spec.logLevel 필드를 수정하여 스케줄러 로그 수준을 늘릴 수 있습니다. 허용 가능한 값은 Normal,Debug, and Trace 이며 추적은 가장 자세한 옵션입니다.

참고

보조 스케줄러의 로그 수준을 변경하려면 실행 중인 스케줄러 리소스를 삭제하고 변경된 로그 수준으로 다시 배포합니다. 이 다운타임 중에 스케줄러는 새 워크로드를 예약할 수 없습니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

현재 실행 중인 NUMAResourcesScheduler 리소스를 삭제합니다.
1. 다음 명령을 실행하여 활성 NUMAResourcesScheduler 를 가져옵니다.
```
$ oc get NUMAResourcesScheduler
```
  출력 예
```
NAME                     AGE
numaresourcesscheduler   90m
```
2. 다음 명령을 실행하여 보조 스케줄러 리소스를 삭제합니다.
```
$ oc delete NUMAResourcesScheduler numaresourcesscheduler
```
  출력 예
```
numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
```

다음 YAML을 nro-scheduler-debug.yaml 파일에 저장합니다. 이 예제에서는 로그 수준을 Debug 로 변경합니다.

apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesScheduler
metadata:
  name: numaresourcesscheduler
spec:
  imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.13"
  logLevel: Debug

다음 명령을 실행하여 업데이트된 Debug 로깅 NUMAResourcesScheduler 리소스를 만듭니다.

$ oc create -f nro-scheduler-debug.yaml

출력 예

numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created

검증 단계

NUMA 인식 스케줄러가 성공적으로 배포되었는지 확인합니다.

다음 명령을 실행하여 CRD가 성공적으로 생성되었는지 확인합니다.

$ oc get crd | grep numaresourcesschedulers

출력 예

NAME                                                              CREATED AT
numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z

다음 명령을 실행하여 새 사용자 정의 스케줄러를 사용할 수 있는지 확인합니다.

$ oc get numaresourcesschedulers.nodetopology.openshift.io

출력 예

NAME                     AGE
numaresourcesscheduler   3h26m

스케줄러의 로그에 증가된 로그 수준이 표시되는지 확인합니다.

다음 명령을 실행하여 openshift-numaresources 네임스페이스에서 실행 중인 Pod 목록을 가져옵니다.

$ oc get pods -n openshift-numaresources

출력 예

NAME                                               READY   STATUS    RESTARTS   AGE
numaresources-controller-manager-d87d79587-76mrm   1/1     Running   0          46h
numaresourcesoperator-worker-5wm2k                 2/2     Running   0          45h
numaresourcesoperator-worker-pb75c                 2/2     Running   0          45h
secondary-scheduler-7976c4d466-qm4sc               1/1     Running   0          21m

다음 명령을 실행하여 보조 스케줄러 Pod의 로그를 가져옵니다.

$ oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources

출력 예

...
I0223 11:04:55.614788       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.Namespace total 11 items received
I0223 11:04:56.609114       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.ReplicationController total 10 items received
I0223 11:05:22.626818       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.StorageClass total 7 items received
I0223 11:05:31.610356       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.PodDisruptionBudget total 7 items received
I0223 11:05:31.713032       1 eventhandlers.go:186] "Add event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"
I0223 11:05:53.461016       1 eventhandlers.go:244] "Delete event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"

8.5.3. 리소스 토폴로지 내보내기 문제 해결

해당 resource-topology-exporter 로그를 검사하여 예기치 않은 결과가 발생하는 노드 리소스 토폴로지의 문제를 해결합니다.

참고

클러스터의 NUMA 리소스 토폴로지 내보내기 인스턴스의 이름이 참조하는 노드의 이름을 지정하는 것이 좋습니다. 예를 들어 이름 worker가 있는 작업자 노드에는 worker 라는 해당 noderesourcetopECDHE 오브젝트 가 있어야 합니다.

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

NUMA Resources Operator가 관리하는 daemonsets를 가져옵니다. 각 데몬 세트에는 NUMAResourcesOperator CR에 해당 nodeGroup 이 있습니다. 다음 명령을 실행합니다.
```
$ oc get numaresourcesoperators.nodetopology.openshift.io numaresourcesoperator -o jsonpath="{.status.daemonsets[0]}"
```
출력 예
```
{"name":"numaresourcesoperator-worker","namespace":"openshift-numaresources"}
```

이전 단계의 name 값을 사용하여 관심 데몬 세트의 레이블을 가져옵니다.

$ oc get ds -n openshift-numaresources numaresourcesoperator-worker -o jsonpath="{.spec.selector.matchLabels}"

출력 예

{"name":"resource-topology"}

다음 명령을 실행하여 resource-topology 레이블을 사용하여 Pod를 가져옵니다.

$ oc get pods -n openshift-numaresources -l name=resource-topology -o wide

출력 예

NAME                                 READY   STATUS    RESTARTS   AGE    IP            NODE
numaresourcesoperator-worker-5wm2k   2/2     Running   0          2d1h   10.135.0.64   compute-0.example.com
numaresourcesoperator-worker-pb75c   2/2     Running   0          2d1h   10.132.2.33   compute-1.example.com

문제 해결 중인 노드에 해당하는 작업자 Pod에서 실행 중인 resource-topology-exporter 컨테이너의 로그를 검사합니다. 다음 명령을 실행합니다.

$ oc logs -n openshift-numaresources -c resource-topology-exporter numaresourcesoperator-worker-pb75c

출력 예

I0221 13:38:18.334140       1 main.go:206] using sysinfo:
reservedCpus: 0,1
reservedMemory:
  "0": 1178599424
I0221 13:38:18.334370       1 main.go:67] === System information ===
I0221 13:38:18.334381       1 sysinfo.go:231] cpus: reserved "0-1"
I0221 13:38:18.334493       1 sysinfo.go:237] cpus: online "0-103"
I0221 13:38:18.546750       1 main.go:72]
cpus: allocatable "2-103"
hugepages-1Gi:
  numa cell 0 -> 6
  numa cell 1 -> 1
hugepages-2Mi:
  numa cell 0 -> 64
  numa cell 1 -> 128
memory:
  numa cell 0 -> 45758Mi
  numa cell 1 -> 48372Mi

8.5.4. 누락된 리소스 토폴로지 내보내기 구성 맵 수정

클러스터 설정이 잘못 구성된 클러스터에 NUMA Resources Operator를 설치하는 경우 일부 상황에서 Operator가 활성으로 표시되지만 RTE(리소스 토폴로지 내보내기er) 데몬 세트 Pod의 로그에 RTE의 구성이 누락된 것으로 표시됩니다.

Info: couldn't find configuration in "/etc/resource-topology-exporter/config.yaml"

이 로그 메시지는 필수 구성이 있는 kubeletconfig 가 클러스터에 제대로 적용되지 않아 RTE 구성 맵이 누락되었음을 나타냅니다. 예를 들어 다음 클러스터에 numaresourcesoperator-worker configmap CR(사용자 정의 리소스)이 누락되어 있습니다.

$ oc get configmap

출력 예

NAME                           DATA   AGE
0e2a6bd3.openshift-kni.io      0      6d21h
kube-root-ca.crt               1      6d21h
openshift-service-ca.crt       1      6d21h
topo-aware-scheduler-config    1      6d18h

올바르게 구성된 클러스터에서 oc get configmap 은 numaresourcesoperator-worker configmap CR도 반환합니다.

사전 요구 사항

OpenShift Container Platform CLI (oc)를 설치합니다.
cluster-admin 권한이 있는 사용자로 로그인합니다.
NUMA Resources Operator를 설치하고 NUMA 인식 보조 스케줄러를 배포합니다.

절차

다음 명령을 사용하여 MachineConfigPool (mcp) 작업자 CR의 kubeletconfig 및 metadata.labels 에서 spec.machineConfigPoolSelector.matchLabels 의 값을 비교합니다.
1. 다음 명령을 실행하여 kubeletconfig 라벨을 확인합니다.
```
$ oc get kubeletconfig -o yaml
```
  출력 예
```
machineConfigPoolSelector:
  matchLabels:
    cnf-worker-tuning: enabled
```
2. 다음 명령을 실행하여 mcp 레이블을 확인합니다.
```
$ oc get mcp worker -o yaml
```
  출력 예
```
labels:
  machineconfiguration.openshift.io/mco-built-in: ""
  pools.operator.machineconfiguration.openshift.io/worker: ""
```
  cnf-worker-tuning: enabled 레이블은 MachineConfigPool 오브젝트에 존재하지 않습니다.

누락된 라벨을 포함하도록 MachineConfigPool CR을 편집합니다. 예를 들면 다음과 같습니다.

$ oc edit mcp worker -o yaml

출력 예

labels:
  machineconfiguration.openshift.io/mco-built-in: ""
  pools.operator.machineconfiguration.openshift.io/worker: ""
  cnf-worker-tuning: enabled

레이블 변경 사항을 적용하고 클러스터가 업데이트된 구성을 적용할 때까지 기다립니다. 다음 명령을 실행합니다.

검증

누락된 numaresourcesoperator-worker configmap CR이 적용되었는지 확인합니다.

$ oc get configmap

출력 예

NAME                           DATA   AGE
0e2a6bd3.openshift-kni.io      0      6d21h
kube-root-ca.crt               1      6d21h
numaresourcesoperator-worker   1      5m
openshift-service-ca.crt       1      6d21h
topo-aware-scheduler-config    1      6d18h

8.5. NUMA 인식 스케줄링 문제 해결

8.5.1. 보다 정확한 리소스 가용성 보고

8.5.2. NUMA 인식 스케줄러 로그 확인

8.5.3. 리소스 토폴로지 내보내기 문제 해결

8.5.4. 누락된 리소스 토폴로지 내보내기 구성 맵 수정

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

Red Hat 소개

Red Hat legal and privacy links

Red Hat legal and privacy links