第 3 章 发行信息

在 Red Hat OpenStack Platform 16.0 中，启用 OVN 的实时迁移现已成功，因为标记 live_migration_wait_for_vif_plug 默认启用。

在以前的版本中，实时迁移失败，因为系统一直在等待 OpenStack Networking (neutron) 发送 vif_plugged 通知。

在此次功能增强中，添加了对使用附加的基于 SR-IOV 的 neutron 接口进行实例实时迁移的支持。Neutron SR-IOV 接口可以分为两个类别：直接模式和间接模式。直接模式 SR-IOV 接口直接附加到客户机，并公开到客户端操作系统。间接模式 SR-IOV 接口在客户机和 SR-IOV 设备间有一个软件接口，例如 macvtap。此功能为具有间接模式 SR-IOV 设备的实例实现透明的实时迁移。因为在实时迁移过程中没有复制硬件状态的通用方法，直接模式迁移对客户机并不透明。对于直接模式接口，模拟挂起和恢复操作已存在的工作流。例如：使用 SR-IOV 设备，在迁移前分离直接模式接口，并在迁移后重新连接它们。因此，具有直接模式 SR-IOV 端口的实例在迁移过程中会丢失网络连接，除非在客户机中创建了与实时可迁移接口的绑定。

在以前的版本中，无法使用基于 SR-IOV 的网络接口进行实时迁移。因为实时迁移经常用于主机维护及类似的操作，所以这会产生问题。在以前的版本中，该实例必须冷迁移，这需要客户机停机。

此功能增强实现使用基于 SR-IOV 的网络接口进行实例实时迁移。

在 Red Hat OpenStack Platform 16.0 中，您现在可以在本地 registry 中推送、列出、删除和显示（显示元数据）镜像。

在 Red Hat OpenStack Platform 16.0 中，新的编排服务 (heat) 部署参数可供管理员在单元格控制器上打开 nova 元数据服务：

parameter_defaults:
   NovaLocalMetadataPerCell: True

这个新参数自动将来自该单元格计算上的 OVN 元数据代理的流量定向到该单元格控制器上托管的 nova 元数据 API 服务。

根据 RHOSP 拓扑，在单元格控制器上运行元数据服务的能力可减少中央 control plane 上的网络流量。

在此功能增强中，您可以使用以下参数将专用（固定）和共享（未固定）实例调度到同一 计算节点上：

在 Red Hat OpenStack Platform 16.0 中，定义多个路由表并将路由分配到特定的路由表中（当前为技术预览）。

基于策略的路由使用路由表，在带有多个链接的主机上，您可以根据源地址通过特定接口发送流量。

您还可以根据每个接口定义路由规则，如下例所示：

network_config:
  -
    type: route_table
    name: custom
    table_id: 200
  -
    type: interface
    name: em1
    use_dhcp: false
    addresses:
    -
      ip_netmask: 192.0.2.1/24
    routes:
      -
        ip_netmask: 10.1.3.0/24
        next_hop: 192.0.2.5
        table: 200  # Use table ID or table name
    rules:
      - rule: "iif em1 table 200"
        comment: "Route incoming traffic to em1 with table 200"
      - rule: "from 192.0.2.0/24 table 200"
        comment: "Route all traffic from 192.0.2.0/24 with table 200"
      - rule: "add blackhole from 172.19.40.0/24 table 200"
      - rule: "add unreachable iif em1 from 192.168.1.0/24"

在 Red Hat OpenStack Platform 16.0 中，添加了一个用于使用裸机置备服务 (ironic) 从虚拟介质引导裸机的技术预览。

如果机器的基板管理控制器 (BMC) 支持 Redfish 硬件管理协议和虚拟介质服务，ironic 可以指示 BMC 拉取 (pull) 可引导镜像，并将它“插入 (insert)”到节点上的虚拟驱动器中。然后，节点可以从该虚拟驱动器引导到位于该镜像的操作系统。基于 Redfish API 的 ironic 硬件类型支持通过虚拟介质部署、救援（有限制）和引导（用户）镜像。

虚拟介质引导的主要优点是，PXE 引导协议套件的不安全和不可靠的 TFTP 镜像传输阶段由安全的 HTTP 传输替代。

在 Red Hat OpenStack Platform 16.0 中，工作流服务 (mistral) 任务是一个技术预览，它可以使您通过以下操作来实现密码轮转：

执行 rotate-password 工作流，生成新密码并将其存储在计划环境中。

重新部署 overcloud。

您也可以在更改密码后获取密码。

要实现密码轮转，请按照以下步骤操作：

在 Red Hat OpenStack Platform 16.0 中，向编排服务 (heat) 中添加了一个技术预览，用于 rsyslog 更改：

