滚动升级¶

https://blueprints.launchpad.net/glance/+spec/rolling-upgrades

本规范分析了 Glance 项目断言各种滚动升级标签所需的内容，并指出了弥合差距所需的行动。

Ocata 的目标是断言 assert:supports-zero-downtime-upgrade 标签，并以断言 assert:supports-zero-impact-upgrade 标签作为延伸目标。鉴于断言这些标签取决于另一个功能的完成（参见规范提案 [GSP1]），备用目标是断言 assert:supports-rolling-upgrade 标签。无论如何，Glance 在本周期内将在升级方面取得进展。

问题描述¶

目前有四个升级标签

assert:supports-upgrade [GOV3]
assert:supports-rolling-upgrade [GOV1]
assert:supports-zero-downtime-upgrade [GOV4]
assert:supports-zero-impact-upgrade [GOV5]

supports-upgrade¶

对于 Glance，assert:supports-upgrade 标签 [GOV3] 已经断言 [GOV0]。

supports-rolling-upgrade¶

断言 assert:supports-rolling-upgrade 标签的要求列在 [GOV1] 中。它们是

该项目已经被标记为 type:service [GOV2]。
- Glance 状态：完成
该项目已经成功断言了 assert:supports-upgrade 标签 [GOV3]。
- Glance 状态：完成
该项目有一个明确的计划，允许操作员将新代码推出到服务的子集，无需同时重启所有服务上的新代码。
- Glance 状态：需要定义一个计划。
  
  关于所需计划的更多细节，如 [GOV1] 中所述
  
  该计划应明确指出支持的配置，这些配置预计可以工作，除非没有此类注意事项。这不需要在升级期间完全消除停机时间，而是将范围从“所有服务”缩小到“一次部分服务”。换句话说，“一起重启所有 API 服务”是一个合理的限制。
  
  Glance 服务包括 Glance API 服务器和可选的 Glance Registry API 服务器。Glance Registry API 服务器不打算暴露给最终用户或其他 OpenStack 服务；它明确设计仅供 Glance 内部使用。
  
  (请注意，在某些配置下，滚动升级预计可以工作是可以的。特别是，我们可能需要使用可选的 Glance registry 的部署在专用节点上运行它。）
  
  自 Liberty 版本以来，Glance 一直具有健康检查中间件，可用于向负载均衡器发出信号，表明 API 节点已下线 [GLA2]。这可用于将运行“旧”代码的 Glance 节点从轮换中移除，同时将运行“新”代码的节点引入轮换。
  
  请注意，虽然此提案允许同时运行 API 版本的混合部署，但它并不设想在同一节点上同时运行多个版本的 API。换句话说，我们不打算支持将“新”API 代码部署到节点，同时该节点上运行“旧”Glance 进程的场景。相反，我们希望操作员允许“旧”节点完全排空，并在该节点上部署“新”代码之前停止运行“旧”代码的所有进程。（如果 Glance 节点是虚拟机，则可以简单地删除完全排空的节点，并用包含“新”代码的新虚拟机替换它。）
对以中期升级方式安排的服务进行全面的堆栈集成测试，以验证混合版本服务是否能正确协同工作。
- Glance 状态：需要实现（但请注意，下一标签所需的测试将完全满足此要求）。

supports-zero-downtime-upgrade¶

assert:supports-zero-downtime-upgrade 标签表示一个项目支持最小的滚动升级能力，从而在升级期间不会发生 API 可用性的中断。

断言此标签的要求列在 [GOV4] 中。它们是

该项目已经被标记为 type:service [GOV2]。
- Glance 状态：完成
该项目已经成功断言了 assert:supports-upgrade 和 assert:supports-rolling-upgrade 标签。
- Glance 状态：assert:supports-rolling-upgrade 标签尚未断言。请参阅上一节了解所需内容。
服务必须完全消除控制平面的升级过程中的任何 API 停机时间。
- Glance 状态：关键问题是如何处理发布 N 所需的数据库更改，同时仍然运行发布 N-1 代码。这由另一个规范“滚动升级的数据库策略”[GSP1] 解决。
服务必须能够在升级过程中接收和处理请求，并具有正常的成功率。服务必须通过实施零停机时间门控作业来防止回归，其中同时运行服务的最新版本和旧版本。
- Glance 状态：需要实现。

supports-zero-impact-upgrade¶

assert:supports-zero-impact-upgrade 标签表示一个项目支持滚动升级能力和零停机时间升级（如上所述），从而不会发生任何可察觉的 API 性能下降。

断言此标签的要求列在 [GOV5] 中。它们是

该项目已经被标记为 type:service。
- Glance 状态：完成
该项目已经成功断言了 assert:supports-upgrade、assert:supports-rolling-upgrade 和 assert:supports-zero-downtime-upgrade 标签。
- Glance 状态：请参阅前几节。
服务必须完全消除升级过程中的任何可察觉的性能下降。操作员不应期望升级或迁移过程的任何部分对云的任何部分施加异常高的负载，或导致 API 请求的处理延迟，即使是间歇性的。
- Glance 状态：鉴于我们只谈论 Glance 服务（而不是 DBMS 和存储后端），当实现零停机时间升级时，应该实现这一点。
服务必须通过实施零影响门控作业来防止回归，其中同时运行服务的最新版本和旧版本并在负载下运行。API 响应时间的测量必须表明，与正常操作相比，升级过程中没有统计上显著的异常值。
- Glance 状态：需要实现。

提议的变更¶

有两个主要变化

流程文档

我们需要确定的是，Glance 项目具有“允许操作员将新代码推出到服务的子集，无需同时重启所有服务上的新代码”的明确计划。

产品工作组的“滚动更新和升级”用户故事的“差距”部分 [PWG1] 提供了一个有用的列表，其中列出了操作员在执行 OpenStack 云的滚动升级时将经历的阶段。我们建议清晰地为 Glance 记录相关阶段，以便操作员可以理解 Glance 滚动升级故事。

产品工作组确定的阶段是
1. 维护模式
2. 实时迁移
3. 升级编排 - 部署
4. 多版本互操作性
5. 在线模式迁移
6. 优雅关闭
7. 升级编排 - 移除
8. 升级编排 - 工具
9. 升级门控
10. 项目标记
对于 Glance，从发布 N-1 升级到发布 N，我们可以将其压缩为
1. 升级编排 - 部署
  - 将发布 N 的代码分阶段部署到新的 Glance 节点
2. 在线模式迁移 - 第 1 部分
  - 初始数据库模式迁移（如 [GSP1] 中所述的“扩展”阶段）
  - 后台数据迁移（如 [GSP1] 中所述）
3. 多版本互操作性
  - 启动发布 N 节点
  - 将发布 N-1 节点从轮换中移除，允许它们排空
4. 升级编排 - 移除
  - 一旦完成处理当前请求，就将每个发布 N-1 节点离线
5. 在线模式迁移 - 第 2 部分
  - 最终数据库模式迁移（如 [GSP1] 中所述的“收缩”阶段）
测试

对以中期升级方式安排的服务进行全面的堆栈集成测试，以验证混合版本服务是否能正确协同工作。
- 必须在项目认为其参考实现的项目配置上执行此测试。
- 测试的安排取决于项目（即，应代表对操作员有意义的滚动升级场景）和可用的测试资源。
- 至少必须在门控中进行全栈测试。

我们建议使用 Grenade [GRN1] 进行全栈集成测试。

备选方案¶

另一种选择是不支持 Glance 中的滚动升级。但是，这种选择会影响依赖 Glance 的其他服务（例如，Nova）。这些服务将在 Glance 升级期间遇到中断。因此，这似乎不是一个可行的选择。
本规范中的提案是使用 oslo healthcheck 中间件的“按文件禁用”功能将运行“旧”代码的 Glance 节点从轮换中移除并允许它们排空。Stuart McLaren 提出了一种替代方案，即利用 Glance 的零停机时间配置重新加载功能（自 Kilo 版本以来可用 [GLA1]）并创建一个“优雅停止”函数，该函数将接受信号以在子进程完成时关闭它们。（有关详细信息，请参见 [GSP2]。）

由于我们已经可以使用“按文件禁用”功能，因此不需要此替代方案来实现升级标签。但是，它将是一个用户友好的增强功能，我们可以在某个时候采用它。