12.5. 플랫폼 확인을 위한 대기 시간 테스트 수행

PDF

CNF(클라우드 네이티브 네트워크 기능) 테스트 이미지를 사용하여 CNF 워크로드 실행에 필요한 모든 구성 요소가 설치된 CNF 지원 OpenShift Container Platform 클러스터에서 대기 시간 테스트를 실행할 수 있습니다. 대기 시간 테스트를 실행하여 워크로드에 대한 노드 튜닝의 유효성을 검사합니다.

cnf-tests 컨테이너 이미지는 registry.redhat.io/openshift4/cnf-tests-rhel8:v4.15 에서 사용할 수 있습니다.

12.5.1. 대기 시간 테스트 실행을 위한 사전 요구 사항

대기 시간 테스트를 실행하려면 클러스터가 다음 요구 사항을 충족해야 합니다.

Node Tuning Operator를 사용하여 성능 프로필을 구성했습니다.
클러스터에서 필요한 모든 CNF 구성을 적용했습니다.
클러스터에 기존 MachineConfigPool CR이 적용되어 있습니다. 기본 작업자 풀은 worker-cnf 입니다.

추가 리소스

실시간 기능이 있는 작업자에 대해 워크로드 예약

12.5.2. 대기 시간 측정

cnf-tests 이미지는 세 가지 툴을 사용하여 시스템의 대기 시간을 측정합니다.

hwlatdetect
cyclictest
oslat

각 툴에는 특정 용도가 있습니다. 안정적인 테스트 결과를 얻으려면 도구를 순서대로 사용하십시오.

hwlatdetect: 베어 메탈 하드웨어에서 수행할 수 있는 기준을 측정합니다. 다음 대기 시간 테스트를 진행하기 전에 hwlatdetect 에서 보고한 대기 시간이 운영 체제 튜닝을 통해 하드웨어 대기 시간 급증을 수정할 수 없기 때문에 필요한 임계값을 충족하는지 확인합니다.
cyclictest: hwlatdetect 가 검증을 통과한 후 실시간 커널 스케줄러 대기 시간을 확인합니다. cyclictest 툴은 반복된 타이머를 스케줄링하고 원하는 트리거 시간과 실제 트리거 시간 간의 차이를 측정합니다. 차이점은 인터럽트 또는 프로세스 우선순위로 인한 튜닝의 기본 문제를 찾을 수 있습니다. 툴은 실시간 커널에서 실행해야 합니다.
oslat: CPU 집약적인 DPDK 애플리케이션과 유사하게 작동하며 CPU 과도한 데이터 처리를 시뮬레이션하는 사용량이 많은 루프에 대한 모든 중단 및 중단을 측정합니다.

테스트에서는 다음과 같은 환경 변수를 도입합니다.

표 12.5. 대기 시간 테스트 환경 변수
환경 변수	설명
`LATENCY_TEST_DELAY`	테스트 실행을 시작한 후 시간(초)을 지정합니다. 변수를 사용하여 CPU 관리자 조정 루프가 기본 CPU 풀을 업데이트할 수 있도록 허용할 수 있습니다. 기본값은 0입니다.
`LATENCY_TEST_CPUS`	대기 시간 테스트를 실행하는 Pod에서 사용하는 CPU 수를 지정합니다. 변수를 설정하지 않으면 기본 구성에 모든 분리된 CPU가 포함됩니다.
`LATENCY_TEST_RUNTIME`	대기 시간 테스트를 실행해야 하는 시간(초)을 지정합니다. 기본값은 300초입니다. 참고 대기 시간 테스트가 완료되기 전에 Ginkgo 2.0 테스트 모음이 시간 초과되지 않도록 하려면 `-ginkgo.timeout` 플래그를 `LATENCY_TEST_RUNTIME` + 2분보다 큰 값으로 설정합니다. 또한 `LATENCY_TEST_DELAY` 값을 설정하는 경우 `-ginkgo.timeout` 을 `LATENCY_TEST_RUNTIME` + `LATENCY_TEST_DELAY` + 2분보다 큰 값으로 설정해야 합니다. Ginkgo 2.0 테스트 모음의 기본 시간 초과 값은 1시간입니다.
`HWLATDETECT_MAXIMUM_LATENCY`	워크로드 및 운영 체제에 대해 마이크로초 단위로 허용되는 최대 하드웨어 대기 시간을 지정합니다. `HWLATDETECT_MAXIMUM_LATENCY` 또는 `MAXIMUM_LATENCY` 값을 설정하지 않으면 툴 자체에서 기본 예상 임계값(20 Cryostat)과 실제 최대 대기 시간을 비교합니다. 그런 다음 테스트가 실패하거나 그에 따라 성공합니다.
`CYCLICTEST_MAXIMUM_LATENCY`	`cyclictest` 실행 중에 발생하는 모든 스레드가 예상하는 최대 대기 시간을 지정합니다. `CYCLICTEST_MAXIMUM_LATENCY` 또는 `MAXIMUM_LATENCY` 의 값을 설정하지 않으면 이 툴은 예상 값과 실제 최대 대기 시간의 비교를 건너뜁니다.
`OSLAT_MAXIMUM_LATENCY`	`oslat` 테스트 결과에 대해 마이크로초 단위로 허용되는 최대 대기 시간을 지정합니다. `OSLAT_MAXIMUM_LATENCY` 또는 `MAXIMUM_LATENCY` 값을 설정하지 않으면 이 툴은 예상 값과 실제 최대 대기 시간의 비교를 건너뜁니다.
`MAXIMUM_LATENCY`	마이크로초 단위로 허용되는 최대 대기 시간을 지정하는 통합 변수입니다. 사용 가능한 모든 대기 시간 툴에 적용됩니다.

