流程

1. 登录运行 ceph-mon 服务的节点。此节点通常是 Controller 节点或独立 Ceph 监控节点。

2. 查看 Ceph 集群的状态：

   $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph -s"

3. 确认集群的运行状况状态为 HEALTH_OK，并且所有 Object Storage Daemon (OSD)都是 active。

流程

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

2. 备份数据库：

   [root@director ~]# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql

3. 创建 备份目录，并将目录的用户所有权改为 stack 用户：

   [root@director ~]# mkdir /backup
   [root@director ~]# chown stack: /backup

   您将使用此目录存储包含 undercloud 数据库和文件系统的存档。

4. 进入 备份目录

   [root@director ~]# cd /backup

5. 归档数据库备份和配置文件：

   [root@director ~]# tar --xattrs --xattrs-include='*.*' --ignore-failed-read -cf \
       undercloud-backup-$(date +%F).tar \
       /root/undercloud-all-databases.sql \
       /etc \
       /var/log \
       /var/lib/glance \
       /var/lib/certmonger \
       /var/lib/docker \
       /var/lib/registry \
       /srv/node \
       /root \
       /home/stack

   • --ignore-failed-read 选项跳过任何不适用于 undercloud 的目录。
   • --xattrs 和 --xattrs-include=' 含有扩展属性，这是存储 Object Storage (swift)和 SELinux 的元数据所必需的。

   这会创建一个名为 undercloud-backup-<date>.tar.gz 的文件，其中 & lt;date > 是系统日期。将此 tar 文件复制到安全位置。

流程

1. 执行数据库备份：

   1. 登录 Controller 节点。您可以从 undercloud 访问 overcloud：

      $ ssh heat-admin@192.0.2.100

   2. 进入 root 用户：

      $ sudo -i

   3. 创建用于存储备份的临时目录：

      # mkdir -p /var/tmp/mysql_backup/

   4. 获取数据库密码，并将它存储在 MYSQLDBPASS 环境变量中。密码存储在 /etc/puppet/hieradata/service_configs.json 文件中的 mysql::server::root_password 变量中。使用以下命令存储密码：

      # MYSQLDBPASS=$(sudo hiera -c /etc/puppet/hiera.yaml mysql::server::root_password)

   5. 备份数据库：

      # mysql -uroot -p$MYSQLDBPASS -s -N -e "select distinct table_schema from information_schema.tables where engine='innodb' and table_schema != 'mysql';" | xargs mysqldump -uroot -p$MYSQLDBPASS --single-transaction --databases > /var/tmp/mysql_backup/openstack_databases-$(date +%F)-$(date +%T).sql

      这会转储名为 /var/tmp/mysql_backup/openstack_databases-<date>.sql 的数据库备份，其中 & lt;date > 是系统日期和时间。将此数据库转储复制到安全位置。

   6. 备份所有用户和权限信息：

      # mysql -uroot -p$MYSQLDBPASS -s -N -e "SELECT CONCAT('\"SHOW GRANTS FOR ''',user,'''@''',host,''';\"') FROM mysql.user where (length(user) > 0 and user NOT LIKE 'root')" | xargs -n1 mysql -uroot -p$MYSQLDBPASS -s -N -e | sed 's/$/;/' > /var/tmp/mysql_backup/openstack_databases_grants-$(date +%F)-$(date +%T).sql

      这会转储名为 /var/tmp/mysql_backup/openstack_databases_grants-<date>.sql 的数据库备份，其中 & lt;date > 是系统日期和时间。将此数据库转储复制到安全位置。

2. 备份 Pacemaker 配置：

   1. 登录 Controller 节点。

   2. 运行以下命令来创建当前 Pacemaker 配置的存档：

      # sudo pcs config backup pacemaker_controller_backup

   3. 将生成的存档(pacemaker_controller_backup.tar.bz2)复制到安全的位置。

3. 备份 OpenStack Telemetry 数据库：

   1. 连接到任何控制器并获取 MongoDB 主实例的 IP：

      # MONGOIP=$(sudo hiera -c /etc/puppet/hiera.yaml mongodb::server::bind_ip)

   2. 创建备份：

      # mkdir -p /var/tmp/mongo_backup/
      # mongodump --oplog --host $MONGOIP --out /var/tmp/mongo_backup/

   3. 将 /var/tmp/mongo_backup/ 中的数据库转储复制到安全位置。

4. 备份 Redis 集群：

   1. 从 HAProxy 获取 Redis 端点：

      # REDISIP=$(sudo hiera -c /etc/puppet/hiera.yaml redis_vip)

   2. 获取 Redis 集群的 master 密码：

      # REDISPASS=$(sudo hiera -c /etc/puppet/hiera.yaml redis::masterauth)

   3. 检查到 Redis 集群的连接：

      # redis-cli -a $REDISPASS -h $REDISIP ping

   4. 转储 Redis 数据库：

      # redis-cli -a $REDISPASS -h $REDISIP bgsave

      这会将数据库备份保存在默认的 /var/lib/redis/ 目录中。将此数据库转储复制到安全位置。

5. 备份每个 Controller 节点上的文件系统：

   1. 为备份创建一个目录：

      # mkdir -p /var/tmp/filesystem_backup/

   2. 运行以下命令 ：

      # tar --acls --ignore-failed-read --xattrs --xattrs-include='*.*' \
          -zcvf /var/tmp/filesystem_backup/`hostname`-filesystem-`date '+%Y-%m-%d-%H-%M-%S'`.tar \
          /etc \
          /srv/node \
          /var/log \
          /var/lib/nova \
          --exclude /var/lib/nova/instances \
          /var/lib/glance \
          /var/lib/keystone \
          /var/lib/cinder \
          /var/lib/heat \
          /var/lib/heat-config \
          /var/lib/heat-cfntools \
          /var/lib/rabbitmq \
          /var/lib/neutron \
          /var/lib/haproxy \
          /var/lib/openvswitch \
          /var/lib/redis \
          /var/lib/os-collect-config \
          /usr/libexec/os-apply-config \
          /usr/libexec/os-refresh-config \
          /home/heat-admin

      --ignore-failed-read 选项会忽略任何缺少的目录，如果某些服务没有在自己的自定义角色中使用或分隔，这很有用。

   3. 将生成的 tar 文件复制到安全位置。

6. 归档在 overcloud 上删除的行：

   1. 检查归档的已删除实例：

      $ source ~/overcloudrc
      $ nova list --all-tenants --deleted

   2. 如果没有存档删除的实例，请在其中一个 overcloud Controller 节点上输入以下命令来归档已删除实例：

      # su - nova -s /bin/bash -c "nova-manage --debug db archive_deleted_rows --max_rows 1000"

      重新运行此命令，直到您已归档所有已删除的实例。

   3. 在其中一个 overcloud Controller 节点上输入以下命令来清除所有归档的已删除实例：

      # su - nova -s /bin/bash -c "nova-manage --debug db purge --all --all-cells"

   4. 验证没有剩余的已归档实例：

      $ nova list --all-tenants --deleted

流程

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

2. 停止主 OpenStack Platform 服务：

   $ sudo systemctl stop 'openstack-*' 'neutron-*' httpd

   注意

   这会导致 undercloud 的停机时间短。overcloud 在 undercloud 升级过程中仍然可以正常工作。

3. 将 RHEL 版本设置为 RHEL 7.7：

   $ sudo subscription-manager release --set=7.7

4. 更新 python-tripleoclient 软件包及其依赖项，以确保您具有次要版本更新的最新脚本：

   $ sudo yum update -y python-tripleoclient

5. 运行 openstack undercloud upgrade 命令：

   $ openstack undercloud upgrade

6. 等待命令完成其执行。

7. 重新引导 undercloud 以更新操作系统的内核和其他系统软件包：

   $ sudo reboot

8. 稍等片刻，直到节点启动。
9. 以 stack 用户的身份登录 undercloud。

流程

1. 更改自定义环境文件中的 vhost 用户 socket 目录，如 network-environment.yaml ：

   parameter_defaults:
     NeutronVhostuserSocketDir: "/var/lib/vhost_sockets"

