保持 Red Hat OpenStack Platform 更新

Red Hat OpenStack Platform 16.2

执行 Red Hat OpenStack Platform 的小更新

摘要

您可以对 Red Hat OpenStack Platform(RHOSP)环境进行次要更新,使其与最新的软件包和容器进行更新。

前言

使开源包含更多

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息

对红帽文档提供反馈

我们感谢您对文档提供反馈信息。与我们分享您的成功秘诀。

使用直接文档反馈(DDF)功能

使用 添加反馈 DDF 功能,用于特定句子、段落或代码块上的直接注释。

  1. Multi-page HTML 格式查看文档。
  2. 请确定您看到文档右上角的 反馈 按钮。
  3. 用鼠标指针高亮显示您想评论的文本部分。
  4. 添加反馈
  5. 添加反馈项中输入您的意见。
  6. 可选:添加您的电子邮件地址,以便文档团队可以联系您以讨论您的问题。
  7. Submit

第 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 环境:

  1. 为 RHOSP 次要更新准备您的环境。
  2. 将 undercloud 更新至最新的 OpenStack 16.2.z 版本。
  3. 将 overcloud 更新至最新的 OpenStack 16.2.z 版本。
  4. 升级所有 Red Hat Ceph Storage 服务。
  5. 运行 convergence 命令刷新 overcloud 堆栈。

如果您有多堆栈基础架构,则逐一完全更新每个 overcloud 堆栈。如果您有一个分布式计算节点(DCN)基础架构,则完全更新中央位置的 overcloud,然后在每个边缘站点更新 overcloud,一次更新 overcloud。

更新 RHOSP 环境前的注意事项

要帮助指导您在更新过程中,请考虑以下信息:

已知问题可能会阻止更新

查看以下已知问题:可能会影响成功次版本更新。

BZ#1975240 - 在启用 tsx 标志时从 16.1 升级到 16.2,计算节点在更新期间重启,ping 丢失时重启

从 Red Hat Enterprise Linux (RHEL) 版本 8.3 开始,默认禁用对 Intel 事务同步扩展 (TSX) 功能的支持。这会导致以下迁移方案中主机间实例实时迁移问题:

  • 从启用了 TSX 内核参数的主机迁移到禁用了 TSX 内核参数的主机。

在支持 TSX 功能的 Intel 主机中,实时迁移可能会失败。有关受此问题影响的 CPU 的更多信息,请参阅受影响的配置

如需更多信息,请参阅以下红帽知识库解决方案有关 Intel TSX 对 OpenStack 客户端的影响的指南

BZ#1872404 - 在保持仲裁会导致意外节点关闭时并行重启节点
在解决此问题之前,对于基于可组合角色的节点,您必须先更新 Database 角色,然后再更新 Controller, Messaging, Compute, Ceph 和其他角色。
BZ#2027787 - Undercloud 升级到 16.2 会失败,因为存在 swtpm 的依赖项
advanced-virt-for-rhel-8-x86_64-eus-rpmsadvanced-virt-for-rhel-8-x86_64-rpms 存储库中存在一个已知问题,可防止升级成功。要在升级前禁用这些软件仓库,请参阅 OSP 16.2 中不再需要红帽知识库解决方案 advanced-virt-for-rhel-8-x86_64-rpms
BZ#2009106 - tripleo_nova_libvirt 重启两次后的 podman panic
从 RHOSP 16.1 升级到 16.2 中存在一个已知问题:从 RHOSP 16.2.1 升级到 16.2.2,与 Podman 和 libvirt 服务中的更改相关。如果您在升级前没有迁移工作负载,则升级可能会失败。
BZ#2094265 - Data plane disruption during update from 16.2.1, 16.2.0, or any 16.1 release to 16.2.2 or later in ML2/OVN deployments, BZ#2111871 - overcloud external-update run --stack overcloud --tags ovn 导致网络中断

当您将 RHOSP 从 16.2.0, 16.2.1, 或任何 16.1 更新至 16.2.2 或 16.2.3 时,大量的连接丢失会影响您的负载。

这个错误是由 Open Virtual Network (OVN) 21.12 中的数据库模式变化触发,该变化是在 RHOSP 16.2.2. 和 16.2.3 中引入的。OVN 21.12 包含之前版本不存在的新列。OVN 数据库架构的更改应不会在 OpenStack 中造成影响,但这个特定的更改会受一个程序错误的影响。

特别是,当您运行以下命令时,实例连接会因变量时长(从 20 秒到 3 分钟)丢失:

$ openstack overcloud external-update run --stack overcloud --tags ovn

这个停机时间意外,红帽工程团队会调查。如果您的环境无法容忍停机时间,红帽建议您等待更新您的环境,直到有临时解决方案为止。

BZ2129445 - 16.2.0 known issue nova_libvirt tag: 16.2.0-55.1638436404 libvirt version incompatibility leaves instances in unmanageable state after minor update from RHOSP 16.2.0 to RHOSP 16.2.x

在评估 libvirt 版本不兼容的风险前,不要从 RHOSP 16.2.0 更新至 16.2.2 或 16.2.3。要完成此评估,请检查所有 Compute 节点上的 nova_libvirt 容器中的 libvirt 软件包:

$ sudo podman exec nova_libvirt rpm -q libvirt

如果 libvirt 版本为 7.0,则部署不会受到这个程序错误的影响。您可以执行更新。

如果 libvirt 版本为 7.6,则部署会受到这个程序错误的影响。您的更新存在风险。选择以下选项之一:

  • Wait: 在发布了 RHOSP 16.2.4 时直接更新到 RHOSP 16.2.4。此发行版本包括针对不兼容问题的修复。如果您延迟了更新,则这是首选的选项。
  • 热修复:请联络您的红帽支持代表来探索您的环境是否与解决问题的热修复程序兼容。如果即时更新需要强大业务,则使用此选项。

如果您已经使用版本不兼容的更新,请参阅从 RHOSP16.2.0 升级到 RHOSP16.2.z 后实例无法管理,以了解有关解决这个问题的指导。

流程

