银行互联网金融平台存储层:技术路线选型与架构设计难点详解

Posted twt企业IT社区

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了银行互联网金融平台存储层:技术路线选型与架构设计难点详解相关的知识,希望对你有一定的参考价值。

互联网金融的实现最终看的是IT能力,这是构建金融平台的基础,其中作为最基础的存储层的支持能力是决定农信系统互联网金融能否实现的“木桶短板”,其包括存储技术路线选型和架构设计。
实际生产过程中发现,传统的集中存储处在互联网应用压力下,热点资源,空间分配等冲突严重,另外,海量非结构化数据的快速增长,都对存储提出了满足广泛的性能、持久性、可用性、扩展性和多站点的要求。 在选型和架构设计过程中,如何平衡“开放”、“集中”和“成本”之间的关系,如何确保存储系统的稳定持续和敏态服务是最大的难点。

近日,twt社区组织了关于“农商行/农信社互联网金融平台存储层技术路线选型与架构设计探讨”在线交流活动,在本次活动中,大家踊跃参与,专家认真解答,分享了很多有价值的内容,现总结如下,供广大同行参考。


一、分布式与集中式存储方面


Q1:如何有效评估互联网金融平台采用集中式存储或分布式存储技术路线?

@wybbc HN农信 系统工程师:

IT架构向分布式转型应该是未来的趋势,面对未来海量数据存储需求和应对互联网不可预知的流量要求,容量和性能的扩展能力是一个很重要的因素,估计以后选择分布式存储会越来越多。最终的应用还是要看场景,大数据类的、非结构化的估计会更偏向分布式存储。

@Marvin_Ma 戴尔科技金融行业解决方案中心 售前系统工程师:

农信金融互联网平台的存储选型,一方面取决于上层应用架构、数据库的技术路线,如是选择 Microsoft SQL server ,亦或是 mysql 集群还是 Redis 分布式数据库都有不同的存储选型方向。而上层应用架构的选型则取决于业务的规模预期和访问特点等。另一方面取决于对于存储层性能如 IOPS 相应时间等指标的要求,可对照相应数据库的相关指标量级如 TPS ,处于何种级别,可以预期到规模等。


Q2:分布式储存还是集中式存储选型?

【问题描述】现代化的云原生环境已经去了集中式存储,用了软件定义的分布式。不同paas层有独立的资源池。眼下银行分布式存储和集中式存储的应用场景如何选?互联网金融平台的存储选型是集中式合适还是分布式合适?

@wybbc HN农信 系统工程师:

不管集中式存储还是分布式存储,都逃不脱CAP理论的限制,剩下的就看具体的使用场景更注重哪方面了。对于银行来说,还是成熟稳定最重要。有技术能力的,可以在新技术上多折腾下。

@wzpystcdc 某公司 研发工程师:

分布式存储和集中式存储的区别还是很直观的,如果数据增长容量较大,选择分布式存储相对更安全、高效,小数据对I/O有要求,可根据自身需求选择哪种更符合企业发展。

@Marvin_Ma 戴尔科技金融行业解决方案中心 售前系统工程师:

集中式存储和分布式存储各有利弊,如传统集中存储具有稳定可靠性好,数据服务丰富如有良好的数据一致性存储容灾解决方案,接口标准兼容性广泛,性能强等优点。同时存在着扩展性等方面的限制。分布式架构的存储,扩展集群规模大,硬件成本低廉,同时也存在着单节点性能低,延时高 , 数据弱一致性,标准不统一且非常依赖网络环境和带宽,如果网络发生抖动或者故障,都可能会影响分布式存储系统运行。

