升级框架(16.2 到 17.1)

步骤

1. 以 stack 用户身份登录 undercloud。

2. 禁用所有默认软件仓库，并启用所需的 Red Hat Enterprise Linux (RHEL)软件仓库：

   [stack@director ~]$ sudo subscription-manager repos --disable=*
   [stack@director ~]$ sudo subscription-manager repos \
   --enable=rhel-8-for-x86_64-baseos-tus-rpms \
   --enable=rhel-8-for-x86_64-appstream-tus-rpms \
   --enable=rhel-8-for-x86_64-highavailability-tus-rpms \
   --enable=openstack-17.1-for-rhel-8-x86_64-rpms \
   --enable=fast-datapath-for-rhel-8-x86_64-rpms

3. 在所有节点上将 container-tools 模块版本切换到 RHEL 8：

   [stack@director ~]$ sudo dnf -y module switch-to container-tools:rhel8

4. 安装用于安装和配置 director 的命令行工具：

   [stack@director ~]$ sudo dnf install -y python3-tripleoclient

流程

1. 以 stack 用户身份登录 undercloud 主机。

2. 查找 stackrc undercloud 凭证文件：

   $ source ~/stackrc

3. 安装软件包进行验证：

   $ sudo dnf -y update openstack-tripleo-validations python3-validations-libs validations-common

4. 从 mistral 复制清单：

   $ sudo chown stack:stack /var/lib/mistral/.ssh/tripleo-admin-rsa
   $ sudo cat /var/lib/mistral/<stack>/tripleo-ansible-inventory.yaml > inventory.yaml

   • 将 <stack> 替换为堆栈的名称。

5. 运行验证：

   $ validation run -i inventory.yaml --group pre-upgrade

6. 查看脚本输出，以确定哪些验证成功并失败：

   === Running validation: "check-ftype" ===
   
   Success! The validation passed for all hosts:
   * undercloud

流程

1. 以 stack 用户身份登录 undercloud 主机。

2. 可选：备份 16.2 containers-prepare-parameter.yaml 文件：

   $ cp containers-prepare-parameter.yaml \
     containers-prepare-parameter.yaml.orig

3. 生成默认的容器镜像准备文件：

   $ openstack tripleo container image prepare default \
     --local-push-destination \
     --output-env-file containers-prepare-parameter.yaml

   此命令包括以下附加选项：

   • --local-push-destination，在 undercloud 上设置 registry 作为存储容器镜像的位置。这意味着 director 从 Red Hat Container Catalog 拉取必要的镜像并将其推送到 undercloud 上的 registry 中。director 将该 registry 用作容器镜像源。如果直接从 Red Hat Container Catalog 拉取镜像，请忽略这个选项。

   • --output-env-file 是环境文件名称。此文件的内容包括用于准备您的容器镜像的参数。在本例中，文件的名称是 containers-prepare-parameter.yaml。

     注意

     您可以使用相同的 containers-prepare-parameter.yaml 文件为 undercloud 和 overcloud 定义容器镜像源。

4. 修改 containers-prepare-parameter.yaml 以符合您的需求。有关容器镜像参数的更多信息，请参阅 容器镜像准备参数。

5. 如果您的部署包含 Red Hat Ceph Storage，请为您的部署使用的 Red Hat Ceph Storage 版本更新 containers-prepare-parameter.yaml 文件中的 Red Hat Ceph Storage 容器镜像参数：

   ceph_namespace: registry.redhat.io/rhceph
   ceph_image: <ceph_image_file>
   ceph_tag: latest
   ceph_grafana_image: <grafana_image_file>
   ceph_grafana_namespace: registry.redhat.io/rhceph
   ceph_grafana_tag: latest

   • 将 <ceph_image_file > 替换为部署使用的 Red Hat Ceph Storage 版本的镜像文件的名称：

     • Red Hat Ceph Storage 5: rhceph-5-rhel8

   • 使用部署使用的 Red Hat Ceph Storage 版本的镜像文件的名称替换： <grafana_image_file>

     • Red Hat Ceph Storage 5: rhceph-5-dashboard-rhel8

流程

1. 以 stack 用户身份登录 undercloud 主机。

2. 创建名为 skip_rhel_release.yaml 的文件，并将 SkipRhelEnforcement 参数设置为 true ：

   parameter_defaults:
     SkipRhelEnforcement: true

3. 打开 undercloud.conf 文件，并在文件中的 DEFAULT 部分中添加以下参数：

   container_images_file = /home/stack/containers-prepare-parameter.yaml
   custom_env_files = /home/stack/skip_rhel_release.yaml

   • 在 custom_env_files 参数中添加任何其他自定义环境文件。

     custom_env_files 参数定义升级所需的 skip_rhel_release.yaml 文件的位置。

   • container_images_file 参数定义 containers-prepare-parameter.yaml 环境文件的位置，以便 director 从正确的位置拉取 undercloud 的容器镜像。
4. 检查 文件中的所有其他参数是否有任何更改。
5. 保存该文件。

流程

1. 以 stack 用户身份登录 undercloud 主机。

2. 查找 stackrc undercloud 凭证文件：

   $ source ~/stackrc

3. 登录到 Controller 节点并运行 Pacemaker 命令禁用隔离：

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

   • 将 <controller_ip > 替换为 Controller 节点的 IP 地址。您可以使用 metalsmith list 命令查找 Controller 节点的 IP 地址。
4. 在 fencing.yaml 环境文件中，将 EnableFencing 参数设置为 false，以确保隔离在升级过程中保持禁用。

流程

1. 选择一个环境文件，检查它是否有 ExtraConfig 参数：

   $ grep ExtraConfig ~/templates/custom-config.yaml

2. 如果结果在所选文件中显示 ExtraConfig 参数（如 ControllerExtraConfig），请检查该文件中的完整参数结构。

