升级 Keystone

从 Newton 版本开始，keystone 支持两种不同的跨版本升级方法。传统方法需要为整个升级过程安排大量的停机时间。更现代的方法可以实现零停机时间，但由于升级过程更长，因此更加复杂。

注意

这些步骤的细节完全取决于您的具体部署细节，例如您选择的应用程序服务器和数据库管理系统。请仅将其作为实施您自己的升级过程的指南。

开始之前

计划您的升级

  • 阅读并确保您理解下一个版本的 发行说明。

  • 解决日志中的所有未解决的弃用警告。有些弃用周期短至单个版本，因此如果您留下任何未解决的警告，可能会导致部署中断。重新阅读前一个版本（或两个版本！）的发行说明可能是一个好主意。

  • 准备新的配置文件，包括 keystone.conf、logging.conf、policy.yaml、keystone-paste.ini，以及 /etc/keystone/ 中的其他任何文件，通过自定义下一个版本中对应的文件来完成。

使用停机时间升级

这是基于 keystone-manage db_sync 构建的升级策略的高级描述。它假设您愿意在升级过程中进行控制平面的停机时间，并具有最小的风险。在 keystone 不可用时，其他 OpenStack 服务将无法验证请求，从而有效地阻止控制平面的正常运行。

  1. 停止所有 keystone 进程。否则，您将面临多个版本的 keystone 尝试同时写入数据库的风险，这可能会导致数据被不一致地写入和读取。

  2. 备份您的数据库。Keystone 不支持降级数据库，因此在升级失败时，从完整备份恢复是唯一的恢复选项。

  3. 将所有 keystone 节点升级到下一个版本。

  4. 使用最新版本中对应的文件更新您的配置文件 (/etc/keystone/)。

  5. 从任何单个节点运行 keystone-manage db_sync 以升级数据库模式并运行相应的数据库迁移。

  6. (Newton 新增) 运行 keystone-manage doctor 以诊断常见部署问题的症状并获取解决问题的说明。

  7. 启动所有 keystone 进程。

使用最小停机时间升级

如果您运行使用复制数据库（如 Galera 集群）的 keystone 多节点集群，则可以实现最小停机时间的升级。此方法还可以优化失败升级后的恢复时间。本节假定您熟悉基本情况（使用停机时间升级）。在这些步骤中，节点将被划分为 first 和 other 节点。

  1. 备份您的数据库。无法回滚 keystone 的升级，这是您最坏情况下的回退选项。

  2. 在所有节点上禁用 keystone，但 first 节点除外。可以通过各种机制来完成，具体取决于部署。如果您无法在负载均衡器中禁用服务或将服务置于维护模式，则可以停止 keystone 进程。

  3. 停止集群中的一个 other 节点的数据库服务。这将把旧数据集隔离在集群中的单个节点上。如果更新失败，可以使用此数据重建集群，而无需从备份恢复。

  4. 更新 first 节点上的配置文件。

  5. 升级 first 节点上的 keystone。keystone 现在已为您的云关闭。

  6. 在 first 节点上运行 keystone-manage db_sync。一旦完成，keystone 现在又在集群中的单个节点上工作了。

  7. keystone 现在已升级到单个节点。您的负载均衡器会将所有流量发送到此单个节点。这是您确保 keystone 启动并运行且未损坏的机会。如果 keystone 损坏，请参阅下面的 升级失败后回滚 部分。

  8. 验证 keystone 启动并运行后，开始升级 other 节点。这包括更新配置文件和升级代码。不需要再次运行 db_sync。

  9. 在您停止数据库服务的节点上，请确保重新启动它并确保它正确地重新加入集群。

使用此模型，停机窗口被最小化，因为集群完全离线的时间仅在加载较新版本的 keystone 和运行 db_sync 命令之间。通常，使用此方法可以测量停机时间，尤其是在使用自动化时，停机时间可以控制在几十秒内。

升级失败后回滚

如果升级失败，则只会受到单个节点的影响。这使得恢复更简单、更快速。如果问题直到整个集群升级后才被发现，则需要完全关闭并从备份恢复。这将比修复单个节点（该节点仍然可以使用旧的数据库副本）花费更多时间。强烈建议您在开发环境中练习此过程，然后再首次尝试使用它。

  1. 隔离错误的节点。关闭升级的“坏”节点上的 keystone 和数据库服务。

  2. 从持有旧数据的节点启动数据库集群。这可能需要在任何未持有旧数据的节点上先擦除数据。

  3. 在负载均衡器中启用旧节点上的 keystone，或者如果已停止进程，请重新启动它们。

  4. 验证 keystone 是否正常工作。

  5. 降级坏节点上的代码和配置文件。