2. 将 ovs-dpdk-permissions.yaml 文件添加到 openstack overcloud deploy 命令中，以便将 qemu 组设为 OVS-DPDK 的 hugetlbfs ：

    -e environments/ovs-dpdk-permissions.yaml

3. 确保所有实例的 vHost 用户端口都为 dpdkvhostuserclient 模式。如需更多信息，请参阅 手动更改 vhost 用户端口模式。

流程

1. 检查 yum 日志以确定新镜像存档是否可用：

   $ sudo grep "rhosp-director-images" /var/log/yum.log

2. 如果有新存档，请将当前镜像替换为新镜像。要安装新镜像，首先从 stack 用户主目录(/home/ stack / images )上的 images 目录中删除任何现有的镜像：

   $ rm -rf ~/images/*

3. 在 undercloud 节点上，提供 undercloud 凭证：

   $ source ~/stackrc

4. 解压存档：

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

5. 将 中最新镜像导入到 director，并将节点配置为使用新镜像：

   $ cd ~/images
   $ openstack overcloud image upload --update-existing --image-path /home/stack/images/
   $ openstack overcloud node configure $(openstack baremetal node list -c UUID -f csv --quote none | sed "1d" | paste -s -d " ")

6. 要完成镜像更新，请验证新镜像是否存在：

   $ openstack image list
   $ ls -l /httpboot

   director 还保留旧镜像，并使用更新时的时间戳对其进行重命名。如果不再需要这些镜像，请删除它们。

流程

1. 检查 rhel_reg_release 参数的订阅管理配置。如果没有设置此参数，您必须包括它并设置 7.7:

   parameter_defaults:
     ...
     rhel_reg_release: "7.7"

   确保保存对 overcloud 订阅管理环境文件的更改。

2. 使用您的原始 openstack overcloud deploy 命令更新当前计划，并包含 --update-plan-only 选项。例如：

   $ openstack overcloud deploy --update-plan-only \
     --templates  \
     -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
     -e /home/stack/templates/network-environment.yaml \
     -e /home/stack/templates/storage-environment.yaml \
     -e /home/stack/templates/rhel-registration/environment-rhel-registration.yaml \
     [-e <environment_file>|...]

   --update-plan-only 仅更新存储在 director 中的 Overcloud 计划。使用 -e 选项包括与 Overcloud 相关的环境文件及其更新路径。环境文件的顺序非常重要，因为后续环境文件中定义的参数和资源更为优先。以下列表是环境文件顺序的示例：

   • 任何网络隔离文件，包括 heat 模板集合中的初始化文件(environments/network-isolation.yaml)，然后是自定义 NIC 配置文件。
   • 任何外部负载均衡环境文件。
   • 任何存储环境文件。
   • 任何用于红帽 CDN 或 Satellite 注册的环境文件。
   • 任何其它自定义环境文件。

3. 创建 overcloud 的静态清单文件：

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

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

4. 创建一个包含在所有节点上将操作系统版本设置为 Red Hat Enterprise Linux 7.7 的任务：

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

5. 运行 set_release.yaml playbook：

   $ ansible-playbook -i ~/inventory.yaml -f 25 ~/set_release.yaml --limit undercloud,Controller,Compute

   使用 --limit 选项，将内容应用到所有 Red Hat OpenStack Platform 节点。

6. 使用 openstack overcloud update 命令在所有节点上执行软件包更新：

   $ openstack overcloud update stack -i overcloud

   -i 运行一个互动模式来按顺序更新每个节点。更新过程完成后，脚本会为您提供一个断点进行确认。如果没有 -i 选项，更新会在第一个断点保持暂停。因此，必须包括 -i 选项。

   脚本执行以下功能：

   1. 该脚本在一对一节点上运行：

      1. 对于 Controller 节点，这意味着完全软件包更新。
      2. 对于其他节点，这意味着仅更新 Puppet 模块。

   2. Puppet 同时在所有节点上运行：

      1. 对于 Controller 节点，Puppet 运行会同步配置。
      2. 对于其他节点，Puppet 运行会更新软件包的其余部分并同步配置。

7. 更新过程开始。在此过程中，director 报告 IN_PROGRESS 状态，并定期提示您清除断点。例如：

   starting package update on stack overcloud
   IN_PROGRESS
   IN_PROGRESS
   WAITING
   on_breakpoint: [u'overcloud-compute-0', u'overcloud-controller-2', u'overcloud-controller-1', u'overcloud-controller-0']
   Breakpoint reached, continue? Regexp or Enter=proceed (will clear 49913767-e2dd-4772-b648-81e198f5ed00), no=cancel update, C-c=quit interactive mode:

   按 Enter 清除 on_breakpoint 列表中的最后一个节点中的断点。这将开始该节点的更新。

8. 这个脚本会自动预定义节点的更新顺序：

   • 每个 Controller 节点单独
   • 每个单独 Compute 节点
   • 每个 Ceph Storage 节点
   • 所有其他节点单独

   建议您使用这个顺序来确保更新成功，特别是：

   1. 单独清除每个 Controller 节点的断点。如果节点的服务在更新后必须重启，则每个 Controller 节点都需要一个单独的软件包更新。这可减少到其他 Controller 节点上高可用性服务的中断。
   2. 在 Controller 节点更新后，清除每个 Compute 节点的断点。您还可以键入 Compute 节点名称来清除特定节点上的断点，或使用基于 Python 的正则表达式来一次性在多个 Compute 节点上清除断点。
   3. 清除每个 Ceph Storage 节点的断点。您还可以键入 Ceph Storage 节点名称来清除特定节点上的断点，或使用基于 Python 的正则表达式来一次性清除多个 Ceph Storage 节点上的断点。
   4. 清除所有剩余的断点以更新剩余的节点。您还可以键入节点名称来清除特定节点上的断点，或使用基于 Python 的正则表达式来一次性在多个节点上清除断点。
   5. 等待所有节点完成其更新。

9. 更新命令会在更新完成后报告 COMPLETE 状态：

   ...
   IN_PROGRESS
   IN_PROGRESS
   IN_PROGRESS
   COMPLETE
   update finished with status COMPLETE

10. 如果您为 Controller 节点配置了隔离功能，更新过程可能会禁用它。更新过程完成后，在其中一个 Controller 节点上使用以下命令重新启用隔离：

    $ sudo pcs property set stonith-enabled=true

流程

1. 登录您要重新引导的节点。

2. 可选：如果节点使用 Pacemaker 资源，请停止集群：

   [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster stop

3. 重新引导节点：

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

4. 稍等片刻，直到节点启动。

5. 检查服务。例如：

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

      [heat-admin@overcloud-controller-0 ~]$ sudo pcs status

   2. 如果该节点使用 Systemd 服务，请检查是否所有服务都已启用：

      [heat-admin@overcloud-controller-0 ~]$ sudo systemctl status

   3. 对所有 Controller 和可组合节点重复这些步骤。

流程

1. 登录 Ceph MON 或 Controller 节点，并暂时禁用 Ceph Storage 集群重新平衡：

   $ sudo ceph osd set noout
   $ sudo ceph osd set norebalance

2. 选择第一个 Ceph Storage 节点以重新引导并登录。

3. 重新引导节点：

   $ sudo reboot

4. 稍等片刻，直到节点启动。

5. 登录到 Ceph MON 或 Controller 节点并检查集群状态：

   $ sudo ceph -s

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

6. 从 Ceph MON 或 Controller 节点注销，重新引导下一个 Ceph Storage 节点，并检查其状态。重复此流程，直到您已重新引导所有 Ceph 存储节点。

7. 完成之后，登录 Ceph MON 或 Controller 节点，然后重新启用集群重新平衡：

   $ sudo ceph osd unset noout
   $ sudo ceph osd unset norebalance

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

   $ sudo ceph status

流程

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

2. 要识别您要重新引导的 Compute 节点，请列出所有 Compute 节点：

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

3. 在 overcloud 中，选择 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 节点之间迁移虚拟机。

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

流程

1. 登录到节点。

2. 运行 yum 检查系统软件包：

   $ sudo yum list qemu-img-rhev qemu-kvm-common-rhev qemu-kvm-rhev qemu-kvm-tools-rhev openvswitch

3. 运行 ovs-vsctl 检查当前正在运行的版本：

   $ sudo ovs-vsctl --version

4. 对所有节点重复这些步骤。

流程

1. 查找 undercloud 访问详情：

   $ source ~/stackrc

2. 检查失败的 Systemd 服务：

   $ sudo systemctl list-units --state=failed 'openstack*' 'neutron*' 'httpd' 'docker'

3. 检查 undercloud 可用空间：

   $ df -h

   使用 "Undercloud 要求" 作为基础来确定您是否有足够的可用空间。

4. 如果您在 undercloud 上安装了 NTP，请检查时钟是否已同步：

   $ sudo ntpstat

5. 检查 undercloud 网络服务：

   $ openstack network agent list

   所有代理都应 处于活动状态，其状态应为 UP。

6. 检查 undercloud 计算服务：

   $ openstack compute service list

   所有代理的状态都应 为启用状态，其状态应为 up

流程

1. 查找 undercloud 访问详情：

   $ source ~/stackrc

2. 检查裸机节点的状态：

   $ openstack baremetal node list

   所有节点均应具有有效的电源状态(on)和维护模式，应为 false。

3. 检查失败的 Systemd 服务：

   $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo systemctl list-units --state=failed 'openstack*' 'neutron*' 'httpd' 'docker' 'ceph*'" ; done

4. 检查与所有服务的 HAProxy 连接。获取 haproxy.stats 服务的 Control Plane VIP 地址和身份验证信息：

   $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE sudo 'grep "listen haproxy.stats" -A 6 /etc/haproxy/haproxy.cfg'

5. 使用上一步中获取的连接和身份验证信息来检查 RHOSP 服务的连接状态。

   如果没有启用 SSL，请在以下 cURL 请求中使用这些详情：

   $ curl -s -u admin:<PASSWORD> "http://<IP ADDRESS>:1993/;csv" | egrep -vi "(frontend|backend)" | awk -F',' '{ print $1" "$2" "$18 }'

   如果启用了 SSL，则在以下 cURL 请求中使用这些详情：

   curl -s -u admin:<PASSWORD> "https://<HOSTNAME>:1993/;csv" | egrep -vi "(frontend|backend)" | awk -F',' '{ print $1" "$2" "$18 }'

   将 &lt ;PASSWORD& gt; 和 &lt ;IP ADDRESS > 或 <HOSTNAME > 值替换为 haproxy.stats 服务中的相应信息。生成的列表显示每个节点上的 OpenStack Platform 服务及其连接状态。

6. 检查 overcloud 数据库复制健康状况：

   $ for NODE in $(openstack server list --name controller -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo clustercheck" ; done

7. 检查 RabbitMQ 集群健康状况：

   $ for NODE in $(openstack server list --name controller -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo rabbitmqctl node_health_check" ; done

8. 检查 Pacemaker 资源健康状况：

   $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo pcs status"

   查找：

   • 所有集群节点 在线。
   • 任何集群节点上都没有 停止 资源。
   • 没有 失败的 pacemaker 操作。

9. 检查每个 overcloud 节点上的磁盘空间：

   $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo df -h --output=source,fstype,avail -x overlay -x tmpfs -x devtmpfs" ; done

10. 检查 overcloud Ceph Storage 集群健康状态。以下命令在 Controller 节点上运行 ceph 工具来检查集群：

    $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph -s"

11. 检查 Ceph Storage OSD 是否有可用空间。以下命令在 Controller 节点上运行 ceph 工具来检查可用空间：

    $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph df"

    重要

    每个 Ceph 对象存储守护进程(OSD)的 PG 数量不得超过 250 个。每个 OSD 有更多 PG 升级 Ceph 节点会导致警告状态，并可能导致升级过程失败。在开始升级过程前，您可以增加每个 OSD 的 PG 数量。有关诊断并排除这个问题的更多信息，请参阅 OpenStack FFU 从 10 到 13 超时，因为一个或多个 OSD 中分配的 Ceph PG 大于 250 个。

12. 检查时钟是否在 overcloud 节点上同步

    $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo ntpstat" ; done

13. 查找 overcloud 访问详情：

    $ source ~/overcloudrc

14. 检查 overcloud 网络服务：

    $ openstack network agent list

    所有代理都应 处于活动状态，其状态应为 UP。

15. 检查 overcloud 计算服务：

    $ openstack compute service list

    所有代理的状态都应 为启用状态，其状态应为 up

16. 检查 overcloud 卷服务：

    $ openstack volume service list

    所有代理的状态都应 为启用状态，其状态应为 。

1. 查找 overcloud 访问详情：

   $ source ~/overcloudrc

2. 查找您要生成快照的实例的服务器 ID：

   $ openstack server list

3. 在生成快照前关闭源实例，以确保所有数据清理到磁盘：

   $ openstack server stop SERVER_ID

4. 创建实例的快照镜像：

   $ openstack image create --id SERVER_ID SNAPSHOT_NAME

5. 使用这个快照镜像引导新实例：

   $ openstack server create --flavor DPDK_FLAVOR --nic net-id=DPDK_NET_ID--image SNAPSHOT_NAME INSTANCE_NAME

6. （可选）验证新实例状态为 ACTIVE ：

   $ openstack server list

流程

1. 在每个节点上，运行以下命令将节点的整个 yum 历史记录保存到文件中：

   $ sudo yum history list all > /home/heat-admin/$(hostname)-yum-history-all

2. 在每个节点上，运行以下命令来保存最后的 yum history 项的 ID：

   $ sudo yum history list all | head -n 5 | tail -n 1 | awk '{print $1}' > /home/heat-admin/$(hostname)-yum-history-all-last-id

3. 将这些文件复制到安全位置。

流程

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

2. 禁用当前的 OpenStack Platform 存储库：

   $ sudo subscription-manager repos --disable=rhel-7-server-openstack-10-rpms

3. 启用新的 OpenStack Platform 存储库：

   $ sudo subscription-manager repos --enable=rhel-7-server-openstack-11-rpms

4. 禁用 overcloud 基础镜像的更新：

   $ sudo yum-config-manager --setopt=exclude=rhosp-director-images* --save

5. 停止主 OpenStack Platform 服务：

   $ sudo systemctl stop 'openstack-*' 'neutron-*' httpd

   注意

   这会导致 undercloud 的停机时间短。overcloud 在 undercloud 升级过程中仍然可以正常工作。

6. 默认的 Provisioning/Control Plane 网络已从 192.0.2.0/24 更改为 192.168.24.0/24。如果您在之前的 undercloud.conf 文件中使用了默认网络值，则 Provisioning/Control Plane 网络被设置为 192.0.2.0/24。这意味着您需要在 undercloud.conf 文件中设置某些参数来继续使用 192.0.2.0/24 网络。这些参数：

   • local_ip
   • network_gateway
   • undercloud_public_vip
   • undercloud_admin_vip
   • network_cidr
   • masquerade_network
   • dhcp_start
   • dhcp_end

   在 undercloud.conf 中设置网络值，以确保在将来的升级过程中继续使用 192.0.2.0/24 CIDR。在运行 openstack undercloud upgrade 命令前，请确保您的网络配置设置正确。

7. 运行 yum 以升级 director 的主软件包：

   $ sudo yum update -y instack-undercloud openstack-puppet-modules openstack-tripleo-common python-tripleoclient

8. 运行以下命令来升级 undercloud：

   $ openstack undercloud upgrade

9. 等待 undercloud 升级过程完成。

流程

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

2. 禁用当前的 OpenStack Platform 存储库：

   $ sudo subscription-manager repos --disable=rhel-7-server-openstack-11-rpms

3. 启用新的 OpenStack Platform 存储库：

   $ sudo subscription-manager repos --enable=rhel-7-server-openstack-12-rpms

4. 禁用 overcloud 基础镜像的更新：

   $ sudo yum-config-manager --setopt=exclude=rhosp-director-images* --save

5. 运行 yum 以升级 director 的主软件包：

   $ sudo yum update -y python-tripleoclient

6. 编辑 /home/stack/undercloud.conf 文件，检查 enabled_drivers 参数是否不包含 pxe_ssh 驱动程序。这个驱动已弃用，而是使用 Virtual Baseboard Management Controller (VBMC)并从 Red Hat OpenStack Platform 中删除。有关这个新驱动程序和迁移说明的更多信息，请参阅 Director 安装和使用指南中的 附录 "Virtual Baseboard Management Controller (VBMC) "。

7. 运行以下命令来升级 undercloud：

   $ openstack undercloud upgrade

8. 等待 undercloud 升级过程完成。

流程

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

2. 禁用当前的 OpenStack Platform 存储库：

   $ sudo subscription-manager repos --disable=rhel-7-server-openstack-12-rpms

3. 将 RHEL 版本设置为 RHEL 7.9:

   $ sudo subscription-manager release --set=7.9

4. 启用新的 OpenStack Platform 存储库：

   $ sudo subscription-manager repos --enable=rhel-7-server-openstack-13-rpms

5. 重新启用 overcloud 基础镜像的更新：

   $ sudo yum-config-manager --setopt=exclude= --save

6. 运行 yum 以升级 director 的主软件包：

   $ sudo yum update -y python-tripleoclient

7. 运行以下命令来升级 undercloud：

   $ openstack undercloud upgrade

8. 等待 undercloud 升级过程完成。

9. 重新引导 undercloud 以更新操作系统的内核和其他系统软件包：

   $ sudo reboot

10. 稍等片刻，直到节点启动。

流程

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

2. 停止并禁用 openstack-glance-registry 服务：

   $ sudo systemctl stop openstack-glance-registry
   $ sudo systemctl disable openstack-glance-registry

3. 停止并禁用 mongod 服务：

   $ sudo systemctl stop mongod
   $ sudo systemctl disable mongod

流程

1. 要在 overcloud 部署中直接从 registry.redhat.io 拉取镜像，需要一个环境文件来指定镜像参数。运行以下命令以生成容器镜像环境文件：

   (undercloud) $ sudo openstack overcloud container image prepare \
     --namespace=registry.redhat.io/rhosp13 \
     --prefix=openstack- \
     --tag-from-label {version}-{release} \
     --output-env-file=/home/stack/templates/overcloud_images.yaml

   • 使用 -e 选项包括可选服务的任何环境文件。
   • 使用 -r 选项包括自定义角色文件。
   • 如果使用 Ceph Storage，包括额外的参数来定义 Ceph Storage 容器镜像位置：-- set ceph_namespace ,--set ceph _image,--set ceph_tag.

2. 修改 overcloud_images.yaml 文件，并包括下列参数以在部署期间与 registry.redhat.io 进行身份验证：

   ContainerImageRegistryLogin: true
   ContainerImageRegistryCredentials:
     registry.redhat.io:
       <USERNAME>: <PASSWORD>

   • 将 & lt;USERNAME& gt ; 和 <PASSWORD > 替换为 registry.redhat.io 的凭证。

     overcloud_images.yaml 文件包含 undercloud 上的镜像位置。在您的部署中包含此文件。

     注意

     在运行 openstack overcloud deploy 命令前，您必须登录远程 registry：

     (undercloud) $ sudo docker login registry.redhat.io

流程

1. 查找本地 undercloud registry 的地址。地址使用以下模式：

   <REGISTRY_IP_ADDRESS>:8787

   使用 undercloud 的 IP 地址，之前使用 undercloud.conf 文件中的 local_ip 参数进行设置。对于下列命令，该地址被假定为 192.168.24.1:8787。

2. 登录到 registry.redhat.io ：

   (undercloud) $ docker login registry.redhat.io --username $RH_USER --password $RH_PASSWD

3. 创建模板，将镜像上传到本地 registry，以及环境文件以引用这些镜像：

   (undercloud) $ openstack overcloud container image prepare \
     --namespace=registry.redhat.io/rhosp13 \
     --push-destination=192.168.24.1:8787 \
     --prefix=openstack- \
     --tag-from-label {version}-{release} \
     --output-env-file=/home/stack/templates/overcloud_images.yaml \
     --output-images-file /home/stack/local_registry_images.yaml

   • 使用 -e 选项包括可选服务的任何环境文件。
   • 使用 -r 选项包括自定义角色文件。
   • 如果使用 Ceph Storage，包括额外的参数来定义 Ceph Storage 容器镜像位置：-- set ceph_namespace ,--set ceph _image,--set ceph_tag.

4. 验证是否已创建以下两个文件：

   • local_registry_images.yaml，其中包含来自远程源的容器镜像信息。使用此文件将 Red Hat Container Registry (registry.redhat.io)中的镜像拉取到 undercloud。
   • overcloud_images.yaml，其中包含 undercloud 上的最终镜像位置。您的部署会包含这个文件。

5. 从远程 registry 拉取容器镜像并将其推送到 undercloud registry：

   (undercloud) $ openstack overcloud container image upload \
     --config-file  /home/stack/local_registry_images.yaml \
     --verbose

   拉取所需的镜像可能需要一些时间，具体取决于您的网络和 undercloud 磁盘的速度。

   注意

   容器镜像大约消耗 10 GB 磁盘空间。

6. 该镜像现在存储在 undercloud 的 docker-distribution 注册表中。要查看 undercloud 的 docker-distribution registry 中的镜像列表，请运行以下命令：

   (undercloud) $  curl http://192.168.24.1:8787/v2/_catalog | jq .repositories[]

   注意

   本身中的 _catalog 资源仅显示 100 个镜像。要显示更多镜像，请使用 ?n=<interger& gt; 查询字符串及 _catalog 资源来显示更多镜像数量：

   (undercloud) $  curl http://192.168.24.1:8787/v2/_catalog?n=150 | jq .repositories[]

   要查看特定镜像的标签列表，请使用 skopeo 命令：

   (undercloud) $ curl -s http://192.168.24.1:8787/v2/rhosp13/openstack-keystone/tags/list | jq .tags

   要验证标记的镜像，使用 skopeo 命令：

   (undercloud) $ skopeo inspect --tls-verify=false docker://192.168.24.1:8787/rhosp13/openstack-keystone:13.0-44

流程

1. 创建模板以将镜像拉取到本地 registry：

   $ source ~/stackrc
   (undercloud) $ openstack overcloud container image prepare \
     --namespace=rhosp13 \
     --prefix=openstack- \
     --output-images-file /home/stack/satellite_images

   • 使用 -e 选项包括可选服务的任何环境文件。
   • 使用 -r 选项包括自定义角色文件。
   • 如果使用 Ceph Storage，包括额外的参数来定义 Ceph Storage 容器镜像位置：-- set ceph_namespace ,--set ceph _image,--set ceph_tag.
   注意

   此版本的 openstack overcloud 容器镜像准备命令以 registry.redhat.io 上的 registry 为目标，以生成镜像列表。它使用与 openstack overcloud 容器镜像准备 命令不同的值。

2. 这会利用容器镜像信息创建名为 satellite_images 的文件。您将使用此文件将容器镜像同步到卫星 6 服务器。

3. 从 satellite_images 文件中删除特定于 YAML 的信息，并将其转换为仅包含镜像列表的平面文件。以下 sed 命令完成此操作：

   (undercloud) $ awk -F ':' '{if (NR!=1) {gsub("[[:space:]]", ""); print $2}}' ~/satellite_images > ~/satellite_images_names

   这为您提供了拉取到 Satellite 服务器的镜像列表。

4. 将 satellite_images_names 文件复制到包含 Satellite 6 hammer 工具的系统中。或者，根据 Hammer CLI 指南中的说明将 hammer 工具安装到 undercloud 中。

5. 运行以下 hammer 命令，在您的 Satellite 组织创建新产品(OSP13 容器)：

   $ hammer product create \
     --organization "ACME" \
     --name "OSP13 Containers"

   该定制产品将会包含我们的镜像。

6. 为产品添加基本容器镜像：

   $ hammer repository create \
     --organization "ACME" \
     --product "OSP13 Containers" \
     --content-type docker \
     --url https://registry.redhat.io \
     --docker-upstream-name rhosp13/openstack-base \
     --name base

7. 添加 satellite_images 文件中的 overcloud 容器镜像。

   $ while read IMAGE; do \
     IMAGENAME=$(echo $IMAGE | cut -d"/" -f2 | sed "s/openstack-//g" | sed "s/:.*//g") ; \
     hammer repository create \
     --organization "ACME" \
     --product "OSP13 Containers" \
     --content-type docker \
     --url https://registry.redhat.io \
     --docker-upstream-name $IMAGE \
     --name $IMAGENAME ; done < satellite_images_names