要为 RHOSP 环境进行次要更新准备,请完成以下步骤:

1.1. 长生命版本的升级路径

在开始更新或升级前,熟悉可能的更新和升级路径。

注意

您可以在 /etc/rhosp-release/etc/redhat-release 文件中查看当前的 RHOSP 和 RHEL 版本。

表 1.1. 更新版本路径

当前版本目标版本

RHEL 7.x 上的 RHOSP 10.0.x

RHEL 7.7 latest 上的 RHOSP 10.0

RHEL 7.x 上的 RHOSP 13.0.x

RHEL 7.9 latest 上最新的 RHOSP 13.0

RHEL 8.2 上的 RHOSP 16.1.x

RHEL 8.2 最新 RHOSP 16.1 最新

RHEL 8.2 上的 RHOSP 16.1.x

RHEL 8.4 最新版 RHOSP 16.2

RHEL 8.4 上的 RHOSP 16.2.x

RHEL 8.4 最新版 RHOSP 16.2

表 1.2. 升级版本路径

当前版本目标版本

RHEL 7.7 上的 RHOSP 10

RHEL 7.9 latest 上的 RHOSP 13

RHEL 7.9 上的 RHOSP 13

RHEL 8.2 最新 RHOSP 16.1 最新

RHEL 7.9 上的 RHOSP 13

RHEL 8.4 最新版 RHOSP 16.2

如需更多信息,请参阅升级框架(13 到 16.2)。

红帽提供了两个选项,供您将环境升级到下一个长生命周期版本:

原位升级
在现有环境中对服务进行升级。本指南主要关注此选项。
并行迁移
创建新的 Red Hat OpenStack Platform 16.2 环境,并将您的工作负载从当前环境迁移到新环境中。有关 Red Hat OpenStack Platform 并行迁移的更多信息,请联络红帽全球支持服务。
重要

这个表中的持续时间是基于内部测试的最小估算值,可能不适用于所有生产环境。例如,如果您的硬件有低规格或延长的启动周期,则允许更多的时间使用这些持续时间。要准确衡量每个任务的升级持续时间,请在测试环境中执行与生产环境类似的硬件。

表 1.3. 升级路径的影响和持续时间

 原位升级并行迁移

undercloud 的升级持续时间

每个主要操作的预计持续时间都包括:

  • 30 分钟(Leapp upgrade)命令
  • 30 分钟(Leapp 重启)
  • 40 分钟( director 升级)

无。除了现有的 undercloud 外,您还将创建新的 undercloud。

overcloud control plane 的升级持续时间

每个 Controller 节点的估算:

  • 60 分钟用于 Leapp 升级并重启
  • 服务升级 60 分钟

无。除了现有的 control plane 外,您还需要创建新的 control plane。

control plane 的中断持续时间

bootstrap Controller 节点的服务升级期间,大约 60 分钟。

无。两个 overcloud 在工作负载迁移期间都正常运行。

control plane 中断的结果

您不能在停机期间执行 OpenStack 操作。

没有中断。

overcloud data plane 的升级持续时间

每个 Compute 节点和 Ceph Storage 节点的估算:

  • 60 分钟用于 Leapp 升级并重启
  • 30 分钟服务升级

无。除了现有的 data plane 外,您还会创建新的数据平面。

data plane 的中断持续时间

由于工作负载从节点迁移到节点,因此中断最小。

由于工作负载从 overcloud 迁移到 overcloud,因此中断最小。

额外的硬件要求

不需要额外的硬件。

需要额外硬件来创建新 undercloud 和 overcloud。

1.2. 将环境锁定到 Red Hat Enterprise Linux 发行版本中

Red Hat OpenStack Platform(RHOSP)16.2 支持 Red Hat Enterprise Linux(RHEL)8.4。在执行更新前,将 undercloud 和 overcloud 软件仓库锁定到 RHEL 8.4 版本,以避免将操作系统升级到较新的次版本。

流程

  1. stack 用户的身份登录 undercloud。
  2. Source stackrc 文件:

    $ source ~/stackrc
  3. 编辑 overcloud 订阅管理环境文件,这是包含 RhsmVars 参数的文件。此文件的默认名称为 rhsm.yml
  4. 检查您的订阅管理配置是否包含 rhsm_release 参数。如果 rhsm_release 参数不存在,请添加它并将其设置为 8.4:

    parameter_defaults:
      RhsmVars:
        …​
        rhsm_username: "myusername"
        rhsm_password: "p@55w0rd!"
        rhsm_org_id: "1234567"
        rhsm_pool_ids: "1a85f9223e3d5e43013e3d6e8ff506fd"
        rhsm_method: "portal"
        rhsm_release: "8.4"
  5. 保存 overcloud 订阅管理环境文件。
  6. 创建 overcloud 的静态清单文件:

    $ tripleo-ansible-inventory --ansible_ssh_user heat-admin --static-yaml-inventory ~/inventory.yaml

    如果您使用与默认 overcloud 名称不同的 overcloud 名称,请使用 --plan 选项来设置 overcloud 的名称。

  7. 创建一个 playbook,其中包含将操作系统版本锁定到所有节点上的 RHEL 8.4 的任务:

    $ cat > ~/set_release.yaml <<'EOF'
    - hosts: all
      gather_facts: false
      tasks:
        - name: set release to 8.4
          command: subscription-manager release --set=8.4
          become: true
    EOF
  8. 运行 set_release.yaml playbook:

    $ ansible-playbook -i ~/inventory.yaml -f 25 ~/set_release.yaml --limit <undercloud>,<Controller>,<Compute>
    • 使用 --limit 选项,将内容应用到所有 RHOSP 节点。将 & lt;undercloud& gt ; , <Controller & gt; , <Compute > 替换为环境中包含这些节点的 Ansible 组。
    • 如果您要为这些节点使用不同的订阅,则无法针对 Ceph Storage 节点运行此 playbook。
注意

要手动将节点锁定到版本,登录到节点并运行 subscription-manager 发行版本 命令:

$ sudo subscription-manager release --set=8.4

1.3. 切换到延长更新支持(EUS)软件仓库

