作者侯守立

·2023-05-19 19:58

系统运维工程师·某保险公司

关注3

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

字数 5189阅读 969评论 1赞 5

内容摘要：

文章介绍了分布式数据库在保险应用系统架构演进中的应用，包括技术路线、高可用服务能力测试、OB2-2-2部署架构设计和环境配置等。重点介绍了磁盘和内存配置、问题与对策等内容。

当前摘要为AI生成

一、 **引言**

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

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

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

在业务交易类系统中使用分布式数据库，需着重保证数据库体系的高可用性；为测试该分布式数据库的高可用服务能力，在搭建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副本自动切主到其他节点。 |

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

表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。
![](/home/attachment/202305/19/1232119_168449722990924.png)
 图1： OB 2-2-2 部署架构

2. 基础环境配置

(1) 网络配置

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

(2) 网络策略配置

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

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

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

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

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

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

|   |   |   |
| ------------ | ------------ | ------------ |
| 端口 | 服务 | 说明 |
| 3306 | OB集群的VIP | 开通应用服务器可以访问OB集群的obproxy VIP |
| 2883 | OB集群的obproxy | 开通应用服务器可以访问OB集群的obproxy |
| 2881 | OB集群的observer | 开通应用服务器可以访问OB集群的OB节点 |
| 80/8080 | OCP前端页面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。
 以磁盘配置是480G*2 + 3.84T SATA SSD*8、内存配置是512G为例：
 1) 2块480G系统盘做RAID 1，用来安装操作系统，分50G挂载给根目录，分350G挂载给/home；
 2) 2块盘做RAID 1,划分2.1T挂载给 /data/log1；另外6块盘做RAID5,全部挂载给/data/1。
 其中，/var和/opt目录不要单独挂载分区。

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

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

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

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

五、 **结束语**

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

分布式数据库选型

著作权归作者所有

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

添加新评论1 条评论

yulu4314技术支持长春
2023-05-27 10:58

谢谢分享，已经阅读，学习了！

Ctrl+Enter 发表

匿名评论

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

添加新评论1 条评论

文章目录展开目录

本文隶属于专栏

作者其他文章

相关文章

相关问题