victortp
作者victortp2020-03-27 09:51
系统架构师, 某大型保险

某大型保险集团在线财险业务系统存储架构由集中式向分布式转型实践

字数 4092阅读 7359评论 17赞 18

作者简介:

社区 ID : victortp 某保险集团 分布式存储架构师 有多年分布式架构及存储领域的工作经验

文章摘要:

国内某知名大型保险集团业务范围涵盖寿险、互联网财险、养老保险、企业年金、健康管理等多个领域,随着互联网业务的发展,核心数据库数据量井喷式增长,原有基于 Oracle 一体机的数据库架构已经不能满足业务增长的需要,催生了数据库平台自 Oracle 一体机向 x86 开放平台迁移的需求,采用新型分布式存储架构,提供数据库支持服务,与云端应用服务器一起构成混合云。该新架构是面向互联网的分布式架构,具备了弹性可扩展、 Scale-out 能力,满足了未来业务发展对存储性能和扩展能力的要求。

一、背景分析

1. 系统原有 IT 存储架构

基于在线核心业务系统的运营,需 要 为业务提供极致性能,提供关键业务数据的高可用能力,保证发生意外时,核心数据不丢失。该保险企业在线财险业务系统核心数据库之前运行在 Oracle SuperCluster Solaris 平台上。

2015 年上线运行:

Ø 初始数据量约 2TB
Ø 业务连接数约 1000 左右
Ø 内存资源使用率 30% 左右
Ø CPU 资源使用率 40% 左右

经过 2-3 年的业务发展 :

Ø 数据量约 12TB ,增长量近 6 倍,根据业务的发展预测,以 10TB/ 年的速度递增;
Ø 虽然前端系统采用的外围数据库处理业务,业务平均连接数仍然达到了 4000 左右,增长近 4 倍;
Ø 内存资源平均使用率 80% ,增长近 2.6 倍;
Ø CPU 资源使用率 40% ,基本持平。

2. 业务发展对数据库系统的需求

3. 在线财险业务系统存储架构转型

随着企业在线财险业务的迅速增长,原有的 Oracle SuperCluster Solaris 平台物理硬件资源趋于饱和。按传统处理方式,通常采购新的同架构 Oracle 一体机和服务,进行物理硬件平台的整体升级,保证数据库可以满足业务发展的需要。但是在不久的将来,当前所遇到问题仍会复现,死循环现象明显。另一方面,该型号的产品停产,不再支持扩容升级等支持服务。因此,当前 SuperCluster 一体机平台已经不适应业务发展的需要。

经过对目前的主流的存储架构进行调研和分析后,我们的视角转到了全闪分布式块存储上。

二、 分布式存储架构转型

1. 主流的存储架构调研分析总结

数据库一体机小型机与集中式存储x86服务器+分布式块存储
架构组成计算层:采用x86服务器做为DB server,安装RAC实现负载均衡,计算节点固定,不能扩展节点 互联层:架构中间层,由Infiniband完成计算节点和存储节点的互联 存储层:直连存储,计算存储网络设计为同一机柜中计算层:采用小型机作为架构中的计算节点,安装RAC实现负载均衡,调查目前只有IBM P系统设备 互联层:架构中间层,由FC SAN完成计算节点和存储节点的互联 存储层:采用磁盘阵列作为存储节点,配置SAS或FC磁盘计算层:标准X86服务器做为架构中计算节点,安装RAC实现负载均衡。 互联层:标准TCP网络连接,若采用25GB网络效果更佳,无特殊要求。 存储层:采用标准X86服务器,配置支持RDMA网卡、存储卡实现,节点连通同样采用传统连接。 且计算、存储解耦。
业务风险新旧模块的升级、衔接与切换等容易对业务造成影响,且无法适应快速发展的业务需求,以及新业务的需求。无法云化,无法适应快速发展的业务需求,以及新业务的需求。暂无
扩展能力无法实现存储的大规模扩展,只能重新购置设备且采购周期长受SAN存储双控的限制,扩容能力有限,控制器很容易成为瓶颈计算、存储解耦设计,无论是计算节点、存储节点的扩容只受限于采购周期、机房环境相关,理论上无上限。
生态封闭,无法与分布式应用、大数据、容器、AI等技术架构对接封闭,无法与分布式应用、大数据、容器、AI等技术架构对接相对开放,分布式存储适当开放API接口,用户可主实现监控相关,其它功能依赖厂商
成本维保依赖厂商、按年度计算费用高昂 扩容不易,周期长,在满配仍不能满足需求时,需求更换设备型号,风险不可接受维保费用高昂维保为集中打包方式,X86服务器维保为采购时指定,无特殊费用。 随着运行周期的增加,成本明显降低。

