城商行核心系统换存储踩坑实录

我们在交付某城商行核心系统存储升级项目时,踩了一个代价不小的坑:把核心交易系统的存储从集中式换成了分布式,运行半年后又切了回来。这件事在内部复盘了三次,结论很清楚——不是分布式存储不好,是场景选错了。把整个过程拆开讲,给后面做类似选型的人一个参照。

背景:为什么想换

这家城商行原有核心交易系统跑在华为OceanStor 5500 V5上,配置是双控制器+全闪存NVMe,裸容量20TB,已运行4年。系统整体没什么大问题,但信息科有两个痛点:

第一,容量快满了。核心交易数据每年增长约3TB,加上日志和归档,20TB裸容量去掉RAID和冗余后可用约13TB,到2024年底只剩2TB余量。OceanStor 5500扩展需要加磁盘柜,但机房空间已经紧张。

第二,信创考核压力。2024年省银保监局对辖内城商行做信创专项检查,要求核心系统存储国产化率不低于50%。OceanStor虽然是国产品牌,但底层器件国产化率不达标。信息科需要找一个能在信创目录里的替代方案。

当时深信服EDS刚出520版本,在信创目录里,支持鲲鹏920 CPU平台。信息科的人去参观了另一家股份制银行的EDS部署,回来后倾向于用EDS替换OceanStor。我们作为交付方,做了POC测试,结果POC数据看起来没问题——但POC和生产的差距,后面会讲到。

选型:POC测试为什么没暴露问题

POC测试是在测试环境跑的,用3节点EDS(鲲鹏920+NVMe SSD),配置3副本,跑TPC-C模拟交易负载。测试结果:

指标	OceanStor 5500(现网)	EDS 3节点(POC)
4K随机读IOPS	12万	18万
4K随机写IOPS	6万	9万
读延迟(P99)	0.6ms	0.8ms
写延迟(P99)	0.9ms	1.1ms
聚合带宽	1.8GB/s	3.2GB/s

POC数据看起来EDS全面领先,除了延迟略高。但0.8ms和0.6ms的差距,在测试环境里几乎感觉不到。问题出在POC的负载模型和生产环境不一样——POC用的是均匀分布的TPC-C负载,生产环境的交易高峰有明显的突发性和潮汐效应。

部署:周末割接,周一就出问题

2025年1月某个周末割接。方案是EDS 3节点部署,通过存储虚拟化网关把OceanStor的数据镜像到EDS,然后切换主机多路径策略,把I/O切到EDS侧。割接本身很顺利,周六晚上开工,周日早上6点核心系统启动,交易正常。

周一上午9:30,问题来了。

柜员系统反映交易变慢,查询账户余额要等2-3秒(原来不到1秒)。信息科监控看到核心交易的P99延迟从0.8ms飙到了3.2ms,峰值甚至到5ms。更关键的是,延迟不是稳定在3ms,而是间歇性抖动——大部分时间正常,但每隔几分钟突然跳一下。

排查过程:

第一步,看EDS集群状态。3个节点都在线,CPU利用率35%,磁盘利用率正常,没有重建任务在跑。存储层面看不出异常。

第二步,抓网络包。发现抖动的时间点和EDS节点间的副本同步有关。EDS的3副本写入是同步的——主节点写完后,要等两个副本节点都确认才算写完成。正常情况下副本同步在1ms内完成,但当三个节点中某个节点的CPU出现瞬时高负载(比如GC或者后台任务),副本同步就会延迟到3-5ms。

第三步,对比OceanStor的架构。OceanStor是双控制器+缓存写透架构,写延迟非常稳定,因为控制器内部的高速缓存是共享的,不存在跨节点同步的问题。P99延迟的波动范围只有±0.1ms。而EDS的跨节点副本同步,在极端情况下会引入±2-3ms的抖动。

这就是POC没暴露问题的原因:TPC-C的均匀负载下,副本同步延迟被均摊了;但生产环境的交易突发(比如9:30开门时的集中查询),会让某个节点的CPU瞬时冲高,放大副本同步的延迟抖动。

翻车:三个月断断续续调优没解决

信息科和深信服的技术支持花了三个月调优:

1. 把副本数从3改成2(减少一次跨节点同步),延迟抖动从3ms降到2ms,但数据可靠性下降,银保监不允许核心系统用2副本。

2. 调整EDS的后台任务调度窗口,把重建、压缩、快照等后台任务限制在凌晨2-5点执行。白天抖动频率降低了,但高峰期还是偶尔出现。

3. 在EDS前面加了一层SSD缓存加速,把热数据的读延迟压到0.5ms。写延迟的问题依然存在。

三个月下来,核心交易系统的P99延迟稳定在1.5-2ms之间,比OceanStor的0.6ms还是高了将近3倍。城商行的核心系统对延迟的要求是P99≤1ms,这个指标始终达不到。

结果:切回集中式,分布式没浪费

2025年4月,信息科做了决定:核心交易系统切回OceanStor。但OceanStor的容量问题还是要解决,最终方案是:

• 核心交易系统: 保留OceanStor 5500,新增一台华为OceanStor 5300 V7(信创版,鲲鹏CPU),通过双活配置扩展容量。核心系统的P99延迟恢复到0.6ms。
• OA和测试环境: 迁到EDS上。OA系统对延迟不敏感,EDS的3副本和快照功能在这里反而比OceanStor更实用。
• 日志和归档: 放到EDS的对象存储里,成本比扩OceanStor便宜40%。

EDS没有白买,只是放错了位置。分布式存储的强项是扩展性、多协议和成本,不是极致的延迟稳定性。集中式存储的强项是延迟可控、运维成熟,在核心交易场景仍然是首选。

这个结论和分布式存储增速采购怎么选里的判断完全一致:核心交易数据库用集中式,非结构化数据和备份用分布式。两种架构并存不是浪费,是务实的混合策略。

三个教训

教训一:POC负载模型必须模拟生产潮汐。 均匀分布的TPC-C跑出来的延迟数据没有参考价值。正确的做法是用生产环境的真实交易日志回放,包括高峰期的突发负载。如果当时用生产日志回放,副本同步的延迟抖动在POC阶段就能暴露。

教训二:核心交易场景的延迟指标看P99不看平均值。 EDS的平均写延迟是0.9ms,看起来和OceanStor的0.6ms差不多。但P99延迟差了3倍,而交易系统卡顿恰恰是P99的尾部延迟造成的。选型时必须看P99甚至P99.9。

教训三:分布式存储和集中式存储不是替代关系,是互补关系。 这个项目的最终方案就是混合架构——OceanStor跑核心交易,EDS跑OA和归档。关于分布式存储和超融合架构的区别,可以参考超融合和分布式存储有什么区别,里面从五个维度做了拆解。选型时先看业务场景的延迟敏感度,再看扩展性需求,最后看成本。

如需存储选型评估,联系华南腾飞科技,我们可以安排POC测试和生产负载回放验证。