TSF高可用文档
1.TSF容灾环境部署
1.1.前置容灾部署
参考TSF一键部署文档，进行前置组件的部署；
在容灾场景下，需要确保前置的主备部署机器分别属于zone-1和zone-2可用区；
完成TSF前置组件部署，登录zone-1主可用区运营端；
1.2.模块节点可用区分配
前提条件：需要确保模块用到的vip已正确配置好
| 模块名称 | 模块类型 | 节点个数 | zone-1节点个数 | zone-2 节点个数 | 节点类型(master / slave ) |
|---|---|---|---|---|---|
| tsf-mysql | tsf-storage | 2 | 1 | 1 | zone-1: 1个节点为master；zone-2: 1个节点为slave； |
| tsf-ctsdb | tsf-storage | 3 | 2 | 1 | - |
| tsf-redis | tsf-storage | 2 | 1 | 1 | zone-1: 1个节点为master； zone-2: 1个节点为slave； |
| tsf-elasticsearch | tsf-storage | 3 | 2 | 1 | - |
| tsf-consul-authen | tsf-consul | 5 | 2 | 3 | zone-1: 2个节点为master类型； zone-2: 1个节点为master类型，2个节点为slave； |
| tsf-consul-register | tsf-consul | 5 | 2 | 3 | zone-1: 2个节点为master类型； zone-2: 1个节点为master类型，2个节点为slave； |
| tsf-consul-config | tsf-consul | 5 | 2 | 3 | zone-1: 2个节点为master类型； zone-2: 1个节点为master类型，2个节点为slave； |
| tsf-consul-access | tsf-consul | 3 | 2 | 1 | - |
| * | tsf-mesh | 2 | 1 | 1 | - |
| * | tsf-apaas | 2 | 1 | 1 | - |
| * | tsf-oss | 2 | 1 | 1 | - |
| * | tsf-transaction | 2 | 1 | 1 | - |
| * | license | 2 | 1 | 1 | - |
2.基础组件高可用
以上容灾能力部署方案中，以zone-1可用区为主可用区，zone-2为备可用区；
如果zone-2备可用区不可用，则不需要进行以下演练操作，TSF相应能力不受影响
如果zone-1主可用区不可用，则需要进行TSF部署模块容灾切换操作
2.1.MySQL
故障演练
- 提升MySQL备库为主库
# 登录MySQL备机，清除当前MySQL备库设置，停止主备同步，提升本库为新的主库
# 确保所有的从数据库都已经执行了relay log中的全部更新
# 登录从库MysQL，停止IO线程
mysql> stop slave io_thread;
# 查看主从同步状态
# 检查show processlist的输出，直到看到状态是Slave has read all relay log;
# waiting for the slave I/O thread to update it，表示更新都执行完毕
mysql> show processlist\G
# 提升从库为主库，重置从库为主数据库
# 完全停止 slave 复制
mysql> stop slave;
# 完全清空 slave 复制信息
mysql> reset slave all;
# 清空本机上 master 的位置信息(给原主库同步此原从库做准备)
msyql> reset master;
负载均衡切换
tsf-mysql模块部署了zone-1的master节点和zone-2的slave节点；zone-1挂掉后，切换tsf-mysql的负载均衡由zone-1的master节点为zone-2的slave节点；
故障恢复
- 重启并保证zone-1的tsf-mysql节点进程正常运行
- 重做MySQL备库
登录MySQL主机器上
# 登录新的主库MySQL机器，进行如下操作
# 进行授权账号，让新的从数据库有权限进行连接
# 替换其中 'tsf_mysql_password' 为实际密码
# 如果已存在 replicator 账户，则可以跳过此 CREATE 操作
mysql> CREATE USER 'replicator'@'%' IDENTIFIED BY 'tsf_mysql_password';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'%';
mysql> FLUSH PRIVILEGES;
# 备份数据
# 如果对数据有强一致性要求，建议锁库
mysql> flush tables with read lock;
# 使用以下命令检查主机状态，获取File和Position信息
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000002 | 22421846 | | | | +------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
# 新开一个远程连接在命令行中使用以下命令全量备份数据库
mkdir -p /tony_tmp
mysqldump -A -uroot -p*** > /tony_tmp/backup.sql
# 解锁Master库
# 如果前面有执行锁库，一定要解锁
mysql> unlock tables;
# 将备份文件传输到Slave机器上（假设还是放在/tony_tmp目录下，此处没有限制）
登录新增MySQL备机器上
# 登录需新添加的MySQL备机上，安装MySQL服务，并进行以下主备同步设置
mysql> stop slave;
mysql> source /tony_tmp/backup.sql
# 设置主库相关配置信息
mysql> CHANGE MASTER TO
MASTER_HOST='192.168.10.59', # 新MySQL主机IP
MASTER_PORT=3306, # 新MySQL主机PORT
MASTER_USER='replicator', # 主从同步账号
MASTER_PASSWORD='tsf_mysql_password', #主从同步密码
MASTER_LOG_FILE='mysql-bin.000002', # 修改为在新MySQL上`show binary logs;`的实际输出
MASTER_LOG_POS=22421846; #修改为在新MySQL上`show binary logs;`的实际输出
# 启动从库MySQL
mysql> start slave;
# 查看状态
mysql> show slave status\G
2.2.tsf-consul
故障演练
- tsf-consul-register容灾切换
# tsf-consul-register模块共部署了5个节点
# 2个master节点在zone-1, 1个master节点在zone-2,2个slave在zone-2
# zone-1可用区挂掉之后，登录在zone-2的master类型机器节点
# 进入ts-consul-register相应部署目录
cd <部署路径>/tsf/tsf-consul/tsf-consul-register/tsf-consul-register-v1.12.0/bin
# 修改配置文件 recover_config.json
# 修改对应机器信息的登录端口，用户名，密码为真实数据，其他字段不需要修改
vi recover_config.json
# 修改完 recover_config.json 之后，执行容灾切换脚本
# 执行 switch_backup_cluster.sh 脚本
# 脚本执行大约需1~3分钟左右时间
sh switch_backup_cluster.sh
# 查看执行脚本的输出，有输出 success 字样证明切换成功
# 确认集群状态恢复正常
sh cluster_health.sh
- tsf-consul-config容灾切换
# tsf-consul-config模块共部署了5个节点
# 2个master节点在zone-1, 1个master节点在zone-2,2个slave在zone-2
# zone-1可用区挂掉之后，登录在zone-2的master类型机器节点
# 进入ts-consul-config相应部署目录
cd <部署路径>/tsf/tsf-consul/tsf-consul-config/tsf-consul-config-v1.12.0/bin
# 修改配置文件 recover_config.json
# 修改对应机器信息的登录端口，用户名，密码为真实数据，其他字段不需要修改
vi recover_config.json
# 修改完 recover_config.json 之后，执行容灾切换脚本
# 执行 switch_backup_cluster.sh 脚本
# 脚本执行大约需1~3分钟左右时间
sh switch_backup_cluster.sh
# 查看执行脚本的输出，有输出 success 字样证明切换成功
# 确认集群状态恢复正常
sh cluster_health.sh
- tsf-consul-authen容灾切换
# tsf-consul-authen模块共部署了5个节点
# 2个master节点在zone-1, 1个master节点在zone-2,2个slave在zone-2
# zone-1可用区挂掉之后，登录在zone-2的master类型机器节点
# 进入ts-consul-authen相应部署目录
cd <部署路径>/tsf/tsf-consul/tsf-consul-authen/tsf-consul-authen-v1.12.0/bin
# 修改配置文件 recover_config.json
# 修改对应机器信息的登录端口，用户名，密码为真实数据，其他字段不需要修改
vi recover_config.json
# 修改完 recover_config.json 之后，执行容灾切换脚本
# 执行 switch_backup_cluster.sh 脚本
# 脚本执行大约需1~3分钟左右时间
sh switch_backup_cluster.sh
# 查看执行脚本的输出，有输出 success 字样证明切换成功
# 确认集群状态恢复正常
sh cluster_health.sh
故障恢复
- 重启并保证zone-1的
tsf-consul模块组件正常运行 - tsf-consul-register容灾恢复
# 登陆执行容灾切换的tsf-consul-registry zone-2 master 节点
# 进入ts-consul-register相应部署目录
cd <部署路径>/tsf/tsf-consul/tsf-consul-register/tsf-consul-register-v1.12.0/bin
# 执行 switch_normal_cluster.sh 脚本
# 脚本执行大约需1~3分钟左右时间
sh switch_normal_cluster.sh
# 确认集群状态恢复正常
sh cluster_health.sh
- tsf-consul-config容灾恢复
# 登陆执行容灾切换的tsf-consul-config zone-2 master 节点
# 进入ts-consul-config相应部署目录
cd <部署路径>/tsf/tsf-consul/tsf-consul-config/tsf-consul-config-v1.12.0/bin
# 执行 switch_normal_cluster.sh 脚本
# 脚本执行大约需1~3分钟左右时间
sh switch_normal_cluster.sh
# 确认集群状态恢复正常
sh cluster_health.sh
- tsf-consul-authen容灾恢复
# 登陆执行容灾切换的tsf-consul-authen zone-2 master 节点
# 进入ts-consul-authen相应部署目录
cd <部署路径>/tsf/tsf-consul/tsf-consul-authen/tsf-consul-authenr-v1.12.0/bin
# 执行 switch_normal_cluster.sh 脚本
# 脚本执行大约需1~3分钟左右时间
sh switch_normal_cluster.sh
# 确认集群状态恢复正常
sh cluster_health.sh
2.3.tsf-elasticsearch
ES集群默认不开启跨可用区容灾，在跨可用区容灾场景下，需在ES集群部署完成后执行以下操作进行配置
故障演练
- 执行容灾脚本调整集群配置和分片数量
# 登录任意一台集群机器
# 进入部署bin目录：
cd <部署目录>/common/tsf-storage/tsf-elasticsearch/tsf-elasticsearch/bin
# 执行配置脚本：
sh elasticsearch-cross-zone.sh
- 停掉ES集群中一个或两个节点的进程
# 检查ES集群状态
curl <es-ip>:9200/_cluster/health?pretty # 确认集群状态为yellow，则集群可用，只是部分分片丢失
# 页面查看部署组日志，看是否正常
故障恢复
- 重新拉起停掉的ES节点的进程
- 确认ES集群状态
# 确认集群状态为green，active_shards_percent_as_number为100
curl <es-ip>:9200/_cluster/health?pretty
2.4.tsf-ctsdb
CTSDB集群默认不开启跨可用区容灾，在跨可用区容灾场景下，需在ES集群部署完成后执行以下操作进行配置
故障演练
- 执行容灾脚本调整集群配置和分片数量
# 登录任意一台集群机器
# 进入部署bin目录：
cd <部署目录>/common/tsf-storage/tsf-ctsdb/tsf-ctsdb/bin
# 执行配置脚本：
sh ctsdb-cross-zone.sh
- 停掉CTSDB集群中一个或两个节点的进程
# 检查CTSDB集群状态
curl <ctsdb-ip>:9201/_cluster/health?pretty # 确认集群状态为yellow，集群可用，部分分片丢失
# 页面查看部署组日志，看是否正常
故障恢复
- 重新拉起停掉的CTSDB节点的进程
- 确认CTSDB集群状态
# 确认集群状态为green，active_shards_percent_as_number为100
curl <ctsdb-ip>:9201/_cluster/health?pretty
3.功能模块高可用
- 功能模块的高可用建立于已按照1.2章节划分主、备可用区进行部署，且要针对机器进行反亲和性部署，确保在某个节点故障的时候，对应用的影响只是 N 分之一或者只是一个实例
- 以下容灾场景模拟，可停掉单个可用区的所有机器（如zone1的机器），或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
3.1.tsf-mesh
3.1.1.tsf-mesh-apiserver
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看mesh相关功能是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，mesh相关功能不可用
- 若模块进程全停止，与该模块有依赖关系的组件会异常：tsf-auth、tsf-route
3.1.2.tsf-mesh-pilot
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看mesh相关功能是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，mesh相关功能不可用
- 若模块进程全停止，无相关依赖组件异常
3.1.3.tsf-mesh-mixs
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看mesh相关功能是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，mesh相关功能不可用
- 若模块进程全停止，无相关依赖组件异常
3.2.tsf-apaas
3.2.1.tsf-repository-access
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看包上传相关功能是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，包上传相关功能不可用
- 若模块进程全停止，与该模块有依赖关系的组件会异常：tsf-gateway、tsf-resource
3.2.2.tsf-repository-server
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看包上传、agent导入相关功能是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，包上传、agent导入等相关功能不可用
- 若模块进程全停止，无相关依赖组件异常
3.2.3.tsf-masterapi
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看集群、应用管理，实例上下线等相关功能是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
若模块进程全停止，集群、应用管理，实例上下线等相关功能不可用
若模块进程全停止，与该模块有依赖关系的组件会异常：tsf-apm、tsf-resource、tsf-scalable
3.2.4.tsf-master
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看集群、应用管理，实例上下线等相关功能是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
若模块进程全停止，集群、应用管理，实例上下线等相关功能不可用
若模块进程全停止，无相关依赖组件异常
3.2.5.tsf-controler
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看弹性伸缩等相关功能是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
若模块进程全停止，弹性伸缩等相关功能不可用
若模块进程全停止，无相关依赖组件异常
3.2.6.tsf-ratelimit-master
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看限流相关功能是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
若模块进程全停止，限流相关功能不可用
若模块进程全停止，无相关依赖组件异常
3.3.tsf-oss
3.3.1.tsf-resource
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看集群、部署组、应用管理相关功能操作是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，集群、部署组、应用管理相关功能操作不可用
- 若模块进程全停止，与该模块有依赖关系的组件会异常：tsf-apm、tsf-dcfg、tsf-ms、tsf-route、tsf-scalable、tsf-gateway、tsf-controler
3.3.2.tsf-alarm
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看监控告警相关功能是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，监控告警相关功能操作不可用
- 若模块进程全停止，与该模块有依赖关系的组件会异常：tsf-controler
3.3.3.tsf-apm
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看部署组日志，调用链、依赖拓扑等相关功能是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，部署组日志，调用链、依赖拓扑等相关功能相关功能不可用
- 若模块进程全停止，与该模块有依赖关系的组件会异常：tsf-resource、tsf-gateway
3.3.4.tsf-auth
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看服务鉴权，黑白名单设置等相关功能是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，服务鉴权，黑白名单设置等相关功能相关功能不可用
- 若模块进程全停止，无相关依赖组件异常
3.3.5.tsf-analyst
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看服务数据统计相关功能是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，服务数据统计相关功能不可用
- 若模块进程全停止，无相关依赖组件异常
3.3.6.tsf-dcfg
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看分布式配置相关功能是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，分布式配置相关功能不可用
- 若模块进程全停止，无相关依赖组件异常
3.3.7.tsf-dispatch
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看tsf-oss各模块之间调用是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，tsf各模块之间调用会异常
- 若模块进程全停止，无相关依赖组件异常
3.3.8.tsf-monitor
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看服务监控告警信息是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，服务监控告警相关功能不可用
- 若模块进程全停止，无相关依赖组件异常
3.3.9.tsf-ms
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看服务治理页面相关操作是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，服务治理页面相关操作不可用
- 若模块进程全停止，与该模块有依赖关系的组件会异常：tsf-apm、tsf-auth、tsf-route、tsf-gateway
3.3.10.tsf-ratelimit
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看服务限流页面相关操作是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，服务限流相关功能不可用
- 若模块进程全停止，与该模块有依赖关系的组件会异常：tsf-gateway
3.3.11.tsf-route
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看服务路由页面相关操作是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，服务路由相关功能不可用
- 若模块进程全停止，无相关依赖组件异常
3.3.12.tsf-scalable
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看弹性伸缩页面相关操作是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，弹性伸缩相关功能不可用
- 若模块进程全停止，与该模块有依赖关系的组件会异常：tsf-resource
3.3.13.tsf-template
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看服务编排页面相关操作是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，服务编排相关功能不可用
- 若模块进程全停止，无相关依赖组件异常
3.3.13.tsf-tx
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看分布式事务信息处理相关功能是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，分布式事务信息处理相关功能不可用
- 若模块进程全停止，与该模块有依赖关系的组件会异常：tsf-resource
3.3.14.tsf-metrics
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看监控告警相关功能是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，监控告警相关功能不可用
- 若模块进程全停止，无相关依赖组件异常
3.3.15.tsf-gateway
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看微服务网关相关功能是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，微服务网关相关功能不可用
- 若模块进程全停止，无相关依赖组件异常
3.3.16.tsf-token
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看服务注册相关功能是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，服务注册，consul与服务之间的心跳检测会受影响，导致服务下线
- 若模块进程全停止，无相关依赖组件异常
3.4.license-server
故障演练
- 停掉zone1可用区机器或者在运营端页面停掉模块的一个或多个节点（至少保留一个节点在工作）
- 查看租户端控制台相关操作是否正常
故障恢复
- 重新拉起之前停止的进程
影响范围
- 若模块进程全停止，控制台相关操作不可用
- 若模块进程全停止，无相关依赖组件异常