anrain 发表于 2015-6-1 16:45:28

从“支付宝,对不起”事情,看F5应对数据中心容灾系统的防御战略

从“支付宝,对不起”事情,看F5应对数据中心容灾系统的防御战略

摘要: 支付宝的对不起事件,再一次把容灾系统建设推到了风口浪尖, 当一个金融行业的系统中断那怕是一个小时,将会造成怎样的严重后果!今天,给大家介绍,透过“支付宝,对不起”事件,看F5应对突如其来的数据中心灾难恢复的解决方案,以及金融行业成功案例的分享。

正文
5月27日傍晚,支付宝官网发布声明,因市政施工导致杭州市某地光缆被挖断, 导致支付宝一个主要机房受损,大量用户出现无法正常使用支付宝情况,甚至恢复后出现延时现象,作为一种一直以来用的得心应手的支付方式突然之间不能使用,令人不得不倍感无所适从。不得不说,“支付宝,对不起”事件,所带来的影响超出了一般单一的中断事故,给企业本身声誉和财产带来损失,同时,对金融行业数据中心容灾系统恢复带来了巨大考验。

在“支付宝,对不起”事件的背后,面对异地多活数据中心容灾处理上,支付宝坦言,还是存在技术上不足,在切换速度上没有做到更快速处理,恢复时间上存在缺憾, 所以,通过这次事情,支付宝重中之重,就应该积极优化并逐步改造系统架构建设,才能避免此类事情的再一次发生。

要具备高水平的集成性网络容灾系统,网络架构需要具备连续性、高可用性等方面关键要求,当灾难发生时,可以快速恢复应用正常运行,并保证用户仍然能够继续访问,甚至在体验上毫无察觉。F5公司作为全球安全领航人,致力于解决面向数据中心容灾恢复系统的建设,在数据中心容灾系统的解决方案,发挥极致,建立快速切换应用和数据库的网络架构,提供充分发挥多中心应用多点部署优势,保证业务持续性,助力企业全面提升业务系统和数据中心对突发故障和灾难的恢复响应速度,为架构提供高可用性和连续性,保障企业的利益和信誉不受损失。

F5应对不同容灾场景的解决方案及结构说明
在多中心业务切换场景中,存在流量出口以及业务区内部出现异常两种情况。在两种异常故障中,都需要快速将流量从故障中心截止,并引导流量到备份应用去。依照不同的应用类型,分为基于DNS的快速容灾切换和基于IP的快速容灾切换。

目前容灾快速切换的运维需求有以下几种:
双中心应用快速切换运维需求需要在业务一致性和自动化风险之间做评估,可以分为自动化切换以及手工一键切换两种。

①. 基于DNS的应用自动切换,需要在各种场景中,基础架构可以自动在1分钟内发现应用、链路出口、骨干网到城域网之间的问题,并将用户请求自动引导到可用数据中心。
②. 基于IP地址的应用自动切换,要求在业务访问出现故障的时候,在30秒内可以发现问题,并将应用切换到可以正常工作的数据中心。

③. 基于IP的数据库手工切换,要求从开始执行切换到切换完成,整体在5分钟内完成。

1、互联网基于DNS访问的应用快速自动切换


每条ISP线路上配置一台GTM,每个数据中心部署一套用于DNS安全防护的LTM+AFM系统
• 通过GTM实现用户就进行访问和应用冗余性智能解析。
• LTM上通过iRules将GTM对外的探测分别分布在不同的互联网线路上。
• LTM+AFM系统开启DNS 的抗DDOS功能和DNS查询限制功能,增强DNS基础架构的安全性。
• 通过LTM将解析服务分配在不同的GTM硬件环境上,提供负载均衡和冗余功能。
• GTM系统通过配置到Prober Pool对互联网服务器资源进行探测,每个Server对应一个Prober Pool,每个Prober Pool优先包含与服务器相同运营商的GTM。
• 探测本线路Server的Prober Pool不包含本线路的GTM系统。
• 一个周期内仅当所有Prober Pool中的GTM探测返回结果都失败,才将Server标记为“不可用” 。
上述架构可以在一个检查周期(通常为30秒到1分钟)内发现应用,链路出口,骨干网到城域网之间的故障,将用户请求引导到可用数据中心,实现访问应用快速自动切换。这种架构还可以支持GTM同步组通过内网同步,以降低公网跨运营商时延和网络抖动问题对GTM同步的影响,具备智能,高可用,高安全等特性。

2、内网DNS访问应用快速自动切换

每个数据中心部署两台以上GTM实现基于应用探测结果的DNS解析
• 每个数据中心部署一套用于DNS安全防护的LTM +AFM系统。
• LTM+AFM系统开启DNS 的抗DDOS功能和DNS查询限制功能,增强DNS基础架构的安全性。
• 通过LTM将解析服务分配在不同的GTM硬件环境上,提供负载均衡和冗余功能。
• 走向AD域的流量使用DNS Cache功能,部署透明模式的cache,LTM DNS Service根据TTL时间进行缓存。
• 走向内网其他DNS服务器的流量使用DNS Express,LTM作为Slaver DNS,通过notify机制进行DNS记录的实时同步,DNS服务器异常不会影响内网客户端的以及应用服务器的正常解析。
• 客户端使用两个数据中心的两个LTM上的DNS IP做主用和备用DNS解析服务器。
上述架构在基于DNS解析的业务出现故障在一个检查周期(通常为30秒到1分钟)内发现业务服务器故障,从而实现业务自动快速切换到当前可用的数据中心,包括分支机构客户端方位总部数据中心和数据中心内部服务器互访。

