ADDON OPERATOR 14.4. 置备实时和低延迟工作负载 14.5. 使用性能配置集调整节点以实现低延迟 14.6. 使用 PERFORMANCE ADDON OPERATOR 减少 NIC 队列 14.7. 调试低延迟 CNF 调整状态 14.8. 为红帽支持收集调试数据延迟 第 第 15 章 章 为 为平台 平台验证执 验证执行延 行延迟测试 迟测试 15.1. 运行延迟测试的先决条件 在技术上基于 RPS，通过增加 CPU 缓存命中率来提高数据包处理的效率。RFS 通过确定计 算最方便的 CPU，以便缓存命中更有可能在 CPU 中发生，增加了对队列长度的考虑。因此，会减少 CPU 缓存无效的频率，从而只需要较少的循环来重建缓存。这有助于缩短数据包处理运行时间。 2.3.1. 使用 Machine Config Operator (MCO) 激活 RFS 流程 流程 1. 将以下 用时的一些最佳实践。 2.6.1. 将多个队列用于您的 VirtIO 网络接口 使用多个虚拟 CPU 时，如果您为传入和传出数据包提供多个队列，则可以并行传输软件包。使用 driver 元素的 queues 属性来配置多个队列。指定一个最小为 2 的整数，该整数不超过虚拟服务器的虚拟 CPU 数量。 以下示例规格为网络接口配置两个输入和输出队列： 多个队列旨在为网络接口提供增强的性能，但也使用内存和

