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

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