3. 如果参数包含 SECTION/parameter 语法后跟一个 值 的任何 puppet Hierdata，则它可能已被替换为实际 Puppet 类的参数。例如：

   parameter_defaults:
     ExtraConfig:
       neutron::config::dhcp_agent_config:
         'DEFAULT/dnsmasq_local_resolv':
           value: 'true'

4. 检查 director 的 Puppet 模块，以查看参数现在存在于 Puppet 类中。例如：

   $ grep dnsmasq_local_resolv

   如果是，请更改为新接口。

5. 以下是演示语法更改的示例：

   • 示例 1：

     parameter_defaults:
       ExtraConfig:
         neutron::config::dhcp_agent_config:
           'DEFAULT/dnsmasq_local_resolv':
             value: 'true'

     更改：

     parameter_defaults:
       ExtraConfig:
         neutron::agents::dhcp::dnsmasq_local_resolv: true

   • 示例 2：

     parameter_defaults:
       ExtraConfig:
         ceilometer::config::ceilometer_config:
           'oslo_messaging_rabbit/rabbit_qos_prefetch_count':
             value: '32'

     更改：

     parameter_defaults:
       ExtraConfig:
         oslo::messaging::rabbit::rabbit_qos_prefetch_count: '32'

流程

1. 以 stack 用户身份登录 undercloud 主机。

2. 查找 stackrc undercloud 凭证文件：

   $ source ~/stackrc

3. 验证 undercloud 升级过程中导出的以下文件是否包含 overcloud 升级的预期配置。您可以在 ~/overcloud-deploy 目录中找到以下文件：

   • tripleo-<stack>-passwords.yaml
   • tripleo-<stack>-network-data.yaml
   • tripleo-<stack>-virtual-ips.yaml

   • tripleo-<stack>-baremetal-deployment.yaml

     注意

     如果在 undercloud 升级后没有生成这些文件，请联系红帽支持。

4. 在主堆栈上，将 password .yaml 文件复制到 ~/overcloud-deploy/$(<stack>) 目录。在环境中的每个堆栈中重复此步骤：

   $ cp ~/overcloud-deploy/<stack>/tripleo-<stack>-passwords.yaml ~/overcloud-deploy/<stack>/<stack>-passwords.yaml

   • 将 <stack> 替换为您的堆栈的名称。

5. 在主堆栈上，将 network-data.yaml 文件复制到 stack 用户的主目录并部署网络。在环境中的每个堆栈中重复此步骤：

   $ cp ~/overcloud-deploy/<stack>/tripleo-<stack>-network-data.yaml ~/
   $ mkdir ~/overcloud_adopt
   $ openstack overcloud network provision --debug \
   --output /home/stack/overcloud_adopt/generated-networks-deployed.yaml tripleo-<stack>-network-data.yaml

   有关更多信息，请参阅使用 director 安装和管理 Red Hat OpenStack Platform 中的置备和部署 overcloud。

6. 在主堆栈上，将 virtual-ips.yaml 文件复制到 stack 用户的主目录，并置备网络 VIP。在环境中的每个堆栈中重复此步骤：

   $ cp ~/overcloud-deploy/<stack>/tripleo-<stack>-virtual-ips.yaml ~/
   $ openstack overcloud network vip provision --debug \
   --stack <stack> --output \
   /home/stack/overcloud_adopt/generated-vip-deployed.yaml tripleo-<stack>-virtual-ips.yaml

7. 在主堆栈上，将 baremetal-deployment.yaml 文件复制到 stack 用户的主目录，并置备 overcloud 节点。在环境中的每个堆栈中重复此步骤：

   $ cp ~/overcloud-deploy/<stack>/tripleo-<stack>-baremetal-deployment.yaml ~/
   $ openstack overcloud node provision --debug --stack <stack> \
   --output /home/stack/overcloud_adopt/baremetal-deployment.yaml \
   tripleo-<stack>-baremetal-deployment.yaml

8. 完成以下步骤以准备容器：

   1. 备份用于 undercloud 升级的 containers-prepare-parameter.yaml 文件：

      $ cp containers-prepare-parameter.yaml \
      containers-prepare-parameter.yaml.orig

   2. 在运行脚本以更新 containers-prepare-parameter.yaml 文件前，定义以下环境变量：

      • NAMESPACE: UBI9 镜像的命名空间。例如，NAMESPACE='"namespace":"example.redhat.com:5002",'
      • EL8_NAMESPACE ：UBI8 镜像的命名空间。
      • NEUTRON_DRIVER ：要使用的驱动程序，并确定要使用的 OpenStack Networking (neutron)容器。设置为用于部署原始堆栈的容器类型。例如，设置为 NEUTRON_DRIVER='"neutron_driver":"ovn"，' 以使用基于 OVN 的容器。
      • EL8_TAGS: UBI8 镜像的标签，例如 EL8_TAGS='"tag":"rhel_8_rhosp17.1",'。
      • EL9_TAGS: UBI9 镜像的标签，例如 EL9_TAGS='"tag":"rhel_9_rhosp17.1",'。

      • CONTROL_PLANE_ROLES ：使用 --role 选项的 control plane 角色列表，如 --role ControllerOpenstack, --role Database, --role Messaging, --role Networker, --role CephStorage。要查看环境中的 control plane 角色列表，请运行以下命令：

        $ sudo awk '/tripleo_role_name/ {print "--role " $2}' \
        /var/lib/mistral/$STACK/tripleo-ansible-inventory.yaml \
        | grep -vi compute

      • COMPUTE_ROLES ：使用 --role 选项的 Compute 角色列表，如 --Compute-1。要查看环境中的 Compute 角色列表，请运行以下命令：

        $ sudo awk '/tripleo_role_name/ {print "--role " $2}' \
        /var/lib/mistral/$STACK/tripleo-ansible-inventory.yaml \
        | grep -i compute

      • CEPH_TAGS ：如果您部署 Red Hat Ceph Storage，请指定 Red Hat Ceph Storage 5 容器镜像。例如：" ceph_tag":"5-404"。

   3. 运行以下脚本以更新 containers-prepare-parameter.yaml 文件：

      $ python3 /usr/share/openstack-tripleo-heat-templates/tools/multi-rhel-container-image-prepare.py \
           ${COMPUTE_ROLES} \
           ${CONTROL_PLANE_ROLES} \
           --enable-multi-rhel \
           --excludes collectd \
           --excludes nova-libvirt \
           --minor-override "{${EL8_TAGS}${EL8_NAMESPACE}${CEPH_TAGS}${NEUTRON_DRIVER}\"no_tag\":\"not_used\"}" \
           --major-override "{${EL9_TAGS}${NAMESPACE}${CEPH_TAGS}${NEUTRON_DRIVER}\"no_tag\":\"not_used\"}" \
           --output-env-file \
          /home/stack/containers-prepare-parameter.yaml