8. 同步容器镜像：

   $ hammer product synchronize \
     --organization "ACME" \
     --name "OSP13 Containers"

   等待 Satellite 服务器完成同步。

   注意

   根据具体配置情况，hammer 可能会询问您的 Satellite 服务器用户名和密码。您可以使用配置文件将 hammer 配置为自动登录。请参阅 Hammer CLI 指南中的 "身份验证 "部分。

9. 如果您的 Satellite 6 服务器使用内容视图，请创建新的内容视图版本来纳入镜像。

10. 检查 base 镜像可用的标签：

    $ hammer docker tag list --repository "base" \
      --organization "ACME" \
      --product "OSP13 Containers"

    这会显示 OpenStack Platform 容器镜像的标签。

11. 返回到 undercloud，并为卫星服务器上的镜像生成环境文件。以下是生成环境文件的示例命令：

    (undercloud) $ openstack overcloud container image prepare \
      --namespace=satellite6.example.com:5000 \
      --prefix=acme-osp13_containers- \
      --tag-from-label {version}-{release} \
      --output-env-file=/home/stack/templates/overcloud_images.yaml

    注意

    此版本的 openstack overcloud 容器镜像准备命令以 Satellite 服务器为目标。它使用与上一步中使用的 openstack overcloud 容器镜像准备命令不同的值。

    在运行这个命令时，包含以下数据：

    • --namespace - Satellite 服务器上 registry 的 URL 和端口。Red Hat Satellite 上的 registry 端口是 5000。例如： --namespace=satellite6.example.com:5000。

      注意

      如果您使用 Red Hat Satellite 版本 6.10，则不需要指定端口。使用 443 的默认端口。如需更多信息，请参阅 "如何把 RHOSP13 部署调整为 Red Hat Satellite 6.10？"。

    • --prefix= - 前缀基于标签的 Satellite 6 约定，它使用小写字符并用下划线替换空格。前缀根据您是否使用内容视图而不同：

      • 如果您使用了内容视图，则前缀的结构为 [组织]-[环境]-[内容视图]-[产品]-。例如： acme-production-myosp13-osp13_containers-。
      • 如果不使用内容视图，则前缀的结构为 [组织]-[产品]-。例如： acme-osp13_containers-。
    • --tag-from-label {version}-{release} - 识别每个镜像的最新标签。
    • -e - 包含可选服务的任何环境文件。
    • - R - 包含自定义角色文件。

    • --set ceph_namespace,--set ceph_image,--set ceph_tag - If using Ceph Storage, 包括额外的参数来定义 Ceph Storage 容器镜像位置。请注意，ceph_image 现包含特定于 Satellite 的前缀。这个前缀与 --prefix 选项的值相同。例如：

      --set ceph_image=acme-osp13_containers-rhceph-3-rhel7

      这将确保 overcloud 使用 Ceph 容器镜像，它利用卫星命名约定。

