第一届“金融现代化 IT 基础架构转型论坛（FinTech Infrastructure Wave 2022）”已于 9 月 21 日至 23 日成功举办。该论坛由中国信息通信研究院云计算与大数据研究所、《中国金融电脑》杂志社主办，北京志凌海纳科技有限公司（SmartX）与北京鲲鹏联合创新中心协办，分为三大专场，覆盖银行、保险、证券、基金、期货、信托六大金融细分行业；带来 15+ 实践干货分享，涵盖多云平台建设、核心业务系统信创转型、超融合关键场景落地、核心业务 K8s 改造、数据中心零信任安全、“基础设施即代码”等前沿话题。我们将以文字及图片的形式，为大家回顾本次论坛期间的嘉宾精彩演讲。今天为大家带来方正富邦基金运维经理牟世强的演讲内容：《超融合构建核心数据库资源池》。

本内容作者为方正富邦基金运维经理牟世强，由 FIW2022 组织方编辑整理发出，以下为部分演讲内容。

今天我分享的主题是超融合构建核心数据库资源池，首先介绍一下我们公司。方正富邦基金管理有限公司成立于 2011 年 6 月 30 日，是首家获中国证监会批准设立的两岸合资基金管理公司，也是自《海峡两岸经济合作框架协议》生效后首家获批的陆台合资基金管理公司。我们公司的管理规模排名在 80~90，所以我今天要分享的内容可能对与我们规模业务特点相近的公司有一些借鉴意义。

下面我将从几个维度说明一下我们公司的业务特点。基金管理方面，我们公募基金主要是权益和固收类产品，也有一定量的专户产品，其中固收的规模占比高于权益类，所以我们对接的用户主要是机构用户，直销柜台的用户相对较少，量级在千人左右。

其次，公司官网客户端的使用度不是很高，OLAP 场景多于 OLTP 场景，系统后台任务的特性决定了 OLTP 中单笔事务处理的时间较长，对磁盘的吞吐要求很高。当然这只针对我司现有的基础环境，可能对于其他公司配置高的情况不会有这种问题。同时，我们的业务场景并发低、虚拟环境下数据库 CPU 的开销低，通过超融合虚拟化可以满足大多数的应用场景。

一、传统 IT 基础架构部署挑战

在使用超融合之前，我们的传统 IT 基础架构都面临着哪些挑战？先介绍一下我们公司的基础架构环境，自建司以来公司采用的都是小型机 + 集中存储，后期有把部分小型机替换成 x86 服务器，存储也从 CX 系列到 VNX 系列。我本人也是存储工程师出身，以往的项目经历中接触的甲方大多数对存储的技能储备都较少，而存储在 IT 系统中又是重中之重，通常存储的调整都需要专业公司支持，有时可能还涉及到多家厂商协调配合。

方正富邦基金的传统系统架构主要分为核心生产资源池和一般生产资源池，核心生产资源池是 4 台惠普的 DL580 服务器 + EMC VNX 5600 混闪存储组成的 SAN 架构，承载的业务主要是核心交易系统 O32、TA、估值等系统对应的数据库。

一般生产资源池由 4 台惠普的 DL580 服务器加上 EMC VNX 5500 混闪存储组成的 SAN 架构，支撑转码机、报盘机。办公环境主要用在刀片服务器和 VNX 5500 上。在资源池分开的情况下，我们仍然面临数据过于集中的问题，且存储属于单点，一旦设备存储故障影响范围特别大。另外存储的使用率越来越高，容量和性能都无法满足业务发展。

像 VNX 系列的存储可能上线或出厂已经 8-9 年时间了，后期维护成本和扩容成本都很昂贵。 在此背景下，我司 IT 基础架构转型的目标可以用这句话来表述：以实际需求为出发点，采用成熟先进的技术设备去建设实用、稳健、可靠的技术架构环境，同时这套环境也要便于运维、易于扩展。

超融合的概念在 2012 年被提出，2013 年路坦力进入中国市场，2015 年 SMTX OS 1.0 发布。到 2016 年左右，我作为乙方的工程师，也被要求掌握超融合的技能。2017 年实施了一些超融合的项目，比如一些金融公司，把超融合承载的环境从测试迁移到边缘生产再到主生产，到 2018 年超融合已经占据了很大部分市场，我们认为超融合这时发展得比较成熟，是最适合我们转型目标的产品。

二、超融合部署演进过程

2018 年我们采购了 5 个节点构建一般业务资源池，主要运行一些轻量应用，像报盘、转码机及交易所网关等应用。2019 年面临办公环境的刀片服务器淘汰，我们又采购了 4 节点用于构建办公业务资源池，承载了 90% 以上、接近 100% 的办公类应用。2020 年我们再次采购 4 节点搭建数据库的专用资源池，运行 8 套以上的数据库集群，其中包括大家比较熟悉的估值系统、风控系统，以及监管报送、CC数据中心、直销等。

2021 年一般资源池的使用角色又得到了提升，增加了容灾加固的属性。在容灾架构上我们是怎么做的？下面是我们的拓扑图，我们的核心生产资源依然运行在集中存储上，其中数据库是通过数据库的同步技术在容灾资源池上构建实时副本，再通过异步复制，在我们的深证通行业云上构建异步副本。

