3.4. 已知问题

当前存在一个已知问题：当网络配置改变时，可能会导致接口重启从而造成 overcloud 节点上的网络连接出现问题。
以上问题可能会导致 pacemaker 控制器集群出现问题，从而造成节点被隔离（如果配置了隔离功能）。因此，tripleo-heat-templates 被设计为在 overcloud 更新时不应用网络配置的改变。这可以避免出现以上提到的集群无法工作的问题。

当前，特定的设置步骤需要到 overcloud 控制器的 SSH 连接，并需要 VIP 可以访问 Overcloud 节点。
如果您的环境被配置为使用一个外部的负载均衡系统，这些步骤可能无法正确连接。为了解决这个问题，可以把外部负载均衡系统配置为转发端口 22，这样 SSH 就可以成功连接到 VIP。

controller_v6.yaml 模板包括了一个 Management 网络 VLAN 的参数。当前版本的 director 会不支持这个参数，它会和与 Management 网络相关的注释信息一样被忽略。Management 网络的参考信息不需要被复制到任何定制模板中。

以后的版本会支持这个参数。

在进行部署前或部署过程中，director 不会提供网络验证功能。这意味着，一个包括错误的网络配置的部署可能会运行两个小时而不产生任何输出，并可能导致部署失败。一个网络验证脚本正在被开发，并会包括在以后的版本中。

在这个版本中，RHEL OpenStack Platform director 只支持在一个高可用性（HA）overcloud 部署中使用 3 个控制器节点。

当 Director 连接到 Public API 来完成部署后的配置步骤时有一个要求：Undercloud 节点需要有到 Public API 的路由，它需要可以在标准的 OpenStack API 端口和端口 22（SSH）中被访问到。
为了满足这个要求，检查 Undercloud 可以访问控制器上的 External 网络（这个网络需要被用来进行部署后的配置）。这样，Undercloud 就应该可以在部署后成功连接到 Public API，并进行最后的配置任务。只有在执行了这些配置任务后，新创建的部署才可以被 Admin 账户管理。

在使用 NovaEnableRbdBackend 参数时，临时存储（ephemeral storage）被硬编码为 true。着意味着，NovaEnableRbdBackend 实例无法在 Ceph 存储中使用 cinder 后端。这个问题的一个解决方案是，在 puppet/hieradata/compute.yaml 中增加以下内容：

nova::compute::rbd::ephemeral_storage: false

这会禁用临时存储。

当 openstack-cinder-volume 使用一个 LVM 后端，Overcloud 节点重启后，基于文件的环回设备不会被重新创建。这个问题的一个解决方案是，使用以下命令手工重新创建环回设备：

$ sudo losetup /dev/loop2 /var/lib/cinder/cinder-volumes

然后重启 openstack-cinder-volume。请注意，openstack-cinder-volume 每次只会在 Overcloud Controller 节点的高可用性集群中的一个节点上运行。但是，环回设备应该会存在于所有节点上。

在部署 Red Hat OpenStack Platform director 时，bare-metal 节点应该被关闭， ironic 的 `node-state` 和 `provisioning-state` 需要是正确的。
例如，ironic 把一个节点列为 "Available, powered-on"，但这个服务器实际已被关机，则这个节点将不能用于部署。
因此，您需要确定节点在 ironic 中的状态应该和节点实际状态相匹配。使用 "ironic node-set-power-state <node> [on|off]" 以及 "ironic node-set-provisioning-state <node> available" 来确保节点在 ironic 中的状态与服务器的实际状态相符，并确保节点被标记为 `Available`。
当 ironic 中的状态正确时，ironic 将可以正确管理电源状态并部署相应节点。

为了可以在 Red Hat OpenStack Platform 中正常工作，IBM x3550 M5 服务器对固件的版本有最低要求。
较老版本的固件需要在进行部署前进行升级。相关系统需要被升级到以下版本（或更高版本）：
DSA 10.1, IMM2 1.72, UEFI 1.10, Bootcode NA, Broadcom GigE 17.0.4.4a 

在进行固件升级后，部署过程应该可以正常执行。

一个与 puppet manifest 相关的代码错误会导致在 undercloud 的安装过程中错误地禁用 LVM 分区自动挂载功能。因此，带有除 root 和 swap 分区以外分区的 undercloud 无法被引导到一个 emergency shell。

这个问题可以通过以下方法之一解决：

1. 从 /etc/fstab 中手动删除挂载点。使用这个方法可以防止上面的问题在以后进行的 manifest 操作中发生。其它的分区也可以被删除，它们的空间可以分配给其它分区（如 root 或 swap）。

2. 配置分区在 /etc/lvm.conf 中激活。使用这个方法可以防止上面的问题在再次执行 undercloud 安装过程（更新或升级）前发生。

3. 把初始部署限制为只使用 root 和 swap 分区。这会完全解决上面的问题。

当使用 Red Hat Ceph 作为临时存储（ephemeral storage）的后端时，Compute 服务无法正确计算可用存储空间的数量。特别是，Compute 只会简单地加可用存储，而不会考虑复制（replication）。这会导致计算出的结果包括更多的可用存储，并可能导致无法预料的过度分配存储的问题。

现在，为了计算正确的临时存储，会直接对 Ceph 服务进行查询。

在 `tuned` 档案被激活后，为了正确设置分配给 PMD 的内核，`tuned` 服务需要在 `openvswitch` 服务启动前被启动。 

为了解决这个问题，可以运行以下脚本来修改 `tuned` 服务：

#!/bin/bash

tuned_service=/usr/lib/systemd/system/tuned.service

grep -q "network.target" $tuned_service
if [ "$?" -eq 0 ]; then
  sed -i '/After=.*/s/network.target//g' $tuned_service
fi

grep -q "Before=.*network.target" $tuned_service
if [ ! "$?" -eq 0 ]; then
  grep -q "Before=.*" $tuned_service
  if [ "$?" -eq 0 ]; then
    sed -i 's/^\(Before=.*\)/\1 network.target openvswitch.service/g' $tuned_service
  else
    sed -i '/After/i Before=network.target openvswitch.service' $tuned_service
  fi
fi

systemctl daemon-reload
systemctl restart openvswitch
exit 0

当前有一个已知的问题：`Instance.pci_devices` 项可以是  null，但 `get_instance_pci_devs()` 无法正确处理这个情况。如果把没有 `pci_devices` 的数据传递到较老部署（如 Red Hat OpenStack Platform 9）中的实例时，会导致系统出现问题（系统会重复 `None` 来作为一个列表）。
可能出现这个问题的范围包括：作为升级过程的一部份所触发的实时迁移操作；试图把虚拟机实时从 Red Hat OpenStack Platform 9 主机迁移到 Red Hat OpenStack Platform 10 主机。
一个可以解决这个问题的补丁程序正在被开发，并将作为一个勘误发行以供红帽的用户使用。如果您计划进行需要对已存在的实例进行实时迁移的升级操作，请等待这个勘误发行后再进行您的升级操作。

Red Hat Enterprise Linux 6 只包括 GRUB Legacy，而 OpenStack bare metal provisioning（ironic）只支持 GRUB2。因此，部署使用本地引导的分区镜像会在 bootloader 安装过程中失败。
这个问题的一个解决方案是，如果使用 RHEL 6 作为裸机实例，不要在 flavor 设置中把 boot_option 设置为 local。您也可以考虑部署已安装了 GRUB Legacy 的 RHEL 整个磁盘的镜像。

在部署或升级到使用 Ceph 和专用 blockstorage 节点作为 LVM 的 Red Hat OpenStack 10 环境时，创建带有附加卷的实例将无法工作。在升级过程中，director 配置 Block Storage 服务的程序中包括一个错误导致了这个问题。

具体来说，当 Ceph 和专用 blockstorage 节点被一起配置时，heat 模板在默认情况下无法正确处理这个情况。因此，director 无法定义一些所需设置。

请注意，在生产环境中，LVM 并不是一个适当的 Block Storage 后端，特别是在一个企业级环境中。

为了解决这个问题，在 upgrade/deployment 中添加一个包括以下内容的环境文件：

parameter_defaults:
  BlockStorageExtraConfig:
    tripleo::profile::base::cinder::volume::cinder_enable_iscsi_backend: true
    tripleo::profile::base::cinder::volume::cinder_enable_rbd_backend: false

输入的`AllocationPools` IPv6 网络和 IP 分配池的地址范围必须是一个符合 RFC 5952 规定的有效格式值。格式不正确的值将会导致出现错误。
输入的 IPv6 地址格式必须正确：前导 0 可以完全不包括，或完全包括（重复的 0 可以由 "::" 替代）。
例如，IP 地址 "fd00:0001:0000:0000:00a1:00b2:00c3:0010" 可以表示为"fd00:1::a1:b2:c3:10"，但是不能为 "fd00:01::0b2:0c3:10"（这个值包括无效的前导 0 - 01, 0b2, 0c3）。这个项中的值必须截掉所有前导 0 或包括全部前导 0。

当升级会部署一个集成了较老版本的外部 Ceph Storage Cluster 集群（Red Hat Ceph Storage 1.3）的 Red Hat OpenStack Platform 环境时，您需要确保系统的向后兼容性。要实现这个目的，在升级/部署过程中添加一个带有以下内容的环境文件：

parameter_defaults:
  ExtraConfig:
    ceph::conf::args:
      client/rbd_default_features:
        value: "1"

当使用用户空间数据路径（DPDK）时，一些非 PMD 线程运行在运行 PMD（由`pmd-cpu-mask'配置）的同一个 CPU 上。 这会导致 PMD 被抢占，并产生延迟、数据丢弃等问题。

在这个版本中，post-install.yaml 文件（ https://access.redhat.com/documentation/en/red-hat-openstack-platform/10/single/network-functions-virtualization-configuration-guide/#ap-ovsdpdk-post-install）包括了相关的解决方案。

在以前的版本中，Ceph Storage 节点使用本地文件系统（格式化为 `ext4`）作为 `ceph-osd` 服务的后端。

请注意，一些 Red Hat OpenStack Platform 9（Mitaka）的 `overcloud-full` 镜像以 `ext4` 而不是 `xfs` 的格式进行创建。

在 Jewel 版本中，`ceph-osd` 会检查后端所允许的文件名的最大长度。如果这个限制小于为 Ceph 本身配置的限制，它将拒绝启动。这个问题的一个解决方案是，登录到 Ceph Storage 节点，运行以下命令检查 `ceph-osd` 使用的文件系统：

# df -l --output=fstype /var/lib/ceph/osd/ceph-$ID

其中的 $ID 是 OSD ID，例如：

# df -l --output=fstype /var/lib/ceph/osd/ceph-0

请注意，一个 Ceph Storage 节点可能会包括多个 `ceph-osd` 实例，在这个情况下，`/var/lib/ceph/osd/ 目录中会包括多个子目录来分别代表不同的实例。

如果有*任何* OSD 实例使用 `ext4` 文件系统，则需要配置 Ceph 来使用较短的文件名。这可以通过使用一个额外的、包括以下内容的环境文件进行部署或升级来实现：

parameter_defaults:
  ExtraConfig:
    ceph::profile::params::osd_max_object_name_len: 256
    ceph::profile::params::osd_max_object_namespace_len: 64

作为结果，您现在就可以验证，在从 Red Hat OpenStack Platform 9 升级到 Red Hat OpenStack Platform 10 后，是否每个 `ceph-osd` 实例都已被运行。

使用 "openstack baremetal import --json instackenv.json" 导入的节点需要在导入前关机。如果节点没有被关机，Ironic 将不会尝试添加节点或进行内省。
因此，在运行 "openstack baremetal import --json instackenv.json" 前需要关闭所有 overcloud 节点。
当节点被关闭后，导入操作可以成功运行。

在使用 DHCP HA 时，应该通过可组合角色把 `NeutronDhcpAgentsPerNetwork` 的值设置为 dhcp-agents 的数量（如果这个数量小于 3）或 3。如果没有进行这个设置，它的值会被默认设置为 `ControllerCount` 的值，而这个值可能并不是最佳的，因为可能没有运行足够的 dhcp-agents 以满足为每个网络产生这么多数量的 DHCP 服务器。

Glance 没有在 /etc/glance/glance.conf 中被 glance.store.http.Store 配置为一个 known_store，这意味着，glance 客户端无法使用 --copy-from 参数创建镜像，运行这些命令会出现 "400 Bad Request" 错误。这个问题的一个临时解决方案是，编辑 /etc/glance/glance-api.conf 文件，在 "stores" 配置选项的列表中添加 glance.store.http.Store，然后重启 openstack-glance-api 服务。这将可以使用 --copy-from 参数来成功创建 glance 镜像。

"openstack overcloud update stack" 命令的运行会马上返回，即使它还在后台进行操作。因为这个命令不是交互式的，所以它看起来好象在一直运行。在这种情况下，在运行这个命令时使用 "-i"，它会提示用户输入需要手工输入的信息。

一个与时间相关的问题有时会导致 Overcloud neutron 服务无法自动地正确启动。这意味着服务无法访问实例。这个问题的一个临时解决方法是，在 Controller 节点集群中运行以下命令：

$ sudo pcs resource debug-start neutron-l3-agent

实例将可以正常工作。