但是随着技术的发展集中存储目前处于第五代存储阶段,存储性能提升到了非常高的水平。依托于存储的高性能,采用有效容量优化存储使用方式。同时在扩展性上主流品牌产品均支持横向集群扩展以应对单一的大规模应用场景;如 DellEMC 的第五代存储旗舰产品 PowerStore 通过单独的数据缩减处理模块实现性能无损的重删压缩,并且可以实现横向集群扩展,以及纵向的升级。支持容器化以及DevOps,支持多种插件程序,包括 VMware 插件程序 (vRO 插件 ) 、 Kubernetes 插件程序 (CSI Driver) 和 Ansible 插件程序 (Ansible Module) 。可以很好的对接云原生的环境。两种技术都在不断发展提升之中,需要从多个角度去评判存储选型的方向。银行的核心诉求还是稳定可靠。


Q3:目前环境是使用某品牌的传统集中存储,如果需要更换存储平台,现有多路径软件更换问题?

@邓毓 江西农信 系统工程师:

再装一套新的多路径,识别新的存储,等传统集中存储数据全部迁移完后,把盘删了,多路径也删了。这也不是个难点,逐步过渡嘛。

@Marvin_Ma 戴尔科技金融行业解决方案中心 售前系统工程师:

一般主流的存储厂家都有对应自研发的多路径软件,建议更换存储平台后,可咨询并重新装对应存储平台厂家建议的多路径软件,这样兼容性会更好,在故障路径切换的该场景下也表现更佳。


Q4:从扩展性和高可用角度来看,怎样去选择集中存储和分布式存储?

@邓毓 江西农信 系统工程师:

从这两个角度,集中式存储的上限较分布式存储低了,一是扩展性存在瓶颈,纵向扩展空间有限。二是高可用性方面,集中式存储自身的备件冗余方面还是很不错的,但数据的副本冗余上较分布式而言,还是存在一定的限制。

@Marvin_Ma 戴尔科技金融行业解决方案中心 售前系统工程师:

扩展性角度,从设计的出发或者简单从名字就可以了解,分布式存储的扩展性是优于集中存储的。随着技术的发展集中式存储也具备了横向集群的扩展性以及纵向的升级特性,以满足单一应用的大规模集群。但是扩展性的探讨要涉及到考验对自己业务的科学评测,到底是需要多大的规模的扩展性,比如对应到今天的讨论的农信的互联网金融平台,需要存储平台扩展性到多少,是否需要理论上的无限扩展能力。从某华东省联社互联网金融平台核心存储的案例来看,集中存储的扩展性是足以支撑业务平台长期发展的。 

高可用性角度, 集中存储整体解决方案构建的高可用架构比如存储双活,两台设备同时可读可写,任意一台故障,业务无影响不中断; 分布式存储一般采用多副本或纠删码方式实现,实现集群的可用性。小规模集群下,一般也会有一些限制比如就允许坏一个节点,但是目前的全闪存的集中存储的坏盘率是远低于分布式存储通常采用的机械盘,小规模下集中存储的数据服务更丰富。因此还是需要因地制宜,根据集群规模和容量需求去设计考量。


Q5:分布式存储落地如何实践?分布式存储如何选型和测试?稳定性测试如何实践?

@邓毓 江西农信 系统工程师:

前期先进行技术方案沟通,然后制定POC测试方案,挑选几家进行POC测试,测试内容包括:性能测试、可靠性测试、功能测试、业务测试等等,再汇总测试结果进行详细对比,附加上厂商资质、案例、团队、服务支持等方面的对比,综合评比一下后选择最合适的产品。

@Marvin_Ma 戴尔科技金融行业解决方案中心 售前系统工程师:

分布式存储分类较多,简单来说分为分布式 SAN (如 DELLEMC 的 Powerflex 前身是 ScaleIO 、 VAN 等),分布式 NAS 集群(如 DELLEMC 的 Isilon ),分布式对象存储(如 DELLEMC ECS )。

分布式SAN,一般适用于读写密集型的场景(分析性数据库,关系型数据库),对于性能和集群扩展性有一定要求的场景,可以先小规模部署,后续扩展实现线性增长。

