3.4. Red Hat OpenStack Platform 17.1.1 维护发行版本 - 2023 年 9 月 20 日

在这个版本中，在替换 bootstrap Controller 节点后对 OVN 数据库操作进行负面影响。在此次更新之前，您无法使用原始 bootstrap Controller 节点主机名和 IP 地址替换 Controller 节点，因为名称重复使用会导致 OVN 数据库 RAFT 集群出现问题。

现在，您可以将原始主机名和 IP 地址用于替换 Controller 节点。

在此次更新之前，在使用带有 OVN 服务供应商驱动程序的负载均衡服务(octavia)的 RHOSP 17.1 环境中，负载均衡器健康检查浮动 IP 地址(FIP)没有正确填充协议端口。对 FIP 的请求被错误地分发到位于"ERROR"状态中的负载均衡器成员。

在这个版本中，这个问题已被解决，对浮动 IP 地址(FIP)的任何新的负载均衡器健康检查都会使用协议端口正确填充。如果在部署此更新前创建了健康监控器，您必须重新创建它们来解决这个问题。

在 RHOSP 17.1.1 中，tripleo_frr_bgp_peers 角色特定参数现在可以用来为 Free Range Routing (FRR)指定 IP 地址或主机名来对等参数。

示例

  ControllerRack1ExtraGroupVars:
    tripleo_frr_bgp_peers: ["172.16.0.1", "172.16.0.2"]

此发行版本包括可选功能的技术预览，可用于定义自定义路由器类别，并使用自定义路由器类型创建路由器。

如需更多信息，请参阅使用路由器类型创建自定义虚拟路由器。

如果您在迁移到 OVN 机制驱动程序的过程中使用 IPv6 连接到实例，则当 ML2/OVS 服务停止时，与实例的连接可能会延迟到几分钟。

在迁移到 OVN 机制驱动程序时，IPv6 的路由器广告守护进程 radvd 会停止。在停止 radvd 时，路由器公告将不再广播。这个广播中断会导致实例连接在 IPv6 上丢失。新 ML2/OVN 服务启动后，会自动恢复 IPv6 通信。

临时解决方案： 要避免潜在的中断，请使用 IPv4。

在 RHOSP 17.1.1 中，director 不允许自动配置 NS 记录以匹配父的 NS 记录。临时解决方案：在以后的发行版本中提供了自动临时解决方案，管理员可以手动更改位于 undercloud 的 /usr/share/ansible/roles/designate_bind_pool/templates/ 中的编排服务(heat)模板文件。在 Jinja 模板( pool.yaml.j2) 中，在包含 ns_records 的行后删除代码，直到下一个空行（行 13-16）），并为其基础架构插入适当的值。最后，管理员应重新部署 overcloud。

示例

  ns_records:
    - hostname: ns1.desiexample.com
      priority: 1
    - hostname: ns2.desiexample.com
      priority: 2

在使用 BGP 动态路由的 RHOSP 17.1 环境中，目前存在一个已知问题：浮动 IP (FIP)端口转发失败。

配置 FIP 端口转发时，发送到带有与 FIP 相等的目标 IP 的特定目标端口的数据包将从 RHOSP 网络服务(neutron)端口重定向到内部 IP。无论使用的协议是什么，都会出现这种情况：TCP、UDP 等。

配置 BGP 动态路由时，不公开执行 FIP 端口转发的路由，这些数据包无法访问其最终目的地。

目前，还没有临时解决方案。

在 RHOSP 17.1.1 中，在新部署中存在一个已知问题：当 代理通知服务 初始化时，RHOSP Identity 服务(keystone)通常不可用。这可防止 ceilometer 发现 gnocchi 端点。因此，指标不会发送到 gnocchi。

临时解决方案：重启 Controller 节点上的 agent-notification 服务：

$ sudo systemctl restart tripleo_ceilometer_agent_notification.service

Pacemaker 控制的 ceph-nfs 资源需要一个运行时目录来存储某些进程数据。安装或升级 RHOSP 时会创建该目录。目前，重启 Controller 节点会删除目录，在 Controller 节点重启时不会恢复 ceph-nfs 服务。如果所有 Controller 节点都已重启，ceph-nfs 服务会永久失败。

临时解决方案：如果重启 Controller 节点，登录到 Controller 节点并创建 /var/run/ceph 目录：

