12.8. NUMA 인식 스케줄링 문제 해결
NUMA 인식 Pod 스케줄링과 관련된 일반적인 문제를 해결하려면 다음 단계를 수행하세요.
사전 요구 사항
-
OpenShift Container Platform CLI (
oc)를 설치합니다. - cluster-admin 권한이 있는 사용자로 로그인합니다.
- NUMA 리소스 운영자를 설치하고 NUMA 인식 보조 스케줄러를 배포합니다.
프로세스
다음 명령을 실행하여
noderesourcetopologiesCRD가 클러스터에 배포되었는지 확인하세요.$ 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-schedulerNUMA 인식 스케줄 가능 노드에 CR이 적용된
noderesourcetopologies가 있는지 확인합니다. 다음 명령을 실행합니다.$ 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: ""
12.8.1. 더욱 정확한 리소스 가용성 보고 링크 복사링크가 클립보드에 복사되었습니다!
cacheResyncPeriod 사양을 활성화하면 NUMA 리소스 운영자가 노드에서 보류 중인 리소스를 모니터링하고 정의된 간격으로 스케줄러 캐시에서 이 정보를 동기화하여 더욱 정확한 리소스 가용성을 보고할 수 있습니다. 이는 최적이 아닌 스케줄링 결정으로 인해 발생하는 토폴로지 친화성 오류를 최소화하는 데에도 도움이 됩니다. 간격이 낮을수록 네트워크 부하가 커집니다. cacheResyncPeriod 사양은 기본적으로 비활성화되어 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin권한이 있는 사용자로 로그인합니다.
프로세스
현재 실행 중인
NUMAResourcesScheduler리소스를 삭제합니다.다음 명령을 실행하여 활성
NUMAResourcesScheduler를가져옵니다.$ oc get NUMAResourcesScheduler출력 예
NAME AGE numaresourcesscheduler 92m다음 명령을 실행하여 보조 스케줄러 리소스를 삭제합니다.
$ oc delete NUMAResourcesScheduler numaresourcesscheduler출력 예
numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
다음 YAML을
nro-scheduler-cacheresync.yaml파일에 저장합니다. 이 예에서는 로그 수준을Debug로 변경합니다.apiVersion: nodetopology.openshift.io/v1 kind: NUMAResourcesScheduler metadata: name: numaresourcesscheduler spec: imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.19" cacheResyncPeriod: "5s"1 - 1
- 스케줄러 캐시 동기화를 위한 간격 값을 초 단위로 입력합니다. 대부분의 구현에서는
5초의값이 일반적입니다.
다음 명령을 실행하여 업데이트된
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"
12.8.2. 고성능 워크로드가 실행되는 위치 변경 링크 복사링크가 클립보드에 복사되었습니다!
NUMA 인식 보조 스케줄러는 작업자 노드와 워크로드를 최적으로 처리할 수 있는 NUMA 노드에서 고성능 워크로드를 스케줄링합니다. 기본적으로 보조 스케줄러는 가장 사용 가능한 리소스가 있는 선택한 작업자 노드 내의 NUMA 노드에 워크로드를 할당합니다.
워크로드가 실행되는 위치를 변경하려면 scoringStrategy 설정을 NUMAResourcesScheduler 사용자 정의 리소스에 추가하고 해당 값을 MostAllocated 또는 BalancedAllocation 으로 설정할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin권한이 있는 사용자로 로그인합니다.
프로세스
다음 단계를 사용하여 현재 실행 중인
NUMAResourcesScheduler리소스를 삭제합니다.다음 명령을 실행하여 활성
NUMAResourcesScheduler를 가져옵니다.$ oc get NUMAResourcesScheduler출력 예
NAME AGE numaresourcesscheduler 92m다음 명령을 실행하여 보조 스케줄러 리소스를 삭제합니다.
$ oc delete NUMAResourcesScheduler numaresourcesscheduler출력 예
numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
nro-scheduler-mostallocated.yaml파일에 다음 YAML을 저장합니다. 이 예제에서는scoringStrategy를MostAllocated로 변경합니다.apiVersion: nodetopology.openshift.io/v1 kind: NUMAResourcesScheduler metadata: name: numaresourcesscheduler spec: imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v{product-version}" scoringStrategy: type: "MostAllocated"1 - 1
scoringStrategy구성이 생략되면 기본값LeastAllocated가 적용됩니다.
다음 명령을 실행하여 업데이트된
NUMAResourcesScheduler리소스를 만듭니다.$ oc create -f nro-scheduler-mostallocated.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
다음 명령을 실행하여 스케줄러의 관련
ConfigMap리소스를 확인하여ScoringStrategy가 올바르게 적용되었는지 확인합니다.$ oc get -n openshift-numaresources cm topo-aware-scheduler-config -o yaml | grep scoring -A 1출력 예
scoringStrategy: type: MostAllocated
12.8.3. NUMA 인식 스케줄러 로그 확인 링크 복사링크가 클립보드에 복사되었습니다!
로그를 검토하여 NUMA 인식 스케줄러의 문제를 해결합니다. 필요한 경우 NUMAResourcesScheduler 리소스의 spec.logLevel 필드를 수정하여 스케줄러 로그 수준을 늘릴 수 있습니다. 허용 가능한 값은 Normal,Debug 및 Trace 이며 Trace 는 가장 자세한 옵션입니다.
보조 스케줄러의 로그 수준을 변경하려면 실행 중인 스케줄러 리소스를 삭제하고 변경된 로그 수준으로 다시 배포합니다. 이 다운타임 동안 새 워크로드를 예약할 수 없습니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin권한이 있는 사용자로 로그인합니다.
프로세스
현재 실행 중인
NUMAResourcesScheduler리소스를 삭제합니다.다음 명령을 실행하여 활성
NUMAResourcesScheduler를 가져옵니다.$ oc get NUMAResourcesScheduler출력 예
NAME AGE numaresourcesscheduler 90m다음 명령을 실행하여 보조 스케줄러 리소스를 삭제합니다.
$ oc delete NUMAResourcesScheduler numaresourcesscheduler출력 예
numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
nro-scheduler-debug.yaml파일에 다음 YAML을 저장합니다. 이 예에서는 로그 수준을Debug로 변경합니다.apiVersion: nodetopology.openshift.io/v1 kind: NUMAResourcesScheduler metadata: name: numaresourcesscheduler spec: imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.19" logLevel: Debug다음 명령을 실행하여 업데이트된
DebugloggingNUMAResourcesScheduler리소스를 만듭니다.$ 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"
12.8.4. 리소스 토폴로지 내보내기 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
해당 resource-topology-exporter 로그를 검사하여 예기치 않은 결과가 발생하는 noderesourcetopologies 오브젝트의 문제를 해결합니다.
해당 노드에서 클러스터의 NUMA 리소스 토폴로지 내보내기 인스턴스의 이름을 지정하는 것이 좋습니다. 예를 들어, 이름이 worker인 작업자 노드에는 worker 라는 해당 noderesourcetopologies 오브젝트가 있어야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin권한이 있는 사용자로 로그인합니다.
프로세스
NUMA Resources Operator에서 관리하는 데몬 세트를 가져옵니다. 각 daemonset에는
NUMAResourcesOperatorCR에 해당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
12.8.5. 누락된 리소스 토폴로지 내보내기 구성 맵 수정 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 설정이 잘못 구성된 클러스터에 NUMA Resources Operator를 설치하는 경우 Operator가 active로 표시되지만 RTE(Resource topology exporter) 데몬 세트 Pod의 로그에 RTE의 구성이 누락되어 있음을 보여줍니다.
Info: couldn't find configuration in "/etc/resource-topology-exporter/config.yaml"
이 로그 메시지는 필요한 구성이 있는 kubeletconfig 가 클러스터에 제대로 적용되지 않아 RTE configmap 이 누락되었음을 나타냅니다. 예를 들어 다음 클러스터에 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의spec.machineConfigPoolSelector.matchLabels값과kubeletconfig및metadata.labels의 값을 비교합니다.다음 명령을 실행하여
kubeletconfig레이블을 확인합니다.$ oc get kubeletconfig -o yaml출력 예
machineConfigPoolSelector: matchLabels: cnf-worker-tuning: enabled다음 명령을 실행하여
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개체에 없습니다.
예를 들어,
MachineConfigPoolCR을 편집하여 누락된 레이블을 포함합니다.$ oc edit mcp worker -o yaml출력 예
labels: machineconfiguration.openshift.io/mco-built-in: "" pools.operator.machineconfiguration.openshift.io/worker: "" cnf-worker-tuning: enabled- 레이블 변경 사항을 적용하고 클러스터가 업데이트된 구성을 적용할 때까지 기다립니다. 다음 명령을 실행합니다.
검증
누락된
numarsourcesoperator-workerconfigmapCR이 적용되었는지 확인하세요.$ 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
12.8.6. NUMA 리소스 운영자 데이터 수집 링크 복사링크가 클립보드에 복사되었습니다!
oc adm must-gather CLI 명령을 사용하면 NUMA 리소스 연산자와 관련된 기능 및 객체를 포함하여 클러스터에 대한 정보를 수집할 수 있습니다.
사전 요구 사항
-
cluster-admin역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc)가 설치되어 있습니다.
프로세스
must-gather 를사용하여 NUMA 리소스 연산자 데이터를 수집하려면 NUMA 리소스 연산자must-gather이미지를 지정해야 합니다.$ oc adm must-gather --image=registry.redhat.io/openshift4/numaresources-must-gather-rhel9:v4.19