참고

대기 시간 툴과 관련된 변수가 통합 변수보다 우선합니다. 예를 들어 OSLAT_MAXIMUM_LATENCY 가 30 마이크로초로 설정되고 MAXIMUM_LATENCY 가 10 마이크로초로 설정된 경우 oslat 테스트는 최대 허용 가능한 대기 시간으로 30 마이크로초의 최대 허용 대기 시간으로 실행됩니다.

12.5.3. 대기 시간 테스트 실행

클러스터 대기 시간 테스트를 실행하여 CNF(클라우드 네이티브 네트워크 기능) 워크로드에 대한 노드 튜닝을 검증합니다.

참고

root가 아니거나 권한이 없는 사용자로 podman 명령을 실행하는 경우 마운트 경로가 권한 거부 오류로 인해 실패할 수 있습니다. podman 명령이 작동하도록 하려면 볼륨 생성에 :Z 를 추가합니다(예: -v $(pwd)/:/kubeconfig:Z. 이렇게 하면 podman 에서 적절한 SELinux 레이블을 다시 지정할 수 있습니다.

프로세스

kubeconfig 파일이 포함된 디렉터리에서 쉘 프롬프트를 엽니다.
현재 디렉터리에 kubeconfig 파일과 볼륨을 통해 마운트된 관련 $KUBECONFIG 환경 변수가 테스트 이미지를 제공합니다. 이렇게 하면 실행 중인 컨테이너에서 컨테이너 내부에서 kubeconfig 파일을 사용할 수 있습니다.

다음 명령을 입력하여 대기 시간 테스트를 실행합니다.

$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUNTIME=<time_in_seconds>\
-e MAXIMUM_LATENCY=<time_in_microseconds> \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.15 /usr/bin/test-run.sh \
--ginkgo.v --ginkgo.timeout="24h"

선택 사항: Append --ginkgo.dryRun 플래그는 시험 실행 모드에서 대기 시간 테스트를 실행합니다. 이 기능은 테스트가 실행되는 명령을 확인하는 데 유용합니다.
선택 사항: Append --ginkgo.v 플래그는 상세 정보 표시가 증가하여 테스트를 실행합니다.
선택 사항: 대기 시간 테스트가 완료되기 전에 Ginkgo 2.0 테스트 모음이 시간 초과되지 않도록 하려면 Append --ginkgo.timeout="24h" 플래그가 있습니다.
중요
각 테스트의 기본 런타임은 300초입니다. 유효한 대기 시간 테스트 결과의 경우 LATENCY_TEST_RUNTIME 변수를 업데이트하여 최소 12시간 동안 테스트를 실행합니다.

12.5.3.1. hwlatdetect 실행

hwlatdetect 툴은 RHEL(Red Hat Enterprise Linux) 9.x의 일반 서브스크립션과 함께 rt-kernel 패키지에서 사용할 수 있습니다.

참고

사전 요구 사항

클러스터에 실시간 커널이 설치되어 있습니다.
고객 포털 인증 정보를 사용하여 registry.redhat.io 에 로그인했습니다.

프로세스

hwlatdetect 테스트를 실행하려면 다음 명령을 실행하여 변수 값을 적절하게 대체합니다.

$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.15 \
/usr/bin/test-run.sh --ginkgo.focus="hwlatdetect" --ginkgo.v --ginkgo.timeout="24h"

hwlatdetect 테스트는 10분(600초) 동안 실행됩니다. 관찰된 최대 대기 시간이 MAXIMUM_LATENCY (20 Cryostat)보다 작으면 테스트가 성공적으로 실행됩니다.

결과가 대기 시간 임계값을 초과하면 테스트가 실패합니다.

중요

유효한 결과를 위해 테스트는 최소 12시간 동안 실행되어야 합니다.

실패 출력 예

running /usr/bin/cnftests -ginkgo.v -ginkgo.focus=hwlatdetect
I0908 15:25:20.023712      27 request.go:601] Waited for 1.046586367s due to client-side throttling, not priority and fairness, request: GET:https://api.hlxcl6.lab.eng.tlv2.redhat.com:6443/apis/imageregistry.operator.openshift.io/v1?timeout=32s
Running Suite: CNF Features e2e integration tests
=================================================
Random Seed: 1662650718
Will run 1 of 3 specs