12. overcloud_images.yaml 文件包含 Satellite 服务器上的镜像位置。在您的部署中包含此文件。

流程

1. 查看您的自定义环境文件：

   $ cat ~/templates/custom_environment.yaml

2. 检查文件内容中的 resource_registry 部分。

3. 检查 resource_registry 部分中的任何可组合服务。可组合的服务与以下命名空间：

   OS::TripleO::Services

   例如，以下可组合服务用于 OpenStack Bare Metal Service (ironic) API：

   OS::TripleO::Services::IronicApi

4. 检查可组合服务是否映射到特定 Puppet 的 Heat 模板。例如：

   resource_registry:
     OS::TripleO::Services::IronicApi: /usr/share/openstack-triple-heat-template/puppet/services/ironic-api.yaml

5. 检查 /usr/share/openstack-triple-heat-template/docker/services/ services/ 中是否存在容器化版本的 Heat 模板，并将服务重新 map 到容器化版本：

   resource_registry:
     OS::TripleO::Services::IronicApi: /usr/share/openstack-triple-heat-template/docker/services/ironic-api.yaml

   另外，为 服务使用更新的环境文件，该文件位于 /usr/share/openstack-tripleo-heat-templates/environments/ 中。例如，启用 OpenStack Bare Metal Service (ironic)的最新环境文件是 /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml，其中包含容器化服务映射。

   如果自定义服务没有使用 containerised 服务，请保留到特定于 Puppet 的 Heat 模板的映射。