在 Red Hat OpenStack Platform 16.0 中，您可以使用 director 在服务模板中包括动态验证。此功能在RHOSP 16.0 中是一个技术预览。可以在要检查的步骤的末尾，或者下一步的开始插入添加内容。

在本例中，执行验证以确保 rabbitmq 服务在部署后运行：

deploy_steps_tasks:
  # rabbitmq container is supposed to be started during step 1
  # so we want to ensure it's running during step 2
  - name: validate rabbitmq state
    when: step|int == 2
    tags:
      - opendev-validation
      - opendev-validation-rabbitmq
    wait_for_connection:
      host: {get_param: [ServiceNetMap, RabbitmqNetwork]}
      port: 5672
      delay: 10

通过 heat，您可以包括 openstack-tripleo-validations 角色中的现有验证：

deploy_steps_tasks:
  - name: some validation
    when: step|int == 2
    tags:
      - opendev-validation
      - opendev-validation-rabbitmq
    include_role:
      role: rabbitmq-limits
    # We can pass vars to included role, in this example
    # we override the default min_fd_limit value:
    vars:
      min_fd_limit: 32768

您可以在此处找到 rabbitmq-limits 角色的定义 https://opendev.org/openstack/tripleo-validations/src/branch/stable/train/roles/rabbitmq-limits/tasks/main.yml

以下是使用现有服务健康检查的示例：

deploy_steps_tasks:
  # rabbitmq container is supposed to be started during step 1
  # so we want to ensure it's running during step 2
  - name: validate rabbitmq state
    when: step|int == 2
    tags:
      - opendev-validation
      - opendev-validation-rabbitmq
    command: >
      podman exec rabbitmq /openstack/healthcheck

在 Red Hat OpenStack Platform 16.0 中，向编排服务 (heat) 中添加了一个技术预览。一个新的参数 NovaSchedulerQueryImageType，被添加用于控制镜像类型（scheduler/query_placement_for_image_type_support）的计算服务 (nova) 放置和调度程序组件查询放置。

当设置为 true（默认）时，NovaSchedulerQueryImageType 会排除不支持引导请求中使用的镜像磁盘格式的计算节点。

例如，libvirt 驱动程序使用 Red Hat Ceph Storage 作为临时后端，且不支持 qcow2 镜像（不需要昂贵的转换步骤）。在本例中，启用 NovaSchedulerQueryImageType 可确保调度程序不会向使用 Red Hat Ceph Storage 的计算节点发送引导 qcow2 镜像的请求。

现在，您可以将浮动 IP 地址的 TCP、UDP 或者其它协议端口的流量转发到与 neutron 端口的一个固定 IP 地址关联的 TCP、UDP 或其他协议端口。转发的流量由 neutron API 的扩展程序和 OpenStack Networking 插件来管理。浮动 IP 地址可以配置多个转发定义。但是，您无法转发预先与 OpenStack Networking 端口关联的 IP 地址的流量。为浮动 IP 地址转发流量，这些地址由网络上的集中路由器（legacy、HA 和 DVR+HA）管理。

要转发浮动 IP 地址端口的流量，请使用以下 OpenStack Networking 插件命令：

openstack floating ip port forwarding create
--internal-ip-address <internal-ip-address>
--port <port>
--internal-protocol-port <port-number>
--external-protocol-port <port-number>
--protocol <protocol>
<floating-ip>

--internal-ip-address <internal-ip-address> 接收转发流量的 neutron 端口的固定、IPv4、内部 IP 地址。

--port <port> 接收转发的流量的 neutron 端口的名称或 ID。

--internal-protocol-port <port-number> neutron 的协议端口号，接收转发流量的固定 IP 地址。

--external-protocol-port <port-number> 转发流量的浮动 IP 地址端口的协议端口号。

--protocol <protocol> 浮动 IP 地址端口使用的协议（如 TCP、UDP）。

<floating-ip> 转发流量的端口的浮动 IP（IP 地址或 ID）。

下面是一个示例：

openstack floating ip port forwarding create \
    --internal-ip-address 192.168.1.2 \
    --port f7a08fe4-e79e-4b67-bbb8-a5002455a493 \
    --internal-protocol-port 18343 \
    --external-protocol-port 8343 \
    --protocol tcp \
    10.0.0.100

在清理 BM 节点期间，Nova-compute ironic 驱动程序会尝试更新该节点。清理操作大约需要五分钟，但 nova-compute 会尝试在大约两分钟内更新节点。超时后，nova-compute 会停止 nova 实例并将其置于 ERROR 状态。

作为临时解决方案，为 nova-compute 服务设置以下配置选项：