同时我们在 2020 年新构建的数据库资源池，也用相同方式在容灾资源池上构建了实时副本，在深证通行业云上构建异步副本。未来我们计划将核心系统跑在超融合上，传统的三层架构环境作为容灾资源池。当然随着设备老化，我们也可能直接跳过，去专门构建一套超融合的容灾资源池，为此我们也做了一些超融合在关键业务数据库上的性能验证。

三、关键业务数据库跑批性能验证

下面我来介绍一下关键业务数据库的跑批性能验证。项目背景是我们的数据中心系统的数据量大概有 2.4TB，数据量已经超过了超融合单节点的 SSD 缓存容量，所以后台跑批任务执行时，有时会发生击穿，导致任务完成超时，进而影响我们系统处理。

基金数据中心系统，简称 CC，作用主要是集中处理分析来自多个业务系统，如直销、估值、TA 等系统的数据，然后支撑业务部门数据使用和分析挖掘需要，如市场营销、客户管理、运营支撑、报表报告、投研策略等。我们主要想验证在高速闪存，也就是 NVMe 介质的配置下超融合的性能表现，同时也为后续核心业务系统像 O32、TA 在技术架构的选型上能够提供一些参考。

我们的测试方法主要是比较 NVMe SSD 的配置和传统的 SATA SSD 混闪，测试用例是我们的数据中心系统，同时把近两个月的历史数据导入测试环境，每天模拟，手动主动触发后台任务，和生产上跑出来的时间做比较。测试环境的配置为 48 Cores、256 GB 内存加上 3.2TB 的全闪。

我们的拓扑图由三个节点组成的，后端网络是 25GbE，生产的服务器配置其实在计算资源上，比如 CPU 是 6326，内存单节点是 512GB，这些都高于我们的测试环境，唯一的差别就是我们生产环境使用的是 SSD 缓存加上机械盘的存储。

由于是测试服务器，我们使用的测试机缓存容量有限，单节点 3.2 TB，总共容量可能为 9.6，再去除副本可用容量大概是四点几个 TB。在我们搭建的测试数据库，比如 CC 以及跑批任务依赖的估值数据库，最终空间使用率已经在 90% 以上，可能达到了 96%。我们测试虚拟机的配置和生产是完全一致的。

接下来我们看一下测试结果，从单任务跑批验证上来看，我们最关心的 CC、估值数据落地，在测试环境最快达到了 5 分 21 秒，而生产环境最快是 37 分钟。我们从历史数据两个月也执行了大概 50 多次，每次的结果都很接近，生产环境中 37 分钟是最快的，有时还会跑到 50 多分钟。多任务跑批验证时，每项任务都优于生产环境，在汇总上测试环境一共用了 31 分 42 秒，而生产环境大概用了 176 分钟。单任务跑批执行时间和多任务跑批差距如此之大，可能就是在混闪配置下，任务并行使得机械盘 I/O 被占满，所以可能任务会出现暂停状态，导致后面的顺序任务无法执行。

我们看一下 CPU 的负载监控数据， CPU 的使用率在部分时段存在 70%、50%、30%、20% 等持续时间的连续负载压力，非常符合我们的跑批场景下的特点， CPU 等待部分时段占比较高，通常情况下在 I/O 密集型的应用等待占比会高一些，对应存储负载的监控也能佐证这一点。我们测试环境的 CPU 配置是稍低的，还具备一定优化空间，在我们未来投入生产选型时会提升 CPU 配置。

存储负载监控数据主要以读取为主，峰值时大概在 1.5GB/s 左右持续读取压力，其余时间存在多次较高的突发访问量。结合之前 CPU 监控数据使用率和等待占比来看，存储性能就是我们跑批场景下最关键的影响性能因素。

最终测试结论是得益于超融合架构和 NVMe 高速硬件介质，同时结合我们后端 25GbE 的高速网络，以及超融合 I/O 本地化特性，优化了存储读写性能，使得测试结果相比于当前的生产环境有特别明显的性能提升。

本次的测试结果，为后续 TA、O32 等核心业务系统迁移到超融合环境中提供了参考依据。测试期间超融合存储空间使用率达到 96%，多次测试的结果之间性能差异在秒级，所以我们认为 SmartX 超融合架构在高负载场景下，依然可以保持着可靠稳定的性能输出。

四、经验分享

最后我想跟大家分享一下使用超融合过程的一些经验，以及注意事项。

第一点是超融合相比于集中存储对前期的规划要求更高，需要明确业务场景、集群的使用性质，避免发生虚拟机体量太大、存储资源不足造成的计算资源浪费，或者是密集型的应用对计算资源要求高，而我们前期配置时性能不足。

第二点是在虚拟环境下，数据库操作系统基础环境的准备，可以通过克隆方式去实现，大量节约了平时环境搭建的时间。

第三点是我们数据库的基础资源、CPU 及内存，都是伴随虚拟机的特性可以随时调整。如果是传统的采购物理家+存储的方式，我们一开始采购硬件时，可能要留出很多后面扩展的空间，否则容易造成资源前期投入的浪费。

第四点是超融合的简单部署，在业务上线时可以很大程度上缩短上线时间。有时在实际的生产环境中，可能从不考虑商务因素，从到货、搭建再到实时上线，可能在一天时间就可以搞定。

第五点是虚拟化主机维护时需要数据库关机。因为基于多写入器的核心数据库不支持在线 vMotion，所以维护主机时，跑在上面的数据库服务器需要关机重启。