9. 如果使用 Red Hat Ceph Storage，请创建一个名为 ceph_params.yaml 的文件，并包含以下内容：

   parameter_defaults:
     CephSpecFqdn: true
     CephConfigPath: "/etc/ceph"
     CephAnsibleRepo: "rhceph-5-tools-for-rhel-8-x86_64-rpms"
     DeployedCeph: true

   注意

   如果您的 Red Hat Ceph Storage 部署包含短名称，您必须将 CephSpecFqdn 参数设置为 false。如果设置为 true，则清单会生成一个短名称和域名，从而导致 Red Hat Ceph Storage 升级失败。

10. 在 templates 目录中创建一个名为 upgrade-environment.yaml 的环境文件，并包含以下内容：

    parameter_defaults:
      ExtraConfig:
        nova::workarounds::disable_compute_service_check_for_ffu: true
      DnsServers: ["<dns_servers>"]
        DockerInsecureRegistryAddress: <undercloud_FQDN>
      UpgradeInitCommand: |
        sudo subscription-manager repos --disable=*
          if $( grep -q  9.2  /etc/os-release )
          then
            sudo subscription-manager repos --enable=rhel-9-for-x86_64-baseos-eus-rpms --enable=rhel-9-for-x86_64-appstream-eus-rpms --enable=rhel-9-for-x86_64-highavailability-eus-rpms --enable=openstack-17.1-for-rhel-9-x86_64-rpms --enable=fast-datapath-for-rhel-9-x86_64-rpms
            sudo podman ps | grep -q ceph && subscription-manager repos --enable=rhceph-5-tools-for-rhel-9-x86_64-rpms
            sudo subscription-manager release --set=9.2
          else
            sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-tus-rpms --enable=rhel-8-for-x86_64-appstream-tus-rpms --enable=rhel-8-for-x86_64-highavailability-tus-rpms --enable=openstack-17.1-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpms
            sudo podman ps | grep -q ceph && subscription-manager repos --enable=rhceph-5-tools-for-rhel-8-x86_64-rpms
            sudo subscription-manager release --set=8.4
          fi
    
          if $(sudo podman ps | grep -q ceph )
          then
            sudo dnf -y install cephadm
          fi

    • 将 <dns_servers> 替换为 DNS 服务器 IP 地址的逗号分隔列表，例如 ["10.0.0.36", "10.0.0.37"]。

    • 将 <undercloud_FQDN > 替换为 undercloud 主机的完全限定域名(FQDN)，例如 "undercloud-0.ctlplane.redhat.local:8787"。

      有关您可以在环境文件中配置的升级参数的更多信息，请参阅升级 参数。

11. 在 undercloud 上，在 templates 目录中创建一个名为 overcloud_upgrade_prepare.sh 的文件。您必须为环境中的每个堆栈创建此文件。此文件包含 overcloud 部署文件的原始内容，以及与您的环境相关的环境文件。例如：

    #!/bin/bash
    openstack overcloud upgrade prepare --yes \
      --timeout 460 \
      --templates /usr/share/openstack-tripleo-heat-templates \
      --ntp-server 192.168.24.1 \
      --stack <stack> \
      -r /home/stack/roles_data.yaml \
      -e /home/stack/templates/internal.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
      -e /home/stack/templates/network/network-environment.yaml \
      -e /home/stack/templates/inject-trust-anchor.yaml \
      -e /home/stack/templates/hostnames.yml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
      -e /home/stack/templates/nodes_data.yaml \
      -e /home/stack/templates/debug.yaml \
      -e /home/stack/templates/firstboot.yaml \
      -e /home/stack/templates/upgrades-environment.yaml \
      -e /home/stack/overcloud-params.yaml \
      -e /home/stack/overcloud-deploy/overcloud/overcloud-network-environment.yaml \
      -e /home/stack/overcloud_adopt/baremetal-deployment.yaml \
      -e /home/stack/overcloud_adopt/generated-networks-deployed.yaml \
      -e /home/stack/overcloud_adopt/generated-vip-deployed.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/nova-hw-machine-type-upgrade.yaml \
      -e /home/stack/skip_rhel_release.yaml \
      -e ~/containers-prepare-parameter.yaml

    1. 在原始 network-environment.yaml 文件中(/home/stack/templates/network/network-environment.yaml)，删除所有指向 OS::TripleO::*::Net::SoftwareConfig 的 resource_registry 资源。

    2. 在 overcloud_upgrade_prepare.sh 文件中，包含与您的环境相关的以下选项：

       • 环境文件 (upgrades-environment.yaml) 带有特定于升级的参数 (-e)。
       • 包含新容器镜像位置(-e)的环境文件(containers-prepare-parameter.yaml)。在大多数情况下，这是 undercloud 使用的环境文件。
       • 环境文件(skip_rhel_release.yaml)，带有发行版本参数(-e)。
       • 与您的部署相关的任何自定义配置文件(-e)。
       • 如果适用，使用 --roles-file 的自定义角色(roles_data)文件。
       • 对于 Ceph 部署，环境文件(ceph_params.yaml)以及 Ceph 参数(-e)。
       • 在 overcloud 采用过程中生成的文件(network-deployed.yaml,vip-deployed.yaml,baremetal-deployment.yaml) (-e)。
       • 如果适用，带有您的 IPA 服务(-e)的环境文件(ipa-environment.yaml)。

       • 如果使用自定义堆栈名称，请使用 --stack 选项传递名称。

         注意

         您必须在模板中包含 nova-hw-machine-type-upgrade.yaml 文件，直到所有 RHEL 8 Compute 节点都升级到环境中的 RHEL 9。如果排除了此文件，则 /var/log/containers/nova 目录中的 nova_compute.log 中会出现一个错误。将所有 RHEL 8 Compute 节点升级到 RHEL 9 后，您可以从配置中删除此文件并更新堆栈。

    3. 如果您在要升级的部署中通过 NFS 启用共享文件系统服务(manila)，则必须在 overcloud_upgrade_prepare.sh 脚本文件末尾指定额外的环境文件。您必须在脚本末尾添加环境文件，因为它会覆盖之前在脚本中指定的另一个环境文件：

       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/manila-cephfsganesha-config.yaml

