.

本作品采用知识共享署名 3.0 未移植许可协议授权。

http://creativecommons.org/licenses/by/3.0/legalcode

Fast-forward upgrades

https://blueprints.launchpad.net/tripleo/+spec/fast-forward-upgrades

Fast-forward upgrades 是将环境从发布版本 N 升级到 N+X 的单步升级，其中 X 大于 1，对于 fast-forward 升级通常为 3。 本规范概述了 TripleO 如何在 Newton 和 Queens OpenStack 发布版本之间编排此类升级。

问题描述

OpenStack 升级通常被运维人员视为存在问题 [1] [2]。 虽然 TripleO 升级在最近几个周期中有了很大的改进，但许多运维人员仍然不愿在每个新版本发布时进行升级。

这通常会导致环境停留在首次部署时使用的发布版本。 最终，此发布版本将达到其支持生命周期 (EOL) 的结束，迫使运维人员升级到下一个受支持的发布版本。 此外，环境也可能存在一些限制，这些限制不允许在给定发布版本达到 EOL 之前执行升级，从而再次迫使运维人员等待发布版本达到 EOL。

虽然可以线性升级到具有上游发布节奏的受支持版本，但提供长期支持 (LTS) 版本的下游发行版可能无法在最初安装的发布版本达到 EOL 后提供相同的路径。 在这种情况下，运维人员也可能希望避免运行多个冗长的线性升级以达到所需的发布版本。

提议的变更

概述

TripleO 对 fast-forward 升级的支持将首先针对 Newton 和 Queens 发布版本之间的 N 到 N+3 升级

Newton    Ocata     Pike       Queens
+-----+   +-----+   +-----+    +-----+
|     |   | N+1 |   | N+2 |    |     |
|  N  | ---------------------> | N+3 |
|     |   |     |   |     |    |     |
+-----+   +-----+   +-----+    +-----+

这将给人留下跳过 Ocata 和 Pike 发布版本的印象，fast-forward 升级将环境从 Newton 移动到 Queens。 实际上，由于具有 supports-upgrade 标签的 OpenStack 项目仅需要支持 N 到 N+1 升级 [3]，因此升级仍然需要遍历每个发布版本，完成数据库迁移和其他有限的任务。

注意事项

在概述对 TripleO 的建议更改之前，值得强调 fast-forward 升级的以下注意事项

  • 在升级期间控制平面不可访问

  • 在升级期间，数据平面和活动工作负载必须保持可用。

先决条件

在开始 overcloud fast-forward 升级之前，必须完成以下先决任务

  • 在 N 上对 overcloud 进行滚动式小版本更新

这是一个正常的 TripleO overcloud 更新 [4]，应将环境中的每个节点升级到底层 OS 的最新受支持版本，并拉取最新的软件包。 运维人员可以根据需要重新启动节点。 重新启动可确保在继续升级之前重新加载最新的内核、openvswitch、QEMU 和任何其他依赖于重新启动的软件包。 这可以在 overcloud fast-forward 升级之前很久进行，并应消除升级期间需要额外重新启动的需求。

  • 将 undercloud 从 N 升级到 N+3

在进行任何 overcloud 升级之前，undercloud 也需要升级到 N+3。 同样，这可以在 overcloud 升级之前很久进行。 目前，这是一个 N 和 N+1 发布版本之间的传统线性升级，直到我们达到目标 N+3 Queens 发布版本为止。

  • 在升级开始之前缓存容器镜像

随着 Pike 中引入容器化的 TripleO overcloud，如果运维人员希望最终获得容器化的 Queens overcloud，则需要在 fast-forward 升级之前缓存所需的容器镜像。

高级流程

在高级别上，fast-forward 升级将执行以下操作，以将 overcloud 从 N 移动到 N+3

  • 停止所有角色上的所有 OpenStack 控制和计算服务

这将关闭 OpenStack 控制平面，同时保持数据库等基础设施服务运行，并允许任何工作负载继续运行而不受中断。 对于 HA 环境，这将禁用集群，确保 OpenStack 服务不会重新启动。

  • 将单个主机从 N 升级到 N+1，然后从 N+1 升级到 N+2

如前所述，OpenStack 项目当前仅支持 N 到 N+1 升级，因此 fast-forward 升级仍然需要遍历每个发布版本，以完成数据迁移和其他必需的任务。 为了尽快完成此操作，升级的这部分仅限于每个角色的单个主机。

  • 可选升级和部署单个 canary 计算主机到 N+3

由于 fast-forward 升级旨在确保工作负载在升级期间处于在线和可访问状态，因此我们可以选择性地将所有托管控制服务的角色 _和_ 单个 canary 计算主机升级到 N+3，以验证工作负载将在升级期间保持活动和可访问状态。

将在升级开始时选择一个 canary 计算节点，并在其上启动实例以验证它和数据平面在升级期间是否保持活动状态。 如果两者变得不可访问，升级将停止，并提供恢复程序，将所有主机回滚到 N+1，而不会对未受影响的计算主机上的活动工作负载造成进一步中断。

  • 升级和部署所有角色到 N+3

如果未采用上述可选的 canary 计算主机升级，则 fast-forward 升级的最后一步将是在 N+2 和 N+3 之间进行的传统 N 到 N+1 迁移，然后部署所有角色到 N+3。 此最后一步本质上是将 overcloud 重新部署到容器上 N+3 (Queens)，如从 Ocata 升级到 Pike 的 TripleO 环境中所见。