无论是数据库一体机还是传统 SAN 架构都是采用双控或者多控结构,在控制器之间通过 NTB 或者其他技术达到状态一致。规模受限,无法实现大规模集群、无法 Scale Out, 只能 Scale Up 。结构复杂,成本高,存在明显不足。这些架构已不能满足我们业务发展的需求,因此我们的视角转到了分布式块存储上。

2. 基于分布式存储的数据库架构及分布式块存储产品选型

经过对当前可选分布式块存储产品的调研和相关 POC 测试,我们最终选择了青云 QingCloud 的分布式块存储产品 QingStor NeonSAN ,提供数据库支持服务。以下是基于分布式存储的数据库架构:

该架构采用了标准 X86 物理服务器构成:

(1) 计算层:为三节点 X86 物理服务器作为 Oracle RAC 的计算节点,构成三节点数据库服务集群。
(2) 存储层:初期采用三节点全闪配置的 QingStor NeonSAN 作为底层的存储节点,构建存储服务集群,适用了高负载、并发用户数较高、 IOPS 要求较高的核心业务,存储层提供三副本块存储用于数据库存储卷且提供较高层次的故障保护。
(3) 网络层:由传统网络层提供传输,交换机无特殊配置。

经过了近二年的运行,此套分布式存储解决方案与传统方案对比,主要优势如下:

(1) 采用计算与存储分离的全分布式架构后,海量的数据压力分散到了多个并发存储节点,系统性能、吞吐量按照线性扩展。
(2) 全闪的存储节点之间采用 RDMA 互联,性能超越原有的一体机平台,存储系统提供负载均衡机制,有效避免单点性能瓶颈。
(3) 由开放的 X86 平台取代了传统数据库一体机与与集中式存储设备,大幅缩短了存储系统的建设与扩容周期,有效满足业务数据量激增的扩容需求,同时大幅度节省采购、维护与运营成本。

三、 业务场景实测

以下是针对真实业务场景在 X86 + QingStor NeonSAN 分布式存储开放式架构运行环境下的实测数据:

1. 单应用场景下的测试

测试对象: 日常耗时最长的存储过程 ETL_W_PERFORMANCE_CHANNEL_YMD

表 1_ 生产系统平执行时长

时间日期平均时长(小时)
2018年1月1日-2018年1月19日2.7
2017年10月-2017年12月1.6

测试结果:

表 2_ 测试结果信息**

测试频次测试起始时间测试结束时间执行时长
第一次2018/1/23 19:45:332018/1/23 20:54:151小时8分钟
第二次2018/1/24 7:56:422018/1/24 8:49:1953分钟

在无并行应用场景下,相对于生产系统而言,跑批执行时长由原来的 2 小时左右 ( 生产系统实际执行时长 ) ,缩短到了 1 小时左右,执行效率有明显提升。实际运行过程中,并无这种应用场景,该场景用来考察存储设备在核心应用并行执行的高负荷下的运行情况。

2. 多应用负载场景下的测试

测试对象: 日常耗时最长的存储过程 ETL_W_PERFORMANCE_CHANNEL_YMD

表 3_ 生产系统平均执行时长

时间日期平均时长(小时)
2018年1月1日-2018年1月19日2.7
2017年10月-2017年12月1.6

多表关联视图 analyzer. e_performance

生产系统从数据读取到抽取到目标端,平均执行时长为 30 分钟。

精算准备金取数 SQL

精算准备抽取退保、再保和理赔数据加工中的部分复杂 SQL 语句进行 plsql 应用端查询测试。

表 4_ 生产系统平均执行时长