12. 为环境中的每个堆栈运行升级准备命令：

    $ source stackrc
    $ chmod 755 /home/stack/overcloud_upgrade_prepare.sh
    $ sh /home/stack/overcloud_upgrade_prepare.sh

13. 等待升级准备完成。

14. 下载容器镜像：

    $ openstack overcloud external-upgrade run --stack <stack> --tags container_image_prepare

流程

1. 启用 Ceph 5 Tools 存储库：

   [stack@director ~]$ sudo subscription-manager repos --enable=rhceph-5-tools-for-rhel-8-x86_64-rpms

2. 安装 ceph-ansible 软件包：

   [stack@director ~]$ sudo dnf update -y ceph-ansible

流程

1. 以 stack 用户身份登录 undercloud 主机。

2. 查找 stackrc undercloud 凭证文件：

   $ source ~/stackrc

3. 使用 ceph 标签运行 Red Hat Ceph Storage 外部升级过程：

   $ openstack overcloud external-upgrade run \
      --skip-tags "ceph_health,opendev-validation, ceph_ansible_remote_tmp" \
      --stack <stack> \
      --tags ceph,facts 2>&1

   • 将 <stack> 替换为您的堆栈的名称。

4. 创建 ceph-admin 用户并分发适当的密钥环：

   ANSIBLE_LOG_PATH=/home/stack/cephadm_enable_user_key.log \
   ANSIBLE_HOST_KEY_CHECKING=false \
   ansible-playbook -i /home/stack/overcloud-deploy/<stack>/config-download/<stack>/tripleo-ansible-inventory.yaml \
     -b -e ansible_python_interpreter=/usr/libexec/platform-python /usr/share/ansible/tripleo-playbooks/ceph-admin-user-playbook.yml \
    -e tripleo_admin_user=ceph-admin \
    -e distribute_private_key=true \
     --limit ceph_osd,ceph_mon,Undercloud

5. 更新 Red Hat Ceph Storage 节点上的软件包：

   $ openstack overcloud upgrade run \
       --stack <stack> \
       --skip-tags ceph_health,opendev-validation,ceph_ansible_remote_tmp \
       --tags setup_packages --limit ceph_osd,ceph_mon,Undercloud \
       --playbook /home/stack/overcloud-deploy/<stack>/config-download/<stack>/upgrade_steps_playbook.yaml 2>&1

   注意

   Ceph 监控服务(CephMon)在 Controller 节点上运行。此命令包含 ceph_mon 标签，它也会更新 Controller 节点上的软件包。

6. 配置 Red Hat Ceph Storage 节点以使用 cephadm ：

   $ openstack overcloud external-upgrade run \
       --skip-tags ceph_health,opendev-validation,ceph_ansible_remote_tmp \
       --stack <stack> \
       --tags cephadm_adopt  2>&1

7. 修改 overcloud_upgrade_prepare.sh 文件，将 ceph-ansible 文件替换为 cephadm heat 环境文件。

   #!/bin/bash
   openstack overcloud upgrade prepare  --yes \
     --timeout 460 \
    --templates /usr/share/openstack-tripleo-heat-templates \
     --ntp-server 192.168.24.1 \
     --stack <stack> \
     -r /home/stack/roles_data.yaml \
     -e /home/stack/templates/internal.yaml \
     …
     -e /usr/share/openstack-tripleo-heat-templates/environments/cephadm/cephadm-rbd-only.yaml \
     -e ~/containers-prepare-parameter.yaml

   注意

   本例使用 environments/cephadm/cephadm-rbd-only.yaml 文件，因为没有部署 RGW。如果您计划部署 RGW，请在升级 RHOSP 环境后使用 environments/cephadm/cephadm.yaml，然后运行堆栈更新。

8. 如果您之前在运行 overcloud 升级准备时添加了 overcloud_upgrade_prepare.sh 文件，请修改 overcloud_upgrade_prepare.sh 文件，以删除以下环境文件：

   -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/manila-cephfsganesha-config.yaml

9. 保存该文件。