流程

1. 如果使用 director 管理的或外部 Ceph Storage 集群，请安装 ceph-ansible 软件包：

   1. 在 undercloud 上启用 Ceph 工具存储库：

      [stack@director ~]$ sudo subscription-manager repos --enable=rhel-7-server-rhceph-3-tools-rpms

   2. 将 ceph-ansible 软件包安装到 undercloud:

      [stack@director ~]$ sudo yum install -y ceph-ansible

2. 检查特定于 Ceph 的环境文件，并确保您的 Ceph 特定 heat 资源使用容器化服务：

   • 对于 director 管理的 Ceph Storage 集群，请确保 resource_register 中的资源指向 docker/services/ceph-ansible 中的模板：

     resource_registry:
       OS::TripleO::Services::CephMgr: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-mgr.yaml
       OS::TripleO::Services::CephMon: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-mon.yaml
       OS::TripleO::Services::CephOSD: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-osd.yaml
       OS::TripleO::Services::CephClient: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-client.yaml

     重要

     此配置包含在 /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml 环境文件中，您可以使用 -e 包含在所有将来的部署命令中。

     注意

     如果环境中您要使用的环境或模板文件没有存在于 /usr/share 目录中，您必须包括文件的绝对路径。

   • 对于外部 Ceph Storage 集群，请确保 resource_register 中的资源指向 docker/services/ceph-ansible 中的模板：

     resource_registry:
       OS::TripleO::Services::CephExternal: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-external.yaml

     重要

     此配置包含在 /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible-external.yaml 环境文件中，您可以使用 -e 包括在所有将来的部署命令中。

3. 对于 director 管理的 Ceph Storage 集群，请使用新的 CephAnsibleDisksConfig 参数来定义如何映射磁盘。以前的 Red Hat OpenStack Platform 版本使用 ceph::profile::params::osds hieradata 来定义 OSD 布局。将此 hieradata 转换为 CephAnsibleDisksConfig 参数的结构。以下示例说明了如何在 collocated 和 non-collocated Ceph journal 磁盘的情况下将 hieradata 转换为 CephAnsibleDisksConfig 参数的结构。

   重要

   您必须设置 osd_scenario。如果未设置 osd_scenario，则可能会导致部署失败。

   • 在 Ceph 日志磁盘并置的情形中，如果您的 hieradata 包含以下内容：

     parameter_defaults:
       ExtraConfig:
         ceph::profile::params::osd_journal_size: 512
         ceph::profile::params::osds:
           '/dev/sdb': {}
           '/dev/sdc': {}
           '/dev/sdd': {}

     使用 CephAnsibleDisksConfig 参数以下列方式转换 hieradata，并将 ceph::profile::params::osds 设置为 {} ：

     parameter_defaults:
       CephAnsibleDisksConfig:
         devices:
         - /dev/sdb
         - /dev/sdc
         - /dev/sdd
         journal_size: 512
         osd_scenario: collocated
       ExtraConfig:
           ceph::profile::params::osds: {}

   • 在一个场景中，如果 hieradata 包含以下内容，则日志位于更快速专用设备，并且是非并置：

     parameter_defaults:
       ExtraConfig:
         ceph::profile::params::osd_journal_size: 512
         ceph::profile::params::osds:
           '/dev/sdb':
              journal: ‘/dev/sdn’
           '/dev/sdc':
              journal: ‘/dev/sdn’
           '/dev/sdd':
              journal: ‘/dev/sdn’

     使用 CephAnsibleDisksConfig 参数以下列方式转换 hieradata，并将 ceph::profile::params::osds 设置为 {} ：

     parameter_defaults:
       CephAnsibleDisksConfig:
         devices:
         - /dev/sdb
         - /dev/sdc
         - /dev/sdd
         dedicated_devices:
         - /dev/sdn
         - /dev/sdn
         - /dev/sdn
         journal_size: 512
         osd_scenario: non-collocated
       ExtraConfig:
         ceph::profile::params::osds: {}

   有关 ceph-ansible 中使用的 OSD 磁盘布局选项的完整列表，请查看 /usr/share/ceph-ansible/group_vars/osds.yml.sample 中的示例文件。

