基于超融合构建核心数据库资源池的探索与实践.docx

《基于超融合构建核心数据库资源池的探索与实践.docx》由会员分享，可在线阅读，更多相关《基于超融合构建核心数据库资源池的探索与实践.docx（11页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、基于超融合构建核心数据库资源池的探索与实践方正富邦基金管理有限公司（以下简称“方正富邦”）成立于 2011 年 6 月 30 日，是首家获证监会批准设立的两岸合资基金管理公司。方正富邦的业务具有以下特点。一是方正富邦的公募基金产品主要包括权益类和固收类，也有一定量的专户产品，其中固收类产品的占比高于权益类产品，对接的用户主要是机构用户，直销柜台的用户相对较少，量级在千人左右。二是方正富邦官网客户端的使用度不是很高，OLAP场景多于OLTP场景，系统后台任务的特性决定了 OLTP中单笔事务处理的时间较长，对磁盘的吞吐要求很高。同时，业务场景并发低、虚拟环境下数据库CPU的开销低。基于上述特征，通

2、过超融合虚拟化技术可以满足大多数应用场景的需求。一、传统IT基础架构面临的挑战方正富邦的传统IT基础架构主要分为核心生产资源池和一般生产资源池，核心生产资源池是由4台惠普的DL580服务器加上EMC VNX 5600混闪存储组成的SAN架构，承载的业务主要包括核心交易系统O32、TA、估值等系统对应的数据库。一般生产资源池是由4台惠普的DL580服务器加上EMC VNX 5500混闪存储组成的SAN架构，可支撑转码机、报盘机。办公环境主要运行在刀片服务器和VNX 5500上。在资源池分开的情况下，数据库仍然面临着数据过于集中的问题，且存储系统常出现单点故障。此外，存储的使用率越来越高，容量和性

3、能都无法满足业务发展。在此背景下，方正富邦IT基础架构转型以实际需求为出发点，采用成熟先进的技术设备去建设实用、稳健、可靠的技术架构环境，同时这套环境也要便于运维、易于扩展。二、超融合部署演进过程方正富邦自2017年起开始接触并了解超融合技术，2018年采购了5个节点构建一般业务资源池，主要运行一些轻量应用，如报盘、转码机及交易所网关等应用；2019年采购了4个节点用于构建办公业务资源池，该资源池承载了90%以上的办公类应用；2020年再次采购了4个节点用于搭建数据库的专用资源池，并在其上运行了8套以上的数据库集群，其中包括估值、风控、监管报送、基金数据中心（CC）、直销等系统。2021年，一

4、般资源池的角色定位得到加强，增加了容灾加固的属性，其容灾架构如图1所示。方正富邦的核心生产资源依然运行在集中存储上，其中，数据库是通过数据库的同步技术在容灾资源池上构建实时副本，再通过异步复制，在深证通行业云上构建异步副本。图1 方正富邦资源池容灾架构同时，方正富邦在2020年新构建的数据库资源池上也采用相同方式，在容灾资源池上构建了实时副本，在深证通行业云上构建异步副本。未来，方正富邦计划将核心系统跑在超融合上，传统的三层架构环境将作为容灾资源池。为此，方正富邦针对超融合在关键业务数据库上的性能进行了验证。三、关键业务数据库跑批性能验证方正富邦数据中心的数据量大概有2.4TB，已经超过了超融

5、合单节点的SSD缓存容量，后台执行跑批任务时，有时会发生击穿的情况，导致任务完成超时，进而影响系统处理。CC系统的主要作用是集中处理分析来自多个业务系统（如直销、估值、TA等）的数据，用以满足业务部门使用和分析挖掘数据的需要，如市场营销、客户管理、运营支撑、报表报告、投研策略等。本次性能验证以CC作为测试数据库，主要是为了测试在高速闪存，即NVMe介质的配置下超融合的性能表现，同时也为后续核心业务系统(如O32、TA等）在技术架构选型上提供一些参考。本次测试方法主要是比较NVMe SSD的配置和传统的SATA SSD混闪下超融合的性能，测试用例是方正富邦的数据中心系统，同时把近两个月的历史数据

6、导入测试环境，每天模拟，手动触发后台任务，和生产上跑出来的时间进行比较。测试环境的配置为48Cores、256GB内存加上3.2TB的全闪（如图2所示）。图2测试环境配置测试拓扑图由三个节点组成，后端网络是 25GbE，生产的服务器配置在计算资源上，比如 6326的CPU 、512GB的单节点内存，都高于测试环境，唯一的差别就是生产环境使用的是SSD缓存加上机械盘的存储。由于是测试服务器，使用的测试机缓存容量有限，单节点为3.2TB，总容量大概为9.6TB，再去除副本，可用容量为4TB左右。从任务跑批验证数据对比（如图3所示）可以看出，在单任务跑批验证上，CC、估值数据落地，测试环境最快达到了

7、5分21秒，而生产环境最快是37分钟。在多任务跑批验证上，测试环境每项任务的用时都优于生产环境，且测试环境的总用时为31分42秒，生产环境的总用时是176分钟。单任务跑批和多任务跑批的执行时间差距如此之大，可能是在混闪配置下，任务并行使得机械盘I/O被占满，导致任务出现暂停状态，后面的顺序任务也就无法执行了。图3任务跑批验证数据对比从CPU的负载监控数据（如图4所示）可以看出，CPU的使用率在部分时段存在70%、50%、30%、20%等持续时间的连续负载压力，非常符合跑批场景下的特点，CPU等待部分时段占比较高，通常情况下在I/O密集型的应用等待占比会高一些，对应存储负载的监控也能佐证这一点。

8、图4CPU的负载监控数据从存储负载监控数据（如图5所示）可以看出，峰值大概在1.5GB/s，此时会出现持续读取压力，其余时间存在多次较高的突发访问量。结合之前CPU监控数据使用率和等待占比来看，存储性能就是跑批场景下最关键的影响性能因素。图5存储负载监控数据最终测试结论是：得益于超融合架构、NVMe高速硬件介质、后端25GbE的高速网络等因素，以及超融合I/O本地化特性优化了存储读写性能，测试结果相比于当前的生产环境有较为明显的提升。本次的测试结果为后续TA、O32等核心业务系统迁移到超融合环境中提供了参考依据。测试期间，超融合存储空间使用率达到96%，多次测试的结果之间性能差异在秒级，可以看

9、到，SmartX超融合架构在高负载场景下依然可以保持着可靠稳定的性能输出。四、经验分享在使用超融合构建核心数据库资源池的过程中，方正富邦总结了以下经验以及注意事项。一是相比于集中存储，超融合对前期的规划要求更高，需要明确业务场景、集群的使用性质，避免因虚拟机体量太大、存储资源不足造成计算资源浪费，或者出现密集型的应用对计算资源要求高导致前期配置性能不足的情况。二是在虚拟环境下，通过克隆方式打造数据库操作系统基础环境，可以大量节约平时环境搭建的时间。三是数据库的基础资源、CPU及内存可以伴随虚拟机的特性随时调整。传统“物理机+存储”的采购方式，在开始采购硬件时，需要留出很多可扩展的空间，容易造成前期投入资源的浪费。四是超融合部署简单，可以在很大程度上缩短业务上线时间。在实际的生产环境中，不考虑商务因素，从到货、搭建再到实时上线，有时能在一天时间内完成这些工作。五是虚拟化主机维护时需要数据库关机，因为基于多写入器的核心数据库不支持在线vMotion，所以维护主机时，跑在上面的数据库服务器需要关机重启。11