12.5. 为平台验证执行延迟测试

12.5.1. 运行延迟测试的先决条件

运行延迟测试前，集群必须满足以下要求：

已使用 Node Tuning Operator 配置一个性能配置集。
已在集群中应用了所有所需的 CNF 配置。
已在集群中应用了已存在的 MachineConfigPool CR。默认 worker 池为 worker-cnf。

其他资源

将工作负载调度到具有实时功能的 worker

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μs)和工具本身中实际的最大延迟。然后，测试会失败或成功。
`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. 运行延迟测试

运行集群延迟测试，以验证 Cloud-native Network Function (CNF) 工作负载的节点调整。

注意

当以非 root 用户或非特权用户执行 podman 命令时，挂载路径可能会失败，错误为 permission denied。要使 podman 命令正常工作，请将 :Z 附加到卷创建中，例如 -v $(pwd)/:/kubeconfig:Z。这允许 podman 进行正确的 SELinux 重新标记。

流程

在包含 kubeconfig 文件的目录中打开 shell 提示符。
您可以在当前目录中为测试镜像提供 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.16 /usr/bin/test-run.sh \
--ginkgo.v --ginkgo.timeout="24h"

可选：使用 --ginkgo.dryRun 标志，以 dry-run 模式运行延迟测试。这可用于检查测试会运行哪些命令。
可选：使用 --ginkgo.v 标志来运行测试并增加输出详细程度。
可选：使用 --ginkgo.timeout="24h" 标志，以确保在延迟测试完成前 Ginkgo 2.0 测试套件不会超时。
重要
每个测试的默认运行时为 300 秒。如需有效的延迟测试结果，通过更新 LATENCY_TEST_RUNTIME 变量，对至少 12 小时运行测试。

12.5.3.1. 运行 hwlatdetect

hwlatdetect 工具位于 rt-kernel 软件包中，带有常规订阅 Red Hat Enterprise Linux (RHEL) 9.x。

注意

当以非 root 用户或非特权用户执行 podman 命令时，挂载路径可能会失败，错误为 permission denied。要使 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_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.16 \
/usr/bin/test-run.sh --ginkgo.focus="hwlatdetect" --ginkgo.v --ginkgo.timeout="24h"

hwlatdetect 测试运行了 10 分钟 (600 秒)。当最观察到的延迟低于 MAXIMUM_LATENCY (20 FORWARD) 时，测试会成功运行。

如果结果超过延迟阈值，测试会失败。

重要

对于有效结果，测试应至少运行 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 上的实时内核调度程序延迟。

注意

当以非 root 用户或非特权用户执行 podman 命令时，挂载路径可能会失败，错误为 permission denied。要使 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_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.16 \
/usr/bin/test-run.sh --ginkgo.focus="cyclictest" --ginkgo.v --ginkgo.timeout="24h"

该命令运行 cyclictest 工具 10 分钟（600 秒）。当观察到的延迟低于 MAXIMUM_LATENCY 时，测试会成功运行（在本例中，20 TOKENs）。对于电信 RAN 工作负载，对 20 个以上延迟的激增通常并不能接受。

如果结果超过延迟阈值，测试会失败。

重要

对于有效结果，测试应至少运行 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 结果示例

相同的输出可能会显示不同工作负载的结果。例如，spikes 最长为 18μs 对 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.5.3.3. 运行 oslat

oslat 测试模拟 CPU 密集型 DPDK 应用程序，并测量所有中断和中断来测试集群处理 CPU 大量数据处理的方式。

注意

当以非 root 用户或非特权用户执行 podman 命令时，挂载路径可能会失败，错误为 permission denied。要使 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_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.16 \
/usr/bin/test-run.sh --ginkgo.focus="oslat" --ginkgo.v --ginkgo.timeout="24h"

LATENCY_TEST_CPUS 指定使用 oslat 命令测试的 CPU 数量。

命令运行 oslat 工具 10 分钟（600 秒）。当最观察到的延迟低于 MAXIMUM_LATENCY (20 FORWARD) 时，测试会成功运行。

如果结果超过延迟阈值，测试会失败。

重要

对于有效结果，测试应至少运行 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.16 \
/usr/bin/test-run.sh --report <report_folder_path> --ginkgo.v

其中：

<report_folder_path>: 是生成报告的文件夹的路径。

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.16 \
/usr/bin/test-run.sh --ginkgo.junit-report junit/<file-name>.xml --ginkgo.v

其中：

junit: 是存储 junit 报告的文件夹。

12.5.6. 在单节点 OpenShift 集群上运行延迟测试

您可以在单节点 OpenShift 集群上运行延迟测试。

注意

当以非 root 用户或非特权用户执行 podman 命令时，挂载路径可能会失败，错误为 permission denied。要使 podman 命令正常工作，请将 :Z 附加到卷创建中，例如 -v $(pwd)/:/kubeconfig:Z。这允许 podman 进行正确的 SELinux 重新标记。

先决条件

已安装 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.16 \
/usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"
```
注意
每个测试的默认运行时为 300 秒。如需有效的延迟测试结果，通过更新 LATENCY_TEST_RUNTIME 变量，对至少 12 小时运行测试。要运行存储桶延迟验证步骤，您必须指定最大延迟。有关最大延迟变量的详情，请查看 "Measuring latency" 部分中的表。
运行测试套件后,，清理所有悬停的资源。