您的 Red Hat OpenStack Platform(RHOSP) 订阅包括了 Red Hat Enterprise Linux (RHEL) 8.4 延长更新支持 (EUS) 的软件仓库。EUS 软件仓库包括 RHEL 8.4 的最新安全补丁和程序错误修复。在进行更新前,切换到以下软件仓库。

表 1.4. RHEL 8.4 的 EUS 软件仓库

标准软件仓库EUS 仓库

rhel-8-for-x86_64-baseos-rpms

rhel-8-for-x86_64-baseos-eus-rpms

rhel-8-for-x86_64-appstream-rpms

rhel-8-for-x86_64-appstream-eus-rpms

rhel-8-for-x86_64-highavailability-rpms

rhel-8-for-x86_64-highavailability-eus-rpms

重要

您必须使用 EUS 软件仓库保持与 Podman 特定版本的兼容性。后续 Podman 版本在 Red Hat OpenStack Platform 16.2 中未测试,并可能导致意外的结果。

流程

  1. stack 用户的身份登录 undercloud。
  2. Source stackrc 文件:

    $ source ~/stackrc
  3. 编辑 overcloud 订阅管理环境文件,这是包含 RhsmVars 参数的文件。此文件的默认名称为 rhsm.yml
  4. 检查订阅管理配置中的 rhsm_repos 参数。如果此参数不包括 EUS 软件仓库,请将相关的软件仓库改为 EUS 版本:

    parameter_defaults:
      RhsmVars:
        rhsm_repos:
          *- rhel-8-for-x86_64-baseos-eus-rpms*
          *- rhel-8-for-x86_64-appstream-eus-rpms*
          *- rhel-8-for-x86_64-highavailability-eus-rpms*
          - ansible-2.9-for-rhel-8-x86_64-rpms
          - openstack-16.2-for-rhel-8-x86_64-rpms
          - rhceph-4-tools-for-rhel-8-x86_64-rpms
          - fast-datapath-for-rhel-8-x86_64-rpms
  5. 保存 overcloud 订阅管理环境文件。
  6. 创建 overcloud 的静态清单文件:

    $ tripleo-ansible-inventory --ansible_ssh_user heat-admin --static-yaml-inventory ~/inventory.yaml

    如果您使用与默认 overcloud 名称不同的 overcloud 名称,请使用 --plan 选项来设置 overcloud 的名称。

  7. 创建一个 playbook,其中包含一个在所有节点上将软件仓库设置为 RHEL 8.4 EUS 的任务:

    $ cat > ~/change_eus.yaml <<'EOF'
    - hosts: all
      gather_facts: false
      tasks:
        - name: change to eus repos
          command: subscription-manager repos --disable=rhel-8-for-x86_64-baseos-rpms --disable=rhel-8-for-x86_64-appstream-rpms --disable=rhel-8-for-x86_64-highavailability-rpms --enable=rhel-8-for-x86_64-baseos-eus-rpms --enable=rhel-8-for-x86_64-appstream-eus-rpms --enable=rhel-8-for-x86_64-highavailability-eus-rpms
          become: true
    EOF
  8. 运行 change_eus.yaml playbook:

    $ ansible-playbook -i ~/inventory.yaml -f 25 ~/change_eus.yaml --limit <undercloud>,<Controller>,<Compute>
    • 使用 --limit 选项,将内容应用到所有 Red Hat OpenStack Platform 节点。将 & lt;undercloud& gt ; , <Controller & gt; , <Compute > 替换为环境中包含这些节点的 Ansible 组。
    • 如果您要为这些节点使用不同的订阅,则无法针对 Ceph Storage 节点运行此 playbook。

1.4. 更新 Red Hat Openstack Platform 和 Ansible 软件仓库

更新您的软件仓库以使用 Red Hat OpenStack Platform(RHOSP)16.2 和 Ansible 2.9 软件包。

流程

  1. stack 用户的身份登录 undercloud。
  2. Source stackrc 文件:

    $ source ~/stackrc
  3. 编辑 overcloud 订阅管理环境文件,这是包含 RhsmVars 参数的文件。此文件的默认名称为 rhsm.yml
  4. 检查订阅管理配置中的 rhsm_repos 参数。如果 rhsm_repos 参数使用 RHOSP 16.1 和 Ansible 2.8 软件仓库,请将存储库改为正确的版本:

    parameter_defaults:
      RhsmVars:
        rhsm_repos:
          - rhel-8-for-x86_64-baseos-eus-rpms
          - rhel-8-for-x86_64-appstream-eus-rpms
          - rhel-8-for-x86_64-highavailability-eus-rpms
          *- ansible-2.9-for-rhel-8-x86_64-rpms*
          *- openstack-16.2-for-rhel-8-x86_64-rpms*
          - fast-datapath-for-rhel-8-x86_64-rpms
  5. 保存 overcloud 订阅管理环境文件。
  6. 创建 overcloud 的静态清单文件:

    $ tripleo-ansible-inventory --ansible_ssh_user heat-admin --static-yaml-inventory ~/inventory.yaml

    如果您使用与默认 overcloud 名称不同的 overcloud 名称,请使用 --plan 选项来设置 overcloud 的名称。

  7. 创建一个 playbook,它包含在所有 RHOSP 节点上将存储库设置为 RHOSP 16.2 的任务:

    $ cat > ~/update_rhosp_repos.yaml <<'EOF'
    - hosts: all
      gather_facts: false
      tasks:
        - name: change osp repos
          command: subscription-manager repos --disable=openstack-16.1-for-rhel-8-x86_64-rpms --enable=openstack-16.2-for-rhel-8-x86_64-rpms --disable=ansible-2.8-for-rhel-8-x86_64-rpms --enable=ansible-2.9-for-rhel-8-x86_64-rpms
          become: true
    EOF
  8. 运行 update_rhosp_repos.yaml playbook:

    $ ansible-playbook -i ~/inventory.yaml -f 25 ~/update_rhosp_repos.yaml --limit <undercloud>,<Controller>,<Compute>
    • 使用 --limit 选项,将内容应用到所有 RHOSP 节点。将 & lt;undercloud& gt ; , <Controller & gt; , <Compute > 替换为环境中包含这些节点的 Ansible 组。
    • 如果您要为这些节点使用不同的订阅,则无法针对 Ceph Storage 节点运行此 playbook。
  9. 创建一个 playbook,它包含在所有 Ceph Storage 节点上将存储库设置为 RHOSP 16.2 的任务:

    $ cat > ~/update_ceph_repos.yaml <<'EOF'
    - hosts: all
      gather_facts: false
      tasks:
        - name: change ceph repos
          command: subscription-manager repos --disable=openstack-16-deployment-tools-for-rhel-8-x86_64-rpms --enable=openstack-16.2-deployment-tools-for-rhel-8-x86_64-rpms --disable=ansible-2.8-for-rhel-8-x86_64-rpms --enable=ansible-2.9-for-rhel-8-x86_64-rpms
          become: true
    EOF
  10. 运行 update_ceph_repos.yaml playbook:

    $ ansible-playbook -i ~/inventory.yaml -f 25 ~/update_ceph_repos.yaml --limit CephStorage

    使用 --limit 选项,将内容应用到 Ceph Storage 节点。