分布式NAS,主要存储非结构化数据如图片、日志或者Hadoop的存储节点等,性能较好,可以小规模起步,后续线性扩展分布式对象,相对于 NAS 场景更为丰富,单TB成本也较有优势。既可像NAS一样实现文件的共享,也会在海量文件处理场景更有优势。

对象存储构建往往可以适配到多个应用场景构建数据湖。如影像平台长期归档数据,备份数据的长期归档,交互数据如邮件存储,云原生应用数据存储,大数据分析数据存储、开发镜像等数据可以统一存放,对不同用户设置访问权限。在多应用的场景下,对象存储在部署后容量的使用增速一般会比较快,因此一般对象存储建议起步容量较大一般在400TB 以上。


二、对象存储方面


Q1:海量文件的迁移方案?

【问题描述】在存储迁移中,有种典型的场景就是海量小文件的迁移,这块有什么较好的不占用太多停机窗口的数据迁移方案?

@邓毓 江西农信 系统工程师:

刚好我们在做这一块,也迁移得差不多了,这里我简单说一下,之前我们的影像系统存在海量图片文件,存储在集中式SAN存储中,按照在线、近线和离线三种方式存储,数据量越来越大,严重影响存取效率,存储架构层次多、过于复杂,难以管理,我们采取的改造方案是,通过增加影像应用存取接口,逐步读取集中式存储中的影像数据来迁移至对象存储中,各渠道应用调用影像系统的接口不变,但影像系统的处理逻辑进行改造,增加了判断,全新的影像文件直接落至对象存储,旧的未迁移的影像文件读取依旧从集中式存储中读取,新的和迁移后影像文件读取则变为对象存储,待旧的文件全部迁移完成后,将原有的集中式存储读取接口关闭,最终实现数据迁移。

@wybbc HN农信 系统工程师:

应该很多厂商提供专业的迁移工具和迁移服务吧。如果前期有比较合理的存储专用网络设计,带宽容量较大,还是比较快的,未必都需要停机窗口。我们几十T的nas小文件同步也经常做。真正很海量的小文件,都是不是OLTP系统,停机窗口应该也还是有的。

@Marvin_Ma 戴尔科技金融行业解决方案中心 售前系统工程师:

从原阵列迁移到对象存储平台,一般数据量比较巨大,举一个平台数据迁移的例子。迁移主要涉及几个方面:

1、接口的改造,应用软件若不支持 S 3接口要先进行接口改造,客户可以自行改造或者同应用厂家合作,比如对接的是 DELL 的 ECS ,DELL可以提供接口的代码样例,目前DELLEMC的ECS已经同信雅达等主流厂家做过接口的适配联调以及兼容应验证等工作。

2、如果原应用已经支持目标接口协议如S3,可直接从应用层面做迁移,应用厂家会有相应的方案。

3、也可依托存储厂家从底层做数据迁移存储厂家有对应的迁移方法和工具。部分用户会采用逐步迁移的方式,原有数据存放方式维持不变慢慢迁移至对象,新业务数据直接写入至对象存储的方式来进行存放。

@陈炼 某科技有限公司 存储工程师:

1、 目前针对文件系统迁移都没有很好的解决方案,各厂家提供集成OS迁移命令封装形式的工具;实现在线迁移方式;

2、采用多次增量同步,减少最后一次停机窗口。


Q2:通过内容管理平台统一对接对象存储的必要性有多高?

【问题描述】使用对象存储解决海量非结构化数据的管理问题时,在对象存储之上再加一层内容管理平台,众多应用系统通过内容管理平台统一对接对象存储的必要性有多高?

@邓毓 江西农信 系统工程师:

有必要,统一管理、统一接口,屏蔽底层对象存储接口,渠道应用和内容管理平台接口对接,进行服务调用,而不是直接各自调用对象存储接口。

@wybbc HN农信 系统工程师:

