[ English | 日本語 | Deutsch | Indonesia ]

升级

除了对象存储之外，从一个版本的 OpenStack 升级到另一个版本可能需要大量的努力。本章提供了一些关于 OpenStack 环境升级操作方面的指导。

升级前注意事项

升级计划

  • 彻底查阅 发行说明，了解新的、更新的和已弃用的功能。找出版本之间的不兼容性。

  • 考虑升级对用户的影响。升级过程会中断您环境的管理，包括仪表板。如果您为升级做好充分准备，现有的实例、网络和存储应该继续运行。但是，实例可能会遇到间歇性的网络中断。

  • 考虑升级您环境的方法。您可以对正在运行的实例执行升级，但这是一种危险的方法。您可以考虑使用实时迁移将实例临时迁移到其他计算节点，同时执行升级。但是，您必须确保在整个过程中数据库的一致性；否则您的环境可能会变得不稳定。另外，不要忘记提前通知您的用户，包括给他们足够的时间来执行自己的备份。

  • 考虑采用服务配置文件中的结构和选项，并将它们与现有的配置文件合并。 OpenStack 配置参考 包含大多数服务的新增、更新和已弃用的选项。

  • 与所有主要的系统升级一样，您的升级可能由于一个或多个原因而失败。 您可以通过具备将环境回滚到先前版本的能力（包括数据库、配置文件和软件包）来为这种情况做好准备。 我们在 回滚失败的升级 中提供了一个回滚环境的示例过程。

  • 制定升级流程，并通过使用与您的生产环境类似的测试环境对其进行彻底评估。

升级前测试环境

最重要的一步是升级前测试。 如果您在发布新版本后立即升级，未发现的错误可能会阻碍您的进度。 一些部署者更喜欢等到发布第一个点版本后才进行升级。 但是，如果您有一个重要的部署，您可能会跟踪该版本的开发和测试，以确保针对您的用例的错误得到修复。

即使您的架构与本指南中描述的架构几乎相同，每个 OpenStack 云也各不相同。 因此，您仍然必须在您的环境中测试版本之间的升级，使用您环境的近似克隆。

但是，这并不是说它需要与生产环境相同的大小或使用相同的硬件。 重要的是要考虑您正在升级的云的硬件和规模。 以下提示可以帮助您最大限度地降低成本

使用您自己的云

开始测试 OpenStack 下一个版本的最简单方法是在您自己的云中设置一个新环境。 这可能看起来很奇怪，尤其是在运行计算节点时使用的双重虚拟化。 但这是一种快速测试配置的可靠方法。

使用公共云

考虑使用公共云来测试云控制器的配置的可扩展性限制。 大多数公共云按小时计费，这意味着即使进行具有许多节点的测试也可以成本低廉。

在同一系统上创建另一个存储端点

如果您使用外部存储插件或与您的云共享的文件系统，您可以通过创建第二个共享或端点来测试它是否有效。 这允许您在将新版本委托给您的存储之前对其进行测试。

监控网络

即使在较小规模的测试中，也要查找过多的网络数据包，以确定组件间通信中是否发生了一些可怕的事情。

要设置测试环境，您可以使用以下几种方法

  • 使用 安装教程和指南 为您的平台执行完整的手动安装。 检查最终的配置文件和已安装的软件包。

  • 创建自动化配置基础设施的克隆，并更改软件包仓库 URL。

    更改配置，直到它工作为止。

两种方法都是有效的。 使用与您的经验相匹配的方法。

升级前测试系统非常适合让配置工作。 但是，重要的是要注意，系统的历史使用情况和用户交互的差异会影响升级的成功与否。

如果可能，我们强烈建议您转储生产数据库表，并使用此数据在您的开发环境中测试升级。 几个 MySQL 错误是在数据库迁移期间发现的，因为新鲜安装和从一个版本迁移到另一个版本的表之间存在细微的表差异。 这将对大型真实数据集产生影响，您不希望在生产中断期间遇到这种情况。

人为规模测试只能达到一定程度。 在您的云升级后，您必须密切关注云的性能方面。

升级级别

升级级别是一项添加到 OpenStack Compute 的功能，自 Grizzly 版本以来，用于为 Compute 服务之间的 RPC（消息队列）通信提供版本锁定。