[...]

• Failure [283.574 seconds]
[performance] Latency Test
/remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:62
  with the hwlatdetect image
  /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:228
    should succeed [It]
    /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:236

    Log file created at: 2022/09/08 15:25:27
    Running on machine: hwlatdetect-b6n4n
    Binary: Built with gc go1.17.12 for linux/amd64
    Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
    I0908 15:25:27.160620       1 node.go:39] Environment information: /proc/cmdline: BOOT_IMAGE=(hd1,gpt3)/ostree/rhcos-c6491e1eedf6c1f12ef7b95e14ee720bf48359750ac900b7863c625769ef5fb9/vmlinuz-4.18.0-372.19.1.el8_6.x86_64 random.trust_cpu=on console=tty0 console=ttyS0,115200n8 ignition.platform.id=metal ostree=/ostree/boot.1/rhcos/c6491e1eedf6c1f12ef7b95e14ee720bf48359750ac900b7863c625769ef5fb9/0 ip=dhcp root=UUID=5f80c283-f6e6-4a27-9b47-a287157483b2 rw rootflags=prjquota boot=UUID=773bf59a-bafd-48fc-9a87-f62252d739d3 skew_tick=1 nohz=on rcu_nocbs=0-3 tuned.non_isolcpus=0000ffff,ffffffff,fffffff0 systemd.cpu_affinity=4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79 intel_iommu=on iommu=pt isolcpus=managed_irq,0-3 nohz_full=0-3 tsc=nowatchdog nosoftlockup nmi_watchdog=0 mce=off skew_tick=1 rcutree.kthread_prio=11 + +
    I0908 15:25:27.160830       1 node.go:46] Environment information: kernel version 4.18.0-372.19.1.el8_6.x86_64
    I0908 15:25:27.160857       1 main.go:50] running the hwlatdetect command with arguments [/usr/bin/hwlatdetect --threshold 1 --hardlimit 1 --duration 100 --window 10000000us --width 950000us]
    F0908 15:27:10.603523       1 main.go:53] failed to run hwlatdetect command; out: hwlatdetect:  test duration 100 seconds
       detector: tracer
       parameters:
            Latency threshold: 1us 1
            Sample window:     10000000us
            Sample width:      950000us
         Non-sampling period:  9050000us
            Output File:       None

    Starting test
    test finished
    Max Latency: 326us 2
    Samples recorded: 5
    Samples exceeding threshold: 5
    ts: 1662650739.017274507, inner:6, outer:6
    ts: 1662650749.257272414, inner:14, outer:326
    ts: 1662650779.977272835, inner:314, outer:12
    ts: 1662650800.457272384, inner:3, outer:9
    ts: 1662650810.697273520, inner:3, outer:2

[...]

JUnit report was created: /junit.xml/cnftests-junit.xml


Summarizing 1 Failure:

[Fail] [performance] Latency Test with the hwlatdetect image [It] should succeed
/remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:476

