本文介绍了应用实例（即集群）的一些主要操作的实现流程。

创建集群

创建集群

  1. 创建当前集群所有节点的资源，如云服务器、硬盘、IP 地址等。

  2. 将本集群中所有信息注册到 metadata service 中。

  3. 启动所有节点的 confd agent，监控 metadata service 中本集群信息的变化并按照 /etc/confd 下的模板（toml、tmpl）定义刷新配置。如果 toml 文件里定义 reload_cmd 且配置确实发生变更则执行该命令。

  4. 执行 init 和 start 中定义的 cmd，按照 init 中 post_start_service 定义的顺序执行。

    • 如果 post_start_service 为 true，则表示 init 在 start 后执行。

    • 不同 role 节点相同命令的执行顺序，按照 order 的定义从小到大依次执行，默认为 0（最早执行），相同 order 的节点并行执行。

删除集群

删除集群

  1. 如果待删除的节点定义了 destroy service，则从第 3 步开始执行；如果没有，则执行第 2 步和最后一步。

  2. 不同角色节点按照 order 升序执行 stop cmd。

  3. 如果待删除节点 destroy service 里定义了 post_stop_service 为 False，则从第 5 步开始执行；否则，执行第 4 步和最后一步。

  4. 待删除的不同角色按照 order 升序执行 stop cmd，然后按照 order 升序执行 destroy cmd。

  5. 待删除的不同角色按照 order 升序执行 destroy cmd，依据返回值正常（0）或非正常（非０）决定下一步。

    此处如此设置是为了提供一种保护措施，您可以在 destroy 命令里查看能否删除该节点或集群，以防数据丢失。

    • 如果 destroy cmd 返回非正常且用户不选择强行删除，则此任务失败且终止。

    • 如果 destroy cmd 返回正常或者在不正常情况下用户选择强行删除，则不同角色节点按照 order 升序执行 stop cmd。

  6. 删除当前集群所有资源，并且将本集群中所有信息从 metadata service 中注销。

关闭集群

关闭集群

  1. 不同角色节点按照 order 升序执行 stop cmd。

  2. 关闭每个节点的 confd agent。

  3. 关闭节点虚拟机。

  4. 将本集群中所有信息从 metadata service 中注销。

启动/恢复集群

启动/恢复集群

  1. 启动节点虚拟机。

  2. 将集群信息注册到 metadata service。

  3. 启动集群每个节点的 confd agent。

  4. 不同角色节点按照 order 升序执行 start cmd。

增加节点

增加节点
说明

新增角色节点需支持横向伸缩，即定义了 scale_horizontal 的 advanced_actions，参见 云应用开发模板规范 - 完整版。

  1. 创建新增节点的资源，如云服务器、硬盘、IP 地址等。

  2. 注册新增节点的信息到 metadata service 中（即 /hosts 目录下），同时注册到 /adding-hosts 这个临时目录下。

    应用的云服务器可以从 /adding-hosts 目录获取信息并执行横向扩容之前预处理操作等。

  3. 由于 metadata service 中集群信息发生改变，因此非新增节点可能会同时更新配置。如果 toml 文件里定义 reload_cmd 且配置确实发生变更则执行该命令。

  4. 启动新增节点的 confd agent，同时更新自身配置信息并执行 reload_cmd。

  5. 执行新增节点 init 和 start 中定义的 cmd，按照 init 中 post_start_service 的定义顺序执行。

    不同角色节点相同命令的执行顺序，按照 order 的定义从小到大依次执行，默认为 0（最早执行），相同 order 的节点并行执行。

  6. 执行非新增节点（即集群中除新增节点外的其他节点，通过nodes_to_execute_on 指定在某几个节点上执行）scale_out 中定义的 cmd。

  7. 删除 metadata service 中 /adding-hosts 这个临时目录下的内容。

  8. 由于 metadata service 中集群信息发生改变，因此各个节点可能会同时更新配置。如果 toml 文件里定义 reload_cmd 且配置确实发生变更则执行该命令。

删除节点

删除节点
说明