此功能是实时升级难题的重要组成部分，在概念上类似于现有的 API 版本控制，它允许不同版本的 OpenStack 服务进行通信而不会出现问题。

没有升级级别，X+1 版本的 Compute 服务可以接收和理解 X 版本的 RPC 消息，但它只能发送 X+1 版本的 RPC 消息。 例如，如果 nova-conductor 进程已升级到 X+1 版本，则该 conductor 服务将能够理解来自 X 版本 nova-compute 进程的消息，但这些 compute 服务将无法理解 conductor 服务发送的消息。

在升级期间，操作员可以向 nova.conf 添加配置选项，这些选项可以锁定 RPC 消息的版本，并允许在不因版本不匹配而中断的情况下实时升级服务。 配置选项允许指定 RPC 版本号（如果需要），但支持发布名称别名。 例如

[upgrade_levels]
compute=X
conductor=X
scheduler=X

会将 RPC 版本锁定到指定服务中用于 X 的 RPC 版本。 随着特定服务的每个实例升级到较新的版本，可以从 nova.conf 中删除相应的行。

使用此功能，理想情况下，应该将 RPC 版本锁定到 nova-compute 节点上正在升级的 OpenStack 版本，以确保例如 X+1 版本的 nova-compute 进程将继续与 X 版本的 nova-conductor 进程一起工作，直到升级完成。 一旦 nova-compute 进程的升级完成，操作员就可以继续升级 nova-conductor，并在 nova.conf 中删除 nova-compute 的版本锁定。

升级流程

本节描述了基于 安装教程和指南 中基本两节点架构的基本 OpenStack 部署的升级流程。 所有节点必须运行带有最新内核和当前发布软件包的受支持的 Linux 发行版。

特定服务升级说明

请参阅以下升级说明，以获取有关升级特定 OpenStack 服务的相关信息

先决条件

  • 在开始升级过程之前，对环境进行一些清理，以确保一致的状态。 例如，未完全从系统中清除的实例可能会导致不确定的行为。

  • 对于使用 OpenStack 网络服务 (neutron) 的环境，请验证数据库的发布版本。 例如

    # su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf \
  --config-file /etc/neutron/plugins/ml2/ml2_conf.ini current" neutron

执行备份

  1. 保存所有节点上的配置文件。 例如

    # for i in keystone glance nova neutron openstack-dashboard cinder heat ceilometer; \
  do mkdir $i-RELEASE_NAME; \
  done
