zhangjunxi570
作者zhangjunxi570·2021-07-28 17:13
系统架构师·某城商银行

城商行存储容灾方案设计及企业级高端存储产品选型实践经验

字数 6922阅读 7517评论 1赞 8

随着新兴存储技术逐渐发展成熟,承载银行业务数据的存储也变得更为多元。以往传统稳态 IT 环境中主要部署集中式存储,当前逐步向敏态 IT 模式转型,分布式存储技术被广泛采纳。金融行业 IT 环境呈现出双态共存的格局,在提高连续性水平支撑业务及运维创新发展的总体目标下,如何通过科学的产品选型和架构设计,发挥好企业级高端存储为代表的集中式存储的作用并放大其价值,成为行业需要共同思考解决的课题。

项目背景

我行同城容灾体系的现状是,采用基于 EMC VPLEX 存储网关实现的同城存储双活体系。在生产和同城两个数据中心,分别对称部署了三套 ALUA 架构双控中端阵列。其中 EMC VPLEX 和中端阵列的服役时间已经超过 6 年,更换超役设备成为我们高端存储项目立项的重要理由之一。其次,项目规划设计还要充分考虑我们行内技术架构的三大转变:第一,主机层广泛应用开放平台。主要是基于 X86 的虚拟化技术,采用小型机部署的业务只剩 5 套,存储容灾切换需要通盘考虑调度上层各类主机和应用架构;第二,行内在 A 类关键业务系统中推广应用级双活改造,应用级双活架构能够容忍一个数据中心存储的故障。其余 B 类及以下系统多为主备型业务仍需要高端存储提供同城容灾能力;第三,我行投产了对象存储用作行内非结构化数据类业务专用存储平台。从传统的块存储中剥离出非结构化数据,对象存储为这部分数据提供容灾能力。基于以上变化我行规划的企业级高端存储项目在容灾设计及产品选型中会存在与以往存储选型不同的关注点和侧重点。

我行高端存储项目规划设计是在银行业存储技术“稳态”与“敏态”并存的技术发展趋势以及行内应用架构转变、非结构化数据管理能力提升的背景下实施的。相信同业也在经历类似的技术路线演进,因此分享我行对存储容灾方案设计选型实施思路供大家参考,希望对大家有所帮助。

业务架构对数据中心容灾设计影响

在展开容灾方案的设计前,我将先从应用架构和数据中心容灾模式互相匹配的角度阐述数据中心容各层资源的容灾技术是如何支撑上层应用达到业务连续性目标的。首先,从容灾切换维度可以将应用分为以下四种架构。

主备型应用架构 是指应用程序平时只在在生产数据中心运行,在同城灾备数据中心应用程序是不活动的,但配置了承载应用程序的计算资源和操作系统,底层存储不论是通过存储双活或者存储复制,在同城灾备数据中心有实时同步的数据镜像,但不可访问,所有 IO 请求都是从生产发起的。

应用级双活架构 是指应用程序平时在两个数据中心都是活动的,都可以对外提供服务。如果基于并行文件系统,两个站点的应用访问共同的文件系统,构成的磁盘来自两个数据中心,由文件系统维护数据的镜像;更为常见的情况是,两站点的应用访问各自的文件系统,底层不是同一个 Lun ,不需要同步到对端的数据中心。

数据库容灾架构 本文主要指 Oracle ADG 、 DB2 HADR 或者其他数据库复制技术。两个站点的数据库存主从关系,通过在灾备站点传输然后应用活动日志使备库实时保持数据同步,备库通常为没有打开的状态,启用备库需要进行切换。两个站点的库在存储底层是各自的数据,原则上不需要通过存储同步到对端。数据库还可以使用一种更简单的容灾方案其模式和主备型应用架构非常相似,及数据库只在生产站点运行,在同城站点只配置了承载数据库程序的计算资源和操作系统,这种情况数据库数据的同步依赖于底层存储的数据镜像技术。

综上,基于日志的数据库复制可以归为应用级双活架构,基于存储的数据容灾可以归为主备型应用架构。本文存储容灾的设计不考虑延展的数据库集群。

分布式业务架构 是指基于 docker 或者微服务等分布式框架开发的应用程序。但分布式业务系统的具体容灾实现方案又可归类到应用级双活和主备型两种情况。

按照容灾切换情况可以将应用归类统分为两种容灾架构:一是生产中心灾难时需要进行人工干预或者由灾切平台调度完成网络、存储、数据库及应用程序切换,才能恢复业务的主备型应用架构;二是两站点的各层资源均完全解耦,平时两个数据中心都具备对外服务能力,生产中心灾难时几乎无需干预的应用级双活架构。下图是两种应用容灾架构构成的各层资源对比情况。

