升级共享文件系统服务¶

本文档概述了在从 OpenStack 的先前版本升级共享文件系统服务 (manila) 时，操作员应参考的步骤和注意事项。该服务旨在提供最少停机时间的升级体验。由于该服务不在数据平面上运行，因此升级期间不会影响任何已配置的资源（例如共享、共享快照、共享组、共享副本、共享服务器、安全服务和共享网络）的可访问性。客户端可以继续主动使用这些资源，同时正在升级服务控制平面。

规划升级¶

强烈建议您

将共享文件系统服务更新到您当前使用的发行版中的最新代码。
阅读共享文件系统服务发行说明，了解您打算升级到的发行版。特别注意弃用和升级说明。
考虑服务控制平面升级对云用户的潜在影响。升级过程会中断新共享文件系统和相关资源的配置。它还会阻止对现有共享文件系统和相关资源进行管理操作。对共享文件系统的的数据路径访问将保持不中断。
备份共享文件系统服务数据库，以便您可以回滚任何失败的升级到软件的先前版本。虽然 manila-manage 命令提供了一个数据库降级命令，但它不支持生产环境中使用。从失败的更新中恢复的唯一方法是从备份还原数据库。
识别您的共享文件系统服务后端存储系统/解决方案及其驱动程序。确保每个存储系统的版本都受目标发行版中相应驱动程序的支持。如果您使用的是来自第三方供应商的存储解决方案，请查阅他们的产品页面，以确定该解决方案是否受您正在升级的 OpenStack 发行版的支持。许多供应商会在本服务管理指南或其自己的网站上发布支持矩阵。如果您发现不兼容性，请停止，并确定是否需要先升级存储解决方案。
制定升级流程，并通过使用与您的生产环境类似的测试环境对其进行全面评估。

优雅的服务关闭¶

共享文件系统服务组件（调度器、共享管理器、数据管理器）是侦听 AMQP 队列上消息的 Python 进程。当操作员向进程发送 SIGTERM 信号时，它们将停止从队列接收新工作，完成任何未完成的工作，然后终止。

数据库迁移¶

共享文件系统服务仅支持冷升级，这意味着数据库升级期间服务平面预计会关闭。数据库升级包括模式更改以及数据迁移，以适应较新版本的模式。升级后，不支持降级数据库。数据库升级后，旧服务在访问数据库对象时可能会出现故障，因此请确保在升级数据库之前关闭所有 manila-* 服务。

清理已删除的数据库行¶

共享文件系统服务资源在数据库中被软删除，以便用户能够跟踪在生产环境中创建和销毁的实例。软删除还有助于云操作员遵守数据保留策略。不清除软删除条目会影响数据库性能，因为索引会变得非常大，并且数据迁移需要更长时间，因为有更多的数据需要迁移。建议您在升级之前清理服务数据库，以防止不必要的数据迁移。清理将永久删除软删除的数据库记录。

manila-manage db purge <age_in_days>

升级流程¶

确保您正在运行当前使用的 OpenStack 发行版的最新共享文件系统服务软件包。
运行 manila-status upgrade check 命令，以验证服务是否已准备好升级。
备份 manila 数据库
优雅地停止所有共享文件系统服务进程。我们建议按此顺序：manila-api、manila-scheduler、manila-share 和 manila-data。

注意

manila-data 服务可能正在处理耗时的数据库迁移。关闭它会中断任何正在进行中的迁移，并且这些迁移在服务恢复后不会自动启动。您可以使用 manila migration-get-progress 命令检查正在进行中的迁移的状态；对于已完成数据复制阶段的任何正在进行的迁移，请发出 manila migration-complete 命令。

升级所有服务软件包。如果从发行版软件包升级，则预计您的系统软件包管理器会自动处理此操作。
修复任何已弃用的配置选项。
修复任何已弃用的 api 策略。
从任何具有最新 manila 软件包的节点运行 manila-manage db sync。
启动所有共享文件系统服务进程。
通过运行 manila service-list 来检查 services。如果有任何孤立记录，请运行 manila-manage service cleanup 以删除它们。

升级测试¶

共享文件系统服务代码会持续测试从先前版本升级到当前版本的升级情况，使用 Grenade。Grenade 是一个 OpenStack 测试框架项目，用于验证发行版之间的升级场景。它使用 DevStack 初始执行基本的 OpenStack 安装，然后升级到目标版本。测试包括在先前版本上创建各种共享文件系统服务资源，并在升级后验证它们的存在和功能。

升级共享文件系统服务