10. 运行 upgrade preparation 命令：

    $ source stackrc
    $ chmod 755 /home/stack/overcloud_upgrade_prepare.sh
    sh /home/stack/overcloud_upgrade_prepare.sh

    Red Hat Ceph Storage 集群现在升级到版本 5。这会产生以下影响：

    • 您不再使用 ceph-ansible 管理 Red Hat Ceph Storage。相反，Ceph 编排器管理 Red Hat Ceph Storage 集群。有关 Ceph 编排器的更多信息，请参阅 Ceph 操作指南。
    • 在大多数情况下，您不再需要执行堆栈更新来更改 Red Hat Ceph Storage 集群。相反，您可以直接在集群上运行第 2 天的 Red Hat Ceph Storage 操作，如 Ceph 操作指南中所述。您还可以扩展 Red Hat Ceph Storage 集群节点，如部署 Red Hat Ceph Storage 和 Red Hat OpenStack Platform 中的扩展 Ceph Storage 集群中所述。
    • 检查 Red Hat Ceph Storage 集群的健康状态。如需有关监控集群健康状况的更多信息，请参阅部署 Red Hat Ceph Storage 和 Red Hat OpenStack Platform 中的监控 Red Hat Ceph Storage 节点。

    • 不要在 openstack deployment 命令（如 openstack overcloud deploy ）中包含环境文件，如 environments/ceph-ansible/ceph-ansible.yaml。如果您的部署包含 ceph-ansible 环境文件，请将它们替换为以下选项之一：

      Red Hat Ceph Storage 部署	原始 ceph-ansible 文件	Cephadm 文件替换
      仅限 Ceph RADOS 块设备(RBD)	任何 ceph-ansible 环境文件	environments/cephadm/cephadm-rbd-only.yaml
      RBD 和 Ceph 对象网关(RGW)	任何 ceph-ansible 环境文件	environments/cephadm/cephadm.yaml
      Ceph 仪表板	environments/ceph-ansible/ceph-dashboard.yaml	environments/cephadm/中的相应文件
      Ceph MDS	environments/ceph-ansible/ceph-mds.yaml	environments/cephadm/中的相应文件

流程

1. 以 stack 用户身份登录 undercloud 主机。

2. 查找 stackrc undercloud 凭证文件：

   $ source ~/stackrc

3. 在主堆栈中的所有节点上升级 RHOSP：

   $ openstack overcloud upgrade run --yes --stack <stack> --debug --limit allovercloud,undercloud --playbook all

   • 将 <stack> 替换为您要升级节点的 overcloud 堆栈的名称。

     对 RHOSP 部署中的每个堆栈重复此步骤。

流程

1. 以 stack 用户的身份登录 undercloud。

2. 检查 PermitRootLogin 参数的 /etc/ssh/sshd_config 文件：

   $ sudo grep PermitRootLogin /etc/ssh/sshd_config

3. 如果参数不在 /etc/ssh/sshd_config 文件中，编辑该文件并设置 PermitRootLogin 参数：

   PermitRootLogin no

4. 保存该文件。

流程

1. 验证您的 SSH 密钥大小：

   ssh-keygen -l -f ~/.ssh/id_rsa.pub

   输出示例：

   1024 SHA256:Xqz0Xz0/aJua6B3qRD7VsLr6n/V3zhmnGSkcFR6FlJw stack@director.example.local (RSA)

2. 如果您的 SSH 密钥小于 2048 位，请在继续操作前使用 ssh_key_rotation.yaml ansible playbook 替换 SSH 密钥。

   ansible-playbook \
   -i ~/overcloud-deploy/<stack>/tripleo-ansible-inventory.yaml \
   /usr/share/ansible/tripleo-playbooks/ssh_key_rotation.yaml \
   --extra-vars "keep_old_key_authorized_keys=<true|false> backup_folder_path=</path/to/backup_folder>"

   • 将 <stack > 替换为 overcloud 堆栈的名称。
   • 根据您的备份需求替换 &lt ;true|false >。如果没有包含此变量，则默认值为 true。
   • 将 </path/to/backup_folder& gt; 替换为备份路径。如果没有包含此变量，则默认值为 /home/{{ ansible_user_id }}/backup_keys/{{ ansible_date_time.epoch }}

流程

1. 以 stack 用户身份登录 undercloud。

2. 在 templates 目录中创建一个名为 system_upgrade.yaml 的文件，并包含以下内容：

   parameter_defaults:
     UpgradeLeappDevelSkip: "LEAPP_UNSUPPORTED=1 LEAPP_DEVEL_SKIP_CHECK_OS_RELEASE=1 LEAPP_NO_NETWORK_RENAMING=1 LEAPP_DEVEL_TARGET_RELEASE=9.2"
     UpgradeLeappDebug: false
     UpgradeLeappEnabled: true
     LeappActorsToRemove: ['checkifcfg','persistentnetnamesdisable','checkinstalledkernels','biosdevname']
     LeappRepoInitCommand: |
        sudo subscription-manager repos --disable=*
        subscription-manager repos --enable rhel-8-for-x86_64-baseos-tus-rpms --enable rhel-8-for-x86_64-appstream-tus-rpms --enable openstack-17.1-for-rhel-8-x86_64-rpms
         subscription-manager release --set=8.4
     UpgradeLeappCommandOptions:
   "--enablerepo=rhel-9-for-x86_64-baseos-eus-rpms --enablerepo=rhel-9-for-x86_64-appstream-eus-rpms --enablerepo=rhel-9-for-x86_64-highavailability-eus-rpms --enablerepo=openstack-17.1-for-rhel-9-x86_64-rpms --enablerepo=fast-datapath-for-rhel-9-x86_64-rpms"

   注意

   如果您的部署包含 Red Hat Ceph Storage 节点，您必须添加 CephLeappRepoInitCommand 参数，并指定 Red Hat Ceph Storage 节点的源操作系统版本。例如：

   CephLeappRepoInitCommand:
   ...
     subscription-manager release --set=8.6

