第 4 章 技术备注

在以前的版本中，当一个加密的块存储服务 (cinder) 卷镜像被删除时，它的对应密钥不会被删除。

在 Red Hat OpenStack Platform 16.0 中，这个问题已解决。当镜像服务删除 cinder 卷镜像时，它还会删除镜像的密钥。(BZ#1481814)

使用 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 部署的默认驱动程序和服务。(BZ#1779221)

现在，您可以将浮动 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 (BZ#1749483)

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

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

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

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

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

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

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

[ironic]
api_max_retries = 180

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

在 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 打包程序脚本，这样可在虚拟机启动时为它们提供元数据。已经运行的受影响虚拟机在应用临时解决方案后重启，应该会正常运行。(BZ#1790467)

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

在 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']）。(BZ#1631508)

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

parameter_defaults:
   NovaLocalMetadataPerCell: True

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

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

在 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 镜像的请求。(BZ#1710634)

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

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

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