Ran 1 of 194 Specs in 365.797 seconds
FAIL! -- 0 Passed | 1 Failed | 0 Pending | 2 Skipped
--- FAIL: TestTest (366.08s)
FAIL

1: MAXIMUM_LATENCY 또는 HWLATDETECT_MAXIMUM_LATENCY 환경 변수를 사용하여 대기 시간 임계값을 구성할 수 있습니다.
2: 테스트 중에 측정된 최대 대기 시간 값입니다.

hwlatdetect 테스트 결과 예

다음 유형의 결과를 캡처할 수 있습니다.

테스트 전체에서 수행된 변경 사항에 영향을 미치는 기록을 생성하기 위해 각 실행 후에 수집된 대략적인 결과.
최상의 결과 및 구성 설정과 함께 대략적인 테스트 세트입니다.

좋은 결과의 예

hwlatdetect: test duration 3600 seconds
detector: tracer
parameters:
Latency threshold: 10us
Sample window: 1000000us
Sample width: 950000us
Non-sampling period: 50000us
Output File: None

Starting test
test finished
Max Latency: Below threshold
Samples recorded: 0

hwlatdetect 툴은 샘플이 지정된 임계값을 초과하는 경우에만 출력을 제공합니다.

잘못된 결과의 예

hwlatdetect: test duration 3600 seconds
detector: tracer
parameters:Latency threshold: 10usSample window: 1000000us
Sample width: 950000usNon-sampling period: 50000usOutput File: None

Starting tests:1610542421.275784439, inner:78, outer:81
ts: 1610542444.330561619, inner:27, outer:28
ts: 1610542445.332549975, inner:39, outer:38
ts: 1610542541.568546097, inner:47, outer:32
ts: 1610542590.681548531, inner:13, outer:17
ts: 1610543033.818801482, inner:29, outer:30
ts: 1610543080.938801990, inner:90, outer:76
ts: 1610543129.065549639, inner:28, outer:39
ts: 1610543474.859552115, inner:28, outer:35
ts: 1610543523.973856571, inner:52, outer:49
ts: 1610543572.089799738, inner:27, outer:30
ts: 1610543573.091550771, inner:34, outer:28
ts: 1610543574.093555202, inner:116, outer:63

hwlatdetect 의 출력은 여러 샘플이 임계값을 초과했음을 보여줍니다. 그러나 동일한 출력은 다음 요인에 따라 다른 결과를 나타낼 수 있습니다.

테스트 기간
CPU 코어 수
호스트 펌웨어 설정

주의

다음 대기 시간 테스트를 진행하기 전에 hwlatdetect 에서 보고한 대기 시간이 필요한 임계값을 충족하는지 확인합니다. 하드웨어에 의해 도입된 대기 시간을 수정하려면 시스템 벤더 지원에 문의해야 할 수 있습니다.

모든 대기 시간 급증이 하드웨어와 관련된 것은 아닙니다. 워크로드 요구 사항을 충족하도록 호스트 펌웨어를 조정해야 합니다. 자세한 내용은 시스템 튜닝의 펌웨어 매개변수 설정을 참조하십시오.

12.5.3.2. cyclictest 실행

cyclictest 툴은 지정된 CPU에서 실시간 커널 스케줄러 대기 시간을 측정합니다.

참고

사전 요구 사항

고객 포털 인증 정보를 사용하여 registry.redhat.io 에 로그인했습니다.
클러스터에 실시간 커널이 설치되어 있습니다.
Node Tuning Operator를 사용하여 클러스터 성능 프로필을 적용했습니다.

프로세스

cyclictest 를 수행하려면 다음 명령을 실행하여 변수 값을 적절하게 대체합니다.

$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.15 \
/usr/bin/test-run.sh --ginkgo.focus="cyclictest" --ginkgo.v --ginkgo.timeout="24h"

명령은 10분(600초) 동안 cyclictest 툴을 실행합니다. 관찰된 최대 대기 시간이 MAXIMUM_LATENCY 보다 작으면 테스트가 성공적으로 실행됩니다(이 예에서는 20 Cryostat). 20 Cryostat 이상으로 급증하는 대기 시간은 일반적으로 telco RAN 워크로드에는 허용되지 않습니다.

결과가 대기 시간 임계값을 초과하면 테스트가 실패합니다.