存储容灾模式选型

集中存储的容灾特性主要体现在三个方面。第一,支持免网关双活 A-A 架构。第二是数据同步和异步复制功能,可以与双活特性实现免网关的双活 + 异地容灾的三副本数据容灾架构。第三是快照功能。这三个方面的功能是当前采购高端存储时尽量要求满足的特性。

这里需要重点突出免网关双活 A-A 架构能力。免网关,顾名思义就是不依赖于 VPLEX 、 SVC 等存储网关设备,而直接使用存储自身的机头进行两台存储之间的 IO 双活。比如,据笔者了解,华为公司的 HyperMetro 就属于免网关解决方案的主流技术之一。

对存储容灾方案来说,城商行进行同城容灾建设时有存储双活和复制两个选项。同城存储双活是城商行级别金融单位广泛应用的存储容灾架构。我行采取的 VPLEX+ 中端阵列的模式也是同城存储双活的容灾架构。存储双活和同步复制都能达到 RPO=0 的数据不丢失的目标,生产发生灾难时,存储双活还能节省存储层切换的时间, RTO 更短。

因此,按照常规分析,同城存储双活优于复制方案。

2.1 问题一,不同的应用架构对存储容灾技术的利用情况?

存储双活和同步复制对不同业务容灾架构支持情况


从上表来看,主备型应用和数据库的容灾技术本身并不能充分发挥同城存储双活的能力。因为业务平时在生产站点活动,访问存储的请求全部由生产站点主机发起,读请求在生产存储就近完成,写请求发送到同城灾备站点的存储只是完成了数据实时同步的功能。除非进行容灾切换,否则没有从灾备站点主机直接访问灾备站点数据镜像的需求。


而应用级双活应该摆脱对存储容灾手段的依赖。 已经开发或改造成应用级双活的业务并不需要同城存储双活,因为两个站点的应用是完全隔离的,操作系统文件系统即底层的存储 Lun 都是独立的,不需要互相同步或镜像到对端。依赖并行文件系统实现应用双活,两个中心分别有计算资源并要求能够交叉访问到两个站点的存储 Lun ,但数据的冗余和管理由并行文件系统自身去实现, GPFS 负责在不同的 Failgroup 之间镜像数据,而卷原则上不需要同城存储双活。**

结论一、应用级双活架构不需要存储双活,主备型不能利用起存储双活。

2.2 问题二,对主备型业务架构是否存储双活比复制更有优势?

主备型业务配置主机交叉访问存储双活故障场景(有仲裁)

主备型业务非交叉访问同步复制存储故障场景

从上面两表的分析可以看出,对主备型应用而言,同城存储双活表现出优势的故障场景是在仅生产站点的存储故障发生时,业务无感知的情况下。但我们认为高端存储具备足够的冗余性,除非产品重大缺陷,几乎不可能发生在生产中心单独存储彻底故障而服务器网络都没有故障的可能性;对于生产站点全部灾难的场景,同城双活存储在存储层虽然没有切换但是其他资源仍需要进行切换才能恢复应用, RTO 并不会因为减少存储切换环节而显著的降低。发生多点故障,可能会导致影响更加恶劣,即使有存活存储,为保护数据一致性也不可以进行对外服务,不然业务会全面中断。

对主备型应用来说,同城存储复制方案发生生产中心存储或服务器故障的场景都与生产站点故障后果一样的,都需要先进行存储切换再进行其他资源切换才能恢复业务,总体的 RTO 较长。而两种方案对线路抖动的反应是一致的,业务都会 Hang 住。随着技术发展,复制方案的这两个弊端都已经有了相应的解决方案。第一种解决方案主要是针对缩短切换 RTO 要求,可以利用灾切平台提前编排好预案,联动的完成存储和上层各类的切换。第二种方案是对于已经有存储厂商开发出同步复制在发生线路质量变差的后自动或通过人工干预降为异步复制的技术。而在这一方面同城双活存储面对线路抖动束手无策,使得线路质量劣化成为大概率会发生的事件。

结论二,主备型业务架构,存储双活 RTO 略好,受业务切换时间限制,但多点故障可能导致极端过度保护。存储复制 RTO 较长但可以降到可接受范围。

2.3 问题三,哪些上层技术能充分利用存储双活及效果分析

只有延展的上层应用可以利用同城存储双活的功能,主要代表是跨站点的数据库双活集群和延展的虚拟化集群。

跨站点的数据库双活集群例如跨站点的 Oracle RAC 集群在实际落地时对两数据中心之间的线路质量有严苛的要求,任何抖动都会传导到上层服务且时延被放大从而导致干扰 RAC 服务,事实上延展的数据库集群应用案例并没有 OracleADG 普遍。成熟稳定是金融行业业务连续性建设的首要衡量指标,因此跨站点双活数据库容灾没能成为主流的选择。