3、基于IP访问的应用快速自动切换
基于IP的应用自动切换网络架构建议如下图:

建设要点如下:

• 通过F5 BIG-IP 构建业务VS网络Present层分支机构连接总部通过专线同时连接两个数据中心。
• 将多中心的同层次的BIG-IP构建为Device Service Group。
• F5 BIG-IP将多中心相同业务的所有服务器添加为Pool Memer。
• 通过member 中的virtual location功能,F5自动识别服务器所在的数据中心。
上述架构可以实现:

1.   服务器出现故障,在F5一个健康检查周期(可自定义)内发现数据中心服务器故障,将流量切换到到可用数据中心。
2.    F5设备彻底故障的情况下,可以在3秒内将业务IP地址发布在备份数据中心F5设备上。

4、基于IP访问的数据库快速切换
由于数据库的特殊性和重要性,对数据库的多中心切换一般通过手工执行,基于IP的数据库一键手工切换,同时建议在进行数据库多中心部署之前,进行以下优化。
1. F5 BIG-IP作为各分区相连转发设备,实现业务区流量分配的灵活性。
2. APP和DB的业务接口降低Round Trip以保证用户体验,避免跨数据中心APP连接DB出现性能瓶颈。
3. APP、WEB的审计支持SNAT,支持动态部署。
4. 预定义APP启停和F5配置修改脚本,最大程度降低切换时间。
以下是在进行数据库切换前,F5推荐架构中APP/DB之间数据连接情况:

1.第一数据中心的APP通过本中心DB区的F5 LTM上的VS进行数据库连接,并连接至第一数据中心DB。
2.第二数据中心的APP通过本中心DB区的F5 LTM上的VS进行数据库连接,但连接的是第一数据中心的DB。
案例分享:某银行多数据中心灵捷部署安全可靠的互联网业务

客户介绍:

某银行成立于1990年,是国有控股的全国性股份制商业银行,具有雄厚的资金实力,鲜明的股权结构,完善的经营管理体制,布局合理的机构网络,曾被评为中国最佳赢利银行之一,伴随着中国经济和金融业的不断发展,该银行不断改革创新,已在全国23个省、自治区,拥有分支机构430多家,与此同时,为了满足现有业务需求,该银行也积极利用信息化手段,来提高自身的竞争力和客户满意度,为此,数据中心容灾处理和高可用性成为该银行信息化建设重点。

客户需求:

1、互联网业务应用级双活。
2、智能化DNS服务以及DNS的安全防护。
3、引导用户“就近性”访问互联网业务。
4、双中心数据库快速切换,降低RTO。
5、分布式CDN,覆盖全国用户。
6、提升七层应用安全防范能力。

F5解决方案:

方案优势:

1、通过GTM智能化DNS解析, 引导用户就近性访问网银等互联网核心业务;
2、跨数据中心的应用级健康探测机制可最大程度模拟互联网用户的访问请求,及时规3、避链路异常,服务器故障等造成的业务中断;
3、提供对DNS基础架构的安全防护,提供安全高效的DNS服务;
4、多点部署F5 WA(AAM)提供对静态内容的快速分布,提供自主的CDN服务;
5、数据库之前部署F5 LTM, 实现数据库跨数据中心间的快速切换;
6、部分关键业务前端部署F5 LTM+ASM,提供整合的网络层至应用层安全保护,且无需修改网络架构;
7、提供API接口,实现自动化运维;

客户收益:

1、多中心同时运行,提高了数据中心的投资回报率。
2、基于智能DNS的就近性解析策略,提高用户的访问体验。
3、自动发现骨干网链路异常及运营商链路异常引起的业务中断,将RTO从30分钟降低到1分钟。
4、互联网链路一键切换,切换时间从10分钟降低到1分钟。
5、数据库在双中心中实现快速切换,无需修改应用代码,数据库跨数据中心切换时间从30分钟降低到5分钟。
6、通过ASM七层安全模块,每周阻止超过2000次应用层攻击。
7、基于F5 WA(AAM)构建的分布式CDN节点,降低了互联网出口带宽消耗以及服务器压力,同时提高了全国用户的覆盖能力。

结束语
灾害事件不能完全杜绝,容灾是企业数据管理中最重要的环节,面对突如其来的灾难事件,部署先进的技术解决方案才能避免“支付宝,对不起”事件的再一次发生。F5数据中心容灾解决方案,全面帮您的数据中心应对灾难,快速响应,全面防御,保证业务的连续性和高可用性,保障业务不间断,提高服务效率,帮助您提升客户满意度和竞争力。
页: [1]
查看完整版本: 从“支付宝,对不起”事情,看F5应对数据中心容灾系统的防御战略