此过程应该可以在几分钟内完成，并且如果需要，可以最大限度地减少云的停机时间。

无停机时间升级

Newton 版本中新增：

仅支持从 Newton 或更高版本升级的部署进行无停机时间升级。

如果将 Mitaka 部署升级到 Newton，将提供此处描述的命令，但 keystone-manage db_sync --expand 命令将产生停机时间（类似于运行 keystone-manage db_sync），因为它会在运行模式扩展之前运行遗留（产生停机时间）迁移。

Yoga 版本中更改：

迁移工具已从 SQLAlchemy-Migrate 更改为 Alembic。作为此更改的一部分，数据库升级的数据迁移阶段已被删除。

这是基于 keystone-manage db_sync 中附加选项构建的升级策略的高级描述。虽然它比上述升级过程复杂得多，但它假设您不希望在升级过程中进行控制平面的停机时间。使用此升级过程，最终用户仍然能够验证以接收令牌，其他 OpenStack 服务仍然能够正常验证请求。

  1. 备份您的数据库。keystone 不支持降级数据库，因此在升级失败时，从完整备份恢复是唯一的恢复选项。

  2. 停止第一个节点（或者，任何任意节点）上的 keystone 进程。此节点将用于编排数据库升级。

  3. 将您的第一个节点升级到下一个版本，但不要启动任何 keystone 进程。

  4. 更新第一个节点上的配置文件 (/etc/keystone/) 与最新的版本相对应。

  5. 在第一个节点上运行 keystone-manage doctor 以诊断常见部署问题的症状并获取解决问题的说明。

  6. 在第一个节点上运行 keystone-manage db_sync --expand 以扩展数据库模式，使其成为前一个版本和下一个版本都可以使用的超集，并创建触发器以促进实时迁移过程。

    警告

    对于 MySQL，使用 keystone-manage db_sync --expand 命令需要您授予 keystone 用户 SUPER 权限，或者预先在 mysql 中运行 set global log_bin_trust_function_creators=1;。

    此时，数据库中可能存在新列和表，但并非全部以使下一个版本能够正常运行的方式填充。

    随着前一个版本继续写入旧模式，数据库触发器会将数据实时迁移到新模式，以便下一个版本可以读取它。

    注意

    在 Yoga 之前，数据迁移被视为单独处理，需要使用 keystone-manage db_sync --migrate 命令在应用扩展迁移之后。现在不再需要这样做，keystone-manage db_sync --migrate 命令现在是一个空操作。

  7. 更新所有节点（第一个节点除外，您已经完成了此操作）上的配置文件 (/etc/keystone/) 与最新的版本相对应。

  8. 将所有 keystone 节点升级到下一个版本，并一次启动它们。在此步骤中，您将拥有混合版本同时运行，两者都写入数据库。

    随着下一个版本开始写入新模式，数据库触发器也会将数据迁移到旧模式，使两个数据模式保持同步。

  9. 运行 keystone-manage db_sync --contract 以删除旧模式和所有数据迁移触发器。

    完成此过程后，数据库将不再支持以前的版本。

使用 db_sync check

Pike 版本中新增：

Yoga 版本中更改：

以前，如果需要数据迁移，此命令将返回 3。数据迁移现在是扩展模式迁移的一部分，因此不再需要此步骤。

为了检查您的滚动升级的当前状态，您可以运行命令 keystone-manage db_sync --check。这将告知您剩余的任何待办事项以及您可以从当前版本进行的任何可能的升级。以下是可能的返回代码列表。

  • 返回代码 0 表示您当前已更新到最新的迁移脚本版本，并且所有 db_sync 命令均已完成。

  • 返回代码 1 通常意味着您的数据库存在严重问题，并且需要操作员干预。

  • 返回码 2 表示您的当前数据库版本有可用的升级，您的数据库当前未置于版本控制之下，或者数据库已经置于版本控制之下。您的第一步是运行 keystone-manage db_sync --expand。

  • 返回码 4 表示扩展和数据迁移阶段已经完成，下一步是运行 keystone-manage db_sync --contract。