Hat OpenShift Logging Operator。 在以前的版本中，当 ClusterLogForwarder 具有错误配置的 secret 时，Fluentd 收集器 Pod 会 进入崩溃循环。当前发行版本解决了这个问题。现在，ClusterLogForwarder 会验证 secret，并 报告其 status 字段中的任何错误。因此，它不会导致 Fluentd 收集器 Pod 出现崩溃。 Platform 4.7 日志 日志记录 记录 20 在以前的版本中，当 ClusterLogForwarder 使用相同的 secret 具有多个输出时，fluentd 收集器 Pod 会进入崩溃循环。当前发行版本解决了这个问题。现在，多个输出可以共享一个 secret。 (BZ#1890072) 在以前的版本中，如果您删除了 Kibana 路由，Cluster Logging Operator（CLO）将无法恢复或 在以前的版本中，Cluster Logging Operator（CLO）会尝试协调 Elasticsearch 资源，这依赖于 红帽提供的 Elastic 自定义资源定义（CRD）。试图列出未知类型会导致 CLO 退出其协调循环。 这是因为 CLO 试图协调其所有受管资源，无论资源是否被定义。当前发行版本解决了这个问题。 如果用户定义了受管存储，则 CLO 只会协调 OpenShift Elasticsearch Operator

存储驱动程序。但是，如果您已在生产环境中使 用设备映射器，红帽强烈建议您对容器镜像和容器根文件系统使用精简配置。否则，始终将 overlayfs2 用 于 Docker 引擎，或将 overlayFS 用于 CRI-O。 使用循环设备可能会影响性能。虽然您仍可以继续使用它，但会记录以下警告信息： devmapper: Usage of loopback devices is strongly discouraged for SDN 使用 OpenvSwitch、虚拟可扩展 LAN(VXLAN)隧道、OpenFlow 规则和 iptables。这个 网络可以通过使用 jumbo 帧、网络接口卡（NIC）offload、多队列和 ethtool 设置来调整。 VXLAN 提供通过 VLAN 的好处，比如网络从 4096 增加到一千六百万，以及跨物理网络的第 2 层连接。 这允许服务后的所有 pod 相互通信，即使它们在不同系统中运行也是如此。 1. 这里的 pod 数量是测试 pod 的数量。实际的 pod 数量取决于应用程序的内存、CPU 和存储要 求。 2. 系统中有一些控制循环需要迭代给定命名空间中的所有对象，作为对一些状态更改的响应。在单 一命名空间中有大量给定类型的对象可使这些循环的运行成本变高，并降低对给定状态变化的处 理速度。最大值假设系统有足够的 CPU、内存和磁盘来满足应用程序要求。 3. 每个服务端口和每个服务后端在

警报。在这个版本中，修复 Prometheus 警报的作业名称解决了这个问题。 (LOG-1918) 在此次更新之前，日志收集器因为重构组件名称更改而收集自己的日志。这可能会导致收集器处 理自己的日志的潜在反馈循环，这可能会导致内存和日志消息大小问题。在这个版本中解决了这 个问题，它会从集合中排除收集器日志。(LOG-1774) 在此次更新之前，Elasticsearch 会生成错误 Unable to create 这些参数可帮助您权衡延迟和吞吐量之间的利弊。 要优化 Fluentd 的吞吐量，您可以使用这些参数通过配置较大的缓冲和队列、延迟清除以及设置 重试间隔间的更多时间来减少网络数据包的数量。请注意，大型缓冲区需要在节点文件系统有更 多空间。 要优化低延迟，您可以使用参数尽快发送数据，避免批量的构建，具有较短的队列和缓冲，并使 用更频繁的清理和重试。 您可以使用 ClusterLogging 自定义资源（CR）中的以下参数配置 每个块的最大值。当数据达到这个 大小时，Fluentd 会停止将数据写 入一个块。然后，Fluentd 将块发 送到队列并打开一个新的块。 8m 第 第 4 章 章 配置日志部署 配置日志部署 75 totalLimitSize 缓冲区的最大大小，即阶段 （stage）和队列（stage）的总大 小。如果缓冲区的大小超过这个 值，Fluentd 会停止将数据添加到 块，并显示错误失败。所有不在块

来实 现。 Jaeger Collector (Collector, Queue, Workers)- 与 Jaeger 代理类似，Jaeger Collector 接收 span，并将它们放置在内部队列中进行处理。这允许 Jaeger Collector 立即返回到客户端/代 理，而不是等待 span 变为存储。 Storage (Data Store) - 收集器需要一个持久的存储后端。Red 代理会在向客户端发送响应后收集原始遥测数据。为请求收集原始遥测所花的时间不会造成完成该 请求的总时间。但是，由于 worker 忙于处理请求，因此 worker 不会立即开始处理下一个请求。这个过程 为下一个请求的队列等待时间添加，并影响平均延迟和尾部延迟。实际的尾部延迟取决于流量模式。 在网格中，请求会绕过客户端代理，然后是服务器端代理。在 Istio 1.12.3（Istio 带有 telemetry v2）的默 Filters，为它们提供广泛的功能： 控制请求和响应的正文和标头。 对不在请求路径中的服务（如认证或策略检查）的带外 HTTP 请求。 用来相互通信的 sidechannel 数据存储和过滤器队列。 注意 注意 在创建新的 WebAsembly 扩展时，请使用 WasmPlugin API。ServiceMeshExtension API 从 Red Hat OpenShift Service

bd 存储类在使用 Red Hat Ceph Storage 的集群上实时迁移虚拟机。 更新至 OpenShift Virtualization 4.10.5 会导致一些虚拟机(VM)处于实时迁移循环中。如果虚拟机 清单中的 spec.volumes.containerDisk.path 字段设置为相对路径，会出现这种情况。 作为临时解决方案，删除并重新创建 VM 清单，将 spec.volumes 扩展 SELINUX 策略 virt-launcher Pod 的 container_t SELinux 策略被扩展来启用 OpenShift Virtualization 的基本功能。 网络多队列需要以下策略，它可在可用 vCPU 数量增加时扩展网络性能： allow process self (tun_socket (relabelfrom relabelto attach_queue)) 和持久性卷声明（PVC）规格中指定 volumeMode: Block 来置备。 8.16.3.4. 创建本地 建本地块持久性卷 持久性卷 通过填充文件并将其挂载为循环设备，在节点上创建本地块持久性卷（PV）。然后，您可以在 PV 清单中 将该循环设备作为 Block（ （块 块） ）卷引用，并将其用作虚拟机镜像的块设备。 流程 流程 1. 以 root 身份登录节点，在其上创建本地 PV。本流程以

在要管理的应用程序的同一主机上。这通常是通过如 Kubernetes 等容器环境中的 sidecar 来实现 的。 Jaeger Collector （Que,Weue）- 与代理类似，该收集器可以接收 span，并将其放入内部队列 以便进行处理。这允许收集器立即返回到客户端/代理，而不需要等待 span 进入存储。 Storage (Data Store) - 收集器需要一个持久的存储后端。Jaeger 带有一个可插入的机制用于 LE_CACHE_ENTRIE S_MAX 在任何时间可以保存在缓 存中的最大项目数。设为 0 会禁用缓存 有效数量 1000 PARAM_THREESCA LE_CACHE_REFRES H_RETRIES 在缓存更新循环中检索无 法访问的主机的次数 有效数量 1 PARAM_THREESCALE_METRICS_PORT: 8080 PARAM_THREESCALE_CACHE_TTL_SECONDS:

确保部署大小与 Memcached CR spec 指定的大小相同。 使用 memcached Pod 的名称更新 Memcached CR 状态。 下面的小节解释了示例中的控制器如何监视资源以及如何触发协调循环。您可以跳过这些小节来直接进 入运行 Operator。 }, Spec: for(&cachev1.Memcached{}) 将 Memcached 类型指定为要监视的主要资源。对于 Memcached 类型的 每个 Add、Update 或 Delete 事件，协调循环都会为该 Memcached 对象发送一个协调 Request 参数， 其中包括命名空间和名称键。 owns(&appsv1.Deployment{}) 将 Deployment 类型指定为要监视的辅助资源。对于 类型来更改监视事件转换方式以协调协调循环的请求。对于比主和从属资源更 复杂的 Operator 关系，您可以使用 EnqueueRequestsFromMapFunc 处理程序将监控事件转 换为一组任意协调请求。 有关这些配置和其他配置的详情，请参阅上游 Builder 和 Controller GoDocs。 5.3.2.4.3. 协调循 循环 每个控制器都有一个协调器对象，它带有实现了协调循环的 Reconcile()