待删除角色节点需支持横向伸缩，即定义了 scale_horizontal 的 advanced_actions。

  1. 注册待删除节点的信息到 metadata service 的 /deleting-hosts 临时目录下。

  2. 由于 metadata service 中集群信息发生改变，因此所有节点可能会同时更新配置。如果 toml 文件里定义 reload_cmd 且配置确实发生变更则执行该命令。

  3. 若待删除节点定义了 destroy service，则从第 ５ 步开始执行操作；否则，执行第 4 步和最后三步。

  4. 非删除节点不同角色按照 order 升序执行 scale_in cmd，然后待删除节点不同角色按照 order 升序执行 stop_cmd。

  5. 如果待删除节点 destroy service 里定义了 post_stop_service 为 False，则从第 7 步开始执行；否则，执行第 6 步和最后三步。

  6. 非删除节点不同角色按照 order 升序执行scale_in cmd，然后待删除节点不同角色按照 order 升序执行 stop cmd，再按照 order 升序执行 destroy cmd。

  7. 待删除的不同角色按照 order 升序执行 destroy cmd，依据返回值正常 （0） 或非正常（非０）决定下一步。

    此处如此设置是为了提供一种保护措施，您可以在 destroy 命令里查看能否删除该节点，以防数据丢失。

    • 如果 destroy cmd 返回非正常且用户不选择强行删除，则此任务失败且终止，同时删除 metadata service 临时目录 /deleting-hosts 下信息。

    • 如果 destroy cmd 返回正常或者在不正常情况下用户选择强行删除，则不同角色节点按照 order 升序执行 scale_in cmd，然后各节点按 order 升序执行 stop cmd。

  8. 删除集群中这些节点资源。

  9. 将删除了的节点信息从 metadata service 中注销并且删除 /deleting-hosts 临时目录下信息。

  10. 由于 metadata service 中集群信息发生改变，因此剩余所有节点可能会同时更新配置。如果 toml 文件里定义 reload_cmd 且配置确实发生变更则执行该命令。

纵向扩容/更改云服务器类型

纵向扩容/更改云服务器类型

  1. 注册扩容角色到 vertical-scaling-roles。

  2. 如果只扩容硬盘则直接并行执行在线扩容，然后执行最后两步。

  3. 如果待扩容节点定义了 stop service，则执行第 4 步和最后两步；否则，执行第 5 步和最后两步。

  4. 按照 vertical_scaling_policy 的定义顺序执行（sequential）或并行执行（parallel）以下操作：待扩容节点上执行 stop cmd；待扩容节点上执行扩容操作；扩容节点上执行 start cmd。

  5. 非扩容节点上执行 stop cmd，然后待扩容节点上执行扩容操作，最后非扩容节点上执行 start cmd。

  6. 更新扩容节点的信息到 metadata service 中，并删除 vertical-scaling-roles。

    注意

    如果扩容过程中发生异常，vertical-scaling-roles 也会被删除。

  7. 由于 metadata service 中集群信息发生改变，因此所有节点可能会同时更新配置。如果 toml 文件里定义 reload_cmd 且配置确实发生变更，则执行该命令。

切换网络

切换网络

  1. 将 change-vxnet-audit 注册到 metadata service。

  2. 不同角色节点按照 order 升序执行 change_vxnet_pre_check 脚本。

    • 如果返回异常（非0），执行步骤 3。

    • 如果返回 0，执行步骤 4。

  3. 删除注册到 metadata service 内部的 change-vxnet-audit 数据，返回失败，操作结束。

  4. 停止服务，不同角色节点按照 order 升序执行 stop cmd 脚本。

  5. 从 metadata service 中注销集群数据。

  6. 关闭每个节点的 confd agent 服务。

  7. 切换网络（修改集群 vpc/vxnet 信息，为集群节点分配新 IP）。

  8. 重新注册集群信息到 metadata service。

  9. 将 change-vxnet-audit 注册到 metadata service。

  10. 启动集群每个节点的 confd agent 服务。

  11. 不同角色节点按照 order 升序执行 start cmd 脚本。

  12. 删除注册到 metadata service 内部的 change-vxnet-audit 数据。

交换预留 IP

