同城存储双活中的四大风险与应对实践
存储双活技术原理
存储双活部署架构
存储双活是指两台存储放置两个互为备份的数据中心，存储两份数据并且两份数据都可以被读写访问，处于运行状态。当一个数据中心存储发生设备故障，甚至数据中心整体故障时，业务自动切换到另一个数据中心，解决了传统灾备业务无法自动切换的问题。提供给用户更高的数据可靠性以及业务连续性的同时，提高存储系统的资源利用率。
图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的应用系统，客户比较敏感，同时不存在大量账务数据。可采用应用数据库同城双活的架构，使用Oracle RAC或Db2Purescale等，同时配置逻辑复制数据库。在应用层上通过负载配置信号灯机制，控制生产与容灾中心不同类业务模块访问的流量。通过域名或者HOSTS文件控制应用访问数据库指向。将业务按业务模块拆分，按读写方式拆分，能提升整体应用系统性能与稳定性。
图3渠道类应用系统存储双活实践方案
2）针对核心账务类同时涉及批量工作的应用系统，并不是非常建议使用数据库双活，可使用双活存储配置跨站点的HA，实现自动切换。同时应用程序如有需要共享的数据使用高性能NAS相对比较简单，易于管理。
图4核心账务类应用系统存储双活实践方案
总结
根据实际需求规划同城容灾架构，满足业务需求与监管要求，保证出现故障灾难，同城可在规划的RPO与RTO要求内完成切换，并且能长期承载应用系统运行，没有必要一味地追求RTO=0。
规划同城容灾架构需要多部门、多角度针对每个应用系统进行打分评级；根据应用系统特性，如账务类、渠道类、批量类等相关特性组合，制定满足需求的技术容灾方案；在根据应用系统的投入产出制定合理的容灾方案，并不是技术最先进、RPO与RTO都等于零的方案是最合理的方案。
无论是同城双活还是主备中心，都要零信任，给自己留好退路，重要关键系统的数据库逻辑复制以及备份平台都要完备。
同城容灾环境尽量配备完善的监控平台、稳定的调度平台以及周全的切换流程，保证容灾容错环境实时可用，同时出现故障减少人为操作，快速切换。
