互联网下的灾备体系探讨.pptx

互联网的灾 备 体 系 探 讨 2016年6月28日 国内重大事故 1 2 3 4 5 6 5.28 携程与艺龙官网瘫痪 12小时恢复 6.6 青云机房雷击事件 3小时后恢复 9.1 阿里云盾事件 5.1 网易大火事件（骨干网攻击） 2014.3.30 腾讯深圳数据中心主供电线路中断 无中断 5.27 支付宝光纤挖断事情 2小时恢复 影响 项目分类 高可用性关键因素 级别 SLA 年当机 天当机 能力集 1 90.0000% 36.5天 2.4时 流程 2 99.0000% 3.65天 14分 运气 3 99.9000% 8.76时 86秒 运气+堆人（3班倒） 4 99.9900% 52.6分 8.6秒 服务自愈 5 99.9990% 5.25分 0.86秒 架构的容灾、容错、灾备系统 6 99.9999% 31.5秒 8.6毫秒 自治 高可用性关键因素 MTBF—故障发生机率 MTTR—故障恢复时间 高可用性关键因素 业务层 高可用性—业务层 降级服务 客户分级 功能分级 高可用性—服务层 服务层 MTBF—服务状态 可用性7级表 级别 名称 解决办法 第一级 数据完全崩溃损坏 数据存放在内存中的服务，内存数据库， 第二级 新增加的数据损坏 正常服务 第三级 数据没有丢失 系统与硬件各种Cache. 第四级 没有数据丢失，服务能力降低 异常数据处理与高级流控系统。 第五级 有部分服务，服务质量不降 多业务跑在一个实例上。 第六级 故障转移时，用户有感知 业务能恢复，恢复比较慢 第七级 故障转移，用户无感知 业务完全无影响 服务模块SLA等级 平台架构—数据落地 无数据落地 数据库 文件 流控系统 高可用性—资源层 资源层 高可用性—资源层 资源 硬件 机房带宽 多运营商 多地 同城 网络设备 光纤 服务器 品牌机 安全设备 软件 第三方服务 域名 证书 基础组件 DOCKER KVM 辅助分析服务 OMM ELK 支付宝的灾备进程 多活数据中心-失败 同城多活+异地数据灾备 异地多活-2013 同城多活+异地灾备要点 同城数据中心：同城数据中心之间用裸纤连接，之间距离不大于40KM，延时在一个局域网内。 数据库分库分表，数据保护模式由集中存储变成“三副本”，每个副本分布在不同的数据中心，一主二从，由应用进行数据的复制和一致性的保证。 应用层面实现的同城多活：数据库实现分布式，同城应用可以跨机房写数据库，应用层的多活就实现了。在强化应用层面的容错和故障处置手段之后，在主数据库故障时，应用可快速把主数据库切换至其他机房的从数据库。这种机制下，不单可以实现数据库的多活，而且进一步实现数据中心层面的同城多活，理论上任何一个数据中心中断都不会导致业务中断，切换过程也非常简单。 异地远程数据备份：在相隔1000公里的远程机房，由应用程序进行数据的备份，通常只需要把关键的账务数据增量同步过去，由于不用备份应用系统，实现起来较为简单。 支付宝—异地多活探索 异地多活的难点 跨中心数据交互 网络延时 解决办法 单元化：保障每个单元之中的基础设施、应用系统、数据库都齐备，大部分业务处理都可以在本单元之中完成； 服务治理：梳理业务之间的耦合关系，尽量减少和降低跨单元之间的数据交互； 异地数据交互优化：则是降低异地数据交互的频率、提高异地之间数据交互的效率，使业务系统可以适应异地的网络延时。 基础级—逻辑示意图 设备级— 核心节点-同城双活 平时状态 同等集群运行 费用 涉及模块 网络互联费用 厂商选择 ***区域内的机房均可 解决问题 1. 机房级故障，例机房或机柜掉电、核心设备出问题，服务器硬件故障。2. 机房级IDC设备故障。3. 省网以下网络故障。 不能解决的问题 1.骨干网波动与故障。2.城市级电力中断。3.省网出口问题。 开发支持 1.用户请求调度的切换速度与后端状态感知。（可以使用DNSPOD的后端监控功能实现） 风险点 1.互联光纤中断造成的数据不同步。 切换时间 分钟级 切换时影响范围 2分之1 项目预计时间 100工作日 执行计划 类型 项目名称 目标 故障机率 执行时间 总结改进 备注 业务层 任意容量失效 服务模块服务能力验证 高 　 　 　 任意区域失效 业务架构容错能力验证 低 　 　 　 任意人员失效 人员架构容错能力验证 中 　 　 　 任意客户失效 客户架构容错能力验证 中 　 　 　 任意资质失效 政策容错能力验证 中 　 　 　 　 　 　 　 　 　 服务层 任意服务失效演练（单/组） 业务架构容错能力验证 低 　 　 　 任意组件失效演练（单/组） 业务架构容错能力验证 低 　 　 　 任意数据失效演练（单/组） 灾备服务容错能力验证 低 　 　 　 　 　 　 　 　 　 资源层 设备服务能力