중요

유효한 결과를 위해 테스트는 최소 12시간 동안 실행되어야 합니다.

실패 출력 예

running /usr/bin/cnftests -ginkgo.v -ginkgo.focus=cyclictest
I0908 13:01:59.193776      27 request.go:601] Waited for 1.046228824s due to client-side throttling, not priority and fairness, request: GET:https://api.compute-1.example.com:6443/apis/packages.operators.coreos.com/v1?timeout=32s
Running Suite: CNF Features e2e integration tests
=================================================
Random Seed: 1662642118
Will run 1 of 3 specs

[...]

Summarizing 1 Failure:

[Fail] [performance] Latency Test with the cyclictest image [It] should succeed
/remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:220

Ran 1 of 194 Specs in 161.151 seconds
FAIL! -- 0 Passed | 1 Failed | 0 Pending | 2 Skipped
--- FAIL: TestTest (161.48s)
FAIL

cyclictest 결과 예

동일한 출력은 워크로드마다 다른 결과를 나타낼 수 있습니다. 예를 들어 4G DU 워크로드에는 최대 18 Cryostats의 급증이 허용되지만 5G DU 워크로드에서는 허용되지 않습니다.

좋은 결과의 예

running cmd: cyclictest -q -D 10m -p 1 -t 16 -a 2,4,6,8,10,12,14,16,54,56,58,60,62,64,66,68 -h 30 -i 1000 -m
# Histogram
000000 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000001 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000002 579506   535967  418614  573648  532870  529897  489306  558076  582350  585188  583793  223781  532480  569130  472250  576043
More histogram entries ...
# Total: 000600000 000600000 000600000 000599999 000599999 000599999 000599998 000599998 000599998 000599997 000599997 000599996 000599996 000599995 000599995 000599995
# Min Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Avg Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Max Latencies: 00005 00005 00004 00005 00004 00004 00005 00005 00006 00005 00004 00005 00004 00004 00005 00004
# Histogram Overflows: 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000
# Histogram Overflow at cycle number:
# Thread 0:
# Thread 1:
# Thread 2:
# Thread 3:
# Thread 4:
# Thread 5:
# Thread 6:
# Thread 7:
# Thread 8:
# Thread 9:
# Thread 10:
# Thread 11:
# Thread 12:
# Thread 13:
# Thread 14:
# Thread 15:

잘못된 결과의 예

running cmd: cyclictest -q -D 10m -p 1 -t 16 -a 2,4,6,8,10,12,14,16,54,56,58,60,62,64,66,68 -h 30 -i 1000 -m
# Histogram
000000 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000001 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000002 564632   579686  354911  563036  492543  521983  515884  378266  592621  463547  482764  591976  590409  588145  589556  353518
More histogram entries ...
# Total: 000599999 000599999 000599999 000599997 000599997 000599998 000599998 000599997 000599997 000599996 000599995 000599996 000599995 000599995 000599995 000599993
# Min Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Avg Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Max Latencies: 00493 00387 00271 00619 00541 00513 00009 00389 00252 00215 00539 00498 00363 00204 00068 00520
# Histogram Overflows: 00001 00001 00001 00002 00002 00001 00000 00001 00001 00001 00002 00001 00001 00001 00001 00002
# Histogram Overflow at cycle number:
# Thread 0: 155922
# Thread 1: 110064
# Thread 2: 110064
# Thread 3: 110063 155921
# Thread 4: 110063 155921
# Thread 5: 155920
# Thread 6:
# Thread 7: 110062
# Thread 8: 110062
# Thread 9: 155919
# Thread 10: 110061 155919
# Thread 11: 155918
# Thread 12: 155918
# Thread 13: 110060
# Thread 14: 110060
# Thread 15: 110059 155917

12.5.3.3. oslat 실행

oslat 테스트는 CPU 집약적인 DPDK 애플리케이션을 시뮬레이션하고 모든 중단 및 중단을 측정하여 클러스터가 CPU 과도한 데이터 처리를 처리하는 방법을 테스트합니다.

참고

사전 요구 사항

고객 포털 인증 정보를 사용하여 registry.redhat.io 에 로그인했습니다.
Node Tuning Operator를 사용하여 클러스터 성능 프로필을 적용했습니다.

프로세스

