滚动更新和升级

跨项目规范 - 正在评审

用户故事追踪器 - 滚动升级追踪器

问题描述

问题定义

OpenStack 操作员通常因为担心升级的侵入性而避免升级或更新 OpenStack。这阻止了操作员充分利用他们的 OpenStack 云，特别是他们访问不断改进的平台以及与不断扩展的 OpenStack 生态系统互操作的能力。

以下用例涵盖了基于 OpenStack 上游代码库的部署。虽然一些功能可能被发行版提供商利用来改进他们对非破坏性更新和升级的支持，但它们在本文件中并未具体涵盖。

机会/理由

这就是为什么企业无法充分利用其 OpenStack 云的一个主要原因。升级和更新从来都不容易，并且在许多环境中需要控制平面和数据平面的长时间停机。 这是 OpenStack 平台固有的非云特性。修复升级和更新将消除许多限制 OpenStack 采用的担忧。

需求规范

用例

本节使用了 OpenStack UX 人物。

• 作为 Quinn 应用开发者，我希望体验一个稳定、定期更新和升级的 OpenStack 平台，以便利用新功能、错误修复和安全增强，从而使我的云开发体验始终保持世界一流。
• 作为 Rey 云操作员，我希望为我的用户提供一个可靠且可用的 OpenStack 平台，以便他们不会遇到任何数据平面停机或长时间的控制平面停机
• 作为 Rey，我希望对我有能力执行 OpenStack 云更新充满信心，以便我可以每月执行一次。
• 作为 Rey，我希望能够在发起云升级或更新时回滚到最近的版本，以防出现问题，这样即使出现错误，我仍然可以避免数据平面或控制平面停机。
• 作为 Rey，我希望能够定义数据和控制平面主机的滚动重启特性，以便我的用户不受滚动升级或更新的影响。
• 作为 Rey，我希望能够在升级之前运行预升级测试，以确保我的云能够升级或更新到指定版本，以便我对升级或更新的成功充满信心。
• 作为 Rey，我希望有一种方法来验证升级是否成功完成，并获得关于任何问题的明确指示以及如何使用具体操作（例如修复、修正和重试、回滚）来解决这些问题。
• 作为 Rey，我希望提前了解升级计划，包括时间安排、依赖关系以及哪些服务会受到影响。

用例示例

1. 成功的升级

   1. 云操作员安排 OpenStack 升级到最新版本
   2. 云操作员可以确信，通过查看适当的服务版本说明，API 将按预期执行
   3. 云操作员按照简单的文档执行升级
   4. 云操作员通知用户升级成功以及新功能和增强功能的可用性
   5. 云操作员安排下一次更新在 1 个月后进行（或根据需要），以利用回溯移植、错误修复和安全更新

2. 不成功的更新/升级

   1. 云操作员安排 OpenStack 升级或更新到最新的 6 个月版本
   2. 在执行升级或更新时，云操作员注意到一个意外错误
   3. 云操作员返回到先前已知、无错误的狀態

3. 立即更新

   1. 云操作员被告知在 OpenStack 服务中发现了一个安全漏洞，并且当前版本有一个补丁可用
   2. 云操作员安排更新以修复该漏洞
   3. 成功完成更新后，云操作员的云不再易受攻击

4. 数据平面的滚动升级

   1. 云操作员安排 OpenStack 升级或更新以解决需要重启整个数据平面主机群的安全漏洞
   2. 云操作员发起升级或更新，并以自动化的、可配置的方式执行数据平面主机的重启
   3. 云用户不受重启的影响

相关用户故事

无。

要求

无。

差距

今天的升级需要在数据平面、网络连接和通常的控制平面中进行停机。

目前阻止滚动升级的差距涵盖了许多方面，可以通过执行滚动升级的过程来最好地说明这些方面。

1. 维护模式 - 防止在主机上安排其他实例
2. 实时迁移 - 改进从主机实时迁移现有资源
3. 升级编排 - 部署 - 编排升级或新版本服务的部署
4. 多版本互操作性 - 启用相同 OpenStack 服务不同版本之间的通信
5. 在线模式迁移 - 启用在服务停机时间的情况下进行数据库模式迁移
6. 优雅关闭 - 确保在处理过程中的请求后才能关闭服务
7. 升级编排 - 移除 - 编排潜在的旧版本服务移除和清理
8. 升级编排 - 工具 - 易于使用的工具，用于在控制平面和数据平面主机上执行升级
9. 升级门控 - 基于成功的滚动升级对项目进行门控
10. 项目标记 - 通知操作员哪些项目可以成功执行滚动升级