测试语句执行时长
测试一:退保保单30分钟
测试二:再报数据分出保费2小时
测试三:理赔金额55分钟

测试结果

在以上三个应用并行执行的情况下,各自的执行结果。

表 5_ 测试结果信息

测试频次测试起始时间测试结束时间执行时长(分钟)
第一次2018/1/24 10:572018/1/24 12:1579
第二次2018/1/24 12:562018/1/24 14:0872
第三次2018/1/24 14:112018/1/24 14:5746
第四次2018/1/24 15:002018/1/24 15:3030
第五次2018/1/24 15:582018/1/24 16:3032

结果分析:

在并行应用场景下,相对于生产系统而言,跑批执行时长由原来的 2 小时 ( 生产系统实际执行时长 ) ,缩短到了 50 分钟,执行效率有明显提升,而且,重复执行时间比初次执行时间由明显减少。

3. 测试总体情况分析

x86 + QingStor NeonSAN 分布式存储的新生产环境下的单应用场景和多应用场景下的测试效果,均好于目前生产环境实际的执行效果,效率至少有 30% 的提升。此次采用 x86 计算 + 分布式块存储架构替换 Oracle SuperCluster 一体机是在满足业务发展历程中采用新架构的一次有益的尝试。

四、 未来规划

一期已经部署容量为 12TB 存储服务集群,在未来三年,我们将根据业务情况对这套系统进行扩容和升级。在扩容规划方面,经过半年的持续运行,数据量增长至 17.8T ,计划扩容六台存储节点提升现有核心生产数据库存储集群的可用容量。此外,我们已上线另外一套存储集群资源池用于 DW 业务系统,继续采用 X86 计算 + QingStor NeonSAN 存储架构的数据库服务架构体系,逐步将网络接口从 10GB 升级至 25GB ,用以满足大容量、高性能存储集群对带宽资源的使用,同时将新增存储资源增加到 Oracle ASM 中,平衡数据容量与业务压力。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

18

添加新评论17 条评论

Allen_KKLTAllen_KKLT产品经理, H3C
2021-04-19 21:19
是否开始构建datalake?前端展现用的是什么类型数据库?
shuhan5679shuhan5679技术经理, nns
2021-02-07 08:58
学习了,感谢分享
hufeng719hufeng719系统工程师, 某钢铁企业
2020-04-07 18:29
x86服务器架构+分布式块存储是趋势,我们主要看中的是它的易扩展性、高可用性以及后期运维的便捷性。至于性能方面,完全取决于硬件设备配置。
admkingadmking技术经理, 互联网
2020-04-03 06:43
分布式存储的多数据中心容灾,不知道是怎么做的?

admking@victortp 看来还是要用传统的技术了。

2020-04-14 12:02

victortp@admking 用oracle自己的adg实现的,由于基于tcp网络的传输量太大,在带宽不足时经常有延时,还不如dg稳定可靠。

2020-04-13 11:22
zhuqibszhuqibs软件开发工程师, Adidas
2020-04-02 16:25
我有几点想法 (1)原来是使用oracle的exadata一体机,虽然比较贵,但是也是用的flash card的层的,虽然不是全闪,oracle对复杂查询是有优化的,不可能比分布式存储慢,除非,原先的exadata缺乏优化; (2)青云的产品,特点就是便宜,所以总的成本必然是下降的,但可靠性不如exadata高; (3)如果全闪使用三副本的话,写的性能如何?好像测试中并没有体现,要知道分布式存储的写是有降低的,因为要满足大部分副本的写成功,而exadata,只是一份数据。
zllhczllhc项目经理, 王强
2020-04-02 16:15
跑批时间能减半,看来也是提升了不少!x86+分布式架构已经是趋势了!
saricsaric系统架构师, FNT
2020-04-02 16:13
文章图文并茂、表格、测试结果数据等详细阐述了存储架构由集中式向分布式转型的实施案例。如果能在脱敏的情况下,分享一下具体迁移技术的实施操作步骤、迁移命令等细节,那就是画龙点睛的分布式转型范本案例!

