文章摘要：

某银行结合自身影像数据增长、监管和信创需求，通过区分生命周期基于分布式存储架构实现长期数据保存，分享了该场景下成功的选型经验，选型评估维度包括业务涉及的文件大小以及读写IO比例、故障应急响应速度、分布式存储灾备能力等等，以确保选型符合实际需求并具备一定的前瞻性。

一、项目背景和需求分析

1、当前的问题

随着我行大数据以及业无纸化业务的发展，信息系统逐步拆分细化，我们发现传统NAS存储以及光盘塔的容量和存储方案以及不能满足数据备份归档、影像文件和日志文件、数据库高并发备份的需求。例如，现有共享存储设备的功能和性能存在一定局限性，一是单租户最大吞吐量为2Gb/s，日常使用率已达到1.3Gb/s，二是例如该设备底层设定的存储快照的最大个数为4096个，随着接入系统与文件目录的数量增加，目前快照个数已经无法满足使用需求。另外，考虑到该存储设备已经使用了超过5年，设备制造商即将对该型号产品结束生命周期，后续将不再提供官方的扩容支持。我行综合考虑认为继续进行扩容的投资意义较小，性价比较低。因此，我行亟待引入新一代的共享存储产品解决以上需求和问题。

2、业务场景特征

目前我行使用共享存储设备的主要业务场景是各个前端业务系统对产生的相关非结构化数据进行归档，用于日志大数据分析、历史数据查询、业务凭证存储等业务场景。从三个指标分析现有需求：第一是需要留存的影像文件大小150KB左右，每天前端系统产生总量约150G影像；第二是目录层级低于10级，文件存储的路径比较复杂，执行IO时对性能资源消耗更多，同时一个业务系统挂载多个共享文件系统，每个共享文件系统大约提供10TB可用容量；第三是各个业务系统还需要归档留存应用交易日志，日志文件大小几百MB不等，每日的日志总量大小约110G，约300个压缩日志文件。综合考虑以上业务需求特征，我行的共享存储面对的场景相对复杂，从零碎文件类型到大容量文件均有存储需求，同时目录层级较深，所需的运行处理性能较高。随着影像系统改造、日志易等系统使用S3协议的业务场景越来越多，规划和部署支持S3协议的分布式存储也势在必行。

3、满足数据增长及监管需求

为了满足我行未来业务增长所需日志和影像存储空间，同时满足监管对相关数据的保留周期需求，并且随着数据容量持续增长，需要存储设备具有极优的平滑扩容能力，提供高性能的文件访问能力。

弹性的分布式存储集群，具有高扩展性、高性能、高可用、操作简单、成本低廉等优点，是解决上述问题的一个可选方案，分布式存储具有性能和容量线性扩展能力，消除系统瓶颈，单一命名空间可管理文件量数百倍于传统存储，扩容时可以实现随节点数增加而达到性能接近线性增加，扩容过程中也能让上层业务无感知 。

4、技术路线选择

经分析研究目前市场上的主流存储产品，有以下三类产品可以满足我行的需求场景：分布式存储、集中式nas、蓝光光盘塔。从适用场景、产品优势等方面考虑，我行最终选择了分布式存储加蓝光光盘塔的组合方式满足业务需求。

二、产品方案选型思路

我行选择的分布式存储加蓝光光盘塔的组合方案中，因为蓝光光盘塔产品成熟度和集成度较高，选型难度不高，因此在本文中不再赘述。而各个厂商的分布式存储产品不管是从产品定位、产品架构、还是成熟度、可用性方面都有着比较大的差异，因此我行从软硬件部署架构的角度出发，梳理对比了两种方案不同维度的优劣势。

三、 POC测试

A公司
分布式存储为软硬一体。支持信创设备。
完全自主研发，元数据管理为分布式，集群规模增大，不会出现短板，读性能排第三，写性能最好，数据是追加写入，写性能是第二名D公司的1.5倍，符合我行使用场景，读少写多。无块设备功能，无双活功能,nfs快照个数约10w个。重构1TB数据耗时约15分钟。

B公司
分布式存储为软硬一体，不支持信创设备。
基于gpfs更改，元数据管理为分布式，集群节点规模大之后，瓶颈在于元数据更新，每个节点元数据都需要更新，每个节点都能提供读写元数据服务，集群节点数小于30节点，读性能排第二，写性能排第三。无块设备功能，无双活功能，满足功能及性能需求。快照个数约20w个，重构1TB数据耗时约15分钟。

C公司
分布式存储为纯软，支持信创设备。
基于ceph更改，元数据管理为分布式，集群规模增大，不会出现短板，有块设备功能，无双活功能。满足功能需求，nfs读、写、混合读写性能低于A/B/D公司，nfs快照个数约12w个。重构1TB数据耗时约13分钟。

