跳到主要内容
版本：3.9.x

双集群升级

你可以使用双集群升级策略来升级 API7 企业版集群。

双集群升级策略会在你现有的生产集群（集群 X）旁边部署一个全新的、平行的集群（集群 Y）。每个集群都是完全独立的，具有各自的控制平面、数据平面和数据库。在升级过程中，禁止通过 API 或继续操作 CP 来修改你的配置。

使用外部负载均衡器将流量逐渐从旧集群转移到新集群。这种升级方法可实现零停机时间并允许即时回滚，如下图所示：

准备工作​

  1. 阅读升级指南并确保你了解整个升级过程是如何执行的。
  2. 确保你有足够的资源来并行运行两个完整的生产集群。
  3. 从集群 X（数据库 X）备份你当前的数据。
  4. 查看升级注意事项。
  5. 检查当前版本与目标升级版本之间的所有更改。
  6. 为流量切换准备外部负载均衡器配置。
  7. 规划流量切换时间表和监控策略。

双集群升级步骤​

信息

以下实施步骤仅供参考。实际执行可能会根据你的部署环境而有所不同。

第 1 步：冻结配置更改​

宣布配置更改的维护窗口。在整个升级过程中，不要对旧集群（集群 X）上的 API 配置进行任何更改。这对于防止两个集群之间出现不一致至关重要。

  • 停止通过集群 X 上的 API 或控制台（Dashboard）进行的所有配置修改。
  • 记录所有配置的当前状态以供参考。

第 2 步：部署新集群（集群 Y）​

  1. 提供新数据库（数据库 Y）：

    • 为集群 Y 设置一个新的数据库实例。
    • 确保它具有与数据库 X 相似的足够容量和性能特征。

  2. 备份和恢复数据库：

    • 使用 pg_dump 或你首选的备份方法对数据库 X 执行完整备份。
    • 使用 pg_restore 或你首选的恢复方法将备份恢复到数据库 Y。

  3. 部署新版本的 API7 企业版：

    • 根据你的 API7 企业版安装方法（Docker、Kubernetes），部署目标版本的新 API7 企业版集群。
    • 配置控制平面（CP B）以连接到数据库 Y。
    • 部署数据平面（DP B）节点并配置它们连接到 CP B。
    • 更新配置文件中的镜像版本：
      • api7-ee-dashboard (用于 CP)
      • api7-ee-dp-manager (用于 CP)
      • api7-ee-gateway (用于 DP)

  4. 启动并验证集群 Y：

    • 启动集群 Y 并确保所有组件正常运行。
    • 访问 CP B 的控制台（Dashboard）以验证其是否可用。
    • 隔离进行全面的功能和性能测试，以确保集群 Y 正常工作。
    • 验证数据库 X 的所有配置是否正确加载到集群 Y 中。

第 3 步：开始流量切换​

  1. 配置负载均衡器：

    • 配置外部负载均衡器，将一小部分生产流量（例如 1-10%）发送到新的数据平面（DP B）。
    • 将大部分流量（90-99%）保留在旧数据平面（DP A）上。

  2. 监控集群 Y：

    • 密切监控集群 Y 的性能、错误率和日志。
    • 将其行为与集群 X 进行比较。

第 4 步：逐渐增加流量​

如果集群 Y 保持稳定且性能符合预期，请逐步增加其接收的流量百分比：

  1. 增加至 25%：将 25% 的流量切换至 DP B，监控一段时间（例如 1-2 小时）。
  2. 增加至 50%：将 50% 的流量切换至 DP B，监控一段时间（例如 1-2 小时）。
  3. 增加至 75%：将 75% 的流量切换至 DP B，监控一段时间（例如 2-4 小时）。

在每个阶段：

  • 在充足的观察期内继续监控关键指标。
  • 比较集群 X 和集群 Y 之间的错误率和日志。
  • 注意任何异常或问题。

第 5 步：完成流量迁移​

  1. 切换 100% 流量：

    • 一旦你对集群 Y 的稳定性和性能充满信心，请将 100% 的流量导向它。
    • 现在所有的 API 请求都应该由 DP B 处理。

  2. 保持集群 X 作为热备：

    • 让集群 X 运行一段指定时间（例如 24-48 小时）作为热备。
    • 这样如果出现任何问题，就可以立即回滚。

  3. 延长观察：

    • 在此期间密切监控集群 Y。
    • 验证所有功能是否按预期工作。

第 6 步：回滚（如果需要）​

如果在升级过程中遇到任何严重问题：

  1. 立即回滚：

    • 通过负载均衡器将所有流量重定向回集群 X（DP A）。
    • 由于集群 X 保持不变，回滚是即时的，不需要恢复数据。

  2. 调查问题：

    • 调查集群 Y 遇到的问题。
    • 在再次尝试升级之前解决所有问题。

第 7 步：停用旧集群​

观察期过后且没有出现问题：

  1. 最终验证：

    • 执行最终验证以确认集群 Y 运行正常。
    • 确保已为集群 Y 正确配置了所有监控和告警系统。

  2. 停用集群 X：

    • 安全地停用集群 X 及其数据库（数据库 X）以释放资源。

特别注意事项​

资源要求​

该策略最耗费资源，因为它需要并行运行两个完整的生产环境。确保你有：

  • 足以供两个集群使用的计算资源
  • 足够的网络容量
  • 用于两个独立数据库的存储

状态插件​

两个集群之间不同步运行时指标和有状态插件（如限流）的状态。如限流等有状态插件将其计数器数据存储在 Redis 中，而不是数据库中。

注意事项：

  • 如果每个集群使用独立的 Redis 实例，这可能会在流量切换阶段导致短暂的不一致。
  • 例如，用户发起的请求可能会超过配置的限制，因为他们的请求被分摊到位于不同 Redis 实例中的两个独立的限流计数器上。

缓解策略：

  • 考虑为两个 API7 企业版集群使用共享的 Redis 集群以保持一致的状态。
  • 或者，在过渡期间接受暂时的限流误差。
  • 规划流量切换时间表以最大程度地减少这些不一致的影响。

配置冻结​

在整个过程中强制执行严格的配置冻结至关重要，以防止两个集群之间出现不一致。在升级过程中所做的任何配置更改都可能导致：

  • 集群间数据不一致
  • 流量切换期间出现意外行为
  • 回滚场景中遇到困难

零停机时间​

双集群升级策略提供了真正的零停机时间。在整个升级过程中，API 请求将继续得到处理，流量会逐渐从旧集群切换到新集群。