集中式存储的双活架构设计中，分别在双中心部署存储来实现存储双活，通常综合成本因素的考虑，一个中心会部署一套存储系统，当一个数据中心的存储出现问题，计算资源会访问另一个数据中心的存储，避免业务中断。本议题主要围绕两个关键点展开分析和讨论 存储双活架构中应该如何评估数据中心本地存储的单点故障风险？在设计和实施的时候应该在哪些方面消除可能存在的单点故障风险？
本期为大家带来《迈向YB数据时代》2022年春季刊“集成实施”栏目中的议题三
存储双活架构下，如何消除本地数据中心的存储单点故障风险？
议题主编 某金融科技公司高级技术主管 张鹏
在提出议题下关键点的主张前，专家们先对为什么会有存储双活架构的存在、正常情况下的数据读写如何实现、异常情况下数据读写如何处理几点认知取得了共识。
为什么会有存储双活架构的存在？
我们知道企业实现业务连续性管理的最高目标就是实现业务RTO&RPO的极限。这也是近些年来在企业容灾领域追求双活的原动力。双活容灾系统的实现是以一系列关键条件为基础的
1 数据可以在双数据中心实现同步复制；
2 双数据中心之间可以实现数据层的无中断读写；
3 双数据中心之间可以实现业务层的平滑切换。
那么对于前两个条件的实现，可以通过数据库层实现，也可以通过存储层实现。通过存储层实现的架构就是我们所谓的存储双活架构，当然存储层实现双活架构的模式也有很多种，下图就是实现存储双活架构的典型物理架构，结合架构图我们进行具体分析如图1所示。
首先，从功能角度来看，通过系列物理设备的组合，将数据中心A和B的存储阵列的物理卷进行镜像组合之后，可以为上层应用提供一个可以在双数据中心共享使用的虚拟逻辑存储卷，这个虚拟卷实现了在双数据中心的数据同步复制，当然这个虚拟卷在双中心之间的共享方式根据双活机制的差异会有不同的共享方式（以VPLEX为例 AA共享，以SVC为例 AP共享 。
其次，从物理拓扑架构角度来看，纵向上存储网关对上层应用的存储服务负责，存储阵列通过FC-SAN对存储网关的逻辑存储服务负责。横向上存储网关及存储阵列通过波分设备实现FC-SAN的共享联通及集群的通讯联系，同时双中心之间通过以太网实现与第三方仲裁中心的联通。
以数据中心A为例，正常情况下的数据读写如何实现？
我们之前章节分析过实现双活的首要关键条件就是要在双数据中心实现数据读写的同步复制，这个过程就是要在正常的读写流程当中完成数据在底层的正常复制裂变。具体过程如下所述
1 数据中心A的主机向虚拟卷（存储网关提供给主机的虚拟卷 发起写请求；
2 数据中心A的存储网关将写请求分别拆分为向存储阵列A和存储阵列B写入的物理请求；
3 存储阵列A将写请求写入缓存，并返回ACK给存储网关A；
4 存储阵列B将存储网关传递过来的写请求写入缓存，并返回ACK给存储网关A；
5 数据中心A的主机写请求完毕。
以数据中心A为例，异常情况下数据读写如何处理？
所谓异常读写，主要是指数据流无法在A中心正常落盘的情况。遇到这种场景的时候，我们需要明确两点 数据存储服务提供者的角色转换和数据如何在异常情况下落盘。
正常情况下，数据存储服务的提供者应该是数据中心A的存储网关，那么当数据中心A的存储网关无法再提供同样服务的时候，就会由数据中心B的存储网关来接管其任务；
正常情况下，数据应该在存储底层进行复制裂变实现双写完成，但是异常情况下数据流无法在数据中心A的存储阵列落盘的时候，会在存储集群的事务日志当中记录双中心之间的差异事务量，一旦存储双活架构恢复正常之后，可以通过日志来进行故障侧的增量数据复制。
社区专家主张
张鹏主编 本议题由某金融系统高级主管赵海、哈尔滨银行架构师董立国分别针对如何避免单点故障的方法，以及遇到了单点故障的处理方案等关键点进行了主张。主张在经过江西农信运维技术经理邓毓、北京农商行存储架构师刘振国及我本人的复议后，最终达成一定的共识供同行参考。
赵海 某金融系统高级主管
在存储双活架构下，任何存储层的单点故障都会导致数据中心级的切换。
问题 企业的容灾架构主要还是为了应对数据中心级的灾难，但是在存储双活架构下，任何存储层的单点故障都会导致数据中心级的切换，这个代价实在不值，我们采取什么样的措施可以避免因为此类单点故障导致的中心级切换？
对于设备级的单点故障，其实应该归类到本地高可用性的范畴来探讨。但是就整个双活容灾架构来讲，这个本地高可用的规划设计也是必须要涉及的核心内容，具体结合图2来看。
从图2来看，纵向上数据会从主机层发起，到物理存储阵列层结束。那么发生故障的位置有可能是以上图中A、B、C任意的位置。我们依次来分析
如果故障发生在A点位置，那么最有可能的就是存储网关的故障以及主机到存储网关之间的链路中断故障。一方面，可以在存储网关选型的时候选择从存储引擎到引擎内部各模块的冗余度都很高的产品，既可以减小存储网关层本身的单点故障风险，又可以将存储网关到主机层的链路冗余程度提高到更高的程度。另外一方面，这类存储网关的单点故障定会引起存储网关的切换，另外数据中心的存储网关必须迅速切换角色，保障数据写入没有中断，这就要求存储网关本身具备同步缓存的能力，当然具体模式可以有不同的技术方案。
如果故障发生在B点位置，那么最有可能就是FC-SAN交换机的单点故障以及存储网关到交换机接口链路的故障。同样的思路，我们希望在交换机的选择上和多链路策略上多下功夫。存储网关我们可以将其看作是针对物理存储的主机，所以它也需要能对FC-SAN链路具备很好的多链路管理功能。另外，FC-SAN交换机必须要通过冗余设备级联的方式来减小设备单点故障风险，就设备本身来讲也需要选择接口板模块具备冗余配置的型号。
如果故障发生在C点位置，那么最有可能就是存储阵列的单点故障。大多数存储阵列的冗余度都是足够的，从存储控制器节点到存储磁盘的冗余配置模式上都相对比较成熟。但是为了防止整个存储设备掉电之类的故障风险，我们可以采取以下策略来进行处理
图3 存储本地高可用架构
存储网关层本身就是处理存储读写的逻辑虚拟层，那么正常情况下它应该具备灵活的镜像组合策略以及虚拟化策略。如果我们可以通过本地加一重镜像的方式来保障本地存储故障发生整体设备故障的时候对整体容灾系统的影响最低。还有一个好处就是通过这样的架构配置，我们可以为存储设备的维修提供足够的时间窗口。
董立国 哈尔滨银行架构师
无论采用何种存储双活技术，仍需要根据应用系统属性增加必要的本地存储高可用架构。
存储双活技术原理
存储双活部署架构
存储双活是指两台存储放置两个互为备份的数据中心，存储两份数据并且两份数据都可以被读写访问，处于运行状态。当一个数据中心存储发生设备故障，甚至数据中心整体故障时，业务自动切换到另一个数据中心，解决了传统灾备业务无法自动切换的问题。提供给用户更高的数据可靠性以及业务连续性的同时，提高存储系统的资源利用率。
图4 存储双活部署图
1 脑裂 存储双活，首先要保证数据的一致性，所以在设计仲裁模式的时候，建议建立第三方站点作为仲裁站点，不具备第三站点也可使用主备仲裁方式。但也不能完全避免仲裁失败的情况，所以还要考虑强制启动，可强制启动任意一端的存储作为源端。
2 读写 存储双活的写一般都是在缓存层完成，双存储在写入缓存后，主机端即认为写完成。同时要尽量减少跨中心的读写，一般可通过主机端集群配置业务分离，增加本地读写，减少数据冲突，来提升读写性能。
3 应用层 如果只有存储双活没有应用双活，存储双活不仅没有大幅度减少RTO，同时还增加了更多的风险。所以无论是数据库还是应用程序必须为双活，存储双活才有意义。
4 故障切换 存储双活切换，并非全无感知，本地存储故障，一般会HANG一段时间，自动切换同城存储，RPO=0，RTO一般为秒级,数据库一般不会宕机；同城链路故障也会HANG一段时间，仲裁决定主站点，RPO=0，RTO一般为秒级，数据库一般不会宕机；仲裁服务器故障，对存储双活运行与同步一般无影响。
存储双活的风险
1 链路风险 根据监管要求同城应用级灾难备份中心，应与生产中心直线距离至少达到30km（如果直线距离达到30千米，一般裸光纤距离会在60千米以上 。存储双活需要充分考虑性能与稳定性，尤其是光纤链路抖动是不可避免的。可能由于链路抖动带来大面积业务阻塞， 者批量过程中出现链路抖动，导致IO失败，可能出现批量重跑 造成数据错误的情况。
2 集群风险:存储双活一般都是主备数据中心使用一套集群系统，存储的集群系统则变成了单点，集群系统的故障 BUG等将造成更为严重的后果，导致双存储全部无法使用 造成数据不一致。
3 逻辑错误与数据坏块 存储双活无法解决逻辑错误以及数据库出现的数据坏块。
4 运维风险 存储双活对运维工程师提出了更高的要求，增加了运维的复杂程度。
存储双活实践
根据以上存储双活的风险，无论采用何种存储双活技术，仍需要根据应用系统属性增加必要的本地存储高可用架构。建议为独立的主机、网络、存储以及物理区域。
图5 存储双活实践架构
容错必要性
逻辑保护 当出现存储集群故障 者数据库出现物理坏块的情况，可为数据库提供保障。读写分离 逻辑复制数据库一般都为可读状态，可以分流部分查询业务到逻辑复制库，减少主库读压力。
容错切换 生产端访问容灾端存储，性能无法满足需求，同时如果只有本应用系统切换同城，造成其他应用系统跨站点访问，延时增高，影响业务的情况下，可启用生产端逻辑复制库接管业务。
实践方案
1 针对渠道类7*24的应用系统，客户比较敏感，同时不存在大量账务数据。可采用应用数据库同城双活的架构，使用Oracle RAC Db2Purescale等，同时配置逻辑复制数据库。在应用层上通过负载配置信号灯机制，控制生产与容灾中心不同类业务模块访问的流量。通过域名 者HOSTS文件控制应用访问数据库指向。将业务按业务模块拆分，按读写方式拆分，能提升整体应用系统性能与稳定性。
图6 渠道类应用系统存储双活实践方案
2 针对核心账务类同时涉及批量工作的应用系统，并不是非常建议使用数据库双活，可使用双活存储配置跨站点的HA，实现自动切换。同时应用程序如有需要共享的数据使用高性能NAS相对比较简单，易于管理。
图7 核心账务类应用系统存储双活实践方案
总结
根据实际需求规划同城容灾架构，满足业务需求与监管要求，保证出现故障灾难，同城可在规划的RPO与RTO要求内完成切换，并且能长期承载应用系统运行，没有必要一味地追求RTO=0。
规划同城容灾架构需要多部门、多角度针对每个应用系统进行打分评级；根据应用系统特性，如账务类、渠道类、批量类等相关特性组合，制定满足需求的技术容灾方案；在根据应用系统的 入产出制定合理的容灾方案，并不是技术最先进、RPO与RTO都等于零的方案是最合理的方案。
无论是同城双活还是主备中心，都要零信任，给自己留好退路，重要关键系统的数据库逻辑复制以及备份平台都要完备。
同城容灾环境尽量配备完善的监控平台、稳定的调度平台以及周全的切换流程，保证容灾容错环境实时可用，同时出现故障减少人为操作，快速切换。
存储双活架构并不意味着万无一失，无论是同城双活还是主备中心，都要零信任，给自己留好退路，重要关键系统的数据库逻辑复制以及备份平台都要完备。欢迎更多同行在twt社区分享存储双活架构下，保稳定、除风险的实战故事。
阅读更多《迈向YB数据时代》精彩内容，请识别以下二维码
《迈向YB数据时代》
数据，作为企业最核心的战略资产，正在由于规模越来越大变成一只令人恐怖的怪兽。在人类数据应用规模即将进入YB时代的当下，如何存好、用好、管好海量数据成为大中型企业普遍面临的巨大挑战。《迈向YB数据时代》，由twt社区和华为存储用户俱乐部联合主办，凝结中国一线用户中应用创新技术专家的具有代表性、前瞻性的技术洞见、实战经验、同行共识，从趋势、架构、实施和运维四大方向，为中国大中型企业应对数据及存储管理中的重大应用挑战提供代表性的参考指南。“乘众人之智，则无不任也；用众人之力，则无不胜也。”让我们一同携手，从容迈向YB数据时代！
《迈向YB数据时代》2022年春季刊以数据容灾为主题，集二十多家从事企业科技战线的各路精英之学识经验，围绕数据容灾备份这一黄金战甲，以精益架构、集成实施、持续运维、趋势动态四个栏目展开，每个栏目又分为若干业内同行认为亟待解决的议题，每个议题中各位同行专家从不同维度充分剖析诠释，同时以朴实敦厚而又精炼有序之论给予解决思路和方法。我们在此将春季刊的内容进行连载放送，希望可以为企业同行提供容灾备份战线上的参考，更希望可以成为集结八方同道之号角。
2022年春季刊【精益架构】议题一 纯数据备份和容灾技术不再是未来主流，如何通过二者的无缝衔接来支撑业务的连续性？
2022年春季刊【精益架构】议题二 如何构建既健壮又安全的存储双活架构？
2022年春季刊【精益架构】议题三 如何正确认知双活数据中心的存储层脑裂？
2022年春季刊【精益架构】议题四 为避免脑裂，存储双活架构设计应遵循哪些思想和方法？
2022年春季刊【精益架构】议题五 如何多维度分析数据库复制与存储复制的架构差异？
2022年春季刊【集中实施】议题一 存储双活实施中如何通过第三方仲裁机制避免脑裂发生？
2022年春季刊【集中实施】议题二 存储双活的实施方案中，如何正确认识多路径软件和配置的注意事项？
*本 所发布内容仅代表作者观点，不代表社区立场
Powered by 小羊羔外链网 8.3.12
©2015 - 2024 小羊羔外链网
您的IP:3.144.187.103,2024-04-25 13:12:44,Processed in 0.05148 second(s).