[ironic]
api_max_retries = 180

这样，nova-compute 就会继续更长时间尝试更新 BM 节点，并最终成功。

存在从 ML2/OVS 迁移到 OVN 失败的问题。此故障是由 Red Hat OpenStack Platform director 中的新保护机制导致，以便在更改机制驱动程序时防止升级。

有关临时解决方案，请参阅《使用开源虚拟网络联网》指南中的“准备迁移”。

使用 Linux bridge ML2 驱动程序和代理的 Red Hat OpenStack Platform 部署无法防止解析协议 (ARP) 欺骗。属于 Red Hat Enterprise Linux 8 一部分的以太网网桥帧表管理 (ebtables) 的版本与 Linux bridge ML2 驱动程序不兼容。

Red Hat OpenStack Platform 11 中已弃用 Linux Bridge ML2 驱动程序和代理，不应再使用。

红帽建议您改用 ML2 Open Virtual Network (OVN) 驱动程序和服务，即 Red Hat OpenStack Platform director 部署的默认驱动程序和服务。

替换 overcloud Controller 可能会在节点间造成 swift 环（ring）不一致的问题。这可能导致对象存储服务可用性下降。如果发生了这种情况，请使用 SSH 登录到之前存在的 Controller 节点，部署更新的环，然后重启 Object Storage 容器：

(undercloud) [stack@undercloud-0 ~]$ source stackrc
(undercloud) [stack@undercloud-0 ~]$ nova list
...
| 3fab687e-99c2-4e66-805f-3106fb41d868 | controller-1 | ACTIVE | -          | Running     | ctlplane=192.168.24.17 |
| a87276ea-8682-4f27-9426-6b272955b486 | controller-2 | ACTIVE | -          | Running     | ctlplane=192.168.24.38 |
| a000b156-9adc-4d37-8169-c1af7800788b | controller-3 | ACTIVE | -          | Running     | ctlplane=192.168.24.35 |
...

(undercloud) [stack@undercloud-0 ~]$ for ip in 192.168.24.17 192.168.24.38 192.168.24.35; do ssh $ip 'sudo podman restart swift_copy_rings ; sudo podman restart $(sudo podman ps -a --format="{{.Names}}" --filter="name=swift_*")'; done

在 Red Hat OpenStack Platform 16.0 中，配置 OpenStack 实例所需的元数据信息不可用，且可能在没有连接的情况下启动，这是一个已知的问题。

排序问题导致无法为 ovn_metadata_agent 更新 haproxy 打包程序。

可能的解决方法是让云操作器运行以下 Ansible 命令，以便在更新后重启选定节点上的 ovn_metadata_agent，以确保 ovn_metadata_agent 使用 haproxy 打包程序脚本的更新版本：

`ansible -b <nodes> -i /usr/bin/tripleo-ansible-inventory -m shell -a "status=`sudo systemctl is-active tripleo_ovn_metadata_agent`; if test \"$status\" == \"active\"; then sudo systemctl restart tripleo_ovn_metadata_agent; echo restarted; fi"`

在以前的 Ansible 命令中，nodes 可能是单个节点（如 compute-0）、所有计算（如 compute*）或 "all"。

因为 ovn_metadata_agent 最常用于计算节点，所以以下 Ansible 命令会重启云中所有计算节点的代理：

`ansible -b compute* -i /usr/bin/tripleo-ansible-inventory -m shell -a "status=`sudo systemctl is-active tripleo_ovn_metadata_agent`; if test \"$status\" == \"active\"; then sudo systemctl restart tripleo_ovn_metadata_agent; echo restarted; fi"`

重启 ovn_metadata_agent 服务后，它们会使用更新的 haproxy 打包程序脚本，这样可在虚拟机启动时为它们提供元数据。已经运行的受影响虚拟机在应用临时解决方案后重启，应该会正常运行。

Red Hat OpenStack 16.0 中存在一个已知问题：除非禁用并发多线程 (SMT) 控制，否则 KVM 客户机不会在 IBM POWER8 系统中启动。SMT 不会被自动禁用 。

解决方案是在部署 overcloud 后在所有 IBM POWER 8 计算节点上执行 sudo ppc64_cpu --smt=off，以及后续的重启。

在 Red Hat OpenStack 16.0 中，存在一个已知问题：“openstack network agent list” 命令会间歇性地表示 OVN 代理处于停机状态，而实际上代理处于活动状态且云可以正常工作。

受影响的代理有：OVN Controller 代理、OVN 元数据代理和 OVN Controller 网关代理。

当前没有解决此问题的方法。您应当忽略“openstack network agent list”命令的输出。