基于同城存储双活提供的在两个数据中心并发访问的卷,虚拟化集群跨站点部署组成延展的集群(以往主流的容灾方案是网络大二层 + 延展的虚拟化集群),但是如果业务是主备型的,平时只运行在生产站点服务器上,同城数据中心即使计算资源和存储资源都是可用的而没有业务运行其上,生产站点发生灾难时可以通过 VMware HA 技术保护生产运行的虚机。此方案优势是实施便捷改造少,缺点是通过 VMwareHA 恢复的虚机启动是乱序的很难根据业务关联性进行编排。构建此方案所需的大二层网络或者 VXLAN 技术,增加网络维护的复杂度。

结论三,真正能够发挥同城存储双活能力的上层应用实现起来限制较多,或对主备型应用架构 RTO 优化有限,增加网络复杂度。

问题四,同城存储双活潜在的风险

为了应对脑裂风险,同城存储双活需要在第三点部署仲裁,三个站点形成一个绑定在一起的三角形。我们认为运营商线路是不可控的因素,而两个站点之间以及到仲裁都是运行在运营商的线路上。最大风险在于当脑裂发生时,可能会出现由于过度保护而导致两个站点的存储都不能对外提供服务而严重影响业务。相比较而言,同步复制量数据中心相对独立,故障场景简单清晰。

结论四,同步复制因使两个中心解耦,更安全。

综上,我行认为同城存储双活的优势有限,存在着客观风险,因此存储双活应被视为站内高可用技术。而同城存储复制方案虽然牺牲了一定的 RTO ,但它最大的优势在于使得两个数据中心彻底解耦,可以彻底摆脱运营商线路质量等不可控的因素。

产品选型分析

产品选型部分将从我行接触的三个主流厂商的产品和技术进行对比,分别是 E 厂商的 PowerMax 2000 、华为高端全闪存 OceanStor Dorado 18500 V6 以及 Hi 厂商的 VSP 5000 。我们主要从单阵列的可靠性、数据管理、容灾实现能力等几个关键能力方面进行比较。我们考察的产品定位都是配置 NVME 介质的产品。我行产品的选型分析仅仅是结合我行业务需求与关注重点的选择,如果存在偏颇的地方还请各位同业专家批评指正。

EMC

EMC PowerMax 2000 是典型的横向扩展的虚拟矩阵架构。 PowerMax 2000 最大支持两个引擎,通过 Infiniband 交换机互联。后端使用 Gen3 PCIe 协议连接硬盘扩展柜。不能异构其他阵列。

就单阵列的可靠性方面来说, EMC 的产品与另外两个厂商相比的劣势在于引擎之间不共享后端硬盘扩展柜,存在单个引擎故障而存活的引擎连接不到归属于故障引擎的扩展柜的风险。但是引擎可靠性已达到 6 个 9 ,几乎不会发生这种故障。

在重删压缩技术方面,产品配置了硬件的重删压缩卡,执行重删压缩不消耗控制器 CPU ,因此开启重删压缩对性能影响较小。该产品承诺 4:1 的数据压缩比。三个产品中只有该产品配置了硬件的重删压缩卡。

容灾方案方面来说, EMC 支持 SRDF Metro 存储双活或 SRDF S/A 复制。但不支持双活 + 同步复制的技术方案,主要的考虑是维护三份实时镜像的数据可能会放大延迟并受线路质量影响。这种方案较为保守但稳定成熟。双活方案支持双仲裁,避免单一仲裁不可用风险。复制方案同城站点的数据时刻读状态。

Hi

Hi VSP5000 系列的产品也是一款横向扩展架构的企业级存储产品。支持异构其他阵列,全系运行一套系统支持高端向中低端产品容灾节约灾备端投入。

就硬件可靠性来说,该厂商承诺 8 个 9 系统可靠性。后端扩展柜和各种板卡在控制器之间都共享而且冗余连接。全局缓存在控制器之间进行统一编址管理。该产品硬件可靠性设计较为完善。

重删压缩技术方面,该产品需要消耗控制器资源。

容灾方案而言,构成双活的两个镜像会区分主从角色,而另外两厂商的产品支持全对等的双活,比较起来较为不足。

华为

华为高端全闪存 OceanStor Dorado 18500V6 区别于另外两个厂商,是一控制框满配四个控制器形态,内部使用无源背板而不是用交换机将四个控制器互联在一起,前后端的接口卡及后端的扩展柜在四个控制器之间共享。使用 100Gb RDMA 协议连接扩展框。处理器基于 ARM 架构开发。支持异构其他存储,可纳管中低端存储为其实现容灾保护现有投入。

