第 3 章 发行信息

此 Red Hat OpenStack Platform 发行版本包括以下功能增强：

Swift 对象以明文形式存储在磁盘上。如果问题早已达到生命期，这些磁盘可能会造成安全风险。加密对象可以缓解这些风险。

Swift 以透明方式执行这些加密任务，在上传到 swift 时自动加密对象，然后在提供给用户时自动解密。这个加密和解密使用相同的(ymmetric)密钥进行，密钥保存在 Barbican 中。

为 collectd 可组合服务添加了以下新参数。如果 CollectdGnocchiAuthMode 设置为 'simple'，则 CollectdGnocchiProtocol, CollectdGnocchiServer, CollectdGnocchiPort 和 CollectdGnocchiUser 被考虑进行配置。

如果 CollectdGnocchiAuthMode 设置为 'keystone'，则将 CollectdGnocchiKeystone* 参数考虑进行配置。

下面是添加的参数的详细描述：

本节中列出的项目作为技术预览提供。有关技术预览状态范围的详情，以及相关的支持影响，请参阅 https://access.redhat.com/support/offerings/techpreview/。

"必需" （必需）"legacy" （默认; 必须有；如果可用）"首选" (nice 才需要具有)

在所有情况下，如果可能，都提供严格的 NUMA 关联性。这些策略允许您配置每个 PCI 别名应严格的 NUMA 关联性，以最大化资源利用率。策略之间的主要区别在于，在调度失败前，您将要考虑到的 NUMA 关联性量。

当为 PCI 设备配置"首选"策略时，nova 会在与 PCI 设备的 NUMA 节点不同的 NUMA 节点上使用 CPU （如果可用）。这会增加资源利用率，但会降低这些实例的性能。

本节概述了本发行版本的重要信息，包括推荐做法和 Red Hat OpenStack Platform 的显著变化。您必须将此信息纳入考量，才能确保您的部署获得最佳效果。

因此，共享文件系统服务现在支持通过 IPv6 网络导出由 NetApp ONTAP 后端支持的共享。对导出的共享的访问由 IPv6 客户端地址控制。

# ip netns exec qrouter...
RTNETLINK answers: Invalid argument

要在网络命名空间中运行命令，您必须从创建命名空间的 neutron 容器执行它。例如，l3-agent 为路由器创建网络命名空间，因此命令需要更改为：

# docker exec neutron_l3_agent ip netns exec qrouter...

与使用 'qdhcp' 开头的网络命名空间类似，您需要从 'neutron_dhcp' 容器中执行。

请注意，在 GA 版本中 tripleo 默认不配置扩展。如需临时解决方案，请参阅 .BZ#1577592。

parameter_defaults: NovaReservedHostMemory: 2048

要更改默认网络的名称，请使用自定义的可组合网络文件(network_data.yaml)，并使用 '-n' 选项将其包含在您的 'openstack overcloud deploy' 命令中。在这个文件中，您应该将 "name_lower" 字段设置为您要更改的网络的自定义 net 名称。有关更多信息，请参阅高级 Overcloud 自定义指南中的"使用 Composable Networks"。

另外，您需要为 ServiceNetMap 表添加本地参数到 network_environment.yaml，并将旧网络名称的所有默认值覆盖到新的自定义名称。默认值可以在 /usr/share/openstack-tripleo-heat-templates/network/service_net_net_map.j2.yaml 中找到。在以后的 OSP-13 版本中将不需要修改 ServiceNetMap。

因此，引导虚拟机可能无法作为 metadata-agent 置备新的元数据命名空间，集群不会如预期执行。

可能的解决方法是，在将新控制器提升为 OVN 数据库的 master 后，重启所有计算节点中的 ovn_metadata_agent 容器。另外，将 plugin.ini 上的 ovsdb_probe_interval 增加到 600000 毫秒。

此问题的症状是： - 在 OpenStack 服务日志中执行任何形式的条目：DuplicateMessageError: Found duplicate message (629ff0024219488499b0fac0caa3a3a5)。跳过它。- "openstack network agent list" 返回一些代理为 DOWN