对于操作员来说，成功的云升级或更新涉及云中部署的所有 OpenStack 服务。因此，这些方面中的许多方面都需要对操作员可能部署的所有项目进行增强。我们首先回顾这些项目

多版本互操作性

在滚动升级期间，重要的是 RPC 通信能够处理并发运行的多个服务版本。实现此功能的一种常见模式是版本对象。Oslo 中存在版本对象库。每个单独的项目必须考虑版本对象是否是多版本互操作性工作的正确工具。以下是常用 OpenStack 项目的版本对象状态

• Nova - 已实现
• Neutron - 正在进行中
• Glance - 不适用
• Cinder - 正在进行中，不需要
• Swift - 不适用
• Keystone - 不适用
• Horizon - 不适用
• Heat - 已实现
• Ceilometer - 提出了替代方案

在线模式迁移

与多版本互操作性一样，在线模式迁移也以多种方式解决。一些项目建议在整个开发周期内进行标准的模式扩展和收缩，而不是在升级时进行在线操作。以下是常用 OpenStack 项目的在线模式迁移状态

• Nova - 策略已实现
• Neutron - 已实现
• Glance - 未知
• Cinder - 策略已实现
• Swift - 未知
• Keystone - 未知
• Horizon - 未知
• Heat - 正在进行中
• Ceilometer - 未知

维护模式

维护模式仅在整个主机用于创建虚拟资源的服务中才有用。以下是适用 OpenStack 项目的维护模式状态

• Nova - 已实现
• Cinder - 已实现
• Neutron - 已实现
• Ceilometer - 未知
• Swift - 已实现

实时迁移

与维护模式一样，实时迁移仅适用于主机提供资源的服务。以下是适用 OpenStack 项目的实时迁移状态

• Nova - 已实现（需要一些改进）
• Cinder - 可用（取决于后端）

优雅关闭

优雅关闭适用于所有常用的 OpenStack 服务，并且应该导致在处理完现有请求后才能关闭服务。以下是常用 OpenStack 项目的优雅关闭状态

• Nova - 已实现
• Neutron - 已实现
• Glance - 未知
• Cinder - 已实现
• Swift - 未知
• Keystone - 未知
• Horizon - 未知
• Heat - 未知
• Ceilometer - 未知

其他方面需要在特定的编排项目或 OpenStack 基础设施中进行工作。

升级编排

在 OpenStack 中，许多云部署机制都致力于提供升级编排。根据参考架构，每种部署机制将确定执行滚动升级的适当顺序和方法。每种部署方法对滚动升级的处理状态如下

• Triple O - 未知
• Fuel - 基于任务的部署
• OpenStack Puppet - 未知
• OpenStack Ansible - 升级脚本
• OpenStack Chef - 未知
• Kolla - 正在进行中

升级门控

OpenStack 基础设施尚未开始将升级测试部署到通用门控中。有一个可用的多节点升级测试框架，称为 Grenade。一些项目已经开始在他们的门控中包含升级测试。

• Nova - 由多节点 Grenade 测试门控
• Neutron - 由多节点 grenade 门控
• Glance - 无
• Cinder - 无
• Swift - 未知
• Keystone - 无
• Heat - 无
• Ceilometer - 无

项目标记

存在项目元数据标签，以表明给定的 OpenStack 项目能够执行滚动升级。* 状态 - 已实现

外部参考

• Dan Smith 的升级博客系列
• 滚动升级项目元数据标签
• Grenade - OpenStack 升级测试工具

拒绝的用户故事/使用场景

无。

术语表

• 控制平面 运行 OpenStack 服务的主机或基础设施（例如 nova-api）
• 数据平面 云用户在 OpenStack 云上创建的实例基础设施。（示例：虚拟机、存储卷、网络、数据库等）
• 升级 安装完全不同的 OpenStack 主要软件版本，每年提供两次新版本。升级可能包括破坏合同的 API 更改。
• 更新 安装新的 OpenStack 软件，通常来自稳定分支，以获得访问错误修复、安全补丁等。这些可以根据需要进行得频繁。
• 回滚 执行升级或更新，以及由于错误、不一致或准备不足而随后返回到升级或更新之前的版本。理解在升级或更新后执行的任何操作或数据可能会丢失，因为回滚的结果。