交换预留 IP
说明

  • local 集群：表示当前操作集群。

  • remote 集群：表示和当前集群交换 IP 的集群。

  1. 将 exchange-reserved-ips-audit 注册到 remote 集群的 metadata service 内。

  2. 将 exchange-reserved-ips-audit 注册到 local 集群的 metadata service 内。

  3. remote 集群不同角色节点按 order 升序执行 exchange-reserved-ips pre_check 脚本：

    • 如果执行报错（返回非 0），执行步骤 4。

    • 如果执行正常（返回 0），执行步骤 5。

  4. 删除 remote 和 local 注册到 metadata service 的 exchange-reserved-ips-audit 数据，退出流程，操作结束。

  5. local 集群不同角色节点按 order 升序执行 exchange-reserved-ips pre_check 脚本：

    • 如果执行报错（返回非 0），执行步骤 6。

    • 如果执行正常（返回 0），执行步骤 7。

  6. 删除 local 和 remote 注册到 metadata service 的 exchange-reserved-ips-audit 数据，退出流程，操作结束。

  7. local 集群不同角色节点按 order 升序执行 stop cmd 脚本。

  8. remote 集群不同角色节点按 order 升序执行 stop cmd 脚本。

  9. 交换两个集群的预留 IP，更新数据库相关记录。

  10. 将交换后的预留 IP 注册到 local 集群 metadata service 的 /endpoints 中。

  11. local 集群不同角色节点按 order 升序执行 start cmd。

  12. 将交换后的预留 IP 注册到 remote 集群 metadata service 的 /endpoints 中。

  13. remote 集群不同角色节点按 order 升序执行 start cmd。

  14. 删除 local 和 remote 注册到 metadata service 的 exchange-reserved-ips-audit 数据，流程完成。

备份集群

备份集群

  1. 如果配置包定义 backup selector：

    1. 执行 backup selector 获取集群中支持备份的节点列表。

    2. 不同角色的非 replica 节点按照 order 升序排列，执行 backup cmd 脚本。

  2. 如果配置包未定义 backup selector：

    1. 如果未定义 backup with replica，集群节点过滤，排除掉 replica 节点，否则使用全部节点。

    2. 按照 order 升序排列，执行 backup cmd 脚本。

  3. 节点的硬盘做快照备份（kvm 备份挂载盘，lxc 备份主机），默认增量备份，同时校验备份链长度和个数。

  4. 备份完成，不同角色节点按照 order 升序执行 backup cleanup 脚本。

备份恢复集群

备份恢复集群

  1. 如果配置包中 backup_policy 定义为 device：

    1. 根据备份时集群的配置信息（cpu、内存、硬盘、环境变量等）创建集群。

    2. 注册集群信息到 metadata service。

    3. 启动每个节点的 confd agent 服务。

  2. 如果配置包中 backup_policy 定义不是 device，不同角色的节点按照 order 升序执行 stop cmd 脚本。

  3. 如果定义了 restore cmd，不同角色的节点按照 order 升序执行 restore cmd 脚本。

  4. 如果没有定义 restore cmd，不同角色的节点按照 order 升序执行 start cmd 脚本。

并行升级

并行升级

  1. 关闭集群节点。

  2. 以新版本镜像启动节点。

  3. 启动所有节点的 confd agent，监控 metadata service 中本集群信息的变化并按照 /etc/confd 下的模板（toml、tmpl）定义刷新配置。如果 toml 文件里定义 reload_cmd 且配置确实发生变更则相应地执行该命令。

  4. 执行 start 和 upgrade 中定义的 cmd，按照 upgrade 中 post_start_service 的定义顺序执行。

    • 如果 post_start_service 为 true，则表示 upgrade 在 start 后执行。

    • 不同 role 节点相同命令的执行顺序，按照 order 的定义从小到大依次执行，默认为 0（最早执行），相同 order 的节点并行执行。

  5. 如果第 4 步中的命令执行后的返回值非 0，则此次升级任务失败，需要手动关闭集群并执行第 6 步降级操作。

  6. 集群节点以旧版本镜像启动。

  7. 启动所有节点的 confd agent，监控 metadata service 中本集群信息的变化并按照 /etc/confd 下的模板（toml、tmpl）定义刷新配置。如果 toml 文件里定义 reload_cmd 且配置确实发生变更则相应地执行该命令。

  8. 不同的角色节点按 order 升序执行 start 中定义的 cmd。

说明

第 1 步到第 4 步的流程，按照 upgrading_policy 的定义， 顺序执行 (sequential) 或 并行执行 (parallel)。

并行升级失败恢复

