作者简介:
社区 ID : victortp 某保险集团 分布式存储架构师 有多年分布式架构及存储领域的工作经验
文章摘要:
国内某知名大型保险集团业务范围涵盖寿险、互联网财险、养老保险、企业年金、健康管理等多个领域,随着互联网业务的发展,核心数据库数据量井喷式增长,原有基于 Oracle 一体机的数据库架构已经不能满足业务增长的需要,催生了数据库平台自 Oracle 一体机向 x86 开放平台迁移的需求,采用新型分布式存储架构,提供数据库支持服务,与云端应用服务器一起构成混合云。该新架构是面向互联网的分布式架构,具备了弹性可扩展、 Scale-out 能力,满足了未来业务发展对存储性能和扩展能力的要求。
基于在线核心业务系统的运营,需 要 为业务提供极致性能,提供关键业务数据的高可用能力,保证发生意外时,核心数据不丢失。该保险企业在线财险业务系统核心数据库之前运行在 Oracle SuperCluster Solaris 平台上。
2015 年上线运行:
Ø 初始数据量约 2TB
Ø 业务连接数约 1000 左右
Ø 内存资源使用率 30% 左右
Ø CPU 资源使用率 40% 左右
经过 2-3 年的业务发展 :
Ø 数据量约 12TB ,增长量近 6 倍,根据业务的发展预测,以 10TB/ 年的速度递增;
Ø 虽然前端系统采用的外围数据库处理业务,业务平均连接数仍然达到了 4000 左右,增长近 4 倍;
Ø 内存资源平均使用率 80% ,增长近 2.6 倍;
Ø CPU 资源使用率 40% ,基本持平。
随着企业在线财险业务的迅速增长,原有的 Oracle SuperCluster Solaris 平台物理硬件资源趋于饱和。按传统处理方式,通常采购新的同架构 Oracle 一体机和服务,进行物理硬件平台的整体升级,保证数据库可以满足业务发展的需要。但是在不久的将来,当前所遇到问题仍会复现,死循环现象明显。另一方面,该型号的产品停产,不再支持扩容升级等支持服务。因此,当前 SuperCluster 一体机平台已经不适应业务发展的需要。
经过对目前的主流的存储架构进行调研和分析后,我们的视角转到了全闪分布式块存储上。
数据库一体机 | 小型机与集中式存储 | 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 。结构复杂,成本高,存在明显不足。这些架构已不能满足我们业务发展的需求,因此我们的视角转到了分布式块存储上。
经过对当前可选分布式块存储产品的调研和相关 POC 测试,我们最终选择了青云 QingCloud 的分布式块存储产品 QingStor NeonSAN ,提供数据库支持服务。以下是基于分布式存储的数据库架构:
该架构采用了标准 X86 物理服务器构成:
(1) 计算层:为三节点 X86 物理服务器作为 Oracle RAC 的计算节点,构成三节点数据库服务集群。
(2) 存储层:初期采用三节点全闪配置的 QingStor NeonSAN 作为底层的存储节点,构建存储服务集群,适用了高负载、并发用户数较高、 IOPS 要求较高的核心业务,存储层提供三副本块存储用于数据库存储卷且提供较高层次的故障保护。
(3) 网络层:由传统网络层提供传输,交换机无特殊配置。
经过了近二年的运行,此套分布式存储解决方案与传统方案对比,主要优势如下:
(1) 采用计算与存储分离的全分布式架构后,海量的数据压力分散到了多个并发存储节点,系统性能、吞吐量按照线性扩展。
(2) 全闪的存储节点之间采用 RDMA 互联,性能超越原有的一体机平台,存储系统提供负载均衡机制,有效避免单点性能瓶颈。
(3) 由开放的 X86 平台取代了传统数据库一体机与与集中式存储设备,大幅缩短了存储系统的建设与扩容周期,有效满足业务数据量激增的扩容需求,同时大幅度节省采购、维护与运营成本。
以下是针对真实业务场景在 X86 + QingStor NeonSAN 分布式存储开放式架构运行环境下的实测数据:
表 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 小时左右,执行效率有明显提升。实际运行过程中,并无这种应用场景,该场景用来考察存储设备在核心应用并行执行的高负荷下的运行情况。
表 3_ 生产系统平均执行时长
时间日期 | 平均时长(小时) |
2018年1月1日-2018年1月19日 | 2.7 |
2017年10月-2017年12月 | 1.6 |
生产系统从数据读取到抽取到目标端,平均执行时长为 30 分钟。
精算准备抽取退保、再保和理赔数据加工中的部分复杂 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 分钟,执行效率有明显提升,而且,重复执行时间比初次执行时间由明显减少。
x86 + QingStor NeonSAN 分布式存储的新生产环境下的单应用场景和多应用场景下的测试效果,均好于目前生产环境实际的执行效果,效率至少有 30% 的提升。此次采用 x86 计算 + 分布式块存储架构替换 Oracle SuperCluster 一体机是在满足业务发展历程中采用新架构的一次有益的尝试。
一期已经部署容量为 12TB 存储服务集群,在未来三年,我们将根据业务情况对这套系统进行扩容和升级。在扩容规划方面,经过半年的持续运行,数据量增长至 17.8T ,计划扩容六台存储节点提升现有核心生产数据库存储集群的可用容量。此外,我们已上线另外一套存储集群资源池用于 DW 业务系统,继续采用 X86 计算 + QingStor NeonSAN 存储架构的数据库服务架构体系,逐步将网络接口从 10GB 升级至 25GB ,用以满足大容量、高性能存储集群对带宽资源的使用,同时将新增存储资源增加到 Oracle ASM 中,平衡数据容量与业务压力。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞18
添加新评论17 条评论
2021-04-19 21:19
2021-02-07 08:58
2020-04-07 18:29
2020-04-03 06:43
admking: @victortp 看来还是要用传统的技术了。
victortp: @admking 用oracle自己的adg实现的,由于基于tcp网络的传输量太大,在带宽不足时经常有延时,还不如dg稳定可靠。
2020-04-02 16:25
2020-04-02 16:15
2020-04-02 16:13
大老虎: @saric oracle 这种方式,应该就是纯数据在线迁移了,我想也就是表分区的迁移,创建新的表空间,迁移分区,下线老的表空间。
victortp: @saric 主要就是需要 xttr这方面需要反复测试,这个环节搞定后,其它的基本没有问题。
2020-04-02 16:04
2020-03-31 12:56
victortp: @jim8602 从性能测试上青云当时是做得最好了,另外还有一个厂商的东东,不过那个是基于cepH的在高压力数据库上一测试就出局了。
2020-03-31 12:44
patrick_zheng: @yangyuhang 1、高级功能指哪些高级功能?目前QoS、克隆等功能都是支持的; 2、数据稳定性依托强一致副本,软件架构稳定性基于去中心化,无单点故障,网络稳定性依托于全冗余的网络设计; 3、快照基于COW技术; 4、暂时不支持压缩去重; 5、暂时不支持快照一致性组,这部分功能依托QingCloud IaaS平台完成; 6、同上; 7、快照不支持读写; 8、可以。
2020-03-30 15:52
victortp: @woshishui072612 三副本下,在前期部属时确保多副本不在一台主机上的前提下,三节点任一节点下线不影响稳定运行,迁移时基于xttr的恢复机制,可以做到迁移窗口所需时间最短,两者都还是要结合起来才好。
2020-03-30 15:30
2020-03-30 15:19
victortp: @mayu0630 本地采用分布式存储,远端灾备相关为了快速切换使用数据库本身的技术,oracle就是dg,这样架构简单且可靠。
2020-03-30 14:30
2020-03-30 14:24
2020-03-30 14:14
victortp: @wangzimingsq88 只是部属的oracle和mysql基于类型db没有测试,不过挂载到windows上试了下,支持sqlserver也应当没有问题
2020-03-30 14:08
victortp: @匿名用户 1,部属不要跨机房,避免IO路径长,网络要接在单独的交换机上,正常数据库压力下IO延迟基于在个位数的毫秒级, 2,成本约1.5 w/实际可用TB,对比总成本相当原传统存储的40%左右 3,稳定性主要是来自于网络,经历过混用交换机到独占交换机的场景。 就像您所说的,分布式存储的稳定性与网络的规划和部属有必然的联系。
匿名用户: @victortp 感谢回复,后面等有机会了我也去实验一下~
victortp: @匿名用户 1,分布式存储集群放在存储区域网络下,统一配置25GB/100GB自适应交换机,严格控制收敛比,X86端配置10GB网卡,目前看没有问题。由于全PCIE卡式配置,IO延迟很低。 2,关于成本,三副本下可用存储空间1.5W/TB,比传统存储约3w~~4W,这个成本的节省还是相当明显的,还有一个优点是扩容方便,扩容90TB存储(3节点),硬件到位后部属时间约1天。 3,总差价相当明显,且X86指定 cpu 网卡 pcie卡,硬件适用性提高了,也降低了采购成本 4,稳定性在保证网络通畅的前提下还是比较好了,升级也方便,由于有三副本,关机升级即可。比较关键的是一定是保证网络的通畅,以及存储节点上不能有任何人工的大IO操作,比如dump内存之类的。