3. 在 system_upgrade.yaml 文件中添加 LeappInitCommand 参数，以指定适用于您的环境的额外要求，例如，如果您需要定义基于角色的覆盖：

     LeappInitCommand: |
       sudo subscription-manager repos --disable=*
       sudo subscription-manager repos
     --enable=rhel-9-for-x86_64-baseos-eus-rpms --enable=rhel-9-for-x86_64-appstream-eus-rpms --enable=rhel-9-for-x86_64-highavailability-eus-rpms --enable=openstack-17.1-for-rhel-9-x86_64-rpms --enable=fast-datapath-for-rhel-9-x86_64-rpms
   
       leapp answer --add --section check_vdo.confirm=True
   
       dnf -y remove irb

4. 如果您使用基于内核的 NIC 名称，请在 system_upgrade.yaml 文件中添加以下参数，以确保在整个升级过程中保留 NIC 名称：

   parameter_defaults:
     NICsPrefixesToUdev: ['en']
   ...

5. 运行 Leapp 升级：

   $ openstack undercloud upgrade --yes --system-upgrade \
   /home/stack/system_upgrade.yaml

   注意

   如果您需要再次运行 Leapp 升级，您必须首先将软件仓库重置为 RHEL 8。

6. 重新引导 undercloud：

   $ sudo reboot

流程

1. 以 stack 用户身份登录 undercloud 主机。

2. 查找 stackrc undercloud 凭证文件：

   $ source ~/stackrc

3. 运行以下脚本，但没有 CONTROL_PLANE_ROLES 参数：确保您包含用于运行 overcloud 升级准备容器时使用的变量。

   python3 \
   /usr/share/openstack-tripleo-heat-templates/tools/multi-rhel-container-image-prepare.py \
        ${COMPUTE_ROLES} \
        --enable-multi-rhel \
        --excludes collectd \
        --excludes nova-libvirt \
        --minor-override \
   "{${EL8_TAGS}${EL8_NAMESPACE}${CEPH_TAGS}${NEUTRON_DRIVER}\"no_tag\":\"not_used\"}" \
        --major-override \
        "{${EL9_TAGS}${NAMESPACE}${CEPH_TAGS}${NEUTRON_DRIVER}\"no_tag\":\"not_used\"}" \
        --output-env-file \
   /home/stack/containers-prepare-parameter.yaml

   注意

   CONTROL_PLANE_ROLES 参数定义 control plane 角色的列表。从脚本中删除此参数为升级到 RHEL 9.2 准备 control plane 角色。如果脚本中包含 CONTROL_PLANE_ROLES 参数，则 control plane 角色会保留在 RHEL 8.4 上。

4. 在 skip_rhel_release.yaml 文件中，将 SkipRhelEnforcement 参数设置为 false ：

   parameter_defaults:
     SkipRhelEnforcement: false

5. 更新 overcloud_upgrade_prepare.sh 文件：

   $ openstack overcloud upgrade prepare --yes \
       ...
       -e /home/stack/system_upgrade.yaml \
       -e /home/stack/containers-prepare-parameter.yaml \
       -e /home/stack/skip_rhel_release.yaml \
       ...

   • 使用特定于升级的参数(-e)包括 system_upgrade.yaml 文件。
   • 包含 containers-prepare-parameter.yaml 文件，并删除了 control plane 角色(-e)。
   • 包含 skip_rhel_release.yaml 文件，其中包含发行版本参数(-e)。

6. 运行 overcloud_upgrade_prepare.sh 脚本：

   $ sh /home/stack/overcloud_upgrade_prepare.sh

7. 获取系统升级所需的任何新的或修改的容器：

   $ openstack overcloud external-upgrade run  \
        --stack <stack> \
        --tags container_image_prepare 2>&1

8. 升级第一个 control plane 节点三分之一：

   $ openstack overcloud upgrade run --yes \
        --stack <stack> \
        --tags system_upgrade \
        --limit <controller-0>,<database-0>,<messaging-0>,<networker-0>,<ceph-0>

   • 将 <stack> 替换为您的堆栈的名称。
   • 将 & lt;controller-0>,<database-0& gt;, <messaging-0 &gt; , <networker-0 > , <ceph-0 > 替换为您自己的节点名称。

9. 登录到每个升级的节点，并验证每个节点的集群是否正在运行：

   $ sudo pcs status

   在升级了第二个 control plane 节点的三分之一后，重复这个验证步骤，并在升级最后三分之一 control plane 节点后。

10. 升级第二个 control plane 节点的三分之一：

    $ openstack overcloud upgrade run --yes \
         --stack <stack> \
         --tags system_upgrade \
         --limit <controller-1>,<database-1>,<messaging-1>,<networker-1>,<ceph-1>

    • 将 & lt;controller-1&gt; ,<database-1& gt;, <messaging -1&gt; , <networker -1> , <ceph -1> 替换为您自己的节点名称。

11. 升级 control plane 节点的最后三分之一：

    $ openstack overcloud upgrade run --yes \
         --stack <stack> \
         --tags system_upgrade \
         --limit <controller-2>,<database-2>,<messaging-2>,<networker-2>,<ceph-2>

    • 将 & lt;controller-2&gt; ,<database-2& gt;, <messaging -2&gt; , <networker -2> , <ceph -2> 替换为您自己的节点名称。

流程

1. 以 stack 用户身份登录 undercloud 主机。

2. 查找 stackrc undercloud 凭证文件：

   $ source ~/stackrc

