53

渲染后台故障演练实践

 4 years ago
source link: https://www.tuicool.com/articles/imqe2mR
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

故障回顾

  • 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 :存储任务调度信息、任务结果等持久化数据。
Nb2ABjv.png!webimage2019-6-21_18-1-28.png?version=1&modificationDate=1561111290000&api=v2

演练项

image2019-6-21_18-29-27.png?version=1&modificationDate=1561112968801&api=v2image2019-6-21_18-30-52.png?version=1&modificationDate=1561113054000&api=v2

(图片来自网络)

渲染后台是较为底层的服务,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是否真的有效,完成质量如何,只有真实重现和验证,才能完成闭环。发生过的故障也应该时常拉出来练练,看是否有劣化趋势;
  • 架构容灾测试:主备切换、负载均衡,流量调度等为了容灾而存在的手段的时效和效果,容灾手段本身健壮性如何;
  • 参数调优:限流的策略调优、报警的阈值、超时值设置等;

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK