红帽全球峰会第 1 章 准备次版本更新
使用最新的软件包和容器保持 Red Hat OpenStack Platform (RHOSP) 16.2 环境进行更新。
您可以更新以下版本：
| 旧的 RHOSP 版本 | 新的 RHOSP 版本 |
|---|---|
| Red Hat OpenStack Platform 16.1.z | Red Hat OpenStack Platform 16.2 最新 |
| Red Hat OpenStack Platform 16.2.z | Red Hat OpenStack Platform 16.2 最新 |
RHOSP 次要更新过程工作流
您必须完成以下步骤来更新 RHOSP 环境：
- 为 RHOSP 次要更新准备您的环境。
- 将 undercloud 更新至最新的 OpenStack 16.2.z 版本。
- 将 overcloud 更新至最新的 OpenStack 16.2.z 版本。
- 升级所有 Red Hat Ceph Storage 服务。
- 运行聚合命令以刷新 overcloud 堆栈。
如果您有多堆栈基础架构，请一次完全更新每个 overcloud 堆栈。如果您有分布式计算节点(DCN)基础架构，请在中央位置完全更新 overcloud，然后在每个边缘站点更新 overcloud，一次更新 overcloud。
在更新 RHOSP 环境前的注意事项
要帮助您在更新过程中指南，请考虑以下信息：
- 红帽建议备份 undercloud 和 overcloud control plane。有关备份节点的更多信息，请参阅 备份和恢复 undercloud 和 control plane 节点。
- 熟悉可能会阻止更新的已知问题。
- 在开始更新前，熟悉可能的更新和升级路径。更多信息请参阅 第 1.1 节 “长生命版本的升级路径”。
-
要识别您当前的维护发行版本，请运行
$ cat /etc/rhosp-release。您还可以在更新环境后运行此命令以验证更新。
已知的可能会阻止更新的问题
查看可能影响成功次版本更新的已知问题。
在从 16.1 到 16.2.6 的一些更新期间，collectd 容器(sensubility)会使用超过所需内存，这会导致 podman-initiated 重启。如果在更新过程中发生 podman-initiated restart，则更新会失败。
如果在更新过程中发生 podman-initiated 重启 collectd 容器，则必须禁用 collectd 容器，然后在成功更新后启用 collectd 容器。有关禁用和启用 collectd 容器的更多信息，请参阅以下红帽知识库解决方案更新失败，因为 collectd 容器(sensubility)运行 OOM。
运行 Pacemaker 版本 2.0.3-5.el8_2.4 的 overcloud 节点可能无法成功更新，因为节点上关闭集群时出现的竞争条件。
如果当前在任何 overcloud 节点上安装了 Pacemaker 版本 2.0.3-5.el8_2.4，则必须升级 Pacemaker，然后才能更新 overcloud 节点。如需更多信息，请参阅以下红帽知识库解决方案 从 OSP16.1 更新至 OSP16.2 可能无法更新某些 HA 容器。
从 Red Hat Enterprise Linux (RHEL) 版本 8.3 开始，默认禁用对 Intel 事务同步扩展 (TSX) 功能的支持。这会导致以下迁移场景中在主机间实例实时迁移问题：
- 从启用了 TSX 内核参数的主机迁移到禁用 TSX 内核参数的主机。
在支持 TSX 功能的 Intel 主机中，实时迁移可能会失败。有关受此问题影响的 CPU 的更多信息，请参阅受影响的配置。
有关更多信息，请参阅以下红帽知识库解决方案有关 Intel TSX 对 OpenStack 客户机的影响的指南。
对于运行 RHEL 8.4 的节点，且基于可组合角色，您必须先更新 Database 角色，然后才能更新任何其他角色。
advanced-virt-for-rhel-8-x86_64-eus-rpms 和 advanced-virt-for-rhel-8-x86_64-rpms 软件仓库存在一个已知问题，可防止成功升级。要在升级前禁用这些软件仓库，请参阅 OSP 16.2 不再需要红帽知识库解决方案 advanced-virt-for-rhel-8-x86_64-rpms。
从 RHOSP 16.1 升级到 16.2 时存在一个已知问题，并从 RHOSP 16.2.1 升级到 16.2.2，与 Podman 和 libvirt 服务的更改相关。如果您没有在升级前迁移工作负载，则升级可能会失败。
在评估对 libvirt 版本不兼容的风险之前，不要从 RHOSP 16.2.0 更新至 16.2.2 或 16.2.3。
要评估您的风险，请完成以下步骤：
检查所有 Compute 节点上的
nova_libvirt容器中的 libvirt 软件包：sudo podman exec nova_libvirt rpm -qa libvirt-*
$ sudo podman exec nova_libvirt rpm -qa libvirt-*Copy to Clipboard Copied! Toggle word wrap Toggle overflow 检查
nova_compute容器的 libvirt 版本：sudo podman exec nova_compute rpm -qa libvirt-*
$ sudo podman exec nova_compute rpm -qa libvirt-*Copy to Clipboard Copied! Toggle word wrap Toggle overflow
如果 libvirt 版本是 7.0，则部署不受这个程序错误的影响。您可以执行更新。
如果 libvirt 版本为 7.6，则部署会受到这个程序错误的影响。您的更新存在风险。要更新您的部署，请按照 更新 RHOSP 16.2.0 时的 libvirt 版本不兼容问题(bug 2109350)中的内容进行操作。
如果更新包含 OVN DB 模式升级，请不要在从 RHOSP 16.1 更新至 16.2 时更改 OVN DB 条目。这样做可能会导致错误配置和数据丢失。
如果您在更新过程中更改 OVN DB，其中包括 OVN DB 模式升级和 OpenShift、Kuryr 和负载均衡服务(octavia)，您可能无法删除负载均衡实体。
临时解决方案： 如果您在更新过程中更改了 OVN DB，其中包括 OVN DB 模式升级和 OpenShift、Kuryr 和负载均衡服务，且无法删除负载均衡实体，请执行以下步骤：
- 访问 mysql octavia DB。
-
将实体的
provisioning_status更改为DELETED。
如果在更新过程中更改 OVN DB 后在更改 OVN DB 后对任何其他 OVN DB 实体发生，请运行 neutron-db-sync 工具。
由于 openstack-keystone:16.2.6 镜像中存在已知的错误，从任何 Red Hat OpenStack Platform (RHOSP) 16.x 版本到 RHOSP 16.2.6-20 的一个小更新会失败。
临时解决方案 ： 选择以下选项之一：
- 选项 1： 将您的环境更新至 RHOSP 16.2.7。
- 选项 2： 请参阅红帽知识库解决方案 Keystone 报告"在 overcloud 部署后报告"使用抽象方法 reset_last_active"的抽象类身份 报告。
流程
要为次要更新准备 RHOSP 环境，请完成以下步骤：
1.1. 长生命版本的升级路径
在开始更新或升级前，熟悉可能的更新和升级路径。
您可以在 /etc/rhosp-release 和 /etc/redhat-release 文件中查看当前的 RHOSP 和 RHEL 版本。
| 当前版本 | 目标版本 |
|---|---|
| RHOSP 10.0.x on RHEL 7.x | RHEL 7.7 latest 上的 RHOSP 10.0 latest |
| RHOSP 13.0.x on RHEL 7.x | RHEL 7.9 latest 上的 RHOSP 13.0 最新 |
| RHOSP 16.1.x on RHEL 8.2 | RHEL 8.2 最新上的 RHOSP 16.1 最新 |
| RHOSP 16.1.x on RHEL 8.2 | RHEL 8.4 最新上的 RHOSP 16.2 最新 |
| RHOSP 16.2.x on RHEL 8.4 | RHEL 8.4 最新上的 RHOSP 16.2 最新 |
| 当前版本 | 目标版本 |
|---|---|
| RHEL 7.7 上的 RHOSP 10 | RHEL 7.9 latest 上的 RHOSP 13 最新 |
| RHOSP 13 on RHEL 7.9 | RHEL 8.2 最新上的 RHOSP 16.1 最新 |
| RHOSP 13 on RHEL 7.9 | RHEL 8.4 最新上的 RHOSP 16.2 最新 |
如需更多信息，请参阅升级 框架(13 到 16.2)
红帽提供了两个选项，将您的环境升级到下一个长生命版本：
- 原位升级
- 在现有环境中执行服务升级。本指南主要侧重于此选项。
- 并行迁移
- 创建新的 Red Hat OpenStack Platform 16.2 环境，并将工作负载从您当前的环境迁移到新环境。有关 Red Hat OpenStack Platform 并行迁移的更多信息，请联系红帽全局专业服务。
此表中的持续时间是基于内部测试的最小估算，可能不适用于所有生产环境。例如，如果您的硬件具有低规格或延长引导周期，则允许更长时间使用这些持续时间。要准确化每个任务的升级持续时间，请在测试环境中执行与生产环境类似的硬件的步骤。
| 原位升级 | 并行迁移 | |
|---|---|---|
| undercloud 的升级持续时间 | 每个主要操作估计持续时间包括：
| 无。除了现有的 undercloud 外，您还将创建新的 undercloud。 |
| overcloud control plane 的升级持续时间 | 每个 Controller 节点的估算：
| 无。除了现有的 control plane 外，您还会创建新的 control plane。 |
| control plane 的中断持续时间 | bootstrap Controller 节点的服务升级的持续时间，大约为 60 分钟。 | 无。这两个 overcloud 在工作负载迁移过程中都可以正常工作。 |
| control plane 中断的结果 | 您不能在中断期间执行 OpenStack 操作。 | 没有中断。 |
| overcloud 数据平面的升级持续时间 | 估算每个 Compute 节点和 Ceph Storage 节点：
| 无。除了现有的数据平面外，您还会创建新的数据平面。 |
| data plane 的中断持续时间 | 因为工作负载从节点迁移到节点，所以中断的最小。 | 因为从 overcloud 迁移到 overcloud 的工作负载，所以中断最小。 |
| 其他硬件要求 | 不需要额外的硬件。 | 要创建新的 undercloud 和 overcloud，需要额外的硬件。 |
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}