渲染后台故障演练实践

故障回顾

• 2018-09-06 淮南机房宕机半天无报警

根本原因：Redis主备切换失效。Redis和Proxy宕机没有P1报警。

• 2018-09-17 早上渲染卡住

根本原因：7:30左右嘉兴机房的出口电信到ipsec中心节点的路由不通造成，ipsec隧道中断造成内网不通

• 2018-10-26 淮南集群渲染图上传OSS批量失败

根本原因：渲染控制节点一主多从，部署人员在部署流程中仅重启了一个节点，其余节点仍然维持旧版本运行，出现不一致

• 2018-11-29 淮南集群链路中断，引发连锁反应

根本原因：淮南集群电信链路中断，导致渲染业务服务无法正确连接集群；同时RenderClient中检查任务状态模块受链路中断波及，检查状态的相关异步线程逻辑超时后，不能正确地回写状态，导致调用方获取任务状态出现异常

• 2018-12-11 滨安和淮南机房下午高峰时宕机

根本原因：渲染集群 Redis 内存耗尽。

• 2019-05-18 滨安集群宕机

根本原因：一个redis节点对应的物理机宕机，redis sentinal出现了脏数据，无法重启恢复，无法选举出master

渲染后台架构

渲染集群五个机房，每个机房有proxy、renderservice、redis、mysql

• Proxy：控制节点，角色为 master 或 slave，每个集群至少部署 2 个以成环；
• Render：渲染节点，每个集群有上百个；
• Redis：存储任务信息、配置信息等等，以主备的方式部署；
• MySQL ：存储任务调度信息、任务结果等持久化数据。

演练项

（图片来自网络）

渲染后台是较为底层的服务，redis是主要依赖的中间件，也是发生故障最多的地方。所以演练的重点是redis；

Redis

• 单点故障：kill one sentinel，kill all sentinel，kill master，
• 主从切换：来回 kill master
• 服务器宕机：one sentinel宕机，all sentinel 宕机，master宕机，all 宕机
• 网络异常： one sentinel网络不通，master网络不通
• 内存异常：redis maxme meroy打满，服务器内存耗尽
• CPU异常：one sentinel满载，master满载
• 磁盘异常：disk io 高，磁盘写满
• 备用redis切换

proxy

• 单点故障
• master 选举
• 负载均衡
• proxy 高负载压测

后续目标：

• CPU异常、网络异常、内存异常、磁盘异常
• 千台大集群proxy验证

mysql

• 网络异常
• 异常重连

网络

淮南机房目前渲染服务器908/2005，接近一半的渲染资源在淮南机房。淮南机房公网出口为了稳定性保障，网络组已经部署两条电信线路：合肥和 江苏 ，目前现网渲染业务走合肥线路，江苏线路做为备份线路

主要模拟场景：当合肥线路中断后，防火墙自动切换到江苏线路后，业务层面使用域名DNS地址从合肥ip地址切换到江苏ip地址，保证业务能正常运行

演练目的

• 预案有效性：主要验证“备胎”靠不靠谱；系统强依赖的模块需要有降级、备用方案；需要对这类方案做有效性验证；
• 监控报警：报警的有无、提示消息是否准确、报警实效是5分钟还是半小时；
• 故障复现：故障的后续Action是否真的有效，完成质量如何，只有真实重现和验证，才能完成闭环。发生过的故障也应该时常拉出来练练，看是否有劣化趋势；
• 架构容灾测试：主备切换、负载均衡，流量调度等为了容灾而存在的手段的时效和效果，容灾手段本身健壮性如何；
• 参数调优：限流的策略调优、报警的阈值、超时值设置等；