4. 使用 -e 选项，包含新的 Ceph 配置环境文件及将来的部署命令。这包括以下文件：

   • director 管理的 Ceph Storage:

     • /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml.
     • 具有基于 Ansible 的磁盘映射的环境文件。
     • 任何额外环境文件及 Ceph 存储自定义。

   • 外部 Ceph 存储：

     • /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible-external.yaml
     • 任何额外环境文件及 Ceph 存储自定义。

流程

1. director 的动态 Ansible 脚本已更新至 OpenStack Platform 12 版本，该版本使用 overcloud 计划中的 RoleNetHostnameMap Heat 参数来定义清单。但是，overcloud 当前使用 OpenStack Platform 11 模板版本，它没有 RoleNetHostnameMap 参数。这意味着您需要创建一个临时静态清单文件，您可以使用以下命令生成：

   $ openstack server list -c Networks -f value | cut -d"=" -f2 > overcloud_hosts

2. 创建一个包含以下内容的 Ansible playbook (undercloud-ca.yml)：

   ---
   - name: Add undercloud CA to overcloud nodes
     hosts: all
     user: heat-admin
     become: true
     vars:
       ca_certificate: /etc/pki/ca-trust/source/anchors/cm-local-ca.pem
     tasks:
       - name: Copy undercloud CA
         copy:
           src: "{{ ca_certificate }}"
           dest: /etc/pki/ca-trust/source/anchors/
       - name: Update trust
         command: "update-ca-trust extract"
       - name: Get the swift endpoint
         shell: |
           sudo hiera swift::keystone::auth::public_url | awk -F/ '{print $3}'
         register: swift_endpoint
         delegate_to: 127.0.0.1
         become: yes
         become_user: stack
       - name: Verify URL
         uri:
           url: https://{{ swift_endpoint.stdout }}/healthcheck
           return_content: yes
         register: verify
       - name: Report output
         debug:
           msg: "{{ ansible_hostname }} can access the undercloud's Public API"
         when: verify.content == "OK"

   此 playbook 包含多个任务，在每个节点上执行以下操作：

   • 将 undercloud 的证书颁发机构文件复制到 overcloud 节点。如果 undercloud 生成的默认位置为 /etc/pki/ca-trust/source/anchors/cm-local-ca.pem。
   • 执行 命令，以更新 overcloud 节点上的证书颁发机构信任数据库。
   • 检查 overcloud 节点上的 undercloud Object Storage Public API，并报告成功。

3. 使用以下命令运行 playbook：

   $ ansible-playbook -i overcloud_hosts undercloud-ca.yml

   这将使用临时清单为您的 overcloud 节点提供 Ansible。

   如果使用自定义证书颁发机构文件，您可以将 ca_certificate 变量改为一个位置。例如：

   $ ansible-playbook -i overcloud_hosts undercloud-ca.yml -e ca_certificate=/home/stack/ssl/ca.crt.pem

4. 生成的 Ansible 输出应该会显示节点的 debug 消息。例如：

   ok: [192.168.24.100] => {
       "msg": "overcloud-controller-0 can access the undercloud's Public API"
   }

流程

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

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

2. 如果结果在所选文件中显示任何角色（如 Controller ExtraConfig ）的 ExtraConfig 参数，请检查该文件中的整个参数结构。

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. 运行以下命令，在 OVERCLOUD_HOSTS 环境变量中保存节点 IP 地址列表：

   $ source ~/stackrc
   $ export OVERCLOUD_HOSTS=$(openstack server list -f value -c Networks | cut -d "=" -f 2 | tr '\n' ' ')

2. 运行以下脚本：

   $ /usr/share/openstack-tripleo-heat-templates/deployed-server/scripts/enable-ssh-admin.sh

3. 继续升级。

   • 在将 openstack overcloud upgrade run 命令与预置备节点搭配使用时，请包含 --ssh-user tripleo-admin 参数。

   • 升级 Compute 或 Object Storage 节点时，使用以下方法：

     1. 将 -U 选项与 upgrade-non-controller.sh 脚本一起使用，并指定 stack 用户。这是因为预置备节点的默认用户是 stack，而不是 heat-admin。

     2. 使用带 --upgrade 选项的节点 IP 地址。这是因为节点没有使用 director 的 Compute (nova)和 Bare Metal (ironic)服务来管理，且没有节点名称。

        例如：

        $ upgrade-non-controller.sh -U stack --upgrade 192.168.24.100

流程

1. Source stackrc 文件：

   $ source ~/stackrc

2. 使用适合部署的所有相关选项和环境文件运行快速升级准备命令：

   $ openstack overcloud ffwd-upgrade prepare \
       --templates \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /home/stack/templates/deprecated_cli_options.yaml \
       -e /home/stack/templates/custom_repositories_script.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       -e <ENVIRONMENT FILE>

   包含以下与您的环境相关的选项：

   • 自定义配置环境文件(-e)。例如：

     • 容器镜像位置(overcloud_images.yaml)的环境文件。请注意，升级命令可能会显示有关使用 --container-registry-file 的警告。您可以忽略这个警告，因为这个选项已弃用，而是使用 -e 作为容器镜像环境文件。
     • 如果适用，使用 deprecated_cli_options.yaml 将已弃用的 CLI 选项映射到 Heat 参数的环境文件。
     • 如果适用，使用 custom_repositories_script.yaml 的自定义存储库脚本环境文件。
     • 如果使用 Ceph Storage 节点，相关的环境文件。
     • 任何与您环境相关的额外环境文件。
   • 如果使用自定义堆栈名称，请使用 --stack 选项传递名称。
   • 如果适用，您的自定义角色(roles_data)文件使用 --roles-file。
   重要

   提示会询问您是否要执行 ffwd-upgrade 命令。输入 yes。

   注意

   您可以多次运行 openstack ffwd-upgrade 准备 命令。如果命令失败，您可以修复模板中的问题，然后重新运行 命令。

3. overcloud 计划更新 OpenStack Platform 13 版本。等待快进升级准备完成。
4. 在进行升级前，先创建 overcloud 的快照或备份。

5. 运行 fast forward upgrade 命令：

   $ openstack overcloud ffwd-upgrade run

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

   提示会询问您是否要执行 ffwd-upgrade 命令。输入 yes。

   注意

   您可以多次运行 openstack ffwd-upgrade 命令。如果命令失败，您可以修复模板中的问题，然后重新运行 命令。

6. 等待快速升级完成。

流程

1. Source stackrc 文件：

   $ source ~/stackrc

2. 如果使用单体 Controller 节点，请针对 Controller 角色运行 upgrade 命令：

   $ openstack overcloud upgrade run --nodes Controller --skip-tags validation

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

3. 如果使用 Controller 服务在多个角色间分割：

   1. 使用 Pacemaker 服务为角色运行 upgrade 命令：

      $ openstack overcloud upgrade run --nodes ControllerOpenStack --skip-tags validation
      $ openstack overcloud upgrade run --nodes Database --skip-tags validation
      $ openstack overcloud upgrade run --nodes Messaging --skip-tags validation
      $ openstack overcloud upgrade run --nodes Telemetry --skip-tags validation

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

   2. 对 Networker 角色运行 upgrade 命令：

      $ openstack overcloud upgrade run --nodes Networker --skip-tags validation

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

   3. 对剩余的自定义角色运行 upgrade 命令，但 Compute 或 CephStorage 角色除外：

      $ openstack overcloud upgrade run --nodes ObjectStorage --skip-tags validation

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

流程

1. Source stackrc 文件：

   $ source ~/stackrc