oslat 테스트를 수행하려면 다음 명령을 실행하여 변수 값을 적절하게 대체합니다.

$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.15 \
/usr/bin/test-run.sh --ginkgo.focus="oslat" --ginkgo.v --ginkgo.timeout="24h"

LATENCY_TEST_CPUS 는 oslat 명령으로 테스트할 CPU 수를 지정합니다.

명령은 10분(600초) 동안 oslat 툴을 실행합니다. 관찰된 최대 대기 시간이 MAXIMUM_LATENCY (20 Cryostat)보다 작으면 테스트가 성공적으로 실행됩니다.

결과가 대기 시간 임계값을 초과하면 테스트가 실패합니다.

중요

유효한 결과를 위해 테스트는 최소 12시간 동안 실행되어야 합니다.

실패 출력 예

running /usr/bin/cnftests -ginkgo.v -ginkgo.focus=oslat
I0908 12:51:55.999393      27 request.go:601] Waited for 1.044848101s due to client-side throttling, not priority and fairness, request: GET:https://compute-1.example.com:6443/apis/machineconfiguration.openshift.io/v1?timeout=32s
Running Suite: CNF Features e2e integration tests
=================================================
Random Seed: 1662641514
Will run 1 of 3 specs

[...]

• Failure [77.833 seconds]
[performance] Latency Test
/remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:62
  with the oslat image
  /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:128
    should succeed [It]
    /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:153

    The current latency 304 is bigger than the expected one 1 : 1

[...]

Summarizing 1 Failure:

[Fail] [performance] Latency Test with the oslat image [It] should succeed
/remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:177

Ran 1 of 194 Specs in 161.091 seconds
FAIL! -- 0 Passed | 1 Failed | 0 Pending | 2 Skipped
--- FAIL: TestTest (161.42s)
FAIL

1: 이 예에서 측정된 대기 시간은 허용되는 최대값을 벗어납니다.

12.5.4. 대기 시간 테스트 실패 보고서 생성

다음 절차를 사용하여 JUnit 대기 시간 테스트 출력 및 테스트 실패 보고서를 생성합니다.

사전 요구 사항

OpenShift CLI(oc)가 설치되어 있습니다.
cluster-admin 권한이 있는 사용자로 로그인했습니다.

프로세스

--report 매개변수를 보고서가 덤프되는 위치에 경로를 전달하여 문제 해결을 위한 클러스터 상태 및 리소스에 대한 정보를 사용하여 테스트 실패 보고서를 생성합니다.
```
$ podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/reportdest:<report_folder_path> \
-e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.15 \
/usr/bin/test-run.sh --report <report_folder_path> --ginkgo.v
```
다음과 같습니다.
<report_folder_path>
보고서가 생성되는 폴더의 경로입니다.Is the path to the folder where the report is generated.

12.5.5. JUnit 대기 시간 테스트 보고서 생성

다음 절차를 사용하여 JUnit 대기 시간 테스트 출력 및 테스트 실패 보고서를 생성합니다.

사전 요구 사항

OpenShift CLI(oc)가 설치되어 있습니다.
cluster-admin 권한이 있는 사용자로 로그인했습니다.

프로세스

--junit 매개변수를 보고서가 덤프되는 위치와 함께 전달하여 JUnit 호환 XML 보고서를 생성합니다.
참고
이 명령을 실행하기 전에 junit 폴더를 생성해야 합니다.
```
$ podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/junit:/junit \
-e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.15 \
/usr/bin/test-run.sh --ginkgo.junit-report junit/<file-name>.xml --ginkgo.v
```
다음과 같습니다.
JUnit
junit 보고서가 저장되는 폴더입니다.

12.5.6. 단일 노드 OpenShift 클러스터에서 대기 시간 테스트 실행

단일 노드 OpenShift 클러스터에서 대기 시간 테스트를 실행할 수 있습니다.

참고

사전 요구 사항

OpenShift CLI(oc)가 설치되어 있습니다.
cluster-admin 권한이 있는 사용자로 로그인했습니다.
Node Tuning Operator를 사용하여 클러스터 성능 프로필을 적용했습니다.

프로세스

