某大型保险集团在线财险业务系统存储架构由集中式向分布式转型实践
【作者】社区ID：victortp，某保险集团分布式存储架构师，有多年分布式架构及存储领域的工作经验。
一、背景分析
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服务器维保为采购时指定，无特殊费用。随着运行周期的增加，成本明显降低。 |
(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:33 | 2018/1/23 20:54:15 | 1小时8分钟 |
| 第二次 | 2018/1/24 7:56:42 | 2018/1/24 8:49:19 | 53分钟 |
在无并行应用场景下，相对于生产系统而言，跑批执行时长由原来的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:57 | 2018/1/24 12:15 | 79 |
| 第二次 | 2018/1/24 12:56 | 2018/1/24 14:08 | 72 |
| 第三次 | 2018/1/24 14:11 | 2018/1/24 14:57 | 46 |
| 第四次 | 2018/1/24 15:00 | 2018/1/24 15:30 | 30 |
| 第五次 | 2018/1/24 15:58 | 2018/1/24 16:30 | 32 |
结果分析：
在并行应用场景下，相对于生产系统而言，跑批执行时长由原来的2小时(生产系统实际执行时长)，缩短到了50分钟，执行效率有明显提升，而且，重复执行时间比初次执行时间由明显减少。
3. 测试总体情况分析
x86 + QingStor NeonSAN分布式存储的新生产环境下的单应用场景和多应用场景下的测试效果，均好于目前生产环境实际的执行效果，效率至少有30%的提升。此次采用x86计算+分布式块存储架构替换Oracle SuperCluster一体机是在满足业务发展历程中采用新架构的一次有益的尝试。
四、未来规划
一期已经部署容量为12TB存储服务集群，在未来三年，我们将根据业务情况对这套系统进行扩容和升级。在扩容规划方面，经过半年的持续运行，数据量增长至 17.8T，计划扩容六台存储节点提升现有核心生产数据库存储集群的可用容量。此外，我们已上线另外一套存储集群资源池用于DW业务系统，继续采用X86计算 + QingStor NeonSAN存储架构的数据库服务架构体系，逐步将网络接口从10GB升级至25GB，用以满足大容量、高性能存储集群对带宽资源的使用，同时将新增存储资源增加到 Oracle ASM中，平衡数据容量与业务压力。
点击文末阅读原文，可到社区原文下提问交流，或下载原文文档 觉得本文有用，请转发或点击“在看”，让更多同行看到
欢迎关注社区 以下技术主题 ，将会不断更新优质资料、文章。地址：
保险：http://www.talkwithtrend.com/Topic/21
分布式存储：http://www.talkwithtrend.com/Topic/23951
下载 twt 社区客户端 APP
长按识别二维码即可下载
或到应用商店搜索“twt”
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场