D公司
分布式存储为纯软，支持信创设备。
基于ceph更改，元数据管理是集中式。集群规模扩大之后，瓶颈在于元数据主节点，一个集群只能只有一个元数据节点提供服务，其他元数据节点是standby模式，读性能排第一，写性能排第二，有块设备功能，有双活功能，nfs快照个数最大8096个。重构1TB数据耗时约5分钟。

四、上线使用效果

根据上述POC测试结果，A公司产品特性更满足我行业务需求。同时因为其产品架构自研，而其他三家公司均使用开源产品改造，有可能存在一定的技术路线风险（例如开源产品出现底层问题而存储厂商难以修复，开源产品版本更新后设备厂商适配不及时等风险）。综合考虑以上因素，我行选择了A公司的OceanStor Pacific分布式存储，满足历史数据归档数据及票据影像需求，投产效果如下：

核心数据库备份时间从40分钟缩短到15分钟内。

数据全生命周期管理：海量的票据影像文件数据可实现永久保存，账务类系统交易日志实现永久保存，日志易系统把重要系统交易日志写入分布式存储，提高日志查询效率，同时实现亿级文件全生命周期管理。

高可靠：提高存储系统性风险的防范能力，分布式架构支持2节点、2个存储节点上1个硬盘同时故障，业务不中断，数据无丢失；重要文件系统使用快照加异步复制至同城灾备数据中心，实现最大程度数据异地容灾。

易运维&高扩展性：在线扩容，分布式架构性能线性扩展，降低运维难度和减少运维工作量。

五、选型经验总结

结合自身业务增长、监管和新创的需求，对未来5年存储空间的规划，以下是分布式存储选型总结。

1. 现有集中式共享存储无法满足业务增长需求，数据持续增长导致存储需具备极优的扩容能力，是全对称分布式架构，此架构无独立元数据节点，可避免元数据节点瓶颈，在性能方面性能随节点数增加而达到接近线性增加，各存储节点数据分布均衡，且扩容过程中对业务无影响。
2. 新系统上线导致影像文件和应用日志变大，从而导致海量非结构化数据快速增长，对未来的存储系统单个命名空间要具备百亿以上文件数量的支持能力，才能从容应对未来的业务扩展。
3. 得盘率，分布式存储此次需保证实际采购的物理容量至可用容量的转化率，故要求分布式存储支持EC（纠删码）数据保护模式，且支持+2/+3/+4灵活EC配比，而非采用3副本数据分片方式（存储可用容量转化率仅为33%），现有环境使用8+2配比。
4. 作为金融数据存储系统，数据强一致性和可靠性作为准入门槛，存储设备具备多种数据冗余保护机制，存储设备支持数据高冗余模式，最多可容忍集群内任意2个节点同时失效而不丢失数据。当宕机3个节点，冗余不足，存储池故障，此时分布式存储无法读写，当节点拉起后，恢复读写，不会丢数据。如果同一个节点坏多个硬盘，故障任意数量硬盘只损失1份冗余。如果同时坏3个不同节点的盘，存储池故障，会丢失数据，如果故障盘还能修复受损扇区，数据可恢复。分布式存储采用EC数据分片模式，需额外支持动态EC，当节点故障时，自动调整EC配比，确保新数据可靠性不降级。
5. 容灾要求:需考虑在发生自然或人为灾难、操作员误操作、应用出现故障的情况下，保护数据并快速进行恢复。为了应对这些挑战，除了设备本身的高可靠机制外，还需要一个有效的方式将数据复制到同城灾备机房。考虑在主数据中心与灾备数据中心（相隔约70KM）分别部署分布式存储集群，通过存储的异步远程复制技术实现数据容灾，相应的支持Failover和Failback能力，达到存储集群间最低RPO<=1分钟，可调整异步复制速率。
6. 网络要求：前端业务网络与后端存储网络分离，配置独立的存储后端交换机，避免将来设备运行多年后出现节点故障或硬盘故障触发的数据重构等内部存储流量对前端业务产生影响（备注：出于前端业务网络压力相对不大，复制网络可与前端业务网络合布，但由于分布式存储数据打散机制导致后端存储网络必须单独部署不共用）
7. 信创需求：为响应人行监管要求，项目所使用的存储系统软件非开源软件开发，不能基于开源Lustre和Ceph等软件平台，需为国产自研软件，保障后续产品的连续性。项目所使用的存储系统硬件及配套交换机均需采用国产芯片。
8. 监控需求：需监控分布式存储io延时、io吞吐量、节点连接数，避免io延时过大、io吞吐量、节点连接数达到最大值，从而影响业务。

协作专家：
1、黄波 某城商行 存储架构师
2、张健 某银行 资深工程师
3、杨金平 某银行 技术主管
4、霍玉亮 某银行 资深工程师

顾问专家：
曾光明 某省农信 分布式存储架构师