3. 在 container-image-prepare.yaml 文件中，确保仅包含 ContainerImagePrepare 参数中指定的标签，并且 MultiRhelRoleContainerImagePrepare 参数已被删除。例如：

   parameter_defaults:
     ContainerImagePrepare:
     - tag_from_label: "{version}-{release}"
       set:
         namespace:
         name_prefix:
         name_suffix:
         tag:
         rhel_containers: false
         neutron_driver: ovn
         ceph_namespace:
         ceph_image:
         ceph_tag:

4. 在 roles_data.yaml 文件中，将 OS::TripleO::Services::NovaLibvirtLegacy 服务替换为 RHEL 9.2 所需的 OS::TripleO::Services::NovaLibvirt 服务。

5. 运行 openstack overcloud upgrade prepare 命令，并使用特定于升级的参数包括 system_upgrade.yaml 文件：

   $ openstack overcloud upgrade prepare --yes
   …​
   -e /home/stack/system_upgrade.yaml
   …​

6. 将 Compute 节点上的操作系统升级到 RHEL 9.2。使用您要升级的节点列表使用 --limit 选项。以下示例升级 compute-0、compute-1 和 compute-2 节点。

   $ openstack overcloud upgrade run --yes --tags system_upgrade --stack <stack> --limit compute-0,compute-1,compute-2

   • 将 <stack> 替换为您的堆栈的名称。

7. 将 Compute 节点上的容器升级到 RHEL 9.2。使用您要升级的节点列表使用 --limit 选项。以下示例升级 compute-0、compute-1 和 compute-2 节点。

   $ openstack overcloud upgrade run --yes --stack <stack>  --limit compute-0,compute-1,compute-2

1. 选择您要升级到 RHEL 9.2 的节点，以及您希望在 RHEL 8.4 上保留哪些节点。为您要为每个批处理节点创建的每个角色选择一个角色名称，如 ComputeRHEL-9.2 和 ComputeRHEL-8.4。

2. 创建存储要升级到 RHEL 9.2 的节点的角色，或存储您要保留在 RHEL 8.4 上的节点。这些角色可以保持为空，直到您准备好将 Compute 节点移到新角色为止。您可以根据需要创建任意数量的角色，并在决定时划分节点。例如：

   • 如果您的环境使用名为 ComputeSRIOV 的角色，您需要运行 Canary 测试来升级到 RHEL 9.2，您可以创建一个新的 ComputeSRIOVRHEL9 角色，并将 Canary 节点移到新角色。
   • 如果您的环境使用名为 ComputeOffload 的角色，而您想要将该角色中的大多数节点升级到 RHEL 9.2，但在 RHEL 8.4 上保留几个节点，您可以创建一个新的 ComputeOffloadRHEL8 角色来存储 RHEL 8.4 节点。然后，您可以选择原始 ComputeOffload 角色中的节点升级到 RHEL 9.2。
3. 将节点从每个 Compute 角色移到新角色。

4. 将特定 Compute 节点上的操作系统升级到 RHEL 9.2。您可以从相同的角色或多个角色升级批处理中的节点。

   注意

   在 Multi-RHEL 环境中，部署应该继续使用 pc-i440fx 机器类型。不要将默认值更新为 Q35。迁移到 Q35 机器类型是在所有 Compute 节点升级到 RHEL 9.2 后要遵循的独立、升级后的步骤。有关迁移 Q35 机器类型的更多信息，请参阅 升级到 RHOSP 17 后为主机更新默认机器类型。

   使用以下步骤将 Compute 节点升级到 Multi-RHEL 环境：

   • 为 Multi-RHEL Compute 节点创建角色
   • 升级 Compute 节点操作系统

流程