内容管理平台与底层的存储充当的角色不一样。内容管理平台是介于用户/系统与存储的中间层,屏蔽底层环境差异,提供真正的、可直接使用的内容管理服务,这个必要性还是很大的。

@Marvin_Ma 戴尔科技金融行业解决方案中心 售前系统工程师:

内容管理平台接口改造后可统一存放至对象平台。目前内容管理平台基本都是挂载一个NAS,但是很多客户用着用着都会遇到这样那样的问题。如数据量越来越大,产生海量文件如何存的问题,尤其是海量小文件。对象存储管理相对 NAS 较简单,对于海量小文件的处理更好。如现有的内容管理平台数据量增长比较快,且有备份,冷数据归档,开发数据存放等场景综合存放规划的考虑,对象还是有必要的,毕竟当数据量达到一定规模后文件的目录结构会比较复杂,性能也会变差,后续迁移的成本和难度都会增加。不如一次性规划完整。从可用性和多站点容灾(双活等)的需求话,对象存储也会更为合适。


Q3:对象存储技术的平稳推进?

【问题描述】可以说互联网业务的快速发展带来了越来越多的非结构化数据,很显然对象存储比较适合这种海量非结构数据的存储。传统的银行大多采用块和文件存储,那么怎样平稳快速的进行对象存储技术的落地呢?在对象存储落地场景这块,同业是否大多采用了基于对象存储自身的两地三中心高可用架构?

@wybbc HN农信 系统工程师:

现在银行的非结构化文件也比较多,特别是互联网线上化业务,以及集中作业系统上线后,大量的客户照片、录音、视频、票据影像、客户资料都是非机构化的。一般选择产品是最好还是要求其支持两地三中心,或多中心部署。

@邓毓 江西农信 系统工程师:

当痛点痛到一定程度时,才会想办法去改变,数据量还不够大时,业务需求和性能需求还没触及时,块和文件存储可以应对,当触及了痛点无法承受时,对象存储技术就能很快进入推进期,这期间一个很大的难点问题就是如何迁移历史数据的问题,目前一般是对应用逻辑进行改造,例如通过增加应用存取接口,逐步读取块或文件存储中的数据来迁移至对象存储中,各渠道应用调用系统的接口不变,但系统的处理逻辑进行改造,增加了判断,全新的文件直接落至对象存储,旧的未迁移的文件读取依旧从块或文件存储中读取,新的和迁移后文件读取则变为对象存储,待旧的文件全部迁移完成后,将原有的块或文件存储读取接口关闭,最终实现数据迁移。能从一开始就使用两地三中心的对象存储架构固然好,但通常一般是在生产数据中心部署对象存储,试试水,后面发现对象存储越来越重要后,再考虑补充容灾的方案。

@Marvin_Ma 戴尔科技金融行业解决方案中心 售前系统工程师:

对象存储使用的范围比较广泛, Web 应用程序,内容和媒体服务如影像数据长期存放,批处理, PASS 平台存储,容错和高可用性,大规模处理和超大数据集,文件同步 , 日志分析,海量小文件,数据备份,冷数据归档等场景均可使用。关键是要规划好场景,单一场景小容量规模下优势较小且性能反而不如 NAS 或统一存储。多场景构建数据资源池,数据体量到达一定规模,优势会比较明显。


三、互联网金融平台存储需求方面


Q1:互联网金融平台存储层技术选型和架构设计的突出难点问题有哪些,如何妥善解决?

@Marvin_Ma 戴尔科技金融行业解决方案中心 售前系统工程师:

互联网金融平台对于存储的要求主要体现在高可用、可扩展性、安全性、高性能这几个方面,技术选型也是以此作为出发点和依据,架构选型中主要问题:

1. 如何构建满足监管要求的数据安全性架构, 需要充分参考银监会人行的业务连续性指引的相关要求,例如在等保 2.0 数据备份相关要求:| 二级 | 本地备份与恢复+异地定时备份 | | 三级 | 本地备份与恢复+异地数据实时备份+本地业务高可用 | | 四级 | 本地备份与恢复+异地数据实时备份+本地业务高可用+异地业务高可用 | 可以通过存储厂家架构方案建议构建,或在现有存储选型基础上构建满足相关安全性要求存储架构。