并行升级失败恢复

  1. 手动关闭集群。

  2. 如果不支持 rollback，再次启动集群，会使用高版本镜像启动虚拟机，启动成功后升级完成。

  3. 如果支持 rollback，关闭集群时进行降级。

    1. 集群版本修改为旧版本。

    2. 集群节点虚拟机镜像改为旧版本镜像。

    3. 恢复旧版环境变量。

    4. 再次启动集群，降级完成。

滚动升级

滚动升级

  1. 将 upgrade-audit 注册到 metadata service。

  2. 不同角色节点按照 order 升序执行 upgrade_pre_check 脚本：

    • 如果返回异常（非 0），升级失败，删除 upgrade-audit，退出升级流程。

    • 如果返回 0，继续执行步骤 3。

  3. 执行 get_nodes_order 脚本，获取角色对应的节点升级顺序。

  4. 每个节点按照顺序依次执行如下操作：

    1. 执行 upgrade pre_cmd 脚本:

      • 如果返回报错（非 0），升级失败，删除 upgrade-audit，退出升级流程。

      • 如果返回 0，继续执行。

    2. 执行 stop_cmd 脚本，关闭服务。

    3. 关闭 confd agent 服务。

    4. 关闭节点虚拟机，替换新版本镜像并启动虚拟机。

    5. 是否配置 post_start_service：

      • 是，先执行 start cmd 脚本，再执行 upgrade cmd 脚本。

      • 否，先执行 upgrade cmd 脚本，再执行 start cmd 脚本。

  5. 如果有任一节点 start/upgrade cmd 执行失败，升级失败，删除 upgrade-audit，退出升级流程。

  6. 如果所有节点 start/upgrade cmd 执行成功，升级成功，删除 upgrade-audit。

滚动升级失败恢复

滚动升级失败恢复

  1. 配置包中是否支持 rollback：

    • 若不支持，则关闭集群，然后使用旧版本镜像再次启动集群，退出流程，操作结束。

    • 若支持，继续执行步骤 2。

  2. 将 upgrade-audit 注册到 metadata service。

  3. 不同角色节点按照 order 升序执行 upgrade_pre_check 脚本：

    • 如果返回报错（非 0），降级失败，删除 upgrade-audit，退出流程，操作结束。

    • 如果返回 0，继续执行步骤 4。

  4. 执行 get_nodes_order 脚本，获取角色对应的节点降级顺序。

  5. 每个节点按照顺序依次执行如下操作：

    1. 执行 stop_cmd 脚本，关闭服务。

    2. 关闭 confd agent 服务。

    3. 关闭节点虚拟机，替换旧版本镜像并启动虚拟机，启动 confd agent 服务。

    4. 执行 start cmd，启动服务。

  6. 所有节点降级成功后，删除注册到 metadata service 中的 upgrade-audit 数据，降级恢复完成。

原地升级

原地升级

  1. 将 upgrade-audit 注册到 metadata service。

  2. 不同角色节点按照 order 升序执行 upgrade pre_check 脚本：

    • 如果返回报错（非 0），升级失败，删除 upgrade-audit，退出流程，操作结束。

    • 如果返回 0，继续执行步骤 3。

  3. 使用配置包中定义的 snapshot 创建硬盘并挂载到正在运行的节点虚拟机上。

  4. 根据升级策略并行或者串行执行 upgrade cmd 脚本。

  5. 解绑新挂载的硬盘并销毁。

  6. 删除注册到 metadata service 中的 upgrade-audit 数据。

  7. 根据步骤 4 的执行结果判断升级是否成功：

    • 如果返回报错（非 0），升级失败。

    • 如果返回 0，升级完成。

原地升级失败恢复

原地升级失败恢复

  1. 配置包中是否支持 rollback：

    • 若不支持，则关闭集群，然后使用旧版本镜像再次启动集群，退出流程，操作结束。

    • 若支持，继续执行步骤 2。

  2. 将 upgrade-audit 注册到 metadata service。

  3. 不同角色节点按照 order 升序执行 upgrade pre_check 脚本：

    • 如果返回报错（非 0），降级失败，删除 upgrade-audit，退出流程，操作结束。

    • 如果返回 0，继续执行步骤 4。

  4. 根据升级策略并行或者串行执行 rollback cmd 脚本。

  5. 删除注册到 metadata service 中的 upgrade-audit 数据，降级恢复完成。