$ mkdir -p /var/run/ceph

在所有已重新引导的 Controller 节点上重复此步骤。如果在创建目录后 ceph-nfs-pacemaker 服务已标记为失败，请从任何 Controller 节点执行以下命令：

$ pcs resource cleanup

目前，当每天 Logrotate 归档所有日志文件时，rsyslog 会停止将日志发送到 Elasticsearch。

临时解决方案：在部署过程中将 "RsyslogReopenOnTruncate: true" 添加到环境文件中，以便 Rsyslog 重新打开日志轮转上的所有日志文件。

目前，RHOSP 17.1 随 puppet-rsyslog 模块一同提供，这会导致 Director 配置 rsyslog。

临时解决方案：在部署 rsyslog 之前，在 /usr/share/openstack-tripleo-heat-templates/deployment/logging/rsyslog-container-puppet.yaml 中手动应用补丁 [1]。

[1] https://github.com/openstack/tripleo-heat-templates/commit/ce0e3a9a94a4fce84dd70b6098867db1c86477fb

在启用了 DVR 的 ML2/OVN 或 ML2/OVS 的 RHOSP 环境中，连接到不同租户网络的实例之间的 east/west 流量会产生大量到光纤。

因此，这些实例之间的数据包不仅到达运行这些实例的 Compute 节点，还到达任何其他 overcloud 节点。

这可能导致对网络的影响，这可能是安全风险，因为光纤在任何位置发送流量。

这个错误将在 FDP 以后的发行版本中解决。您不需要执行 RHOSP 更新来获取 FDP 修复。

目前，RHEL 9.2 中的 Retbleed 漏洞缓解可能会导致 Intel Skylake CPU 上使用 Data Plane Development Kit (OVS-DPDK)的 Open vSwitch 的性能下降。

只有在 BIOS 中禁用了 C-states，超线程被启用，OVS-DPDK 只使用一个给定内核的超线程时，才会发生此性能回归。

临时解决方案：将核心的超线程分配给 OVS-DPDK 或将运行 DPDK 的 SRIOV 客户机（如 NFV 配置指南中的推荐）。

缓冲区超过安全组日志条目的日志队列有时会在达到指定限制前停止接受条目。作为临时解决方案，您可以设置超过您要保存的条目数的队列长度。

您可以使用参数 NeutronOVNLoggingRateLimit 设置每秒的最大日志条目数。如果日志条目创建超过那个速率，则过量在队列中会被缓冲到您在 NeutronOVNLoggingBurstLimit 中指定的日志条目数。

这个问题在突发的第一秒中尤其明显。在较长的突发（如 60 秒）中，速率限值更大，并补偿突发限制。因此，这个问题在短的突发中具有最大比例的影响。

临时解决方案：在比目标值高的值设置 NeutronOVNLoggingBurstLimit。根据需要观察和调整。

UDP 池中的 TCP 运行状况监视器可能无法按预期工作，具体取决于 monitor 使用的端口号。另外，池成员和运行状况监视器的状态也不正确。这是因为 SELinux 规则破坏 UDP 池中特定端口号上使用 TCP 健康监控器。

临时解决方案（如果有）：当前没有临时解决方案。

带有 OVN 机制驱动程序的 RHOSP 17.1 不支持记录每个端口的流事件，或使用 网络日志 create 命令的 --target 选项。

RHOSP 17.1 支持使用 network log create 命令的 --resource 选项为每个安全组记录流事件。请参阅 RHOSP 的网络中的"Logging security group action "。

在 RHOSP 17.1 GA 中，当启用了安全基于角色的访问控制(sRBAC)时，DNS 服务(designate)会被错误配置。当前的 sRBAC 策略包含指定不正确的规则，且必须修正指定才能正常工作。可能的解决方法是在 undercloud 服务器上应用以下补丁并重新部署 overcloud：

https://review.opendev.org/c/openstack/tripleo-heat-templates/+/888159

在 RHOSP 17.1 中，有临时数据包丢失的问题，其中硬件中断请求(IRQ)会在 OVS-DPDK PMD 线程或运行 DPDK 应用程序的客户机上出现非自愿上下文切换。

此问题是在部署过程中置备大量 VF 的结果。VF 需要 IRQ，每个必须绑定到物理 CPU。当没有足够的内务 CPU 处理 IRQ 的容量时，irqbalance 无法绑定所有它们，而 IRQ 在隔离的 CPU 上进行绑定。