OpenStack Networking (neutron) 有一个已知问题：所有创建的实例都会继承与网络关联的 dns_domain 值，而不是为内部 DNS 配置的 dns_domain 值。

造成这个问题的原因是，network dns_domain 属性会覆盖 neutron dns_domain 配置选项。

如果您想要使用内部 DNS 功能，为避免这个问题，请不要为网络设置 dns_domain 属性。

要在使用 Novacontrol 角色时，允许 neutron_api 服务访问部署在 Controller 节点上的放置服务，请在 Controller 环境文件中添加以下 hieradata 配置：

service_config_settings:
     placement:
         neutron::server::placement::password: <Nova password>
  neutron::server::placement::www_authenticate_uri: <Keystone Internal API URL>
  neutron::server::placement::project_domain_name: 'Default'
  neutron::server::placement::project_name: 'service'
  neutron::server::placement::user_domain_name: 'Default'
  neutron::server::placement::username: nova
  neutron::server::placement::auth_url: <Keystone Internal API URL>
  neutron::server::placement::auth_type: 'password'
  neutron::server::placement::region_name: <Keystone Region>

有关使用 Puppet 自定义角色的 hieradata 的更多信息，请参阅 https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html-single/advanced_overcloud_customization/index#sect-Customizing_Puppet_Configuration_Data。

Red Hat OpenStack Platform 负载均衡服务有一个已知问题：重新引导节点时，容器 octavia_api 和 octavia_driver_agent 无法启动。

造成这个问题的原因是在重新引导节点时不存在 /var/run/octavia 目录。

要解决这个问题，请在文件 /etc/tmpfiles.d/var-run-octavia.conf 中添加以下行：

d /var/run/octavia 0755 root root - -

在 Red Hat OpenStack Platform 16.0 中，存在一个已知问题：在配置 overcloud 节点过程中 ansible-playbook 有时会失败。失败的原因是 tripleo-admin 用户没有获得 ssh 授权。另外，openstack overcloud deploy 命令参数 --stack-only 不再运行启用 ssh admin 工作流来授权 tripleo-admin 用户。

解决办法是在使用 --stack-only 和手动 config-download 命令时，使用 openstack overcloud admin authorize 自行运行启用 ssh admin 工作流。有关更多信息，请参阅《director 安装和使用》指南中的“分离置备和配置流程”。

Red Hat OpenStack Platform 16.0 中存在一个已知问题：当节点出现硬（不正常）关闭的情况时，在节点重新开机后，此前运行的容器会在 podman 中变为“Created”状态。

造成这个问题的原因是元数据代理无法生成新容器，因为它已经处于 "Created" 状态。haproxy side-car 容器打包程序脚本预期容器只处于"Exited" 状态，且不会清理 "Created" 状态的容器。

可能的解决方法是让云操作器运行以下 Ansible 临时命令来清理处于 "Created" 状态的所有 haproxy 容器。您必须从位于特定节点上、一组节点或整个集群中的 undercloud 中运行此 Ansible ad-hoc 命令：

`ansible -b <nodes> -i /usr/bin/tripleo-ansible-inventory -m shell -a "podman ps -a --format {{'{{'}}.ID{{'}}'}} -f name=haproxy,status=created | xargs podman rm -f || :"`

在以前的 Ansible ad-hoc 命令中，nodes 可以是清单中的单个主机、一组主机或“all”。

以下是在 compute-0 上运行命令的示例：

`ansible -b compute-0 -i /usr/bin/tripleo-ansible-inventory -m shell -a "podman ps -a --format {{'{{'}}.ID{{'}}'}} -f name=haproxy,status=created | xargs podman rm -f || :"`

在运行 Ansible ad-hoc 命令后，metadata-agent 应该会为给定网络生成一个新的容器。

在 Red Hat OpenStack Platform 16.0 中，删除了 controller-v6.yaml 文件。controller-v6.yaml 中定义的路由现在在 controller.yaml 中定义。（controller.yaml 文件是一个 NIC 配置文件，根据 role_data.yaml 中设置的值产生。）

早期版本的 Red Hat OpenStack Director 包括两个路由：一个用于外部网络上的 IPv6（默认），另一个用于 Control Plane 上的 IPv4。

要使用这两个默认路由，请确保 role_data.yaml 中的控制器定义在 default_route_networks 中包含这两个网络（例如，default_route_networks: ['External', 'ControlPlane']）。

在 Red Hat OpenStack Platform 16.0 中，删除了以下环境文件：/usr/share/openstack-tripleo-heat-templates/environments/deployed-server-bootstrap-environment-rhel.yaml。

此环境文件之前在使用预置备节点时使用。它在以前的 RHOSP 发行版本里已弃用，现在它已被删除。