一个 python-tripleoclient 命令和相关的 Mistral 工作流将控制此最后一步是否应用于所有角色并行，给定角色中的所有主机或给定角色中的选定主机。 后者对于用户希望控制从 N+1 到 N+3 等计算主机移动的顺序非常有用。

实现

与更新 [5] 和升级 [6] 一样，与上述两个操作相关的特定 fast-forward 升级 Ansible 任务将被引入到每个服务的 tripleo-heat-template 服务模板中，作为 RoleConfig 输出。

与 upgrade_tasks 一样，每个任务都与过程中的特定步骤相关联。 对于 fast_forward_upgrade_tasks，这些步骤分为适用于所有主机的预备任务和仅适用于给定角色单个主机的引导任务。

预备步骤任务将映射到以下操作

  • 步骤 1：禁用整个集群

  • 步骤 2：停止 OpenStack 服务

  • 步骤 3：更新主机仓库

引导步骤任务将映射到以下操作

  • 步骤 4：备份 OpenStack 数据库

  • 步骤 5：预打包更新命令

  • 步骤 6：更新所需的软件包

  • 步骤 7：软件包更新后的命令

  • 步骤 8：OpenStack 服务数据库同步

  • 步骤 9：验证

与 update_tasks 一样，每个任务将使用简单的 when 条件来识别它所关联的步骤和发布版本，确保这些任务在升级的正确点执行。

例如，Ocata 上的步骤 2 fast_forward_upgrade_task 任务如下所示

fast_forward_upgrade_tasks:
  - name: Example Ocata step 2 task
    command: /bin/foo bar
    when:
      - step|int == 2
      - release == 'ocata'

然后，这些任务将通过 overcloud heat 模板的 RoleConfig 输出收集到特定于角色的 Ansible playbook 中，并将传入步骤和发布变量以确保任务按正确的顺序执行。

与 major upgrades [8] 一样，将引入一个新的 mistral 工作流和 tripleoclient 命令来生成和执行相关的 Ansible 任务。

openstack overcloud fast-forward-upgrade --templates [..path to latest THT..] \
                           [..original environment arguments..] \
                           [..new container environment agruments..]

运维人员还可以生成 [7]，下载并查看 playbook，以便在使用最新版本的 tripleo-heat-templates 之前使用以下命令

openstack overcloud deploy --templates [..path to latest THT..] \
                           [..original environment arguments..] \
                           [..new container environment agruments..] \
                           -e environments/fast-forward-upgrade.yaml \
                           -e environments/noop-deploy-steps.yaml
openstack overcloud config download

开发工作流

现有的 tripleo-upgrade Ansible 角色将用于自动化 fast-forward 升级过程，供开发人员和 CI 使用，包括初始 overcloud 小版本更新、undercloud 升级到 N+3 和 fast-forward 升级本身。

正在使用 fast_forward_upgrade_tasks 的开发人员还可以通过 tripleo-quickstart 使用 CI 也使用的发布配置部署最小的 overcloud 部署。

此外，在开发任务时，开发人员可以手动渲染和运行 fast_forward_upgrade_tasks 作为独立的 Ansible playbook。 允许他们使用 tripleo-ansible-inventory 针对特定节点运行任务子集。 将如何执行此操作的示例将在文档中记录，希望确保为任何希望为特定服务贡献任务的人提供流畅的开发体验。

替代方案

  • 继续强制运维人员通过每个主要版本线性升级

  • 并行云迁移。

安全影响

N/A

其他最终用户影响

  • 在升级期间控制平面将不可用

  • 数据平面和工作负载将保持在线。

性能影响

N/A

其他部署者影响

N/A

开发人员影响

  • 第三方服务模板提供程序需要在其 THT 服务配置中提供 fast_forward_upgrade_steps。

实现

负责人

主要负责人

  • lbezdick

  • marios

  • chem

其他贡献者

  • shardy

  • lyarwood

工作项

  • 在 RoleConfig 中引入 fast_forward_upgrades_playbook.yaml

  • 在每个服务模板中引入 fast_forward_upgrade_tasks

  • 引入 python-tripleoclient 命令和相关的 Mistral 工作流。

依赖项

  • TripleO - Ansible 升级工作流与 UI 集成 [9]

为 Pike 到 Queens 升级引入的新主要升级工作流显然会影响 fast-forward 升级对 Queens 的外观。 目前，fast-forward 升级的高级流程假定我们可以重用当前在 N+2 和 N+3 之间的 upgrade_tasks 来禁用并可能删除裸机服务。 随着主要升级工作流的引入，这可能会发生变化，因此可能需要将这些步骤编码到 fast_forward_upgrade_tasks 中。

测试

  • 需要创建第三方 CI 作业，以使用 RDO 测试 Newton 到 Queens，因为上游在发布 Pike 时结束了 stable/newton 的 EOL。

  • 这些作业应涵盖初始 undercloud 升级、overcloud 升级和可选的 canary 计算节点检查。

  • 还需要一个额外的第三方 CI 作业来验证 Queens undercloud 是否可以正确管理 Newton overcloud，从而分离在先决条件中讨论的 undercloud 升级和 fast-forward 升级。

  • 最后，应使用最小的 overcloud 角色来验证某些服务的升级。 例如，当通过更改 docker/services/nova-*.yaml 文件更改 Nova 的 fast_forward_upgrade_tasks 时，可以使用基本的 Keystone、Glance、Swift、Cinder、Neutron 和 Nova overcloud 部署来快速验证与 fast-forward 升级相关的更改。

文档影响

  • 这将需要编写大量的开发人员和用户文档，很可能是在文档的新部分中，专门详细介绍 fast-forward 升级流程。

参考资料