某基金公司最初引入 SmartX 榫卯超融合作为 TA 等关键业务系统的灾备承载环境。但在实际部署和测试过程中，榫卯超融合在 TA 数据库批处理场景中的表现优于原有基于物理机的生产环境，性能翻倍。基于稳定的运行效果和显著的处理效率提升，客户将生产与灾备环境架构进行置换，以榫卯超融合承载 TA 等核心生产系统。
这一实践表明，在数据库跑批场景中，基于全闪介质和 ZBS 分布式存储本地读能力的 SmartX 榫卯超融合，可充分满足基金行业关键业务系统生产运行的支持需求。
实践背景
该基金公司原本将 TA 系统运行在物理服务器 + 集中式存储架构上，集中式存储采用 PowerMAX 1000 全闪存储，数据库服务器单独部署于两台物理服务器组成的 RAC 集群。该架构长期承担生产业务运行，但随着业务数据增长，日常批处理窗口和数据库处理效率逐渐成为瓶颈。
在进行升级改造时，客户原本计划基于 SmartX 榫卯超融合构建灾备资源池，保障 TA 等关键系统的业务连续性。但在实际测试后，超融合环境下的 TA 数据库相关处理效率显著提升，明显优于原生产环境。
测试验证：TA 批处理时间缩短一半
原生产环境对比 SmartX 测试环境配置
本次测试中，TA 系统业务数据量约 370G，该数据口径为 data 虚拟磁盘已使用空间。客户重点观察每天 TA 系统跑批过程中，除传输、备份、数据导入导出之外，真实通过批处理脚本处理数据的时间。对比结果如下：
可以看到，在真实业务数据和日常跑批链路下，TA 数据库相关处理时间由约 1 小时缩短至约 31 分钟，性能翻倍，且该性能在每日的多次观测中均稳定输出。
性能瓶颈分析：读 I/O 与读带宽成为关键压力
为了进一步分析性能提升原因，客户观察了 TA 数据库虚拟机和虚拟卷的监控数据。监控结果显示，TA 数据库批处理负载具有明显的读密集和大块读特征。关键监控指标如下：
从这些数据可以看到：
- 主要压力在存储读侧：读 IOPS 和读带宽显著高于写侧压力。
- 批处理存在大块读特征：约 170KiB 的平均块大小说明跑批并非单纯小块随机读写。
- 计算侧和网络侧不是主要瓶颈：数据库 node1 短时峰值约 54%，CPU 使用率未持续打满；网络收发峰值为数百 Mbps，相比存储读压力并不突出。
- 读延迟表现稳定：在高读 I/O 和高读带宽压力下，读延迟短时峰值约 5ms，多数时间保持较低水平。
读写 IOPS 与读写带宽截图
为什么榫卯超融合适合这类场景
在传统物理服务器 + 集中式存储架构中，数据库访问后端数据通常需要经过服务器、存储网络、集中式存储控制器和磁盘介质等多层路径。对于大量读 I/O 和大块读任务而言，数据访问路径、存储控制器能力、后端介质性能以及网络链路都会影响最终处理效率。
I/O 本地化功能，更适合数据库批处理任务的存储模型
在榫卯超融合架构中，虚拟机数据并非完全随机地分布在整个分布式存储池中，而是能够感知上层业务，根据虚拟机运行位置实现数据本地化。
数据库批处理任务的存储 I/O 以读取为主，并且对持续带宽和稳定时延较为敏感。这种负载模型与 SMTX OS 的 I/O 本地化机制较为契合：相比需要通过 FC 或 iSCSI 网络访问集中式存储的架构，榫卯超融合能够减少跨设备数据访问与 SAN 网络性能瓶颈，从而提升数据库批处理任务的执行效率。
直通 NVMe 存储架构，充分发挥硬件并行优势
传统存储方案通常依赖 RAID 卡、存储控制器或专用存储节点完成数据校验、RAID 计算等数据冗余功能。当业务负载持续增加时，阵列卡或存储控制器的处理能力可能成为系统性能瓶颈，底层硬盘的实际性能也难以得到充分发挥。
SMTX 超融合采用分布式存储架构，数据保护能力不依赖单一阵列控制器，而是通过跨节点数据副本机制实现。服务器中的 NVMe 盘直接连接到主机 CPU ，不需要经过传统阵列卡转发，能够减少中间处理环节和数据传输路径，充分发挥现代 NVMe 硬盘并行性能。
数据库与业务虚拟机部署在相同物理服务器节点，减少物理网络绕行
榫卯超融合通过虚拟机实现实例级别的资源隔离，避免不同业务之间相互争抢资源。同时，也可以通过将数据库与业务虚拟机部署在同一物理节点，使其通过虚拟机网络完成通信，不需要经过外部的网络设备，能够缩短数据传输路径，减少了“服务器—物理交换机—服务器”路径中的多次转发。结合虚拟机亲和性、反亲和性以及资源调度策略，在保证高可用和故障切换能力的前提下，维持数据库与相关业务虚拟机的合理拓扑关系。
榫卯超融合在该场景中的价值，并不是简单地“把物理机变成虚拟机”，而是通过分布式架构和优化的资源调度能力，为数据库批处理负载提供更适配的基础设施路径。
灾备“转正”生产：基于榫卯超融合支持 TA 生产业务系统
基于以上测试结果，该基金公司将原本规划的生产与灾备集群架构进行互换，基于榫卯超融合构建生产集群承载 TA 等核心业务系统，原物理服务器 + 集中式存储环境则通过英方承接备份/灾备链路。TA 系统在榫卯超融合上以 Oracle RAC 方式运行，同时保留到原环境的备份/灾备保护。
榫卯超融合生产资源池采用SmartX 一体机，单节点配置双路 Intel Xeon Gold 6526Y、约 1TiB 内存、6 块 3.2TB 全闪盘，并采用 10GbE 网络口径，按照最佳实践配置管理、业务、存储三网络分离。核心部署信息如下：
目前，该生产集群已稳定运行近半年，期间无业务中断。同时，除 TA 外，榫卯超融合集群还陆续承载了 FA 中间件、自研监管报送系统及 MySQL 数据库，未来计划进一步承载 O32 系统。这意味着 榫卯超融合资源池正在从单一系统承载逐步扩展为客户关键业务基础设施的核心底座。
客户价值
- 验证超融合生产承载能力：项目从灾备建设起步，最终通过测试验证承载 TA 生产业务，证明榫卯超融合可支撑基金行业关键业务系统。
- 显著缩短 TA 批处理窗口：TA 业务数据量约 370G，真实批处理脚本处理时间由约 1 小时缩短至约 31 分钟，性能翻倍。
- 保护既有资产：原计划用于灾备的 SmartX 资源池因性能表现优秀转为生产承载，原物理服务器 + 集中式存储环境承接备份/灾备角色，提高了整体资源利用价值。
- 兼顾生产性能与容灾保护：TA 在 SmartX 上以 Oracle RAC 方式运行，同时通过英方备份到原集中式存储 + 物理服务器数据库环境。
- 形成后续业务迁移基础：除 TA 外，FA 中间件、自研监管报送系统 + MySQL 已放在该集群上，O32 预计承载，为更多业务迁移提供了实践基础。
结语
该基金公司的实践说明，基础架构演进的价值不只体现在资源整合，更体现在能否解决真实业务系统中的性能和稳定性问题。面向基金行业 TA 等读密集型数据库批处理场景，基于全闪介质与 ZBS 分布式存储本地读能力的 SmartX 超融合架构，可以在保障生产稳定运行的同时，有效缩短批处理窗口，并为更多关键业务系统迁移到超融合平台提供实践基础。
点击链接获取《金融核心生产业务场景探索文章合集》。
《【信创转型与架构升级篇】金融核心生产业务场景探索文章合集》
推荐阅读：
虚拟化支持证券极速行情&交易系统：交易网卡延时达物理机水平！
浅析 kernel bypass 网卡及其在超融合架构的性能表现
SmartX vs NetApp：基金用户 O32 风控、TA、CC 系统跑批性能验证