단일 노드 OpenShift 클러스터에서 대기 시간 테스트를 실행하려면 다음 명령을 실행합니다.
```
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUNTIME=<time_in_seconds> registry.redhat.io/openshift4/cnf-tests-rhel8:v4.15 \
/usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"
```
참고
각 테스트의 기본 런타임은 300초입니다. 유효한 대기 시간 테스트 결과의 경우 LATENCY_TEST_RUNTIME 변수를 업데이트하여 최소 12시간 동안 테스트를 실행합니다. 버킷 대기 시간 검증 단계를 실행하려면 최대 대기 시간을 지정해야 합니다. 최대 대기 시간 변수에 대한 자세한 내용은 "레이턴 시간 측정" 섹션의 표를 참조하십시오.
테스트 모음을 실행한 후에는 모든 무위 리소스가 정리됩니다.

12.5.7. 연결이 끊긴 클러스터에서 대기 시간 테스트 실행

CNF 테스트 이미지는 외부 레지스트리에 연결할 수 없는 연결이 끊긴 클러스터에서 테스트를 실행할 수 있습니다. 여기에는 다음 두 단계가 필요합니다.

cnf-tests 이미지를 사용자 정의 연결이 끊긴 레지스트리에 미러링합니다.
사용자 정의 연결이 끊긴 레지스트리의 이미지를 사용하도록 테스트에 지시합니다.

클러스터에서 액세스할 수 있는 사용자 정의 레지스트리로 이미지 미러링

oc 에서 테스트 이미지를 로컬 레지스트리에 미러링 하는 데 필요한 입력을 제공하기 위해 이미지에 미러 실행 파일이 제공됩니다.

클러스터 및 registry.redhat.io 에 액세스할 수 있는 중간 머신에서 이 명령을 실행합니다.
```
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.15 \
/usr/bin/mirror -registry <disconnected_registry> | oc image mirror -f -
```
다음과 같습니다.
<disconnected_registry>
구성한 연결이 끊긴 미러 레지스트리입니다(예: my.local.registry:5000/ ).

cnf-tests 이미지를 연결이 끊긴 레지스트리에 미러링한 경우 테스트를 실행할 때 이미지를 가져오는 데 사용되는 원래 레지스트리를 재정의해야 합니다. 예를 들면 다음과 같습니다.

podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e IMAGE_REGISTRY="<disconnected_registry>" \
-e CNF_TESTS_IMAGE="cnf-tests-rhel8:v4.15" \
-e LATENCY_TEST_RUNTIME=<time_in_seconds> \
<disconnected_registry>/cnf-tests-rhel8:v4.15 /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"

사용자 정의 레지스트리의 이미지를 사용하도록 테스트 구성

CNF_TESTS_IMAGE 및 IMAGE_REGISTRY 변수를 사용하여 사용자 정의 테스트 이미지 및 이미지 레지스트리를 사용하여 대기 시간 테스트를 실행할 수 있습니다.

사용자 정의 테스트 이미지 및 이미지 레지스트리를 사용하도록 대기 시간 테스트를 구성하려면 다음 명령을 실행합니다.
```
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e IMAGE_REGISTRY="<custom_image_registry>" \
-e CNF_TESTS_IMAGE="<custom_cnf-tests_image>" \
-e LATENCY_TEST_RUNTIME=<time_in_seconds> \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.15 /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"
```
다음과 같습니다.
<custom_image_registry>
사용자 지정 이미지 레지스트리입니다(예: custom.registry:5000/ ).
<custom_cnf-tests_image>
사용자 지정 cnf-tests 이미지입니다(예: custom-cnf-tests-image:latest ).

클러스터 OpenShift 이미지 레지스트리에 이미지 미러링

OpenShift Container Platform은 클러스터에서 표준 워크로드로 실행되는 내장 컨테이너 이미지 레지스트리를 제공합니다.

프로세스

경로를 통해 레지스트리를 공개하여 레지스트리에 대한 외부 액세스 권한을 얻습니다.

$ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge

다음 명령을 실행하여 레지스트리 끝점을 가져옵니다.

$ REGISTRY=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')

이미지를 공개하는 데 사용할 네임스페이스를 생성합니다.
```
$ oc create ns cnftests
```
테스트에 사용되는 모든 네임스페이스에서 이미지 스트림을 사용할 수 있도록 합니다. 테스트 네임스페이스가 cnf-tests 이미지 스트림에서 이미지를 가져올 수 있도록 하려면 이 작업이 필요합니다. 다음 명령을 실행합니다.
```
$ oc policy add-role-to-user system:image-puller system:serviceaccount:cnf-features-testing:default --namespace=cnftests
```
```
$ oc policy add-role-to-user system:image-puller system:serviceaccount:performance-addon-operators-testing:default --namespace=cnftests
```