来实 现。 Jaeger Collector (Collector, Queue, Workers)- 与 Jaeger 代理类似，Jaeger Collector 接收 span，并将它们放置在内部队列中进行处理。这允许 Jaeger Collector 立即返回到客户端/代 理，而不是等待 span 变为存储。 Storage (Data Store) - 收集器需要一个持久的存储后端。Red Collector 的配置选 项。 options: collector: num-workers: 从队列中拉取的 worker 数量。 整数，如 50。 options: collector: queue-size: Collector 队列的大小。 整数，如 2000。 options: kafka: producer: topic: ES 批量 批量处 处理器配置参数 理器配置参数 参数 参数 描述 描述 值 值 默 默认值 认值 es: bulk: actions: 在批量处理器决定向磁盘 提交更新前可添加到队列 的请求数。 1000 es: bulk: flush-interval: 提交批量 提交批量请 请求的 求的时间 时间. 要禁用批量处理器清除间 隔，请将其设置为零。

来实现。 Jaeger Collector (Collector, Queue, Workers)- 与 Jaeger 代理类似，Jaeger Collector 接收 span，并将它们放置在内部队列中进行处理。这允许 Jaeger Collector 立即返回到客户端/代 理，而不是等待 span 变为存储。 Storage (Data Store) - 收集器需要一个持久的存储后端。Red Collector 的配置选 项。 options: collector: num-workers: 从队列中拉取的 worker 数量。 整数，如 50。 options: collector: queue-size: Collector 队列的大小。 整数，如 2000。 options: kafka: producer: topic: Platform 4.14 分布式追踪 分布式追踪 58 参数 参数 描述 描述 值 值 默 默认值 认值 es: bulk: actions: 在批量处理器决定向磁盘 提交更新前可添加到队列 的请求数。 1000 es: bulk: flush-interval: 提交批量 提交批量请 请求的 求的时间 时间. 要禁用批量处理器清除间 隔，请将其设置为零。