侯守立
作者侯守立2023-05-19 19:58
系统运维工程师, 某保险公司

运用分布式数据库推动保险应用系统架构演进浅析

字数 4551阅读 901评论 1赞 5

一、 引言

随着各种数字化技术的应用,保险客户对保险服务的线上化需求越来越多;为应对不断增加的线上化服务需求,并通过业务创新和产品迭代提升公司的竞争力,公司需要持续推进数字化转型,推动数字化与业务、服务的全面融合,就需要敏捷高效的科技基础架构支撑;而传统的基础架构受限于成本、建设周期及扩展性等难题,难以有效满足保险公司创新的需要。同时,因为各种原因,保险公司的基础设施多采用国外设备与软件,如何保障基础设施安全和自主可控的需要,也要求保险公司必须探索和实践国产化软硬体体系的迭代升级;而基础软件与应用软件的升级替换由于场景复杂、需求差异化和涉及面广,显得尤为困难。

二、 数据库选型与测试分析

公司数字化转型过程中,需要持续提升线上化水平,这势必大幅增加数据交易量和并发量;同时互联网类系统和功能的大范围应用使得公司的基础设施,特别是数据库面临不脉冲式的使用压力,现有数据库难以支撑,需要对未来数据库进行选型和迭代升级。因公司大数据体系架构经过多年的建设,已基本实现自主可控的升级迭代;基础数据库体系主要针对公司管理类、业务交易类等应用系统提供服务;通过对生态体系、行业案例、技术支持力量、现有数据库迁移匹配及应用系统体系架构匹配等情况进行综合分析,选定某型分布式数据库作为未来数据库体系演进的主要技术路线,并对该分布式数据库进行了一系列的测试。

在业务交易类系统中使用分布式数据库,需着重保证数据库体系的高可用性;为测试该分布式数据库的高可用服务能力,在搭建POC环境时,分布式数据库集群为双机房主备集群架构。其中,主集群采用为3副本模式进行部署,每个副本部署2台server,即2-2-2架构;备集群为3副本模式进行部署,每个副本1台server,即1-1-1架构。

测试过程中,设计了server进程宕机(leader 副本)、server进程宕机(follower)、数据库反向代理进程退出、数据盘的数据丢失及集群单zone整体宕机等五个场景,基本达到预期要求。

  1. server进程宕机(leader 副本)场景

表1: server进程宕机测试用例

测试目的server宕机,集群正常工作,访问该节点上的副本的交易恢复时间RTO<30秒
预置条件数据库集群运行正常
测试步骤持续运行sysbench脚本登陆任意节点,将Server进程杀掉检查sysbench压测程序流量恢复时间
预期结果少数成员故障的情况下,受影响的业务租户在秒级恢复(RTO<30秒):
实测结果1.运行Sysbench 命令 (运行5分钟)2.执行杀进程后,副本leader 节点进程被杀掉,集群租户的leader 执行了切换3.进程杀掉后,sysbench 的写入动作中断,然后再30内恢复,实际恢复时间为2秒内恢复4.手动恢复节点5.恢复后副本leader切回原节点
测试结论测试结果符合预期: leader 节点observer进程被kill后,写入脚本中断写入并且在30s内自动恢复,leader副本自动切主到其他节点。

  1. 数据盘的数据丢失场景

表2: 数据盘数据丢失测试用例

测试目的数据盘硬件问题或文件系统问题导致数据盘上数据全部丢失的情况,测试观察集群状态和如何恢复
预置条件数据库集群运行正常,丢失数据自动同步补全
测试步骤Sysbench 运行停止observe进程删除 /data/1/cluster_name/ 下的文件删除后,手动启动observer进程进程启动后,观察集群状态和__all_server表状态
预期结果预期数据同步在执行,同时,经过数据同步后,节点数据追平并且正常提供服务;整个过程集群运行正常
实测结果1.执行sysbench 脚本2.找到租户所在的leader 节点3.手动清理掉/data/1 目录下的文件4.刚刚删除Sysbench 运行情况正常,未发生切主;当触发switch new clog failed , observer 会自动推出
测试结论测试结果符合预期,将leader节点数据文件删除后,当机器observer退出后,leader切主。集群正常使用

三、 数据库应用架构设计及配置

  1. 数据库应用架构设计

根据公司主备机房基础设施自主可用建设情况,结合各应用系统数据库使用需求及系统实施计划安排,经各技术团队分析、讨论与验证,针对主机房两个区、备机房一个区,分布式数据库集群选用3副本模式进行部署,每个副本部署2台server,即2-2-2架构;其中主机房设置两个zone,备机房设置一个zone。

图1: OB 2-2-2 部署架构

  1. 基础环境配置

(1) 网络配置

每个机柜上放置两组万兆ASW交换机,两组ASW交换机做堆叠互为高可用,交换机分别接服务器的两块万兆网卡;网卡做绑定,配置mode4模式,交换机配置为802.3ad。ASW上联DSW做汇聚,DSW上联ISW做对外服务接入;其中,不要使用team做绑定,因为team会导致无法识别/sys/class/net/team0/speed里面的网卡速度。

(2) 网络策略配置

因生产环境网络策略控制严格,为保证OB各服务之间的正常访问使用,需开通必要的网络访问策略。

OB和OCP之间的端口策略为:

表3:OB与OCP端口策略开通表