硬件可靠性


1) 每张前端接口卡通过 4 个 PCIE 3.0X4 端口连接到 4 个控制器,支持 Multihost 技术,能够以 active-active 方式同时访 问 4 个控制器。任一控制器故障物理链路不中断。主机层面无感知。

2) 缓存三倍镜像及持续镜像。单引擎四控支持“四坏三”,三个控制器的故障不能同时发生,“四坏三”需满足控制器依次发生故障并有时间间隔。

3) RAID-TP 支持三块盘同时故障。

重删压缩方面

支持 2.6 : 1 的压缩比,需使用控制器处理资源。

容灾方案方面:

1) 双活方案支持双仲裁。

2) 支持在线同步复制转异步复制,监控带宽和时延,跟原先配置的门槛触发同步转异步,可以规避链路抖动对业务影响。减少人为干预不及时导致的业务中断。

3) 支持双活 + 同步复制容灾架构。

4) 支持 NAS 双活。

以上三个产品均为存储产品线里最高端的产品,因此冗余度,配置丰富性即数据管理能力都非常优异。我行选型主要考虑华为和 E 是权对等的双活,脑裂发生后决策出存活站点较快, IO 暂停的时间短(当然三家产品 IO 暂停的时间均在 linux 操作系统 IO 超时时间范围内均满足需要)。综合考虑之下,选择了性能更为优异、与我行需求更匹配的华为高端全闪存 OceanStor Dorado 18500V6 。

建设规划


最终我行形成了同城“ 2+1 ”的存储容灾架构,即生产中心部署两台存储组成同中心的存储双活,提高生产中心站内的高可用,同城中心部署一台存储与生产形成同步复制。

架构说明

我行计划建成同城“ 2+1 ”存储容灾架构,生产数据中心两台存储 A 和 B 组成本地双活架构,在同一个机房内部署存储双活,提高生产中心存储可靠性,可以有效规避同城双活运营商线路质量问题的影响。

从生产的 A 到同城的 C 配置是同步复制,但预先设置好同步转异步的检查条件,如果延迟等参数触发转换的门槛,可以不经人工干预转为异步复制,最大限度保障生产业务的可用性,降低维护三分镜像的开销。

从生产的 B 到异地的 D 配置成异步复制,满足异地有一份保留一份数据要求。

业务摆放

华为高端全闪存 OceanStor Dorado 18500V6 主要承载行内 A 类关键业务系统。其中已经改造成应用级双活的系统,生产站点的应用通过存储双活保持两份实时镜像的数据,任一台存储故障或进行升级维护,生产存储服务不中断,保障业务系统连续性。同城站点的应用在同城存储保留一份数据镜像。

主备型应用在生产数据中心配置两份双活镜像数据,生产存储 A 到同城存储 C 配置同步复制,利用灾备切换平台预先编排存储切换及上层应用切换,生产中心灾难发生时用灾备切换平台联动的调用存储和应用的切换。一旦生产存储A故障,生产存储B接替A和同城存储C形成复制关系。

总结

华为高端存储项目的实施构建了本地双活 + 同步复制的同城容灾体系,是我行落实提升存储基础架构的关键举措。主要价值体现在:

一、 在生产机房采用免网关 SAN 和 NAS 一体化双活,优先保障生产数据中心的业务连续性,嵌入了我行关键业务向应用级双活架构发展的规划,华为存储的多仲裁方案进一步消除了过去单一仲裁不可用的风险;

二、 同城两数据中心间使用同步复制方案,使两个数据中心在存储架构上进一步解耦,华为特有的同步转异步的技术提高了对传输线路质量的容忍能力,行方须接受维护三个同步镜像的开销;

三、 本次采购的华为存储均配置 NVME 闪存介质,性能优异,可显著提高我行重要交易系统和经营分析类数据库的性能表现,缩短批量时间,提升客户体验。

四、华为存储开放运维接口,兼容目前行内已有的灾备切换平台,预先编排同城存储和应用联动的切换,简化切换操作降低 RTO 时间。

相信华为高端存储项目为我行构建的本地双活 + 同步复制的同城容灾体系一定会为我行金融业务的飞速发展提供重要支持,发挥重要作用!

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

8

添加新评论1 条评论

ny_zhhfny_zhhf软件开发工程师zhang
2021-10-29 11:56
请问下用的什么灾备切换平台?华为存储也可以支持命令行吗?
Ctrl+Enter 发表

本文隶属于专栏

最佳实践
不同的领域,都有先行者,实践者,用他们的最佳实践来加速更多企业的建设项目落地。

作者其他文章

相关文章

相关问题

相关资料

X社区推广