滚动升级

注意

滚动升级功能是实验性的，目前不支持在生产系统中使用。

此声明对于 Glance 的 Queens 版本仍然有效。您可能会问，为什么迟迟不能支持？在断言该功能完全支持之前，Glance 团队需要在 OpenStack 持续集成网关中拥有执行滚动升级的自动化测试。近几个周期，Glance 项目团队缺乏足够的测试和开发资源来优先处理这项工作。

Glance 项目团队致力于 Glance 的稳定性。作为 OpenStack 的一部分，我们致力于The Four Opens。如果您认为能够在生产系统中执行滚动升级非常重要，请随时参与 Glance 社区，以帮助协调和推动这项工作。（我们在此温和地提醒您，“参与”包括提供测试和开发资源。）

本文档范围

此页面描述了一种从 Newton 到 Ocata 进行滚动升级的特定 Glance 服务配置方式。对于其他 Glance 服务配置，可能存在其他滚动升级方式，但这些方式超出了本文档的范围。对于滚动升级的实验性发布，我们仅描述以下简单情况。

先决条件

  • MySQL/MariaDB 5.5 或更高版本

  • 仅运行 Images API v2 的 Glance

  • Glance 不使用 Glance Registry

  • 多个 Glance 节点

  • 负载均衡器或其他类型的重定向设备被用于 Glance 节点的前面，以便可以使节点退出轮换，也就是说，Glance 节点继续运行 Glance 服务，但不再将请求路由到该节点

步骤

以下是使用零停机时间升级 Glance 的过程

  1. 备份 Glance 数据库。

  2. 选择一个任意的 Glance 节点或配置一个新的节点来安装新版本。如果选择现有的 Glance 节点，请优雅地停止 Glance 服务。在下文中，此节点将被称为 NEW NODE（新节点）。

注意

优雅地停止服务

在停止节点上的 Glance 进程之前，可以选择等待所有现有连接耗尽。可以通过将节点从轮换中移除来实现，也就是说，确保不再将请求路由到该节点。这样，当前正在处理的所有请求都有机会完成处理。但是，某些 Glance 请求，例如上传和下载镜像，可能需要很长时间。这会增加耗尽所有连接的等待时间，从而增加完全升级 Glance 的时间。另一方面，在连接耗尽之前停止 Glance 服务会给用户带来错误。虽然从技术上讲，这不能算是停机时间，因为 Images API 请求会持续由其他节点提供服务，但这仍然会对因飞行中请求在错误中终止而感到不愉快的用户造成不好的用户体验。因此，操作员在停止服务时必须谨慎。

  1. 使用新版本升级 NEW NODE 并相应地更新配置。不要在此时间启动 NEW NODE 上的 Glance 服务。

  2. 使用 NEW NODE，使用以下命令扩展数据库

    glance-manage db expand

.. warning::

 For MySQL, using the ``glance-manage db_expand`` command requires that
 you either grant your glance user ``SUPER`` privileges, or run
 ``set global log_bin_trust_function_creators=1;`` in mysql beforehand.

  3. 然后，也在 NEW NODE 上，使用以下命令执行数据迁移

    glance-manage db migrate

    在继续下一步之前，必须完成数据迁移。

  4. 启动 NEW NODE 上的 Glance 进程。现在它可以从负载均衡器接收流量了。

  5. 逐个从剩余节点中获取节点，对于每个节点

    1. 优雅地停止 Glance 进程，如上文步骤 2 中所述。在节点上的“旧” Glance 服务完全关闭之前，不要继续。

    2. 将节点升级到新版本（以及相应的配置）。

    3. 启动升级节点上的更新的 Glance 进程。

  6. 在所有节点都升级到运行新的 Glance 服务之后，并且没有节点运行任何旧的 Glance 服务之后，通过从任何一个升级节点运行以下命令来收缩数据库

    glance-manage db contract