端口服务说明
3306OCP集群的VIP开通所有OB和OCP服务器访问OCP集群的obproxy VIP
80OCP API服务的VIP开通所有OB和OCP服务器访问OCP集群的API VIP
2881/2882/2883OBServer进程;OBServer内部通讯;OBProxy进程开通所有OB和OCP服务器的2881/2882/2883端口互访权限
22/2022/2881-2884/2911/2912/8080/62881-63881Obagent所需端口开通所有OB服务器到所有OCP服务器的指定端口访问
22/2022/2881-2884/2911/2912/8080/62881-63881Obagent所需端口开通所有OCP服务器到所有OB服务器的指定端口访问

应用服务器到OB的端口策略为:

表4:应用与OB端口策略开通表

端口服务说明
3306OB集群的VIP开通应用服务器可以访问OB集群的obproxy VIP
2883OB集群的obproxy开通应用服务器可以访问OB集群的obproxy
2881OB集群的observer开通应用服务器可以访问OB集群的OB节点
80/8080OCP前端页面VIP;OCP节点开通需要访问OCP管控页面的机器的访问策略

(3) OS及磁盘配置

因基础环境自主可控迭代的需要,操作系统选用了麒麟操作系统;在安装OS时,需每台服务器均配置相同的操作系统版本做为yum源并挂载在本机上,时区设置为上海。

OS主要配置注意事项为:

1) 麒麟V10操作系统版本的内核不能低于4.19.90-23.8.v2101.ky10;
2) 需要关闭auditd防止内存OOM,修改/boot/grub2/grub.cfg(legacy启动模式下的路径)、/boot/efi/EFI/kylin/grub.cfg(EFI启动模式下的路径)或者/etc/default/grub下的GRUB_CMDLINE_LINUX,在指定位置添加参数“security= audit=0 idle=nowait”。

BIOS配置为:

1) BIOS需要关闭选项:
关闭SMMU:Advanced > MISC Config > Support Smmu > 设置为“Disable” ;
关闭预取:Advanced > MISC Config > CPU Prefetching Configuration > 设置为“Disable” ;
关闭NUMA:Advanced > Memory Config > NUMA > 设置为“Disable” ;
关闭省电模式:Advanced > Performance Config > Power Policy > 设置为“Disable” 。

2) BIOS需要开启项:
启动顺序1:HDD > Network > USB ;
启动顺序2:HDD 启动项中,第一块盘作为第一启动项 。

磁盘划分配置为:

查看/sys/block/*/queue/hw_sector_size,如果不是512,需要联系服务器厂商更新磁盘驱动,修改sector size为512。
以磁盘配置是480G2 + 3.84T SATA SSD8、内存配置是512G为例:
1) 2块480G系统盘做RAID 1,用来安装操作系统,分50G挂载给根目录,分350G挂载给/home;
2) 2块盘做RAID 1,划分2.1T挂载给 /data/log1;另外6块盘做RAID5,全部挂载给/data/1。
其中,/var和/opt目录不要单独挂载分区。

四、 架构演进中遇到的问题与对策

架构演进是个体系工程,涉及到方方面面,需要不断优化、迭代升级。在引入自主可控的分布式数据库过程中,对基础架构团队、研发团队和运维团队都有着不小的挑战,出现了诸多问题,各团队也在问题的分析和解决过程中,不断成长,为后续应用系统的升级和迭代积累了宝贵的经验,形成了较为完善的迁移和使用规范。

主要问题 :各技术团队的技术存储不足,对分布式数据库的最佳实践了解不够,评估与实施周期被拉长,上线生产后遇到了较多问题;生产环境部署采用分布式存储,各节点为存算一体化管理,部署后进行验证时发现IO读写速度达不到预期,经联系硬件厂商协助排查,进行必要参数调整和优化,问题得以解决;分布式数据库的备份管理、备份策略、恢复性测试及容灾模式等技术实现、管理操作和传统数据库有较大差异,和现有管理制度和规范有一定的冲突,需要更新完善;公司数据中台现有的数据同步技术不支持分布式数据库的同步,需要部署和调试新的同步插件;并遇到日常监控、运维管理及性能优化等一系列问题。

应对策略:成立数据库体系迭代推进小组,包括系统架构、基础软硬件、研发、运维和安全等各条线人员;联系分布式数据库的技术支持,针对硬件基础团队、研发团队和运维团队组织技术培训,并与行业已实施的技术团队展开交流;加强基础设施、应用系统等多维度测试,及时发现问题并设计对应的解决方案;按照从外围到核心,从管理类系统到交易类系统,由易到难,逐步进行数据库体系的迭代更新,取得实践经验后,再加快推广;及时总结经验得失,对实施方案进行优化改进,持续演进,不断完善。

五、 结束语

通过运用自主可控的数据库进行应用系统架构演进的尝试,可以基本满足业务创新和自主可控的相关要求,但实施过程中也遇到了各种难题,距离全面推广尚有很长的道路要走。前一阶段迭代升级中,为降低实施难度,选择了外围管理类和简单业务交易类系统作为试点,并且全部为新建系统,并不涉及历史数据迁移问题;在下一阶段,我们将逐步深入推广至现有应用系统的迭代升级,探索存量数据迁移的实施,构建适用各类场景的、高效和敏捷的数据库服务体系。

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

5

添加新评论1 条评论

yulu4314yulu4314技术支持, 长春
2023-05-27 10:58
谢谢分享,已经阅读,学习了!
Ctrl+Enter 发表

本文隶属于专栏

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

作者其他文章

相关文章

相关问题

X社区推广