2. 运行 upgrade 命令：

   $ openstack overcloud upgrade run --nodes compute-0 --skip-tags validation

   注意

   命令使用 --skip-tags 验证，因为 OpenStack Platform 服务在 overcloud 上不活跃，且无法验证。

   • 如果使用自定义堆栈名称，请使用 --stack 选项传递名称。
3. 等待测试节点升级完成。

流程

1. Source stackrc 文件：

   $ source ~/stackrc

2. 运行 upgrade 命令：

   $ openstack overcloud upgrade run --nodes Compute --skip-tags validation

   注意

   命令使用 --skip-tags 验证，因为 OpenStack Platform 服务在 overcloud 上不活跃，且无法验证。

   • 如果您使用的是自定义堆栈名称，请使用 --stack 选项传递名称。
   • 如果您使用的是自定义 Compute 角色，请确保使用 --nodes 选项包含角色名称。
3. 等待 Compute 节点升级完成。

流程

1. Source stackrc 文件：

   $ source ~/stackrc

2. 运行 upgrade 命令：

   $ openstack overcloud upgrade run --nodes CephStorage --skip-tags validation

   注意

   命令使用 --skip-tags 验证，因为 OpenStack Platform 服务在 overcloud 上不活跃，且无法验证。

   • 如果使用自定义堆栈名称，请使用 --stack 选项传递名称。
3. 等待节点升级完成。

4. 运行 Ceph Storage upgrade 命令。例如：

   $ openstack overcloud ceph-upgrade run \
       --templates \
       -e <ENVIRONMENT FILE> \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /home/stack/templates/deprecated_cli_options.yaml \
       -e /home/stack/templates/custom_repositories_script.yaml
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       --ceph-ansible-playbook '/usr/share/ceph-ansible/infrastructure-playbooks/switch-from-non-containerized-to-containerized-ceph-daemons.yml,/usr/share/ceph-ansible/infrastructure-playbooks/rolling_update.yml'

   包含以下与您的环境相关的选项：

   • 自定义配置环境文件(-e)。例如：

     • 容器镜像位置(overcloud_images.yaml)的环境文件。请注意，升级命令可能会显示有关使用 --container-registry-file 的警告。您可以忽略这个警告，因为这个选项已弃用，而是使用 -e 作为容器镜像环境文件。
     • 如果适用，使用 deprecated_cli_options.yaml 将已弃用的 CLI 选项映射到 Heat 参数的环境文件。
     • 如果适用，使用 custom_repositories_script.yaml 的自定义存储库脚本环境文件。
     • Ceph Storage 节点的相关环境文件。
     • 任何与您环境相关的额外环境文件。
   • 如果使用自定义堆栈名称，请使用 --stack 选项传递名称。
   • 如果适用，您的自定义角色(roles_data)文件使用 --roles-file。
   • 以下 ansible playbook：
   • /usr/share/ceph-ansible/infrastructure-playbooks/switch-from-non-containerized-containerized-ceph-daemons.yml
   • /usr/share/ceph-ansible/infrastructure-playbooks/rolling_update.yml
5. 等待 Ceph Storage 节点升级完成。

流程

1. 查找 stackrc 文件：

   $ source ~/stackrc

2. 运行 upgrade 命令：

   $ openstack overcloud upgrade run --roles ComputeHCI

   如果您使用自定义堆栈名称，请使用 --stack 选项将名称传递给 upgrade 命令。

3. 运行 Ceph Storage upgrade 命令。例如：

   $ openstack overcloud ceph-upgrade run \
       --templates \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       -e <ENVIRONMENT FILE>

   包含以下与您的环境相关的选项：

   • 自定义配置环境文件(-e)。例如：

     • 容器镜像位置(overcloud_images.yaml)的环境文件。请注意，升级命令可能会显示有关使用 --container-registry-file 的警告。您可以忽略这个警告，因为这个选项已弃用，而是使用 -e 作为容器镜像环境文件。
     • 如果适用，使用 deprecated_cli_options.yaml 将已弃用的 CLI 选项映射到 Heat 参数的环境文件。
     • 如果适用，使用 custom_repositories_script.yaml 的自定义存储库脚本环境文件。
     • Ceph Storage 节点的相关环境文件。
   • 如果使用自定义堆栈名称，请使用 --stack 选项传递名称。
   • 如果适用，您的自定义角色(roles_data)文件使用 --roles-file。
   • 以下 ansible playbook：
   • /usr/share/ceph-ansible/infrastructure-playbooks/switch-from-non-containerized-containerized-ceph-daemons.yml
   • /usr/share/ceph-ansible/infrastructure-playbooks/rolling_update.yml
4. 等待 Ceph Storage 节点升级完成。

流程

1. 查找 stackrc 文件：

   $ source ~/stackrc

2. 为 Compute 节点运行 upgrade 命令：

   $ openstack overcloud upgrade run --roles Compute
   If using a custom stack name, pass the name with the --stack option.

3. 等待节点升级完成。

4. 为 ComputeHCI 节点运行 upgrade 命令：

   $ openstack overcloud upgrade run --roles ComputeHCI
   If using a custom stack name, pass the name with the --stack option.

5. 等待节点升级完成。

6. 为 Ceph Storage 节点运行 upgrade 命令：

   $ openstack overcloud upgrade run --roles CephStorage

7. 等待 Ceph Storage 节点升级完成。

8. 运行 Ceph Storage upgrade 命令。例如：

   $ openstack overcloud ceph-upgrade run \
       --templates \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       -e <ENVIRONMENT FILE>

   包含以下与您的环境相关的选项：

   • 自定义配置环境文件(-e)。例如：

     • 容器镜像位置(overcloud_images.yaml)的环境文件。请注意，升级命令可能会显示有关使用 --container-registry-file 的警告。您可以忽略这个警告，因为这个选项已弃用，而是使用 -e 作为容器镜像环境文件。
     • 如果适用，使用 deprecated_cli_options.yaml 将已弃用的 CLI 选项映射到 Heat 参数的环境文件。
     • 如果适用，使用 custom_repositories_script.yaml 的自定义存储库脚本环境文件。
     • Ceph Storage 节点的相关环境文件。
     • 任何与您环境相关的额外环境文件。
   • 如果使用自定义堆栈名称，请使用 --stack 选项传递名称。
   • 如果适用，您的自定义角色(roles_data)文件使用 --roles-file。
   • 以下 ansible playbook：
   • /usr/share/ceph-ansible/infrastructure-playbooks/switch-from-non-containerized-containerized-ceph-daemons.yml
   • /usr/share/ceph-ansible/infrastructure-playbooks/rolling_update.yml
9. 等待 Ceph Storage 节点升级完成。

流程

1. Source stackrc 文件：

   $ source ~/stackrc

2. 运行 fast forward upgrade finalization 命令：

   $ openstack overcloud ffwd-upgrade converge \
       --templates \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /home/stack/templates/deprecated_cli_options.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       -e <OTHER ENVIRONMENT FILES>

   包含以下与您的环境相关的选项：

   • 自定义配置环境文件(-e)。例如：

     • 容器镜像位置(overcloud_images.yaml)的环境文件。请注意，升级命令可能会显示有关使用 --container-registry-file 的警告。您可以忽略这个警告，因为这个选项已弃用，而是使用 -e 作为容器镜像环境文件。
     • 如果适用，使用 deprecated_cli_options.yaml 将已弃用的 CLI 选项映射到 Heat 参数的环境文件。
     • 如果使用 Ceph Storage 节点，相关的环境文件。
     • 任何与您环境相关的额外环境文件。
   • 如果使用自定义堆栈名称，请使用 --stack 选项传递名称。
   • 如果适用，您的自定义角色(roles_data)文件使用 --roles-file。
   重要

   提示会询问您是否要执行 ffwd-upgrade 命令。输入 yes。

3. 等待快速升级最终完成。

流程

1. 登录您要重新引导的节点。

