同城存储双活中的四大风险与应对实践.docx

存储双活技术原理存储双活部署架构存储双活是指两台存储放置两个互为备份的数据中心，存慵两份数据并且两份数据都可以被读写访问，处于运行状态。当一个数据中心存储发生设备故障,甚至数据中心整体故障时，业务自动切换到另一个数据中心，解决了传统灾备业务无法自动切换的问题。提供给用户更高的数据可靠性以及业务连续性的同时，提高存储系统的资源利用率.图1存储双活部署图1）脑裂：存佬双活，首先要保证数据的一致性，所以在设计仲裁模式的时候，建议建立第三方站点作为仲裁站点，不具备第三站点也可使用主备仲裁方式,但也不能完全避免仲裁失败的情况，所以还要考虑强制启动，可强制启动任意一端的存储作为源端.2）读写：存储双活的写一般都是在缓存屐完成，双存储在写入缓存后，主机端即认为写完成。同时要尽量减少居中心的读写，一般可通过主机端集群配置业务分盟,增加本地读写，减少数据冲突，来提升读写性能.3 ）应用层：如果只有存储双活没有应用双活，存储双活不仅没有大幅度减少RTO1同时还增加了更多的风险,所以无论是数据库还是应用程序必须为双活，存储双活才有意义.4 ）故障切换：存储双活切换，并非全无感知，本地存储故獐，一般会HANG一段时间,自动切换同城存储，RPO=O.RTO一般为秒级,数据库一般不会宕机；同城道珞故獐也会HANG一段时间，仲裁决定主站点，RPO=O,RTO一股为秒级，数据库一般不会宕机；仲裁服务器故障,对存储双活运行与同步一般无影响.存储双活的风险1）腌路风睑：根据监管要求同城应用级灾难备份中心，应与生产中心直线距需至少达到30km（如果直线距离达到30千米，一般裸光纤距离会在60千米以上）.存储双活需要充分考虑性能与稳定性，尤其是光纤腌路抖动是不可避免的.可能由于链路抖动带来大面积业务阻塞，或者批量过程中出现链路抖动，导致IO失败,可能出现批般再跑或造成数据借误的情况.2）集群风睑：存储双活一般都是主备数据中心使用一套集群系统，存储的集群系统则变成了单点，集群系统的故障或BUG等将造成更为严函的后果,导致双存储全部无法使用或造成数据不一致.3）逻辑错误与数据坏块存博双活无法解决逻辑错误以及数据库出现的数据坏块.-I）运维风I埼：存储双活对运蘸工程师提出了更高的要求,增加了运维的复杂程度.存储双活实践根据以上存储双活的风睑，无论采用何种存情双活技术，仍需要根据应用系统属性增加必要的本地存储高可用架构,建议为独立的主机、网络、存储以及物理区域.图2存储双活实践架构容错必要性逻辑保护：当出现存储集群故障或者数据庵出现物理坏块的情况，可为数据库提供保障.读写分离：遗娼基制数据库一般都为可读状态，可以分流部分查询业务到逻担豆制麻,减少主麻读压力.容错切换：生产端访问容灾端存储，性能无法满足需求，同时如果只有本应用系统切换同城，造成其他应用系统跨站点访问，延时增高,影响业务的情况下，可启用生产端逻辑豆制阵接管业务.实线方案1 ）针对渠道类7*24的应用系统，客户比较敏感，同时不存在大量账务数据.可采用应用数据库同城双活的架构，使用OraCIeRAC或Db2Purescale等，同时配置逻辑复制数据库.在应用层上通过负载配笆信号灯机制，控制生产与容灾中心不同类业务模块访问的流量.通过域名或者HOSTS文件控制应用访问数据面指向。将业务按业务模块拆分，按读写方式拆分，能提升整体应用系统性能与稳定性.如B甲用：目用甲甲一1.生产数据中心同城灾备中心仲檄&务器第三站点图3渠道类应用系统存描双活实践方案2 ）针对核心账务类同时涉及批IR工作的应用系统，并不是非常建议使用数据库双活，可使用双活存储配苴跨站点的HA,实现自动切换.同时应用程序如有需要共享的数据使用高性能NAS相对比较简单，易于管理.核心账务类应用系统存储双活实践方案总结根据实际需求规划同城容灾架构，满足业务需求与监管要求，保证出现故障灾难.同城可在规划的RPO与RTO要求内完成切换，并且能长期承载应用系统运行，没有必要一味地追求RTO=O.规划同城容灾架构需要多部门、多角度针对每个应用系统进行打分评级；根据应用系统特性，如账务类、渠道类、批鼠类等相关特性组合，制定满足需求的技术容灾方案；在根据应用系统的投入产出制定合理的容灾方案，并不是技术最先进、RPO与RTO都等于零的方案是最合理的方案.无论是同城双活还是主备中心，都要零信任，给自己留好退路，串要关键系统的数据库逻辑豆制以及备份平台都要完备。同城容灾环境尽量配备完善的监控平台、稳定的调度平台以及周全的切换流程，保证容灾容错环境实时可用，同时出现故障减少人为燥作，快速切换.