2. 如何兼顾高性能和TCO ;目前存储发展到第五代存储阶段, NVMe 接口 SSD 磁盘 + SCM (存储级内存)使用下,存储性能和响应时间可以得到很好的保障,同时通过第五代存储的有效容量的使用方式,降低TCO ,拥有更优的存储使用方式。

3. 如何实现架构的高可用一般可采用数据库容灾高可用同存储高可用相结合的方式实现。对于农信互联网金融平台,在存储底层可采用闪存阵列 + 存储网关的方式构建存储高可用架构。

4. 基础设施的监控运维优化,从技术发展的角度看,越来越多的客户倾向于选择开源路线构建数据中心监控系统,如 Zabbix 或 promethus ,这些技术路线,直观简单,易于上手,在设备监控尤其存储性能监控可以做到多维度监控。


Q2:互金的存储需求和传统应用有什么不同?主要是性能压力更大?需要更方便的扩容和维护?支持更丰富的接入方式?

@陈炼 某科技有限公司 存储工程师:

可以从以下四个方面考虑:1、规划,收集周边信息,基于业务最佳实践,快速输出满足应用诉求的服务模型;2、建设,自动化完成各服务等级存储资源分配、调度、映射和挂载;3、运维, 围绕问题实现快速根因分析、故障点定位及修复方案推荐,基于预制策略自动化完成故障隔离或者故障修复 4、优化, 面对业务负载带来的性能和容量诉求,通过QoS调整、数据流动和扩缩容来快速满足业务要求,同时确保业务不中断

@Marvin_Ma 戴尔科技金融行业解决方案中心 售前系统工程师:

互联网金融平台业务模式和传统柜面发生了很大变化, 就个人理解,农信传统核心系统主要服务于柜面渠道和存贷款业务,对于存储的可靠性和可用性要求较高;农信互联网金融平台定位于面向互联网渠道,突破实体介质和地域时空限制,可提供账户、支付、资产、负债、生活缴费、电商、社区等金融和非金融功能一体化服务。特点是:服务渠道共享、线上线下协同、服务场景和流程创新等。结合互联网金融对于底层存储要求要体现几个方面:要求具有高可用、可扩展性、安全性、高性能,相较传统系统,对于性能和扩展性有更高要求,同时要具备同云原生的对接能力,更丰富的接口。


Q3:互联网金融平台对于非结构化数据存储如何考虑?采用对象存储还是其他方式?

@wybbc HN农信 系统工程师:

传统NAS是不能满足需求的,对象存储是个很好的推荐。

@邓毓 江西农信 系统工程师:

对象存储一步到位,目前非结构化数据存储的主流方案。

@Marvin_Ma 戴尔科技金融行业解决方案中心 售前系统工程师:

主要是考虑农信社互金平台的规模以及数据量,以及未来5年的发展规模预期。规模较小的话可直接使用统一存储中的 NAS 功能/NAS阵列。目前用户规模较大的情况,或者可预期的规模较大增长,可把这些非结构化作为对象存储的数据湖的一个使用场景来进行存储。


Q4:互联网金融平台和集中存储环境下两地三中心如何实现?

【问题描述】互联网金融平台比如openstack云平台和集中存储如san如nas对接后,两地三中心部署和传统环境相比有什么变化,带来哪些新的挑战?

@Marvin_Ma 戴尔科技金融行业解决方案中心 售前系统工程师:

两地三中心可采用如下架构:

银行互联网金融平台存储层:技术路线选型与架构设计难点详解