要恢复正常操作，请在任何控制器节点上运行以下命令（您只需要在一个控制器上执行此操作）：pcs resource restart rabbitmq-bundle

目前，Red Hat OpenStack Platform 存在的已知问题包括：

要解决这个问题，请将 OS::TripleO::Services::NeutronDhcpAgent 更改为：

OS::TripleO::Services::NeutronDhcpAgent: docker/services/neutron-dhcp.yaml

因此，Red Hat OpenStack Platform 13 正式发布书 'Back Up 和 Restore the Director Undercloud'。该程序会在此版本正式发行(GA)后被更新，并在验证后立即发布。

由于缺少 FIB 表条目，虚拟机将丢失与公共网络的连接。

将浮动 IP 与虚拟机关联可恢复与公共网络的连接。只要浮动 IP 与虚拟机关联，就可以连接到互联网。但是，您将丢失来自外部网络的公共 IP/浮动 IP。

当部署通过时，三个 OpenDaylight 实例必须只有两个可以正常工作，才能成功进行部署。第三个 OpenDaylight 实例可能会错误地启动。使用 docker ps 命令检查每个容器的健康状况。如果不健康，请使用 docker restart opendaylight_api 重启容器。

当部署失败时，唯一的选项是重启部署。对于基于 TLS 的部署，所有 OpenDaylight 实例都必须正确引导或部署将失败。

为避免此问题，overcloud 仍然在 OSP 10 上，并准备好执行最后的 overcloud 次要版本更新：1.编辑模板文件 /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration/rhel-registration.yaml 2。从模板创建 RHELUnregistration 和 RHELUnregistrationDeployment 资源。3.继续进行小的更新和快进升级过程。

在这种情况下，应该执行以下操作：* 重启有问题的节点。* 监控 REST 端点以验证集群成员是否健康： http://$ODL_IP:8081/jolokia/read/org.opendaylight.controller:Category=ShardManager,name=shard-manager-config,type=DistributedConfigDatastore * 应该包含一个字段 "SyncStatus"，而 "true" 的值代表一个健康的。

由于这些虚拟机之间的 ARP 数据包失败，因此两个虚拟机之间没有网络。

允许 manila-share 服务初始化：

1）创建 /usr/share/openstack/tripleo-heat-templates 的副本，以用于 overcloud 部署。

2）编辑 …​/tripleo-heat-templates/docker/services/ceph-ansible/ceph-base.yaml 文件，将第 295 行中的所有 triple 反斜杠更改为单反斜杠。

删除前：

mon_cap: 'allow r, allow command \\\"auth del\\\", allow command \\\"auth caps\\\", allow command \\\"auth get\\\", allow command \\\"auth get-or-create\\\"'

删除后：

mon_cap: 'allow r, allow command \"auth del\", allow command \"auth caps\", allow command \"auth get\", allow command \"auth get-or-create\"'

3）部署 overcloud，替换 tripleo-heat-templates 的副本的副本，其中验证 /usr/share/openstack-tripleo-heat 模板发生在原始 overcloud-deploy 命令中。

ceph 键 /etc/ceph/ceph.client.manila.keyring 文件会具有适当的内容，manila-share 服务将正确初始化。

监控警告阈值已从每个 OSD 从 300 减小到 200 个 PG。200 仍然是每个 OSD 通常建议 100 个 PG 的两倍。此限制可以通过监视器上的 mon_max_pg_per_osd 选项进行调整。旧的 mon_pg_warn_max_per_osd 选项已被删除。

池消耗的 PG 数量不能降低。如果升级会导致预先存在的部署达到最大限制，您可以在 ceph-upgrade 步骤中提高其预升级值。在环境文件中，添加如下参数设置：

parameter_defaults:
  CephConfigOverrides:
    mon_max_pg_per_osd: 300

此设置应用到 ceph.conf，集群则保持 HEALTH_OK 状态。

始终对 overcloud 外部网络使用 NIC 模板中的 OVS 网桥。默认情况下，这个网桥在 Director 中被命名为 "br-ex" （但您可以使用任何名称）。您应将用于外部网络的物理主机接口连接到此 OVS 网桥。