12.5.7. 在断开连接的集群中运行延迟测试

CNF 测试镜像可在无法访问外部 registry 的断开连接的集群中运行测试。这需要两个步骤：

将 cnf-tests 镜像镜像到自定义断开连接的 registry。
指示测试使用来自自定义断开连接的 registry 的镜像。

将镜像镜像(mirror)到集群可访问的自定义 registry

mirror 中提供了镜像可执行文件，以提供 oc 需要的输入来镜像运行测试到本地 registry 所需的镜像。

从可访问集群和 registry.redhat.io 的中间机器运行这个命令：

$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.16 \
/usr/bin/mirror -registry <disconnected_registry> | oc image mirror -f -

其中：

<disconnected_registry>: 是您配置的断开连接的镜像 registry，如 my.local.registry:5000/。

当您将 cnf-tests 镜像 mirror 到断开连接的 registry 中时，您必须覆盖用于运行测试时用来获取镜像的原始 registry，例如：

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

配置测试以使用自定义 registry 中的镜像

您可以使用 CNF_TESTS_IMAGE 和 IMAGE_REGISTRY 变量来使用自定义测试镜像和镜像 registry 运行延迟测试。

要将延迟测试配置为使用自定义测试镜像和镜像 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.16 /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"

其中：

<custom_image_registry>: 是自定义镜像 registry，如 custom.registry:5000/。
<custom_cnf-tests_image>: 是自定义 cnf-tests 镜像，如 custom-cnf-tests-image:latest。

将镜像镜像 (mirror) 到集群 OpenShift 镜像 registry

OpenShift Container Platform 提供了一个内建的容器镜像 registry，它作为一个标准的工作负载在集群中运行。

流程

通过使用路由公开到 registry 的外部访问权限：

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

运行以下命令来获取 registry 端点：

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

创建用于公开镜像的命名空间：
```
$ oc create ns cnftests
```

使镜像流可供用于测试的所有命名空间使用。这需要允许 test 命名空间从 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 名称和 auth 令牌：

$ 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

对镜像进行 mirror：

$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
registry.redhat.io/openshift4/cnf-tests-rhel8:4.16 \
/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)

您可以选择更改对延迟测试镜像的默认上游镜像。

流程

mirror 命令默认尝试对上游镜像进行 mirror。这可以通过向镜像传递带有以下格式的文件来覆盖：
```
[
    {
        "registry": "public.registry.io:5000",
        "image": "imageforcnftests:4.16"
    }
]
```

将文件传递给 mirror 命令，例如将其在本地保存为 images.json。使用以下命令，本地路径挂载到容器内的 /kubeconfig 中，并可传递给 mirror 命令。

$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.16 /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.16 \
oc get nodes
```
如果这个命令无法正常工作，则可能会出现与跨 DNS、MTU 大小或防火墙访问相关的错误。

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. 在断开连接的集群中运行延迟测试

将镜像镜像(mirror)到集群可访问的自定义 registry

配置测试以使用自定义 registry 中的镜像

将镜像镜像 (mirror) 到集群 OpenShift 镜像 registry

对不同的测试镜像进行镜像(mirror)

12.5.8. 对 cnf-tests 容器的错误进行故障排除

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links