大老虎@saric oracle 这种方式,应该就是纯数据在线迁移了,我想也就是表分区的迁移,创建新的表空间,迁移分区,下线老的表空间。

2020-05-20 13:01

victortp@saric 主要就是需要 xttr这方面需要反复测试,这个环节搞定后,其它的基本没有问题。

2020-04-13 11:23
liujinlongliujinlong项目经理, china
2020-04-02 16:04
1 分布式存储有开源性的好处也同样带来了相应的风险,在分布式情况下,针对平台稳定性的考量个人感觉目前针对商用性上海市对于超融合,及成熟借鉴解决方案厂家的会好一些,不建议直接上开源性的分布式架构(公司技术能力强除外(有后续成本投入))
jim8602jim8602云计算ICT业务售前技术支持, 陕西移动公司
2020-03-31 12:56
分布式存储的发展解决了金融行业数据量增多的问题,是从性能和大数据方面都有了大幅度的提升,缩短了响应时间。那在网络方面和硬件出现故障时,该方案的性能测试项有哪些能否给我们做一些分享。各个厂家的产品优劣能否做一些分析说明。

victortp@jim8602 从性能测试上青云当时是做得最好了,另外还有一个厂商的东东,不过那个是基于cepH的在高压力数据库上一测试就出局了。

2020-04-13 11:24
yangyuhangyangyuhang存储工程师, 某金融科技公司
2020-03-31 12:44
Qing Stro的存储高级功能多不多?稳定吗? 快照基于什么技术? 支持压缩去重吗?快照一致性组支持吗?一个快照一致性组中最多能放多少个lun,能直接overwrite快照一致性组吗?快照是否支持可读可写。 如果两套存储之间要迁移数据,存储系统之间可以直接低层迁移吗

patrick_zheng@yangyuhang 1、高级功能指哪些高级功能?目前QoS、克隆等功能都是支持的; 2、数据稳定性依托强一致副本,软件架构稳定性基于去中心化,无单点故障,网络稳定性依托于全冗余的网络设计; 3、快照基于COW技术; 4、暂时不支持压缩去重; 5、暂时不支持快照一致性组,这部分功能依托QingCloud IaaS平台完成; 6、同上; 7、快照不支持读写; 8、可以。

2020-03-31 17:15
woshishui072612woshishui072612系统架构师, 沧海月明
2020-03-30 15:52
目前分布式存储应用场景越来越多,青云产品加上全闪加持,性能应该会提升不少,在此之外,我可能更关注兼容性和稳定性。 因此对于兼容性、稳定性以及升级这三块有没有详细的测试项以及测试结果分享呢,运行期间有没有出想过因为硬件或者软件导致故障发生?比如任意两个以上的任一硬盘故障是否有影响?任一节点down后会有什么影响?能够做到平滑升级不影响业务,不需要其他介入呢?

victortp@woshishui072612 三副本下,在前期部属时确保多副本不在一台主机上的前提下,三节点任一节点下线不影响稳定运行,迁移时基于xttr的恢复机制,可以做到迁移窗口所需时间最短,两者都还是要结合起来才好。

2020-04-13 11:26
IT小白IT小白项目管理岗, 青海农信
2020-03-30 15:30
分布式存储的发展解决了现在银行数据量增多的问题,不论是从性能上还是大数据方面都有了大幅度的提升,缩短了响应时间,提高了客户体验
mayu0630mayu0630数据库管理员, 北明
2020-03-30 15:19
分布式存储具有高性能,一个具有高性能的分布式存户通常能够高效地管理读缓存和写缓存,并且支持自动的分级存储,由于通过网络进行松耦合链接,分布式存储允许高速存储和低速存储分开部署,或者任意比例混布。与传统的存储架构使用RAID模式来保证数据的可靠性不同,分布式存储采用了多副本备份机制。在分布式存储的容灾中,一个重要的手段就是多时间点快照技术,使得用户生产系统能够实现一定时间间隔下的各版本数据的保存。

victortp@mayu0630 本地采用分布式存储,远端灾备相关为了快速切换使用数据库本身的技术,oracle就是dg,这样架构简单且可靠。