1.5. 设置 container-tools 模块版本

container-tools 模块设置为版本 3.0,以确保在所有节点上使用正确的软件包版本。

流程

  1. stack 用户的身份登录 undercloud。
  2. Source stackrc 文件:

    $ source ~/stackrc
  3. 创建 overcloud 的静态清单文件:

    $ tripleo-ansible-inventory --ansible_ssh_user heat-admin --static-yaml-inventory ~/inventory.yaml

    如果您使用与默认 overcloud 名称不同的 overcloud 名称,请使用 --plan 选项来设置 overcloud 的名称。

  4. 创建一个 playbook,其中包含将 container-tools 模块设置为所有节点上的版本 3.0 的任务:

    $ cat > ~/container-tools.yaml <<'EOF'
    - hosts: all
      gather_facts: false
      tasks:
        - name: disable default dnf module for container-tools
          command: dnf module reset -y container-tools
          become: true
        - name: set dnf module for container-tools:3.0
          command: dnf module enable -y container-tools:3.0
          become: true
    EOF
  5. 针对所有节点运行 container-tools.yaml playbook:

    $ ansible-playbook -i ~/inventory.yaml -f 25 ~/container-tools.yaml

1.6. 更新容器镜像准备文件

容器准备文件是包含 ContainerImagePrepare 参数的文件。您可以使用此文件定义为 undercloud 和 overcloud 获取容器镜像的规则。

在更新环境之前,请检查该文件以确保获取正确的镜像版本。

流程

  1. 编辑容器准备文件。此文件的默认名称为 containers-prepare-parameter.yaml
  2. 检查每个规则集 的标签 参数是否设置为 16.2

    parameter_defaults:
      ContainerImagePrepare:
      - push_destination: true
        set:
          ...
          *tag: '16.2'*
        tag_from_label: '{version}-{release}'
    注意

    如果您不想将特定的标签用于更新,如 16.216.2.2,请删除 标签 键-值对,并指定 tag_from_label。这使用已安装的 Red Hat OpenStack Platform 版本来确定要在更新过程中使用的标签值。

  3. 保存这个文件。

1.7. 更新 SSL/TLS 配置

resource_registry 中删除 NodeTLSData 资源,以更新 SSL/TLS 配置。

流程

  1. stack 用户的身份登录 undercloud。
  2. Source stackrc 文件:

    $ source ~/stackrc
  3. 编辑自定义 overcloud SSL/TLS 公共端点文件,该文件通常命名为 ~/templates/enable-tls.yaml
  4. resource_registry 中删除 NodeTLSData 资源:

    resource_registry:
      *OS::TripleO::NodeTLSData: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/tls/tls-cert-inject.yaml*
      ...

    overcloud 部署使用 HAProxy 中的新服务来确定是否启用了 SSL/TLS。

    注意

    如果这是 enable-tls.yaml 文件的 resource_registry 部分的唯一资源,请删除完整的 resource_registry 部分。

  5. 保存 SSL/TLS 公共端点文件。
  6. 如果您要从 Red Hat OpenStack Platform 16.1 更新,您必须更新 Red Hat Identity Manager (IdM)中的权限,以获取所有预更新检查以传递。使用 ssh 登录到运行 IdM 的服务器,然后运行以下命令:

    $ kinit admin
    $ ipa privilege-add-permission 'Nova Host Management' --permission 'System: Modify Realm Domains'

1.8. 在 overcloud 中禁用隔离

在更新 overcloud 之前,请确保已禁用隔离功能。

如果在 Controller 节点更新过程中在您的环境中部署隔离,overcloud 可能会检测到特定的节点被禁用并尝试隔离操作,这可能会导致意外的结果。

如果您在 overcloud 中启用了隔离,您必须临时在更新期间禁用隔离,以避免产生任何意外的结果。

流程

  1. stack 用户的身份登录 undercloud。
  2. source stackrc 文件:

    $ source ~/stackrc
  3. 登录到 Controller 节点,并运行 Pacemaker 命令以禁用隔离:

    $ ssh heat-admin@<controller_ip> "sudo pcs property set stonith-enabled=false"

    <controller_ip > 替换为 Controller 节点的 IP 地址。您可以使用 openstack server list 命令查找 Controller 节点的 IP 地址。

  4. fencing.yaml 环境文件中,将 EnableFencing 参数设置为 false,以确保隔离在更新过程中被禁用。

第 2 章 更新 undercloud

您可以使用 director 更新 undercloud 节点上的主软件包。要将 undercloud 及其 overcloud 镜像更新至最新的 Red Hat OpenStack Platform(RHOSP)16.2 版本,请完成以下步骤:

先决条件

  • 在将 undercloud 更新至最新的 RHOSP 16.2 版本前,请确保完成所有更新准备过程。更多信息请参阅 第 1 章 准备次要更新

2.1. 对容器化 undercloud 执行次要更新

