实例生命周期
功能概述
本文介绍应用实例,即集群的一些主要操作的实现流程。
操作步骤
创建集群
-
流程示意图
-
流程说明
-
创建当前集群所有节点的资源,如云服务器、硬盘、IP 地址等。
-
将本集群中所有信息注册到 Metadata Service 中。
-
启动所有节点的
confd agent,监控 Metadata Service 中本集群信息的变化并按照/etc/confd目录下的.toml、.tmpl模板文件定义刷新配置。说明 若
.toml文件里定义了reload_cmd且配置确实发生变更,则执行该命令。 -
执行
init和start中定义的cmd,按照init中 post_start_service 定义的顺序执行。-
如果
post_start_service为true,则表示init在start后执行。 -
不同
role节点相同命令的执行顺序,按照Order的定义从小到大依次执行,默认为0,最早执行,相同Order的节点并行执行。
-
-
删除集群
-
流程示意图
-
流程说明
-
如果待删除的节点定义了
destroy service,则从第 3 步开始执行;如果没有,则执行第 2 步和最后一步。 -
不同角色节点按照 Order 升序执行
stop cmd。 -
如果待删除节点
destroy service里定义了post_stop_service为False,则从第 5 步开始执行;否则,执行第 4 步和最后一步。 -
待删除的不同角色按照 Order 升序执行
stop cmd,然后按照 Order 升序执行destroy service。 -
待删除的不同角色按照 Order 升序执行
destroy service,依据返回值正常0或非正常非0决定下一步。-
此处如此设置是为了提供一种保护措施,您可以在
destroy命令里查看能否删除该节点或集群,以防数据丢失。 -
如果
destroy service返回非正常且用户不选择强行删除,则此任务失败且终止。 -
如果
destroy service返回正常或者在不正常情况下用户选择强行删除,则不同角色节点按照 Order 升序执行 stop cmd。
-
-
删除当前集群所有资源,并且将本集群中所有信息从 Metadata Service 中注销。
-
关闭集群
-
流程示意图
-
流程说明
-
不同角色节点按照 Order 升序执行 stop cmd。
-
关闭每个节点的
confd agent。 -
关闭节点虚拟机。
-
将本集群中所有信息从 Metadata Service 中注销。
-
启动/恢复集群
-
流程示意图
-
流程说明
-
启动节点虚拟机。
-
将集群信息注册到 Metadata Service。
-
启动集群每个节点的
confd agent。 -
不同角色节点按照 Order 升序执行
start cmd。
-
增加节点
-
流程示意图
| 说明 |
|---|
新增角色节点需支持横向伸缩,即定义了 scale_horizontal 的 advanced_actions,参见 云应用开发模板规范 - 完整版。 |
-
流程说明
-
创建新增节点的资源,如云服务器、硬盘、IP 地址等。
-
注册新增节点的信息到 Metadata Service 中(即
/hosts目录下),同时注册到/adding-hosts这个临时目录下。应用的云服务器可以从
/adding-hosts目录获取信息并执行横向扩容之前预处理操作等。 -
由于 Metadata Service 中集群信息发生改变,因此非新增节点可能会同时更新配置。如果 toml 文件里定义
reload_cmd且配置确实发生变更则执行该命令。 -
启动新增节点的
confd agent,同时更新自身配置信息并执行reload_cmd。 -
执行新增节点 init 和 start 中定义的 cmd,按照 init 中
post_start_service的定义顺序执行。不同角色节点相同命令的执行顺序,按照 Order 的定义从小到大依次执行,默认为
0,最早执行,相同Order的节点并行执行。 -
执行非新增节点(即集群中除新增节点外的其他节点,通过
nodes_to_execute_on指定在某几个节点上执行)scale_out 中定义的 cmd。 -
删除 Metadata Service 中
/adding-hosts这个临时目录下的内容。 -
由于 Metadata Service 中集群信息发生改变,因此各个节点可能会同时更新配置。如果 toml 文件里定义
reload_cmd且配置确实发生变更则执行该命令。
-
删除节点
-
流程示意图
| 说明 |
|---|
待删除角色节点需支持横向伸缩,即定义了 scale_horizontal 的 advanced_actions。 |
-
流程说明
-
注册待删除节点的信息到 Metadata Service 的
/deleting-hosts临时目录下。 -
由于 Metadata Service 中集群信息发生改变,因此所有节点可能会同时更新配置。如果 toml 文件里定义
reload_cmd且配置确实发生变更则执行该命令。 -
若待删除节点定义了
destroy service,则从第 5 步开始执行操作;否则,执行第 4 步和最后三步。 -
非删除节点不同角色按照 Order 升序执行 scale_in cmd,然后待删除节点不同角色按照 Order 升序执行 stop_cmd。
-
如果待删除节点
destroy service里定义了post_stop_service为 False,则从第 7 步开始执行;否则,执行第 6 步和最后三步。 -
非删除节点不同角色按照 Order 升序执行scale_in cmd,然后待删除节点不同角色按照 Order 升序执行 stop cmd,再按照 Order 升序执行
destroy service。 -
待删除的不同角色按照 Order 升序执行
destroy service,依据返回值正常 (0) 或非正常(非0)决定下一步。此处如此设置是为了提供一种保护措施,您可以在 destroy 命令里查看能否删除该节点,以防数据丢失。
-
如果
destroy service返回非正常且用户不选择强行删除,则此任务失败且终止,同时删除 Metadata Service 临时目录/deleting-hosts下信息。 -
如果
destroy service返回正常或者在不正常情况下用户选择强行删除,则不同角色节点按照 Order 升序执行 scale_in cmd,然后各节点按 Order 升序执行 stop cmd。
-
-
删除集群中这些节点资源。
-
将删除了的节点信息从 Metadata Service 中注销并且删除
/deleting-hosts临时目录下信息。 -
由于 Metadata Service 中集群信息发生改变,因此剩余所有节点可能会同时更新配置。如果 toml 文件里定义
reload_cmd且配置确实发生变更则执行该命令。
-
纵向扩容/更改云服务器类型
-
流程示意图
-
流程说明
-
注册扩容角色到 vertical-scaling-roles。
-
如果只扩容硬盘则直接并行执行在线扩容,然后执行最后两步。
-
如果待扩容节点定义了 stop service,则执行第 4 步和最后两步;否则,执行第 5 步和最后两步。
-
按照 vertical_scaling_policy 的定义顺序执行(sequential)或并行执行(parallel)以下操作:待扩容节点上执行 stop cmd;待扩容节点上执行扩容操作;扩容节点上执行
start cmd。 -
非扩容节点上执行 stop cmd,然后待扩容节点上执行扩容操作,最后非扩容节点上执行
start cmd。 -
更新扩容节点的信息到 Metadata Service 中,并删除 vertical-scaling-roles。
注意 如果扩容过程中发生异常,vertical-scaling-roles 也会被删除。
-
由于 Metadata Service 中集群信息发生改变,因此所有节点可能会同时更新配置。如果 toml 文件里定义
reload_cmd且配置确实发生变更,则执行该命令。
-
切换网络
-
流程示意图
-
流程说明
-
将 change-vxnet-audit 注册到 Metadata Service。
-
不同角色节点按照 Order 升序执行 change_vxnet_pre_check 脚本。
-
如果返回非 0,即为报错,执行步骤 3。
-
如果返回 0,执行步骤 4。
-
-
删除注册到 Metadata Service 内部的 change-vxnet-audit 数据,返回失败,操作结束。
-
停止服务,不同角色节点按照 Order 升序执行
stop cmd脚本。 -
从 Metadata Service 中注销集群数据。
-
关闭每个节点的 Confd Agent 服务。
-
切换网络(修改集群 vpc/vxnet 信息,为集群节点分配新 IP)。
-
重新注册集群信息到 Metadata Service。
-
将 change-vxnet-audit 注册到 Metadata Service。
-
启动集群每个节点的 Confd Agent 服务。
-
不同角色节点按照 Order 升序执行
start cmd脚本。 -
删除注册到 Metadata Service 内部的 change-vxnet-audit 数据。
-
交换预留 IP
-
流程示意图
说明 -
local 集群:表示当前操作集群。
-
remote 集群:表示和当前集群交换 IP 的集群。
-
-
流程说明
-
将 exchange-reserved-ips-audit 注册到 remote 集群的 Metadata Service 内。
-
将 exchange-reserved-ips-audit 注册到 local 集群的 Metadata Service 内。
-
remote 集群不同角色节点按 Order 升序执行 exchange-reserved-ips pre_check 脚本:
-
如果执行报错(返回非 0),执行步骤 4。
-
如果执行正常(返回 0),执行步骤 5。
-
-
删除 remote 和 local 注册到 Metadata Service 的 exchange-reserved-ips-audit 数据,退出流程,操作结束。
-
local 集群不同角色节点按 Order 升序执行 exchange-reserved-ips pre_check 脚本:
-
如果执行报错(返回非 0),执行步骤 6。
-
如果执行正常(返回 0),执行步骤 7。
-
-
删除 local 和 remote 注册到 Metadata Service 的 exchange-reserved-ips-audit 数据,退出流程,操作结束。
-
local 集群不同角色节点按 Order 升序执行
stop cmd脚本。 -
remote 集群不同角色节点按 Order 升序执行
stop cmd脚本。 -
交换两个集群的预留 IP,更新数据库相关记录。
-
将交换后的预留 IP 注册到 local 集群 Metadata Service 的
/endpoints中。 -
local 集群不同角色节点按 Order 升序执行
start cmd。 -
将交换后的预留 IP 注册到 remote 集群 Metadata Service 的
/endpoints中。 -
remote 集群不同角色节点按 Order 升序执行
start cmd。 -
删除 local 和 remote 注册到 Metadata Service 的 exchange-reserved-ips-audit 数据,流程完成。
-
备份集群
-
流程示意图
-
流程说明
-
如果配置包定义
backup selector。-
执行 backup selector 获取集群中支持备份的节点列表。
-
不同角色的非
replica节点按照 Order 升序排列,执行backup cmd脚本。
-
-
如果配置包未定义
backup selector。-
如果未定义
backup with replica,集群节点过滤,排除掉replica节点,否则使用全部节点。 -
按照 Order 升序排列,执行
backup cmd脚本。
-
-
节点的硬盘做快照备份(kvm 备份挂载盘,lxc 备份主机),默认增量备份,同时校验备份链长度和个数。
-
备份完成,不同角色节点按照 Order 升序执行
backup cleanup脚本。
-
备份恢复集群
-
流程示意图
-
流程说明
-
如果配置包中 backup_policy 定义为 device:
-
根据备份时集群的配置信息(cpu、内存、硬盘、环境变量等)创建集群。
-
注册集群信息到 Metadata Service。
-
启动每个节点的 Confd Agent 服务。
-
-
如果配置包中 backup_policy 定义不是 device,不同角色的节点按照 Order 升序执行
stop cmd脚本。 -
如果定义了
restore cmd,不同角色的节点按照 Order 升序执行restore cmd脚本。 -
如果没有定义
restore cmd,不同角色的节点按照 Order 升序执行start cmd脚本。
-
并行升级
-
流程示意图
-
流程说明
说明 第 1 步到第 4 步的流程,按照
upgrading_policy的定义, 顺序执行 (sequential) 或并行执行 (parallel)。-
关闭集群节点。
-
以新版本镜像启动节点。
-
启动所有节点的
confd agent,监控 Metadata Service 中本集群信息的变化并按照/etc/confd目录下的.toml、.tmpl模板文件定义刷新配置。如果 toml 文件里定义
reload_cmd且配置确实发生变更则执行该命令。 -
执行
start和upgrade中定义的cmd,按照upgrade中post_start_service的定义顺序执行。-
如果
post_start_service为true,则表示upgrade在start后执行。 -
不同
role节点相同命令的执行顺序,按照 Order 的定义从小到大依次执行,默认为 0,最早执行,相同 Order 的节点并行执行。
-
-
如果第 4 步中的命令执行后的返回值非 0,则此次升级任务失败,需要手动关闭集群并执行第 6 步降级操作。
-
集群节点以旧版本镜像启动。
-
启动所有节点的
confd agent,监控 Metadata Service 中本集群信息的变化并按照/etc/confd目录下的.toml、.tmpl模板文件定义刷新配置。如果
.toml文件里定义reload_cmd且配置确实发生变更则执行该命令。 -
不同的角色节点按 Order 升序执行
start中定义的cmd。
-
并行升级失败恢复
-
流程示意图
-
流程说明
-
手动关闭集群。
-
如果不支持
rollback,再次启动集群,会使用高版本镜像启动虚拟机,启动成功后升级完成。 -
如果支持
rollback,关闭集群时进行降级。-
集群版本修改为旧版本。
-
集群节点虚拟机镜像改为旧版本镜像。
-
恢复旧版环境变量。
-
再次启动集群,降级完成。
-
-
滚动升级
-
流程示意图
-
流程说明
-
将
upgrade-audit注册到 Metadata Service。 -
不同角色节点按照 Order 升序执行
upgrade_pre_check脚本。-
如果返回非 0,即为报错,升级失败,删除
upgrade-audit,退出升级流程。 -
如果返回 0,继续执行步骤 3。
-
-
执行
get_nodes_Order脚本,获取角色对应的节点升级顺序。 -
每个节点按照顺序依次执行如下操作。
-
执行
upgrade pre_cmd脚本。-
如果返回非 0,即为报错,升级失败,删除
upgrade-audit,退出升级流程。 -
如果返回 0,继续执行。
-
-
执行
stop_cmd脚本,关闭服务。 -
关闭 Confd Agent 服务。
-
关闭节点虚拟机,替换新版本镜像并启动虚拟机。
-
是否配置 post_start_service:
-
是,先执行
start cmd脚本,再执行upgrade cmd脚本。 -
否,先执行
upgrade cmd脚本,再执行start cmd脚本。
-
-
-
如果有任一节点
start/upgrade cmd执行失败,升级失败,删除upgrade-audit,退出升级流程。 -
如果所有节点
start/upgrade cmd执行成功,升级成功,删除upgrade-audit。
-
滚动升级失败恢复
-
流程示意图
-
流程说明
-
配置包中是否支持
rollback。-
若不支持,则关闭集群,然后使用旧版本镜像再次启动集群,退出流程,操作结束。
-
若支持,继续执行步骤 2。
-
-
将
upgrade-audit注册到 Metadata Service。 -
不同角色节点按照 Order 升序执行
upgrade_pre_check脚本。-
如果返回非 0,即为报错,降级失败,删除
upgrade-audit,退出流程,操作结束。 -
如果返回 0,继续执行步骤 4。
-
-
执行
get_nodes_Order脚本,获取角色对应的节点降级顺序。 -
每个节点按照顺序依次执行如下操作。
-
执行
stop_cmd脚本,关闭服务。 -
关闭 Confd Agent 服务。
-
关闭节点虚拟机,替换旧版本镜像并启动虚拟机,启动 Confd Agent 服务。
-
执行
start cmd,启动服务。
-
-
所有节点降级成功后,删除注册到 Metadata Service 中的
upgrade-audit数据,降级恢复完成。
-
原地升级
-
流程示意图
-
流程说明
-
将
upgrade-audit注册到 Metadata Service。 -
不同角色节点按照 Order 升序执行
upgrade pre_check脚本:-
如果返回非 0,即为报错,删除
upgrade-audit,退出流程,操作结束。 -
如果返回 0,继续执行步骤 3。
-
-
使用配置包中定义的 snapshot 创建硬盘并挂载到正在运行的节点虚拟机上。
-
根据升级策略并行或者串行执行
upgradecmd 脚本。 -
解绑新挂载的硬盘并销毁。
-
删除注册到 Metadata Service 中的
upgrade-audit数据。 -
根据步骤 4 的执行结果判断升级是否成功:
-
如果返回非 0,即为报错,升级失败。
-
如果返回 0,升级完成。
-
-
原地升级失败恢复
-
流程示意图
-
流程说明
-
配置包中是否支持
rollback。-
若不支持,则关闭集群,然后使用旧版本镜像再次启动集群,退出流程,操作结束。
-
若支持,继续执行步骤 2。
-
-
将
upgrade-audit注册到 Metadata Service。 -
不同角色节点按照 Order 升序执行
upgrade pre_check脚本。-
如果返回非 0,即为报错,降级失败,删除
upgrade-audit,退出流程,操作结束。 -
如果返回 0,继续执行步骤 4。
-
-
根据升级策略并行或者串行执行
rollback cmd脚本。 -
删除注册到 Metadata Service 中的
upgrade-audit数据,降级恢复完成。
-