# for i in keystone glance nova neutron openstack-dashboard cinder heat ceilometer; \
  do cp -r /etc/$i/* $i-RELEASE_NAME/; \
  done

    注意

    您可以在每个节点上修改此示例脚本以处理不同的服务。

  2. 备份您的生产数据中的完整数据库。 自 Kilo 版本发布以来，不支持数据库降级，并且从备份恢复是唯一可用的方法来检索以前的数据库版本。

    # mysqldump -u root -p --opt --add-drop-database --all-databases > RELEASE_NAME-db-backup.sql

    注意

    考虑更新您的 SQL 服务器配置，如 安装教程和指南 中所述。

管理仓库

在所有节点上

  1. 删除先前发布软件包的仓库。

  2. 添加新发布软件包的仓库。

  3. 更新仓库数据库。

在每个节点上升级软件包

根据您的具体配置，升级所有软件包可能会重启或破坏您的 OpenStack 环境的补充服务。 例如，如果您使用 TGT iSCSI 框架用于块存储卷，并且升级包括用于它的新软件包，则软件包管理器可能会重启 TGT iSCSI 服务并影响与卷的连接。

如果软件包管理器提示您更新配置文件，请拒绝更改。 软件包管理器将后缀附加到较新版本的配置文件。 考虑审查和采用这些文件中的内容。

注意

您可能需要显式安装 ipset 软件包，如果您的发行版未将其作为依赖项安装。

更新服务

要在每个节点上更新服务，通常需要修改一个或多个配置文件，停止服务，同步数据库模式，然后启动服务。 某些服务需要不同的步骤。 我们建议在继续下一个服务之前验证每个服务的运行情况。

您应该升级服务的顺序以及与通用升级流程的任何更改如下所述

控制器节点

  1. 身份服务 - 在同步数据库之前清除任何过期的令牌。

  2. 镜像服务

  3. 计算服务，包括网络组件。

  4. 网络服务

  5. 块存储服务

  6. 仪表板 - 在典型的环境中，更新仪表板只需要重启 Apache HTTP 服务。

  7. 编排服务

  8. 遥测服务 - 在典型的环境中，更新遥测服务只需要重启服务。

  9. 计算服务 - 编辑配置文件并重启服务。

  10. 网络服务 - 编辑配置文件并重启服务。

存储节点

  • 块存储服务 - 更新块存储服务只需要重启服务。

计算节点

  • 网络服务 - 编辑配置文件并重启服务。

最终步骤

在所有发行版上，您必须执行一些最终任务才能完成升级过程。

  1. 通过修改计算节点上的 /etc/nova/nova.conf 文件，将 DHCP 超时时间减少回您环境的原始值。

  2. 更新所有 .ini 文件，以匹配您环境中的 OpenStack 版本所需的密码和管道。

  3. 在迁移后，用户在 openstack image list 和 glance image-list 中看到不同的结果。 为了确保用户在列表命令中看到相同的图像，请编辑 /etc/glance/policy.json 文件和 /etc/nova/policy.json 文件，以包含 "context_is_admin": "role:admin"，这将限制对项目中的私有图像的访问。

  4. 验证您环境的正常运行。 然后，通知您的用户他们的云正在正常运行。

回滚失败的升级

本节提供有关回滚到 OpenStack 以前版本的指导。 所有发行版都遵循类似的流程。

警告

回滚您的环境应该是最后的手段，因为您可能会丢失自备份以来添加的任何数据。

一个常见的情况是在准备升级时关闭生产管理服务，完成了部分升级过程，并发现测试期间未遇到的一个或多个问题。因此，您必须将环境回滚到原始的“已知良好”状态。您还确保在尝试升级过程后没有进行任何状态更改；没有新的实例、网络、存储卷等。任何这些新资源在从备份还原数据库后都将处于冻结状态。

在此范围内，您必须完成以下步骤才能成功回滚您的环境

  1. 回滚配置文件。

  2. 从备份还原数据库。

  3. 回滚软件包。

您应该验证您是否拥有还原所需的备份。回滚升级是一个棘手的过程，因为发行版通常会投入更多精力来测试升级而不是降级。失败的降级比失败的升级需要花费更多的精力来排查和解决。只有您可以权衡尝试推进失败的升级与回滚的风险。通常，应考虑回滚作为最后的选择。

以下针对 Ubuntu 描述的步骤至少在一个生产环境中有效，但可能不适用于所有环境。

要执行回滚

  1. 停止所有 OpenStack 服务。

  2. 将升级过程中创建的配置备份目录的内容复制回 /etc/<service> 目录。

  3. 从升级过程中使用 mysqldump 命令创建的 RELEASE_NAME-db-backup.sql 备份文件中还原数据库

    # mysql -u root -p < RELEASE_NAME-db-backup.sql

  4. 降级 OpenStack 软件包。

    警告

    降级软件包是迄今为止最复杂的一步；它高度依赖于发行版和系统的整体管理。

    1. 确定您的系统上安装了哪些 OpenStack 软件包。使用 dpkg --get-selections 命令。过滤 OpenStack 软件包，再次过滤以省略明确标记为 deinstall 状态的软件包，并将最终输出保存到文件中。例如，以下命令涵盖一个带有 keystone、glance、nova、neutron 和 cinder 的控制器节点

      # dpkg --get-selections | grep -e keystone -e glance -e nova -e neutron \
-e cinder | grep -v deinstall | tee openstack-selections
cinder-api                                      install
cinder-common                                   install
cinder-scheduler                                install
cinder-volume                                   install
glance                                          install
glance-api                                      install
glance-common                                   install
glance-registry                                 install
neutron-common                                  install
neutron-dhcp-agent                              install
neutron-l3-agent                                install
neutron-lbaas-agent                             install
neutron-metadata-agent                          install
neutron-plugin-openvswitch                      install
neutron-plugin-openvswitch-agent                install
neutron-server                                  install
nova-api                                        install
nova-common                                     install
nova-conductor                                  install
nova-consoleauth                                install
nova-novncproxy                                 install
nova-objectstore                                install
nova-scheduler                                  install
python-cinder                                   install
python-cinderclient                             install
python-glance                                   install
python-glanceclient                             install
python-keystone                                 install
python-keystoneclient                           install
python-neutron                                  install
python-neutronclient                            install
python-nova                                     install
python-novaclient                               install

      注意

      根据服务器类型，您的软件包列表的内容和顺序可能与此示例不同。

    2. 您可以使用 apt-cache policy 命令确定可用于还原的软件包版本。例如

      # apt-cache policy nova-common

nova-common:
Installed: 2:14.0.1-0ubuntu1~cloud0
Candidate: 2:14.0.1-0ubuntu1~cloud0
Version table:
*** 2:14.0.1-0ubuntu1~cloud0 500
      500 http://ubuntu-cloud.archive.canonical.com/ubuntu xenial-updates/2025.2/main amd64 Packages
      100 /var/lib/dpkg/status
    2:13.1.2-0ubuntu2 500
      500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
    2:13.0.0-0ubuntu2 500
      500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages

      注意

      如果您删除了发布仓库，则必须先重新安装它们并运行 apt-get update 命令。

      命令输出列出了当前安装的软件包版本、最新的候选版本以及所有版本以及包含每个版本的仓库。查找适当的发布版本— 2:14.0.1-0ubuntu1~cloud0 在这种情况下。手动筛选此软件包列表的过程相当繁琐且容易出错。您应该考虑使用脚本来帮助完成此过程。例如

      # for i in `cut -f 1 openstack-selections | sed 's/neutron/;'`;
  do echo -n $i ;apt-cache policy $i | grep -B 1 RELEASE_NAME |
  grep -v Packages | awk '{print "="$1}';done | tr '\n' ' ' |
  tee openstack-RELEASE_NAME-versions
cinder-api=2:9.0.0-0ubuntu1~cloud0
cinder-common=2:9.0.0-0ubuntu1~cloud0
cinder-scheduler=2:9.0.0-0ubuntu1~cloud0
cinder-volume=2:9.0.0-0ubuntu1~cloud0
glance=2:13.0.0-0ubuntu1~cloud0
glance-api=2:13.0.0-0ubuntu1~cloud0 500
glance-common=2:13.0.0-0ubuntu1~cloud0 500
glance-registry=2:13.0.0-0ubuntu1~cloud0 500
neutron-common=2:9.0.0-0ubuntu1~cloud0
neutron-dhcp-agent=2:9.0.0-0ubuntu1~cloud0
neutron-l3-agent=2:9.0.0-0ubuntu1~cloud0
neutron-lbaas-agent=2:9.0.0-0ubuntu1~cloud0
neutron-metadata-agent=2:9.0.0-0ubuntu1~cloud0
neutron-server=2:9.0.0-0ubuntu1~cloud0
nova-api=2:14.0.1-0ubuntu1~cloud0
nova-common=2:14.0.1-0ubuntu1~cloud0
nova-conductor=2:14.0.1-0ubuntu1~cloud0
nova-consoleauth=2:14.0.1-0ubuntu1~cloud0
nova-novncproxy=2:14.0.1-0ubuntu1~cloud0
nova-objectstore=2:14.0.1-0ubuntu1~cloud0
nova-scheduler=2:14.0.1-0ubuntu1~cloud0
python-cinder=2:9.0.0-0ubuntu1~cloud0
python-cinderclient=1:1.9.0-0ubuntu1~cloud0
python-glance=2:13.0.0-0ubuntu1~cloud0
python-glanceclient=1:2.5.0-0ubuntu1~cloud0
python-neutron=2:9.0.0-0ubuntu1~cloud0
python-neutronclient=1:6.0.0-0ubuntu1~cloud0
python-nova=2:14.0.1-0ubuntu1~cloud0
python-novaclient=2:6.0.0-0ubuntu1~cloud0
python-openstackclient=3.2.0-0ubuntu2~cloud0

    3. 使用 apt-get install 命令通过指定 <package-name>=<version> 来安装每个软件包的特定版本。上一步中的脚本方便地为您创建了一个 package=version 对列表

      # apt-get install `cat openstack-RELEASE_NAME-versions`

      此步骤完成了回滚过程。您应该删除升级发布仓库并运行 apt-get update 以防止意外升级，直到您解决导致回滚环境的任何问题为止。