다음 명령을 실행하여 Docker 보안 이름 및 인증 토큰을 검색합니다.

$ SECRET=$(oc -n cnftests get secret | grep builder-docker | awk {'print $1'}

$ TOKEN=$(oc -n cnftests get secret $SECRET -o jsonpath="{.data['\.dockercfg']}" | base64 --decode | jq '.["image-registry.openshift-image-registry.svc:5000"].auth')

dockerauth.json 파일을 생성합니다. 예를 들면 다음과 같습니다.

$ echo "{\"auths\": { \"$REGISTRY\": { \"auth\": $TOKEN } }}" > dockerauth.json

이미지 미러링을 수행합니다.

$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
registry.redhat.io/openshift4/cnf-tests-rhel8:4.15 \
/usr/bin/mirror -registry $REGISTRY/cnftests |  oc image mirror --insecure=true \
-a=$(pwd)/dockerauth.json -f -

테스트를 실행합니다.

$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUNTIME=<time_in_seconds> \
-e IMAGE_REGISTRY=image-registry.openshift-image-registry.svc:5000/cnftests cnf-tests-local:latest /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"

다른 테스트 이미지 세트 미러링

필요한 경우 대기 시간 테스트에 미러링된 기본 업스트림 이미지를 변경할 수 있습니다.

프로세스

mirror 명령은 기본적으로 업스트림 이미지를 미러링하려고 합니다. 다음 형식의 파일을 이미지에 전달하여 재정의할 수 있습니다.
```
[
    {
        "registry": "public.registry.io:5000",
        "image": "imageforcnftests:4.15"
    }
]
```

파일을 mirror 명령에 전달합니다. 예를 들어 images.json 으로 로컬로 저장하십시오. 다음 명령을 사용하면 로컬 경로가 컨테이너 내 /kubeconfig에 마운트되어 mirror 명령에 전달될 수 있습니다.

$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.15 /usr/bin/mirror \
--registry "my.local.registry:5000/" --images "/kubeconfig/images.json" \
|  oc image mirror -f -

12.5.8. cnf-tests 컨테이너를 사용한 오류 문제 해결

대기 시간 테스트를 실행하려면 cnf-tests 컨테이너 내에서 클러스터에 액세스할 수 있어야 합니다.

사전 요구 사항

OpenShift CLI(oc)가 설치되어 있습니다.
cluster-admin 권한이 있는 사용자로 로그인했습니다.

프로세스

다음 명령을 실행하여 cnf-tests 컨테이너 내부에서 클러스터에 액세스할 수 있는지 확인합니다.
```
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.15 \
oc get nodes
```
이 명령이 작동하지 않으면 DNS, MTU 크기 또는 방화벽 액세스 전반에 걸쳐 발생하는 오류가 발생할 수 있습니다.

12.5. 플랫폼 확인을 위한 대기 시간 테스트 수행

12.5.1. 대기 시간 테스트 실행을 위한 사전 요구 사항

12.5.2. 대기 시간 측정

12.5.3. 대기 시간 테스트 실행

12.5.3.1. hwlatdetect 실행

hwlatdetect 테스트 결과 예

12.5.3.2. cyclictest 실행

cyclictest 결과 예

12.5.3.3. oslat 실행

12.5.4. 대기 시간 테스트 실패 보고서 생성

12.5.5. JUnit 대기 시간 테스트 보고서 생성

12.5.6. 단일 노드 OpenShift 클러스터에서 대기 시간 테스트 실행

12.5.7. 연결이 끊긴 클러스터에서 대기 시간 테스트 실행

클러스터에서 액세스할 수 있는 사용자 정의 레지스트리로 이미지 미러링

사용자 정의 레지스트리의 이미지를 사용하도록 테스트 구성

클러스터 OpenShift 이미지 레지스트리에 이미지 미러링

다른 테스트 이미지 세트 미러링

12.5.8. cnf-tests 컨테이너를 사용한 오류 문제 해결

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

Red Hat 소개

Red Hat legal and privacy links

Red Hat legal and privacy links