director 提供了更新 undercloud 节点上的主软件包的命令。使用 director 在 RHOSP 环境的当前版本中执行次要更新。

流程

  1. 在 undercloud 节点上,以 stack 用户身份登录。
  2. Source stackrc 文件:

    $ source ~/stackrc
  3. 使用 dnf update 命令更新 director 主软件包:

    $ sudo dnf update -y python3-tripleoclient* tripleo-ansible ansible
  4. 使用 openstack undercloud upgrade 命令更新 undercloud 环境:

    $ openstack undercloud upgrade
  5. 等待 undercloud 更新过程完成。
  6. 重新引导 undercloud 以更新操作系统的内核和其他系统软件包:

    $ sudo reboot
  7. 稍等片刻,直到节点启动。

2.2. 更新 overcloud 镜像

您必须将当前的 overcloud 镜像替换为新版本,以确保 director 可以使用最新版本的 RHOSP 软件内省并置备节点。

先决条件

流程

  1. Source stackrc 文件:

    $ source ~/stackrc
  2. stack 用户的主目录(/home/stack/images)的 images 中删除任何存在的镜像。

    $ rm -rf ~/images/*
  3. 解压存档:

    $ cd ~/images
    $ for i in /usr/share/rhosp-director-images/overcloud-full-latest-16.2.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-16.2.tar; do tar -xvf $i; done
    $ cd ~
  4. 将最新的镜像导入到 director:

    $ openstack overcloud image upload --update-existing --image-path /home/stack/images/
  5. 配置节点以使用新镜像:

    $ openstack overcloud node configure $(openstack baremetal node list -c UUID -f value)
  6. 验证新镜像是否存在:

    $ openstack image list
    $ ls -l /var/lib/ironic/httpboot
重要
  • 部署 overcloud 节点时,请确保 overcloud 镜像版本对应于对应的 heat 模板版本。例如,只使用 RHOSP 16.2 镜像和 RHOSP 16.2 heat 模板。
  • 如果您部署了使用红帽客户门户网站或 Red Hat Satellite Server 的连接的环境,overcloud 镜像和软件包存储库版本可能不同步。为确保 overcloud 镜像和软件包存储库版本匹配,您可以使用 virt-customize 工具。如需更多信息,请参阅使用 virt-customize 修改 Red Hat Linux OpenStack Platform Overcloud 镜像。
  • 新的 overcloud-full 镜像替换旧的 overcloud-full 镜像。如果对旧镜像进行了更改,您必须重复新镜像的更改,特别是您要以后部署新节点。

第 3 章 更新 overcloud

更新 undercloud 后,您可以通过运行 overcloud 和容器镜像准备命令、更新节点并运行 overcloud 更新 聚合命令来更新 overcloud。control plane API 在次版本更新过程中可以完全可用。

先决条件

  • 您已将 undercloud 节点更新至最新版本。更多信息请参阅 第 2 章 更新 undercloud
  • 如果您在 stack 用户主目录中使用一组本地核心模板,请确保更新模板并使用高级 Overcloud 自定义指南中的 使用自定义核心 Heat 模板中的推荐工作流。在升级 overcloud 前,您必须更新本地副本。

流程

要更新 overcloud,您必须完成以下步骤:

3.1. 运行 overcloud 更新准备

若要为更新过程准备 overcloud,您必须运行 openstack overcloud update prepare 命令,该命令更新 overcloud 计划到 Red Hat OpenStack Platform(RHOSP)16.2,并为更新准备节点。

先决条件

  • 如果使用 Ceph 订阅并将 director 配置为将 overcloud-minimal 镜像用于 Ceph 存储节点,您必须确保 roles_data.yaml 角色定义文件中,rhsm_enforce 参数设置为 False
  • 如果呈现了自定义 NIC 模板,则必须使用 openstack-tripleo-heat-templates 集合的更新版本重新生成模板,以避免与 overcloud 版本不兼容。有关自定义 NIC 模板的更多信息,请参阅高级 Overcloud 自定义指南中的 Rendering 默认网络接口模板以进行自定义
注意

对于带有 OVN 部署的分布式计算节点(边缘)架构,您必须为每个使用 Compute、distributedCompute 或 DistributedComputeHCI 节点的堆栈完成此步骤,然后才能 在所有 overcloud 服务器上更新 ovn-controller 容器的部分

流程

  1. Source stackrc 文件:

    $ source ~/stackrc
  2. 运行更新准备命令:

    $ openstack overcloud update prepare \
        --templates \
        --stack <stack_name> \
        -r <roles_data_file> \
        -n <network_data_file> \
        -e <environment_file> \
        -e <environment_file> \
        ...

    包括与您的环境相关的以下选项:

    • 如果 overcloud 堆栈的名称与默认名称 overcloud 不同,请在更新准备命令中包括 --stack 选项,并将 < stack_name > 替换为堆栈的名称。
    • 如果您使用自己的自定义角色,请包含您的自定义角色(<roles_data&gt;)文件(-r)。
    • 如果您使用自定义网络,请包括您的可组合网络(<network_data&gt;)文件(-n)。
    • 如果部署高可用性集群,请在更新准备命令中包括 --ntp-server 选项,或者在环境文件中包括 NtpServer 参数和值。
    • 任何自定义配置环境文件(-e)。
  3. 等待更新准备过程完成。

3.2. 运行容器镜像准备

在更新 overcloud 之前,必须准备您的环境所需的所有容器镜像配置,并将最新的 RHOSP 16.2 容器镜像拉取到 undercloud。

要完成容器镜像准备,您必须针对具有 container_image_prepare 标签的任务运行 openstack overcloud external-update run 命令。

注意

如果您不使用默认堆栈名称(即 overcloud ),将堆栈名称设置为 --stack < stack_name& gt; 选项,并将 &lt ;stack_name > 替换为堆栈的名称。

流程

  1. Source stackrc 文件:

    $ source ~/stackrc
  2. 针对具有 container_image_prepare 标签的任务运行 openstack overcloud external-update run 命令:

    $ openstack overcloud external-update run --stack <stack_name> --tags container_image_prepare

3.3. 可选:更新所有 overcloud 服务器上的 ovn-controller 容器

如果您使用 Modular Layer 2 Open Virtual Network 机制驱动程序(ML2/OVN)部署 overcloud,将 ovn-controller 容器更新至最新的 RHOSP 16.2 版本。更新发生在每个运行 ovn-controller 容器的 overcloud 服务器上。

重要

以下流程更新为分配 Compute 角色的服务器上的 ovn-controller 容器,然后更新分配了 Controller 角色的服务器上的 ovn-northd 服务。
如果您在执行此流程前意外更新了 ovn-northd 服务,您可能无法访问虚拟机或创建新虚拟机或虚拟网络。以下流程恢复连接。

注意

对于分布式计算节点(边缘)架构,您必须为每个使用 Compute、distributedCompute 或 DistributedComputeHCI 节点的堆栈完成此步骤,然后才能 更新所有 Controller 节点

流程

  1. stack 用户的身份登录 undercloud。
  2. Source stackrc 文件:

    $ source ~/stackrc
  3. 针对具有 ovn 标签的任务运行 openstack overcloud external-update run 命令:

    $ openstack overcloud external-update run --stack <stack_name> --tags ovn
    • 如果 overcloud 堆栈的名称与默认堆栈名称 overcloud 不同,请使用 --stack 选项设置您的堆栈名称,并将 < stack_name& gt; 替换为您的堆栈的名称。
  4. 等待 ovn-controller 容器更新完成。

3.4. 更新所有 Controller 节点

将所有 Controller 节点更新至最新的 RHOSP 16.2 版本。运行 openstack overcloud update run 命令,并包含 --limit Controller 选项,以仅限将操作限制到 Controller 节点。control plane API 在次要更新过程中被完全支持。

重要

在解决 BZ#1872404 之前,对于基于可组合角色的节点,您必须先更新 Database 角色,然后再更新 Controller, Messaging, Compute, Ceph 和其他角色。

注意

如果您不使用默认堆栈名称(即 overcloud ),将堆栈名称设置为 --stack < stack_name& gt; 选项,并将 &lt ;stack_name > 替换为堆栈的名称。

流程

  1. Source stackrc 文件:

    $ source ~/stackrc
  2. 运行 update 命令:

    $ openstack overcloud update run --stack <stack_name> --limit Controller
  3. 等待 Controller 节点更新完成。

3.5. 更新所有 Compute 节点

将所有 Compute 节点更新至最新的 RHOSP 16.2 版本。要更新 Compute 节点,请运行 openstack overcloud update run 命令,并包含 --limit Compute 选项,以仅限将操作限制到 Compute 节点。

并行化注意事项

当您更新大量 Compute 节点以提高性能时,您可以在后台运行多个更新任务,并配置每个任务来更新独立的 20 个节点。例如,如果您的部署中有 80 个 Compute 节点,您可以运行以下命令来并行更新 Compute 节点:

$ openstack overcloud update run -y --limit 'Compute[0:19]' > update-compute-0-19.log 2>&1 &
$ openstack overcloud update run -y --limit 'Compute[20:39]' > update-compute-20-39.log 2>&1 &
$ openstack overcloud update run -y --limit 'Compute[40:59]' > update-compute-40-59.log 2>&1 &
$ openstack overcloud update run -y --limit 'Compute[60:79]' > update-compute-60-79.log 2>&1 &

这种对节点空间分区的方法是随机的,您不控制要更新哪些节点。节点的选择是基于在运行 tripleo-ansible-inventory 命令时生成的清单文件。

要更新特定的 Compute 节点,列出您要在用逗号分开的批处理中更新的节点:

$ openstack overcloud update run --limit <Compute0>,<Compute1>,<Compute2>,<Compute3>
注意

如果您不使用默认堆栈名称(即 overcloud ),将堆栈名称设置为 --stack < stack_name& gt; 选项,并将 &lt ;stack_name > 替换为堆栈的名称。

流程

  1. Source stackrc 文件:

    $ source ~/stackrc
  2. 运行 update 命令:

    $ openstack overcloud update run --stack <stack_name> --limit Compute
  3. 等待 Compute 节点更新完成。

3.6. 更新所有 HCI Compute 节点

将 Hyperconverged Infrastructure(HCI)Compute 节点更新至最新的 RHOSP 16.2 版本。要更新 HCI Compute 节点,请运行 openstack overcloud update 命令,并包含 --limit ComputeHCI 选项,以仅限 HCI 节点的操作。您还必须运行 openstack overcloud external-update run --tags ceph 命令对容器化的 Red Hat Ceph Storage 4 集群执行更新。

先决条件

  • 在运行 ceph-mon 服务的 Ceph Monitor 或 Controller 节点上,检查 Red Hat Ceph Storage 集群是否正常运行,并且 pg 状态是 active+clean

    $ sudo podman exec -it ceph-mon-controller-0 ceph -s

    如果 Ceph 集群处于健康状态,它将返回 HEALTH_OK 状态。

    如果 Ceph 集群状态不健康,它将返回 HEALTH_WARNHEALTH_ERR 状态。有关故障排除指南,请参阅 Red Hat Ceph Storage 4 故障排除指南

流程

  1. Source stackrc 文件:

    $ source ~/stackrc
  2. 运行 update 命令:

    $ openstack overcloud update run --stack <stack_name> --limit ComputeHCI
    • 将 &lt ;stack_name > 替换为堆栈的名称。如果没有指定,则默认为 overcloud
  3. 等待节点更新完成。
  4. 运行 Ceph Storage update 命令:

    $ openstack overcloud external-update run --stack <stack_name> --tags ceph
  5. 等待计算 HCI 节点更新完成。

3.7. 更新所有 DistributedComputeHCI 节点

更新特定于分布式计算节点架构的角色。当您升级分布式计算节点时,首先更新 DistributedComputeHCI 节点,然后更新 DistributedComputeHCIScaleOut 节点。

注意

如果您不使用默认堆栈名称(即 overcloud),将堆栈名称设置为 --stack <stack_name& gt; 选项,并将 <_stack_name_> 替换为堆栈的名称。

先决条件

  • 在运行 ceph-mon 服务的 Ceph Monitor 或 Controller 节点上,检查 Red Hat Ceph Storage 集群是否正常运行,并且 pg 状态是 active+clean

    $ sudo podman exec -it ceph-mon-controller-0 ceph -s

    如果 Ceph 集群处于健康状态,它将返回 HEALTH_OK 状态。

    如果 Ceph 集群状态不健康,它将返回 HEALTH_WARNHEALTH_ERR 状态。有关故障排除指南,请参阅 Red Hat Ceph Storage 4 故障排除指南

流程

  1. Source stackrc 文件:

    $ source ~/stackrc
  2. 运行 update 命令:

    $ openstack overcloud update run --stack <stack_name> --limit DistributedComputeHCI
  3. 等待 DistributedComputeHCI 节点更新完成。
  4. 运行 Ceph Storage update 命令:

    $ openstack overcloud external-update run --stack <stack_name> --tags ceph
  5. 等待 DistributedComputeHCI 节点更新完成。
  6. 使用同样的流程更新 DistributedComputeHCIScaleOut 节点。

3.8. 更新所有 Ceph Storage 节点

将 Red Hat Ceph Storage 节点更新至最新的 RHOSP 16.2 版本。

重要

RHEL 8.4 支持 RHOSP 16.2。但是,映射到 Ceph Storage 角色更新的主机到最新的主 RHEL 发行版本。有关更多信息,请参阅 Red Hat Ceph Storage: 支持的配置

先决条件

  • 在运行 ceph-mon 服务的 Ceph Monitor 或 Controller 节点上,检查 Red Hat Ceph Storage 集群是否正常运行,并且 pg 状态是 active+clean

    $ sudo podman exec -it ceph-mon-controller-0 ceph -s

    如果 Ceph 集群处于健康状态,它将返回 HEALTH_OK 状态。

    如果 Ceph 集群状态不健康,它将返回 HEALTH_WARNHEALTH_ERR 状态。有关故障排除指南,请参阅 Red Hat Ceph Storage 4 故障排除指南

流程

  1. Source stackrc 文件:

    $ source ~/stackrc
  2. 运行 update 命令:

    $ openstack overcloud update run --stack  <stack_name> --limit CephStorage
    • 将 &lt ;stack_name > 替换为堆栈的名称。如果没有指定,则默认为 overcloud
  3. 等待节点更新完成。
  4. 运行 Ceph Storage 容器更新命令,以作为外部进程运行 ceph-ansible 并更新 Red Hat Ceph Storage 4 容器:

    $ openstack overcloud external-update run --tags ceph
  5. 等待 Ceph Storage 容器更新完成。

3.9. 执行在线数据库更新

有些 overcloud 组件需要在线更新或迁移其数据库表。要执行在线数据库更新,请针对具有 online_upgrade 标记的任务运行 openstack overcloud external-update 命令。

在线数据库更新适用于以下组件:

  • OpenStack Block Storage (cinder)
  • OpenStack Compute (nova)

流程

  1. Source stackrc 文件:

    $ source ~/stackrc
  2. 针对使用 online_upgrade 标签的任务运行 openstack overcloud external-update run 命令:

    $ openstack overcloud external-update run --tags online_upgrade

3.10. 最后介绍更新

要完成最新 RHOSP 16.2 版本的更新,您必须更新 overcloud 堆栈。这可确保堆栈资源结构与常规部署 OSP 16.2 一致,并可在以后执行标准 openstack overcloud deploy 功能。

流程

  1. Source stackrc 文件:

    $ source ~/stackrc
  2. 要在 overcloud 中重新启用隔离,在 fencing.yaml 环境文件中,将 EnableFencing 参数设置为 true
  3. 运行更新最终化命令:

    $ openstack overcloud update converge \
        --templates \
        --stack <stack_name> \
        -r <roles_data_file> \
        -n <network_data_file> \
        -e <environment_file> \
        -e <environment_file> \
        ...
        ...

    包括与您的环境相关的以下选项:

    • fence.yaml 环境文件,将 EnableFencing 参数设置为 true
    • 如果 overcloud 堆栈的名称与默认名称 overcloud 不同,请在更新准备命令中包括 --stack 选项,并将 < stack_name > 替换为堆栈的名称。
    • 如果您使用自定义角色,请包含您的自定义角色(<roles_data&gt;)文件(-r)。
    • 如果您使用自定义网络,请包括您的可组合网络(<network_data&gt;)文件(-n)。
    • 任何自定义配置环境文件(-e)。
  4. 等待更新最终化完成。

第 4 章 重新引导 overcloud

在对最新的 16.2 版本执行次要 Red Hat OpenStack Platform(RHOSP)更新后,重启 overcloud。重启会刷新节点,并带有任何关联的内核、系统级别和容器组件更新。这些更新提供性能和安全性优势。计划停机时间来执行重启过程。

使用以下指南了解如何重新引导不同的节点类型:

4.1. 重新引导 Controller 和可组合节点

根据可组合角色重新引导 Controller 节点和独立节点,并排除 Compute 节点和 Ceph Storage 节点。

流程

  1. 登录您要重新引导的节点。
  2. 可选:如果节点使用 Pacemaker 资源,请停止集群:

    [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster stop
  3. 重新引导节点:

    [heat-admin@overcloud-controller-0 ~]$ sudo reboot
  4. 稍等片刻,直到节点启动。

验证

  1. 验证服务是否已启用。

    1. 如果该节点使用 Pacemaker 服务,请检查该节点是否已重新加入集群:

      [heat-admin@overcloud-controller-0 ~]$ sudo pcs status
    2. 如果该节点使用 Systemd 服务,请检查是否所有服务都已启用:

      [heat-admin@overcloud-controller-0 ~]$ sudo systemctl status
    3. 如果该节点使用容器化服务,则检查节点上的所有容器是否已激活:

      [heat-admin@overcloud-controller-0 ~]$ sudo podman ps

4.2. 重新引导 Ceph Storage (OSD) 集群

完成以下步骤以重新引导 Ceph Storage (OSD) 节点集群。

先决条件

  • 在运行 ceph-mon 服务的 Ceph Monitor 或 Controller 节点上,检查 Red Hat Ceph Storage 集群是否正常运行,并且 pg 状态是 active+clean

    $ sudo podman exec -it ceph-mon-controller-0 ceph -s

    如果 Ceph 集群处于健康状态,它将返回 HEALTH_OK 状态。

    如果 Ceph 集群状态不健康,它将返回 HEALTH_WARNHEALTH_ERR 状态。有关故障排除指南,请参阅 Red Hat Ceph Storage 4 故障排除指南

步骤

  1. 登录到运行 ceph-mon 服务的 Ceph Monitor 或 Controller 节点,并临时禁用 Ceph Storage 集群重新平衡:

    $ sudo podman exec -it ceph-mon-controller-0 ceph osd set noout
    $ sudo podman exec -it ceph-mon-controller-0 ceph osd set norebalance
    注意

    如果您有多堆栈或分布式计算节点(DCN)架构,您必须在设置 nooutnorebalance 标志时指定集群名称。例如: sudo podman exec -it ceph-mon-controller-0 ceph osd set noout --cluster <cluster_name>

  2. 选择第一个要重新引导的 Ceph Storage 节点并登录到该节点。
  3. 重新引导节点:

    $ sudo reboot
  4. 稍等片刻,直到节点启动。
  5. 登录到节点,并检查集群的状态:

    $ sudo podman exec -it ceph-mon-controller-0 ceph status

    确认 pgmap 报告的所有 pgs 的状态是否都正常 (active+clean)。

  6. 注销节点,重新引导下一个节点,并检查其状态。重复此过程,直到您已重启所有 Ceph Storage 节点。
  7. 完成后,登录到运行 ceph-mon 服务的 Ceph Monitor 或 Controller 节点,并重新启用集群重新平衡:

    $ sudo podman exec -it ceph-mon-controller-0 ceph osd unset noout
    $ sudo podman exec -it ceph-mon-controller-0 ceph osd unset norebalance
    注意

    如果您有多堆栈或分布式计算节点(DCN)架构,您必须在取消设置 nooutnorebalance 标志时指定集群名称。例如: sudo podman exec -it ceph-mon-controller-0 ceph osd set noout --cluster <cluster_name>

  8. 执行最后的状态检查,确认集群报告 HEALTH_OK

    $ sudo podman exec -it ceph-mon-controller-0 ceph status

4.3. 重新引导 Compute 节点

为确保 Red Hat OpenStack Platform 环境中实例的停机时间最少,迁移实例工作流 概述了从您要重新引导的 Compute 节点迁移实例。

注意

如果您没有将实例从源 Compute 节点迁移到另一个 Compute 节点,则实例可能会在源 Compute 节点上重启,这可能会导致升级失败。这与 Podman 和 libvirt 服务更改的已知问题相关:

迁移实例工作流

  1. 决定是否在重新引导节点前将实例迁移到另一个 Compute 节点。
  2. 选择并禁用您要重新引导的 Compute 节点,使其不置备新实例。
  3. 将实例迁移到另一个 Compute 节点中。
  4. 重新引导空的 Compute 节点。
  5. 启用空的 Compute 节点。

先决条件

  • 重启 Compute 节点之前,必须决定是否在节点重启过程中将实例迁移到另一个 Compute 节点。

    查看在 Compute 节点之间迁移虚拟机实例时可能遇到的迁移约束列表。如需更多信息,请参阅为实例创建配置 Compute Service 中的迁移限制

  • 如果您无法迁移实例,则可设置以下核心模板参数以在 Compute 节点重启后控制实例的状态:

    NovaResumeGuestsStateOnHostBoot
    确定重新引导后是否将实例返回 Compute 节点上的相同状态。设为 False 时,实例保持关闭,必须手动启动。默认值为 False
    NovaResumeGuestsShutdownTimeout

    重启前等待实例被关闭的时间(以秒为单位)。建议不要将此值设置为 0。默认值为 300

    有关 overcloud 参数及其用法的更多信息,请参阅 Overcloud 参数

    步骤

    1. stack 用户的身份登录 undercloud。
    2. 列出所有的 Compute 节点及其 UUID:

      $ source ~/stackrc
      (undercloud) $ openstack server list --name compute

      识别您要重新引导的 Compute 节点的 UUID。

    3. 在 undercloud 中,选择 Compute 节点并禁用它:

      $ source ~/overcloudrc
      (overcloud) $ openstack compute service list
      (overcloud) $ openstack compute service set <hostname> nova-compute --disable
    4. 列出 Compute 节点上的所有实例:

      (overcloud) $ openstack server list --host <hostname> --all-projects
    5. 可选:如果您决定将实例迁移到另一个 Compute 节点,请完成以下步骤:

      1. 如果您决定将实例迁移至另一个 Compute 节点,则使用以下命令之一:

        • 要将实例迁移到其他主机,请运行以下命令:

          (overcloud) $ openstack server migrate <instance_id> --live <target_host> --wait
        • nova-scheduler 自动选择目标主机:

          (overcloud) $ nova live-migration <instance_id>
        • 一次性实时迁移所有实例:

          $ nova host-evacuate-live <hostname>
          注意

          nova 命令可能会引发一些弃用警告,这些警告信息可以被安全忽略。

      2. 稍等片刻,直至迁移完成。
      3. 确认迁移成功完成:

        (overcloud) $ openstack server list --host <hostname> --all-projects
      4. 继续迁移实例,直到 Compute 节点上不剩任何实例。
    6. 登录到 Compute 节点并重新引导节点:

      [heat-admin@overcloud-compute-0 ~]$ sudo reboot
    7. 稍等片刻,直到节点启动。
    8. 重新启用 Compute 节点:

      $ source ~/overcloudrc
      (overcloud) $ openstack compute service set <hostname>  nova-compute --enable
    9. 确认是否已启用 Compute 节点:

      (overcloud) $ openstack compute service list