2020-04-13 11:37
lcclcc其它, 城市商业银行
2020-03-30 14:30
现在分布式存储能提供的ipos读写带宽性能等都有很大的提升,底层存储集群如具体全nvme ssd配置的服务器,能达到绝大多数数据库级别所需的性能要求,很好的支撑各类存储使用场景。
pysx0503pysx0503系统工程师, 第十区。散人
2020-03-30 14:24
x86服务器运算能力的不断提高,网络带宽的不断加大让分布式架构的成本和性能都呈现出一个合适的位置。成为了很多业务架构升级的首选。只是现在很多厂商的产品众多。如果社区能有专门的针对分布式架构产品的性能和价格对比的文章就好了。可以帮助大家更好的去了解目前市场上主流的分布式架构产品。
wangzimingsq88wangzimingsq88软件开发工程师, 本钢矿业公司
2020-03-30 14:14
要是能增加一下各个厂家数据库应用对比就好了,实践最好有制造业方面的最好,因为制造业应用最多。

victortp@wangzimingsq88 只是部属的oracle和mysql基于类型db没有测试,不过挂载到windows上试了下,支持sqlserver也应当没有问题

2020-04-13 11:28
匿名用户匿名用户其它, 某银行
2020-03-30 14:08
你好,我有几个生产运行中的问题,不知道能否帮忙解答一下: 1.所有分布式存储的有一个无法避免的弊端——分布层通信带来的IO路径过长,会极大的增加IO的延迟,不知道你们在实际使用中,IO的延迟能到多高呢?据我观察,OLAP的数据库中,只要IO延迟高于50ms,就会明显感受到IO问题了,而我在使用全闪存储中,即使但PCIO吞吐达到6GB/S这么高,延迟也保持在5ms以下。 2.成本问题:QingStor NeonSAN这个我还没有接触过,但就我接触到的分布式存储,一般底层都是3副本模式(即使ceph也很少生产有用纠错码的),那么,数据冗余带来的每GB成本对比常见的IBM EMC存储,成本优势还明显么? 3.还是成本问题:其实从你们的数据量上考虑,X86 PC+ASM+全闪存储,是完全可以满足需求的,现在的全闪存储普遍容量在50T以上了,对于你们的业务来说应该是够的。不知道你们当时对比两个方案后总价差距有多大呢? 4.最后还是稳定性吧,因为分布式存储毕竟是一个较为新的领域,不知道贵公司在使用中,有没有一些比较明显的问题呢? 希望不吝赐教,谢谢谢谢~

victortp@匿名用户 1,部属不要跨机房,避免IO路径长,网络要接在单独的交换机上,正常数据库压力下IO延迟基于在个位数的毫秒级, 2,成本约1.5 w/实际可用TB,对比总成本相当原传统存储的40%左右 3,稳定性主要是来自于网络,经历过混用交换机到独占交换机的场景。 就像您所说的,分布式存储的稳定性与网络的规划和部属有必然的联系。

2020-04-13 11:36

匿名用户@victortp 感谢回复,后面等有机会了我也去实验一下~

2020-03-30 15:31

victortp@匿名用户 1,分布式存储集群放在存储区域网络下,统一配置25GB/100GB自适应交换机,严格控制收敛比,X86端配置10GB网卡,目前看没有问题。由于全PCIE卡式配置,IO延迟很低。 2,关于成本,三副本下可用存储空间1.5W/TB,比传统存储约3w~~4W,这个成本的节省还是相当明显的,还有一个优点是扩容方便,扩容90TB存储(3节点),硬件到位后部属时间约1天。 3,总差价相当明显,且X86指定 cpu 网卡 pcie卡,硬件适用性提高了,也降低了采购成本 4,稳定性在保证网络通畅的前提下还是比较好了,升级也方便,由于有三副本,关机升级即可。比较关键的是一定是保证网络的通畅,以及存储节点上不能有任何人工的大IO操作,比如dump内存之类的。

2020-03-30 15:18
Ctrl+Enter 发表

本文隶属于专栏

最佳实践
不同的领域,都有先行者,实践者,用他们的最佳实践来加速更多企业的建设项目落地。

作者其他文章

相关文章

相关问题

相关资料

X社区推广