2. 可选：如果节点使用 Pacemaker 资源，请停止集群：

   [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster stop

3. 重新引导节点：

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

4. 稍等片刻，直到节点启动。

5. 检查服务。例如：

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

      [heat-admin@overcloud-controller-0 ~]$ sudo pcs status

   2. 如果该节点使用 Systemd 服务，请检查是否所有服务都已启用：

      [heat-admin@overcloud-controller-0 ~]$ sudo systemctl status

   3. 对所有 Controller 和可组合节点重复这些步骤。

流程

1. 登录 Ceph MON 或 Controller 节点，并暂时禁用 Ceph Storage 集群重新平衡：

   $ sudo ceph osd set noout
   $ sudo ceph osd set norebalance

2. 选择第一个 Ceph Storage 节点以重新引导并登录。

3. 重新引导节点：

   $ sudo reboot

4. 稍等片刻，直到节点启动。

5. 登录到 Ceph MON 或 Controller 节点并检查集群状态：

   $ sudo ceph -s

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

6. 从 Ceph MON 或 Controller 节点注销，重新引导下一个 Ceph Storage 节点，并检查其状态。重复此流程，直到您已重新引导所有 Ceph 存储节点。

7. 完成之后，登录 Ceph MON 或 Controller 节点，然后重新启用集群重新平衡：

   $ sudo ceph osd unset noout
   $ sudo ceph osd unset norebalance

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

   $ sudo ceph status

流程

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

2. 要识别您要重新引导的 Compute 节点，请列出所有 Compute 节点：

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

3. 在 overcloud 中，选择 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 节点之间迁移虚拟机。

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

流程

1. 登录 Ceph MON 或 Controller 节点，并暂时禁用 Ceph Storage 集群重新平衡：

   $ sudo ceph osd set noout
   $ sudo ceph osd set norebalance

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

3. 列出所有的 Compute 节点及其 UUID：

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

   确定您要重新引导的 Compute 节点的 UUID。

4. 在 undercloud 中，选择 Compute 节点并禁用它：

   $ source ~/overcloudrc
   (overcloud) $ openstack compute service list
   (overcloud) $ openstack compute service set [hostname] nova-compute --disable

5. 列出 Compute 节点上的所有实例：

   (overcloud) $ openstack server list --host [hostname] --all-projects

6. 使用以下命令之一迁移您的实例：

   1. 将实例迁移到您选择的特定主机：

      (overcloud) $ openstack server migrate [instance-id] --live [target-host]--wait

   2. 让 nova-scheduler 自动选择目标主机：

      (overcloud) $ nova live-migration [instance-id]

   3. 一次性实时迁移所有实例：

      $ nova host-evacuate-live [hostname]

      注意

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

7. 等待迁移完成。

8. 确认迁移成功完成：

   (overcloud) $ openstack server list --host [hostname] --all-projects

9. 继续迁移实例，直到所选 Compute 节点中不剩任何实例。

10. 登录到 Ceph MON 或 Controller 节点并检查集群状态：

    $ sudo ceph -s

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

11. 重新引导 Compute HCI 节点：

    $ sudo reboot

12. 稍等片刻，直到节点启动。

13. 再次启用 Compute 节点：

    $ source ~/overcloudrc
    (overcloud) $ openstack compute service set [hostname] nova-compute --enable

14. 验证 Compute 节点是否已启用：

    (overcloud) $ openstack compute service list

15. 注销节点，重新引导下一个节点，并检查其状态。重复此流程，直到您已重新引导所有 Ceph 存储节点。

16. 完成后，登录 Ceph MON 或 Controller 节点，然后再次启用集群重新平衡：

    $ sudo ceph osd unset noout
    $ sudo ceph osd unset norebalance

17. 执行最后的状态检查，确认集群报告 HEALTH_OK：

    $ sudo ceph status

流程

1. 查找 undercloud 访问详情：

   $ source ~/stackrc

2. 检查失败的 Systemd 服务：

   (undercloud) $ sudo systemctl list-units --state=failed 'openstack*' 'neutron*' 'httpd' 'docker'

3. 检查 undercloud 可用空间：

   (undercloud) $ df -h

   使用 "Undercloud 要求" 作为基础来确定您是否有足够的可用空间。

4. 如果您在 undercloud 上安装了 NTP，请检查时钟是否已同步：

   (undercloud) $ sudo ntpstat

5. 检查 undercloud 网络服务：

   (undercloud) $ openstack network agent list

   所有代理都应 处于活动状态，其状态应为 UP。

6. 检查 undercloud 计算服务：

   (undercloud) $ openstack compute service list

   所有代理的状态都应 为启用状态，其状态应为 up

流程

1. 查找 undercloud 访问详情：

   $ source ~/stackrc

2. 检查裸机节点的状态：

   (undercloud) $ openstack baremetal node list

   所有节点均应具有有效的电源状态(on)和维护模式，应为 false。

3. 检查失败的 Systemd 服务：

   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo systemctl list-units --state=failed 'openstack*' 'neutron*' 'httpd' 'docker' 'ceph*'" ; done

4. 检查失败的容器化服务：

   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker ps -f 'exited=1' --all" ; done
   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker ps -f 'status=dead' -f 'status=restarting'" ; done

5. 检查与所有服务的 HAProxy 连接。获取 haproxy.stats 服务的 Control Plane VIP 地址和身份验证详情：

   (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE sudo 'grep "listen haproxy.stats" -A 6 /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg'

   在以下 cURL 请求中使用这些详情：

   (undercloud) $ curl -s -u admin:<PASSWORD> "http://<IP ADDRESS>:1993/;csv" | egrep -vi "(frontend|backend)" | cut -d, -f 1,2,18,37,57 | column -s, -t

   将 <PASSWORD & gt; 和 <IP ADDRESS > 详情替换为 haproxy.stats 服务的实际详情。生成的列表显示每个节点上的 OpenStack Platform 服务及其连接状态。

   注意

   如果节点运行 Redis 服务，则只有一个节点为该服务显示 ON 状态。这是因为 Redis 是一个主动 - 被动服务，它一次仅在一个节点上运行。

6. 检查 overcloud 数据库复制健康状况：

   (undercloud) $ for NODE in $(openstack server list --name controller -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker exec clustercheck clustercheck" ; done

7. 检查 RabbitMQ 集群健康状况：

   (undercloud) $ for NODE in $(openstack server list --name controller -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker exec $(ssh heat-admin@$NODE "sudo docker ps -f 'name=.*rabbitmq.*' -q") rabbitmqctl node_health_check" ; done

8. 检查 Pacemaker 资源健康状况：

   (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo pcs status"

   查找：

   • 所有集群节点 在线。
   • 任何集群节点上都没有 停止 资源。
   • 没有 失败的 pacemaker 操作。

9. 检查每个 overcloud 节点上的磁盘空间：

   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo df -h --output=source,fstype,avail -x overlay -x tmpfs -x devtmpfs" ; done

10. 检查 overcloud Ceph Storage 集群健康状态。以下命令在 Controller 节点上运行 ceph 工具来检查集群：

    (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph -s"

11. 检查 Ceph Storage OSD 是否有可用空间。以下命令在 Controller 节点上运行 ceph 工具来检查可用空间：

    (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph df"

12. 检查时钟是否在 overcloud 节点上同步

    (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo ntpstat" ; done

13. 查找 overcloud 访问详情：

    (undercloud) $ source ~/overcloudrc

14. 检查 overcloud 网络服务：

    (overcloud) $ openstack network agent list

    所有代理都应 处于活动状态，其状态应为 UP。

15. 检查 overcloud 计算服务：

    (overcloud) $ openstack compute service list

    所有代理的状态都应 为启用状态，其状态应为 up

16. 检查 overcloud 卷服务：

    (overcloud) $ openstack volume service list

    所有代理的状态都应 为启用状态，其状态应为 。

流程

1. 查找 undercloud 访问详情：

   $ 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-13.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-13.0.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 /httpboot

流程

1. Source stackrc 文件：

   $ source ~/stackrc

2. 运行部署命令并包括与 overcloud 相关的所有环境文件：

   $ openstack overcloud deploy \
       --templates \
       -e <ENVIRONMENT FILE>

   包含以下与您的环境相关的选项：

   • 使用 -e 自定义配置环境文件。
   • 如果适用，您的自定义角色(roles_data)文件使用 --roles-file。
3. 等待部署完成。