3.2. Red Hat OpenStack Platform 17.1.2 维护发行版本 - 2024 年 1 月 16 日

在这个版本中，解决了在从 OVS 机制驱动程序迁移到 OVN 机制驱动程序的过程中破坏了 IPv6 实例的连接。

现在，您可以在不中断实例的情况下从 OVS 迁移到带有 IPv6 的 OVN。

在这个版本中解决了在重启所有 Controller 节点后导致 ceph-nfs 服务失败的问题。

Pacemaker 控制的 ceph-nfs 资源需要一个运行时目录来存储某些进程数据。

在此次更新之前，在安装或升级 RHOSP 时会创建该目录。但是，重启 Controller 节点会删除该目录，在 Controller 节点重启时不会恢复 ceph-nfs 服务。如果所有 Controller 节点都已重启，ceph-nfs 服务会永久失败。

在这个版本中，会在生成 ceph-nfs 服务前创建该目录，cephfs-nfs 服务继续重启。

在这个版本中解决了在重启一个裸机节点后导致 collectd sensubility 停止工作的权限问题。

现在，在重新引导裸机节点后，collectd sensubility 会继续运行。

在这个版本中解决了这个问题，有时会导致安全组日志记录队列在到达 NeutronOVNLoggingRateLimit 中设置的限制前停止接受条目。

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

在此次更新之前，在短的突发过程中，队列有时会在到达 NeutronOVNLoggingBurstLimit 中指定的限制前停止接受条目。

在这个版本中，NeutronOVNLoggingBurstLimit 值会如预期影响队列限制。

在此次更新之前，puppet-ceilometer 不会在 Compute 节点上的 ceilometer 配置中填充 tenant_name_discovery 参数。这可以防止识别 项目名称和 用户名 字段。

在这个版本中，将 tenant_name_discovery 参数添加到 puppet-ceilometer 中的 Compute 命名空间可解决这个问题。当 tenant_name_discovery 参数设置为 true 时，项目名称和 用户名字段将填充。

在这个版本中解决了一个程序错误，如果原始 ML2/OVS 环境使用 iptables_hybrid 防火墙和中继端口，在迁移到 OVN 机制驱动程序后造成问题。

在以前的版本中，如果原始 ML2/OVS 环境使用 iptables_hybrid firewall 和 trunk 端口，如果您在事件（如硬重启、启动和停止或节点重启后）重新创建带有中继的实例，则会出现实例网络问题。

现在，如果原始 ML2/OVS 环境使用 iptables_hybrid 防火墙和中继端口，您可以迁移到 OVN 机制驱动程序。

在以前的版本中，当 RHOSP 将 Compute 节点升级到带有 RHEL 9.2 的 RHOSP 17.1 后，nova_virtlogd 容器不会按预期从 ubi 8 更新至 ubi 9。容器只有在重新引导 Compute 节点后才会更新。

现在，nova_virtlogd 容器在 RHOSP 升级前更新至 ubi 9。请注意，在后续的 RHOSP 更新中，您必须在对 virtlogd 容器进行任何更改后重新引导 Compute 节点，因为重启会导致工作负载日志无法访问。

在此次更新之前，openstack overcloud deploy 不会将 OVNAvailabilityZone role 参数的值传递给 OVS。

在这个版本中，OVNAvailabilityZone 角色参数可以正确地将值作为 external-ids:ovn-cms-options 中的 availability-zones 值传递。

以下示例演示了如何在环境文件中使用参数来设置 'OVNAvailabilityZone。在部署命令中包括 环境文件。

ControllerParameters:
  OVNAvailabilityZone: 'az1'

部署将 availability-zones=az1 添加到 OVS external-ids:ovn-cms-options。

在这个版本中，在从 OVS 机制驱动程序迁移到 OVN 机制驱动程序后，在租户网络上设置错误的 MTU 值已从 VXLAN 改为 Geneve。在此次更新之前，cloud-init 软件包覆盖了 DHCP 服务器正确设置的值。

例如，在从具有 VXLAN 的 OVS 机制驱动程序迁移到 OVN 机制驱动程序后，使用 1442 MTU 到 Geneve，cloud-init 会将 MTU 重置为 1500。

在这个版本中，DHCP 服务器设置的值会保留。

在 RHOSP 17.1 中，VF-LAG 传输哈希策略卸载提供了一个技术预览，它允许在 NIC 硬件上进行负载均衡以卸载流量/流。这个哈希策略仅适用于 layer3+4 基础散列。

要使用技术预览，请验证您的模板是否包含绑定选项参数来启用 xmit 哈希策略，如下例所示：

