12.4. 대기 시간 테스트 실행

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

중요

항상 DISCOVERY_MODE=true 세트를 사용하여 대기 시간 테스트를 실행합니다. 그렇지 않은 경우 테스트 모음에서 실행 중인 클러스터 구성을 변경합니다.

참고

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

절차

  1. kubeconfig 파일이 포함된 디렉터리에서 쉘 프롬프트를 엽니다.

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

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

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e FEATURES=performance registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \
/usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"
  3. 선택 사항: Append -ginkgo.dryRun 을 사용하여 시험 실행 모드에서 대기 시간 테스트를 실행합니다. 이 명령은 테스트 실행을 확인하는 데 유용합니다.
  4. 선택 사항: Append -ginkgo.v 를 사용하여 향상된 동사를 사용하여 테스트를 실행합니다.

  5. 선택 사항: 특정 성능 프로필에 대해 대기 시간 테스트를 실행하려면 다음 명령을 실행하여 적절한 값을 대체합니다. 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUN=true -e FEATURES=performance -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
-e PERF_TEST_PROFILE=<performance_profile> registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \
/usr/bin/test-run.sh -ginkgo.focus="[performance]\ Latency\ Test"

    다음과 같습니다.

    <performance_profile>
    는 대기 시간 테스트를 실행할 성능 프로필의 이름입니다.
    중요

    유효한 대기 시간 테스트 결과의 경우 최소 12 시간 동안 테스트를 실행합니다.

12.4.1. hwlatdetect 실행

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

중요

항상 DISCOVERY_MODE=true 세트를 사용하여 대기 시간 테스트를 실행합니다. 그렇지 않은 경우 테스트 모음에서 실행 중인 클러스터 구성을 변경합니다.

참고

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

사전 요구 사항

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

절차

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

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e FEATURES=performance -e ROLE_WORKER_CNF=worker-cnf \
-e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \
/usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="hwlatdetect"

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

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

    중요

    유효한 결과를 얻으려면 테스트가 최소 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 194 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 | 193 Skipped
--- FAIL: TestTest (366.08s)
FAIL

    1
    MAXIMUM_LATENCY 또는 HWLA ONTAPTECT_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.4.2. cyclictest 실행

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

중요

항상 DISCOVERY_MODE=true 세트를 사용하여 대기 시간 테스트를 실행합니다. 그렇지 않은 경우 테스트 모음에서 실행 중인 클러스터 구성을 변경합니다.

참고

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

사전 요구 사항

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

절차

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

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e FEATURES=performance -e ROLE_WORKER_CNF=worker-cnf \
-e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \
/usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="cyclictest"

    이 명령은 cyclictest 툴을 10분(600초) 동안 실행합니다. 최대 관찰 대기 시간이 MAXIMUM_LATENCY 보다 작으면 테스트가 성공적으로 실행됩니다(이 예제에서는 20 ECDHE). 20 ECDHE 이상의 대기 시간 급증은 일반적으로 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 194 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 | 193 Skipped
--- FAIL: TestTest (161.48s)
FAIL

cyclictest 결과 예

동일한 출력은 다른 워크로드에 대한 다른 결과를 나타낼 수 있습니다. 예를 들어 최대 18ECDHE의 급증은 4G DU 워크로드에는 허용되지만 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.4.3. oslat 실행

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

중요

항상 DISCOVERY_MODE=true 세트를 사용하여 대기 시간 테스트를 실행합니다. 그렇지 않은 경우 테스트 모음에서 실행 중인 클러스터 구성을 변경합니다.

참고

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

사전 요구 사항

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

프로세스

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

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e FEATURES=performance -e ROLE_WORKER_CNF=worker-cnf \
-e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \
/usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="oslat"

    LATENCY_TEST_CPUS 는 oslat 명령으로 테스트할 CPU 목록을 지정합니다.

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

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

    중요

    유효한 결과를 얻으려면 테스트가 최소 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 194 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 | 193 Skipped
--- FAIL: TestTest (161.42s)
FAIL

    1
    이 예에서 측정된 대기 시간은 최대 허용된 값 외부에 있습니다.