当您使用附加到 OVS 网桥的接口时，部署将正确运行，到租户的外部网络流量将可以正常工作。

出现问题时，neutron 服务器将无法使用 OVN 北和南向 DB 服务器，并将所有 Create/Update/Delete API 连接到 neutron 服务器会失败。

重启 ovn-dbs-bundle 资源将解决这个问题。在其中一个控制器节点中运行以下命令：

"pcs resource restart ovn-dbs-bundle"

VXLAN 隧道必须正确配置，以便 SNAT 流量通过它们。使用 VLAN 租户网络时，使用以下方法之一配置 MTU，以便 SNAT 流量可以通过 VXLAN 隧道：: * 配置 VLAN 租户网络，以在每个网络配置上使用 1450 的 MTU。* 将 NeutronGlobalPhysnetMtu heat 参数设置为 1450。注意：这意味着所有扁平/VLAN 提供商网络均具有 1450 MTU，可能不是可取的（特别是用于外部提供商网络）。* 在lay 下配置 MTU 为 1550 （或更高）的租户网络。这包括在租户网络 NIC 的 NIC 模板中设置 MTU。

Red Hat OpenStack Platform 13 中包含的 HAProxy 版本是一个比 1.6 更早的版本，在配置 PING 类型健康监控器时使用 TCP 连接。

您应该跳过这些测试，或者将这些过滤器添加到您的 nova 配置中。

作为临时解决方案，您需要通过为 undercloud 部署添加额外的模板来使用 control plane 网络手动设置 snmpd 子网，如下所示"

parameter_defaults: SnmpdIpSubnet: 192.168.24.0/24

作为临时解决方案，您需要通过为 undercloud 部署添加额外的模板来使用 control plane 网络手动设置 snmpd 子网，如下所示"

parameter_defaults:
  SnmpdIpSubnet: 192.168.24.0/24

因此，部署可能会失败，并显示消息 "Error response from daemon: No such container: ceph-create-keys"。 这会影响任何 ceph-ansible 运行（包括全新的部署），其中包括：* 多个计算备注或 * 自定义角色作为 ceph 客户端，后者也托管了使用 ceph 的服务。

要避免这个问题，请将默认 PG 号设置为 32；部署完成后，手动提高 PG 号，如存储策略指南所述 https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html/storage_strategies_guide/placement_groups_pgs#set_the_number_of_pgs。

删除客户端后，您必须重启 'nova-compute' 服务。删除客户端并重新启动服务后，可用的 SR-IOV 设备列表将正确。

您可以使用以下临时解决方案之一：

选项 A：在由 Pacemaker 管理的容器的节点上手动更新 /etc/sysconfig/docker 文件，并添加任何新引入的不安全 registry。

选项 B：在升级前运行 openstack overcloud deploy 命令，并使用环境文件和 DockerInsecureRegistryAddress 参数提供所需的新的不安全注册表列表。

所有容器镜像都应该在升级过程中成功下载。

在所有控制器节点上进行故障排除，添加防火墙规则，并确保在 DROP 规则之前插入它们。

IPv4:
  # iptables -A INPUT -p tcp -m multiport --dports 9876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy ipv4" -j ACCEPT
  # iptables -A INPUT -p tcp -m multiport --dports 13876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy_ssl ipv4" -j ACCEPT
  # iptables -A INPUT -p tcp -m multiport --dports 9876,13876 -m state --state NEW -m comment --comment "120 octavia_api ipv4" -j ACCEPT

IPv6:
  # ip6tables -A INPUT -p tcp -m multiport --dports 9876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy ipv6" -j ACCEPT
  # ip6tables -A INPUT -p tcp -m multiport --dports 13876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy_ssl ipv6" -j ACCEPT
  # ip6tables -A INPUT -p tcp -m multiport --dports 9876,13876 -m state --state NEW -m comment --comment "120 octavia_api ipv6" -j ACCEPT

重启 HAProxy：

  # docker restart haproxy-bundle-docker-0

意外的 API 错误。表 'nova_cell0.instances' 不存在

您可以运行以下命令来解决这个错误：

$ sudo nova-manage api_db sync

这个问题不是关键性，不应以主要的方式造成快进的升级过程。