bonding_options: "mode=802.3ad miimon=100 lacp_rate=fast xmit_hash_policy=layer3+4"

当每个物理功能(PF)创建大量虚拟功能(VF)时，RHOSP 部署可能会失败。NetworkManager 在所有这些请求上发出 DHCP 请求，从而导致 NetworkManager 服务失败。

例如，这个问题会在 4 PF 中包含 256 个 VF 的部署期间发生。

临时解决方案 ：避免为每个 PF 创建大量 VF。

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

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

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

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

添加其子网不在负载均衡服务(octavia)可用区中的负载均衡器成员会将负载均衡器置于 ERROR。由于 ERROR 状态而无法删除成员，使负载均衡器不可用。

临时解决方案： 删除负载均衡器。

在启用了 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，Hy-Threading Technology 被启用，OVS-DPDK 只使用一个给定内核的逻辑核心时才会发生此性能回归。

临时解决方案： 将逻辑内核分配给 OVS-DPDK 或 SRIOV 客户机，这些客户机按照 NFV 配置指南中所述运行 DPDK。

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

RHOSP 17.1 支持使用 network log create 命令的 --resource 选项为每个安全组记录流事件。如需更多信息，请参阅配置 Red Hat OpenStack Platform 网络 中的日志记录 安全组操作。

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

在使用 ML2/OVN 机制驱动程序的 RHOSP 17.1 GA 环境中，浮动 IP 端口转发无法正常工作。

FIP 端口转发应该在 Controller 或 Networker 节点上集中。相反，当使用 FIP 时，VLAN 和扁平网络分发南北网络流量。

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

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

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

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

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

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

Ceph 控制面板无法访问 Prometheus 服务端点，并显示以下出错信息： 404 not found。发生此错误的原因是为 Prometheus 服务配置 VIP 不正确。

临时解决方案：

当使用 overcloud-hardened-uefi-full.raw 镜像置备时，一些 AMD 环境无法引导，因为包含的内核参数 console=ttyS0。因此，引导序列会在没有诊断或错误消息的情况下停止。

临时解决方案： 运行以下命令以编辑 overcloud 镜像：

sudo yum install guestfs-tools -y

sudo systemctl start libvirtd

sudo virt-customize -a /var/lib/ironic/images/overcloud-hardened-uefi-full.raw \
    --run-command "sed -i 's/console=ttyS0 //g' /etc/default/grub" \
    --run-command "grub2-mkconfig -o /boot/grub2/grub.cfg" \
    --run-command "grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg"

运行这些命令后，您可以使用 provision 命令置备 AMD 节点。

在包含之前版本中负载平衡服务(octavia)运行状况监控端口的 RHOSP 17.1.2 环境中，运行 neutron-db-sync-tool 可能会随机删除这些预先存在的端口或 OVN 元数据端口。这种意外删除端口会导致健康监控容量丢失，或者与受影响的实例通信丢失。

临时解决方案：手动将现有负载均衡服务运行状况监控端口上的 'device_owner' 字段手动更新 ovn-lb-hm:distributed。这样做可确保如果启动 neutron-db-sync-tool，则运行状况监视器或 OVN 元数据端口不会受到负面影响。

如果您的部署有多个文件系统的外部 Ceph 集群，则无法按预期创建共享文件系统服务(Manila)共享。

cephfs_filesystem_name 驱动程序配置参数需要避免这种情形，无法使用 director 的 heat 模板参数设置。

临时解决方案 ：设置 "cephfs_filesystem_name" 参数，以指定共享文件系统服务(Manila)必须通过 "ExtraConfig" 使用的文件系统。

在环境文件中添加参数，如下例所示：

$ cat /home/stack/manila_cephfs_customization.yaml
parameter_defaults:
  ExtraConfig:
    manila::config::manila_config:
      cephfs/cephfs_filesystem_name:
        value: <filesystem>

将 <filesystem> 值替换为适当的名称，并将此环境文件替换为 openstack overcloud deploy 命令。

director 程序错误可能会在更新或升级到任何 RHOSP 17.1 版本过程中中断或崩溃客户端工作负载。这个错误会影响使用 CephFS-via-NFS 后端启用 RHOSP 共享文件系统服务(manila)的部署。

错误会导致在更新或升级操作过程中删除 Ceph NFS 导出信息。当用户在其共享上设置"访问规则"时，此导出信息由共享文件系统服务(manila)创建。

当 NFS 服务器进入恢复模式时，如果客户端工作负载主动读取或写入到 NFS 共享，客户端工作负载可能会挂起并最终崩溃。

临时解决方案 ： 因为导出信息丢失，请参阅 Red Hat OpenStack 17.1 的 Manila 共享可能会崩溃。