在生产中心机房,通过存储虚拟化网关, 在两台闪存阵列之间构建分布式共享卷,实现存储高可用,两台设备均可读可写。基于存储网关构建的存储数据资源池内,存储数据可实现自由在线流动。在灾备机房部署一套存储阵列以及主机环境,通过存储底层数据复制技术实现同城容灾复制架构。在生产机房通过备份专有设备构建统一集中备份平台,在灾备中心同样部署一台备份专有设备,两台备份设备通过数据复制,实现备份数据的容灾。

@wybbc HN农信 系统工程师:

互联网金融一般多采用分布式架构,采用多副本技术实现容灾,向双活、多活发展。上层接入还是GSLB方案吧。

@邓毓 江西农信 系统工程师:

底层存储数据层,由于采用了集中式存储,那就还是传统的那套块存储同步和异步复制方案。2、数据库层,两种方案,一种是传统方案,HA高可用或RAC(ORACLE)方案+数据库复制方案;另一种是分布式数据库方案,数据库节点多活+数据库复制方案。3、应用层,分布式部署,负载均衡的方式,多个数据中心独立部署的方案。4、WEB层,类似于应用层, 多个数据中心独立部署的方案。5、上层流量引流,通过全局负载均衡进行流量调度,分发到不同的数据中心。


Q5:银行未来存储架构设计规划时,如何把控未来趋势?

【问题描述】1、国产化是趋势,国产化将可能改变技术的变革,在银行存储架构长远设计时,是否要考虑国产化的影响,否则,将可能是方向性错误?这个同行不知道是如何考虑这个问题?2、我们银行也在准备有区块链的课题,问下区块链技术是否可以解决同城灾备建没?区块链分布多副本存储,是否在设计时,同步考虑数据异地存储的灾备体系方案。

@Marvin_Ma 戴尔科技金融行业解决方案中心 售前系统工程师:

从 Gartner2020 的存储魔力象限报告来看, 2020 年的存储行业还是以 NVme 闪存介质为主要的销售卖点的闪存阵列作为主角。客户持续关注 AIOPS ,存储即服务。IT 主管关注的是如何通过存储的选择更好的完成数字化转型。

Gartner 给出一组数据预测

银行互联网金融平台存储层:技术路线选型与架构设计难点详解

由此可以预料到,未来更多客户存储选择更多倾向端到端的 NVMe 的路线,搭建数据中心的基础设施;未来的银行存储规划,更多是从业务发展角度出发,以业务发展为驱动力,数据中心的现代化为基石,驱动金融业银行业数字化转型。我们认为金融业数字化转型最终的目标是发现数据价值、挖掘数据价值、实现数据价值。围绕数据价值,我们建议金融企业重点关注 4 个方面的内容:基础设施、法规与监管、应用与数据、生产效率。具体可以参考DELL科技集团的金融业数字化转型的四大解决方案:IT 转型、应用转型、安全转型、和生产力转型。目前无论是存储层面的同城灾备建设方案,还是数据库应用层面结合的容灾方案,都有成熟的方案和广泛的使用案例。而区块链在存储领域尤其在边缘节点数据存储方面有很多优势和使用方式。

原题:农商行/农信社互联网金融平台存储层技术路线选型与架构设计探讨”在线交流活动总结

点击文末阅读原文,可以到原文下留言交流

觉得本文有用,请转发、点赞或点击“在看”,让更多同行看到


 资料/文章推荐:



下载 twt 社区客户端 APP

银行互联网金融平台存储层:技术路线选型与架构设计难点详解

或到应用商店搜索“twt”


以上是关于银行互联网金融平台存储层:技术路线选型与架构设计难点详解的主要内容,如果未能解决你的问题,请参考以下文章

金融企业云管平台架构设计及难点探讨

银行大数据平台架构设计及应用 | 周末送资料

解密支付平台建设资金底线防火墙的杀手级设计方案

银行云管平台有哪些架构设计难点和运维要点?

核心系统选型中小银行核心系统架构设计如何解决去耦和扩展性难题?

大数据中台架构以及建设全流程一(Paas层设计)