临时解决方案：您可以尝试一个或多个这些操作：

在运行 DNS 服务(designate)的 RHOSP 17.1 中，存在一个已知问题：如果配置更改，则不会重启 bind9 和 unbound 服务。

临时解决方案：在每个控制器上运行以下命令来手动重启容器：

$ sudo systemctl restart tripleo_designate_backend_bind9
$ sudo systemctl restart tripleo_unbound

在使用运行 RHOSP DNS 服务（指定）的 IPv6 网络的 RHOSP 17.1.1 环境中，BIND 9 后端服务器可能会拒绝 DNS 通知消息。造成这个问题的原因是，同一接口上同一网络上同一网络通常会有多个 IP 地址，并且可能会显示消息与指定 Worker 服务以外的源重复。

临时解决方案：应用以下补丁：

目前，以下部署架构不支持 Multi-RHEL：

当执行从 RHOSP 16.2 升级到 17.1 GA 时，存在一个已知问题。集合代理 collectd-sensubility 无法在 RHEL 8 Compute 节点上运行。

临时解决方案：在受影响的节点上编辑文件，/var/lib/container-config-scripts/collectd_check_health.py，并将第 26 行的 "healthy: .State.Health.Status}" 替换为 "healthy: .State.Healthcheck.Status}"/。

在使用 ML2/OVN 机制驱动程序的 RHOSP 17.1 GA 环境中，浮动 IP 端口转发无法正常工作。造成这个问题的原因是，当使用 FIP 时 VLAN 和扁平网络分发南北网络流量，而是应在 Controller 或 Networker 节点上集中 FIP 端口转发。

临时解决方案： 要通过集中式网关节点解决这个问题并强制 FIP 端口转发，可将 RHOSP 编排服务(heat)参数 NeutronEnableDVR 设置为 false，或者使用 Geneve 而不是 VLAN 或扁平项目网络。

在这个 RHOSP 发行版本中，存在一个已知问题：使用 Intel X710 和 E810 系列控制器虚拟功能(VF)的 SR-IOV 接口可能会遇到涉及链接状态流的网络连接问题。受影响的客户机内核版本有：

元数据服务在多个尝试启动 HAProxy 子容器失败时，元数据服务可能会不可用。元数据代理记录类似："ProcessExecutionError: Exit code: 125; Stdin: ; Stdout: Starting a new child container neutron-haproxy-ovnmeta-<uuid>" 的错误消息。

临时解决方案：运行 podman kill <_container name_> 以停止有问题的 haproxy 子容器。

OVNAvailabilityZone Role 参数不被识别为预期，这会导致在 OVN 中可用区配置失败。

临时解决方案：使用 OVNCMSOptions 参数配置 OVN 可用区。例如：

ControllerParameters:
  OVNCMSOptions: 'enable-chassis-as-gw,availability-zones=az1'

在使用动态路由的 RHOSP 17.1 环境中，更新到 RHOSP 17.1.1 无法正常工作。具体来说，没有更新 Free Range Routing (FRR)组件。

临时解决方案：在更新 RHOSP 17.1 前，在 undercloud 上应用以下补丁：

在使用带有健康监控器的 OVN 供应商驱动程序的 RHOSP 17.1.1 环境中，池负载均衡状态会错误地将 fake 成员显示为 ONLINE。如果没有使用运行状况监控器，则状态假的成员会显示 NO_MONITOR 的正常操作。

当成员无效时，可能会发生假的负载平衡池成员，例如当成员 IP 地址中存在拼写错误时。为池配置的运行状况监视器不会对假的成员执行健康检查，当计算池状态时，全局操作状态会错误地将假的成员视为 ONLINE。另外，如果池中的所有其他成员都处于 ERROR 操作状态，则会将不正确的 DEGRADED 操作状态分配给池而不是 ERROR，因为池的成员是具有不正确的 ONLINE 状态的假成员。

临时解决方案：目前，这个问题还没有临时解决方案。

网络服务(neutron)不会阻止您禁用或删除网络配置文件，即使该配置集是路由器正在使用的类别的一部分。禁用或删除配置集可能会破坏路由器的正确操作。

临时解决方案：在禁用或删除网络配置集前，请确保它不是路由器当前使用的类别的一部分。