1. 从 stack 用户的主目录（/home/stack/images）的 images 中删除任何存在的镜像。

   $ rm -rf ~/images/*

2. 解压存档：

   $ cd ~/images
   $ for i in /usr/share/rhosp-director-images/overcloud-full-latest-17.1.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-17.1.tar; do tar -xvf $i; done
   $ cd ~

流程

1. 以 stack 用户的身份登录 undercloud。

2. 如果您的 Compute 节点支持并发多线程(SMT)，但创建了带有 hw:cpu_thread_policy=isolated 策略的实例，您必须执行以下选项之一：

   • 取消设置 hw:cpu_thread_policy 线程策略并调整实例大小：

     1. 提供 overcloud 身份验证文件：

        $ source ~/overcloudrc

     2. 取消设置类别的 hw:cpu_thread_policy 属性：

        (overcloud) $ openstack flavor unset --property hw:cpu_thread_policy <flavor>

        注意
        • 取消设置 hw:cpu_thread_policy 属性可将策略设置为默认的 prefer 策略，这会将实例设置为使用启用了 SMT 的 Compute 节点（如果可用）。您还可以将 hw:cpu_thread_policy 属性设置为 require，这将为启用 SMT 的 Compute 节点设置硬要求。
        • 如果 Compute 节点没有 SMT 架构或足够的 CPU 内核，则调度将失败。要防止这种情况，将 hw:cpu_thread_policy 设置为 prefer 而不是 require。默认 首选 策略确保线程同级在可用时被使用。
        • 如果使用 hw:cpu_thread_policy=isolate，则必须禁用 SMT，或使用不支持 SMT 的平台。

     3. 将实例转换为使用新的线程策略。

        (overcloud) $ openstack server resize --flavor <flavor> <server>
        (overcloud) $ openstack server resize confirm <server>

        使用 hw:cpu_thread_policy=isolated 策略为所有固定实例重复此步骤。

   • 从 Compute 节点迁移实例，并在 Compute 节点上禁用 SMT：

     1. 提供 overcloud 身份验证文件：

        $ source ~/overcloudrc

     2. 禁用 Compute 节点接受新虚拟机：

        (overcloud) $ openstack compute service list
        (overcloud) $ openstack compute service set <hostname> nova-compute --disable

     3. 从 Compute 节点迁移所有实例。有关实例迁移的更多信息，请参阅 在 Compute 节点之间迁移虚拟机实例。
     4. 重新引导 Compute 节点，并在 Compute 节点的 BIOS 中禁用 SMT。
     5. 引导 Compute 节点。

     6. 重新启用 Compute 节点：

        (overcloud) $ openstack compute service set <hostname> nova-compute --enable

3. Source stackrc 文件：

   $ source ~/stackrc

4. 编辑包含 NovaVcpuPinSet 参数的环境文件。

5. 将 CPU 固定配置从 NovaVcpuPinSet 参数迁移到 NovaComputeCpuDedicatedSet 和 NovaComputeCpuSharedSet ：

   • 将 NovaVcpuPinSet 的值迁移到之前用于固定实例的主机的 NovaComputeCpuDedicatedSet。
   • 将 NovaVcpuPinSet 的值迁移到之前用于未固定实例的主机的 NovaComputeCpuSharedSet。
   • 如果没有为 NovaVcpuPinSet 设置值，则所有 Compute 节点内核都应分配给 NovaComputeCpuDedicatedSet 或 NovaComputeCpuSharedSet，具体取决于您要在节点上托管的实例类型。

   例如，您之前的环境文件可能包含以下固定配置：

   parameter_defaults:
     ...
     NovaVcpuPinSet: 1,2,3,5,6,7
     ...

   要将配置迁移到固定配置，请设置 NovaComputeCpuDedicatedSet 参数，然后取消设置 NovaVcpuPinSet 参数：

   parameter_defaults:
     ...
     NovaComputeCpuDedicatedSet: 1,2,3,5,6,7
     NovaVcpuPinSet: ""
     ...

   要将配置迁移到未固定配置，请设置 NovaComputeCpuSharedSet 参数，然后取消设置 NovaVcpuPinSet 参数：

   parameter_defaults:
     ...
     NovaComputeCpuSharedSet: 1,2,3,5,6,7
     NovaVcpuPinSet: ""
     ...

   重要

   确保 NovaComputeCpuDedicatedSet 或 NovaComputeCpuSharedSet 的配置与 NovaVcpuPinSet 中定义的配置匹配。要更改其中任一个的配置，或配置 NovaComputeCpuDedicatedSet 或 NovaComputeCpuSharedSet，请确保在更新配置前，使用固定配置的 Compute 节点不会运行任何实例。

6. 保存该文件。

7. 运行部署命令，以使用新的 CPU 固定参数更新 overcloud。

   (undercloud) $ openstack overcloud deploy \
       --stack _STACK NAME_ \
       --templates \
       ...
       -e /home/stack/templates/<compute_environment_file>.yaml
       ...

流程

1. 以 stack 用户的身份登录 undercloud。

2. source stackrc 文件：

   $ source ~/stackrc

3. 以 heat-admin 用户身份登录 Controller 节点：

   (undercloud)$ metalsmith list
   $ ssh heat-admin@<controller_ip>

   将 <controller_ip > 替换为 Controller 节点的 IP 地址。

4. 检索没有设置机器类型的实例列表：

   [heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \
     nova-manage libvirt list_unset_machine_type

5. 检查 nova-hw-machine-type-upgrade.yaml 文件中的 NovaHWMachineType 参数，以获取实例主机的默认机器类型。RHOSP 16.2 中 NovaHWMachineType 参数的默认值如下：

   x86_64=pc-i440fx-rhel7.6.0,aarch64=virt-rhel7.6.0,ppc64=pseries-rhel7.6.0,ppc64le=pseries-rhel7.6.0

6. 使用默认实例类型更新每个实例的系统元数据：

   [heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \
     nova-manage libvirt update_machine_type <instance_uuid> <machine_type>

   • 将 <instance_uuid > 替换为实例的 UUID。
   • 将 <machine_type> 替换为要记录的实例类型。

7. 确认为所有实例记录了机器类型：

   [heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \
     nova-status upgrade check

   如果实例在没有机器类型的情况下找到，这个命令会返回一个警告。如果收到这个警告，请从第 4 步重复这个过程。

8. 将 Compute 环境文件中的 NovaHWMachineType 默认值更改为 x86_64=q35 并部署 overcloud。

验证

1. 创建具有默认机器类型的实例：

   (overcloud)$ openstack server create --flavor <flavor> \
     --image <image> --network <network> \
     --wait defaultMachineTypeInstance

   • 将 <flavor > 替换为实例的类别名称或 ID。
   • 将 <image > 替换为没有设置 hw_machine_type 的镜像的名称或 ID。
   • 将 & lt;network > 替换为要连接实例的网络的名称或 ID。

2. 验证实例机器类型是否已设置为默认值：

   [heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \
     nova-manage libvirt get_machine_type <instance_uuid>

   将 <instance_uuid > 替换为实例的 UUID。

3. 硬重启一个类型为 x86_64=pc-i440fx 的实例：

   (overcloud)$ openstack server reboot --hard <instance_uuid>

   将 <instance_uuid > 替换为实例的 UUID。

4. 验证实例机器类型尚未更改：

   [heat-admin@<controller_ip> ~]$ sudo podman exec -i -u root nova_api \
     nova-manage libvirt get_machine_type <instance_uuid>

   将 <instance_uuid > 替换为实例的 UUID。

流程

1. 以 stack 用户身份登录 undercloud 主机。

2. 查找 stackrc undercloud 凭证文件：

   $ source ~/stackrc

3. 登录到 Controller 节点并运行 Pacemaker 命令重新启用隔离：

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

   • 将 <controller_ip > 替换为 Controller 节点的 IP 地址。您可以使用 openstack server list 命令查找 Controller 节点的 IP 地址。
4. 在 fencing.yaml 环境文件中，将 EnableFencing 参数设置为 true。