某银行基于虚拟化集成GoldenDB分布式数据库+全闪SAN存储创新架构承载OLTP/OLAP混合负载重要系统实践分享

字数 4947阅读 5132评论 7赞 5

内容摘要：

银行非核心业务类系统国产化数据库改造需考虑兼容性、大数据量存储、平滑迁移、高可用架构、运维管理和安全等问题，选型时需评分，采用集中式和分布式相结合的方式进行部署，实现多租户管理和统一运维管理平台。实践经验：采用基于虚拟化集成GoldenDB分布式数据库+全闪SAN存储资源池多租户模式承载OLTP和OLAP混合负载，提升资源利用率和灵活性。

当前摘要为AI生成

# 摘要：
银行行业数据库使用广泛，其中在非核心类应用中面临数据库种类多、SQL查询复杂、历史数据量大等共性问题，这些问题为非核心类业务系统的国产数据库的替换带来不小的挑战。本文从这些业务系统的特性及改造难点入手，基于国产数据库通用选型标准，结合实际的国产数据库的使用情况，分析国产化数据库多租户部署模式在非核心类业务系统中的实施成果。
# 1、银行行业非核心类重要系统国产化数据库改造
随着数字化浪潮以及信创改造的层层叠进，银行行业国产化数据库的转型也是进入深水区，在核心业务系统和非核心业务系统中全面展开。但当前传统的集中式数据库在银行行业应用占比仍然较高，从传统集中式数据库向国产化数据库的转型升级仍然面临着应用兼容性、系统可用性、性能和扩展性、迁移成本等一系列挑战。
## 1.1 非核心类重要系统应用特性
银行行业非核心类应用系统所使用的数据库多以传统的集中式数据库如Oracle、DB2为主，这类商业数据库产品成熟稳定、功能强大，满足性能和高可用要求。还有一部分应用系统使用开源MySQL或PostgreSQL数据库，应用在开发规范和SQL语法上具备更多的自主性和随意性。这一类应用系统和数据库使用有以下特性：
* 应用普遍存在大量的复杂查询和业务分析逻辑，使用大量的存储过程、自定义函数实现定制化的需求；
* 部分应用存储大量的历史数据，单库容量已经超过10T、甚至单表超过1T；
* 部分应用表和索引设计不规范、SQL语法不规范，存在冗余索引、索引过多等不符合开发规范问题；
* 高可用架构基于数据库技术如RAC、ADG或存储复制实现，部分应用如MySQL、PostgreSQL还是单实例运行；
* 应用系统和数据库与现有的开发运维体系深度耦合，包括资源交付、监控、变更、性能管理和应急等能力。

## 1.2 非核心类重要系统改造难点
非核心类交易应用系统由于各系统使用数据库种类众多、业务使用的复杂性，在实际的国产化数据库升级改造过程中，为满足应用最小成本改造以及平滑迁移，还需要克服不少难点：
* 存量存储过程和复杂SQL语句的兼容：国产数据库相比传统的集中式数据库，在存储过程和SQL语句的兼容性上存在一定的差距。部分应用可能存在上百个存储过程，在数据库迁移改造过程中，就需要针对这些存储过程进行针对性开发优化，以满足应用的需求，减少应用的改造工作；
* 复杂SQL语句性能差异：国产数据库的优化器对于复杂SQL语句的处理性能上普遍较弱，对于一些多表关联查询等复杂SQL语句需要应用配合优化
* 多种类型的数据库的兼容性：非核心类业务使用多种数据库，在国产数据库选型上是采用一种数据库兼容多种类型如MySQL系、Oracle系、PostgreSQL系，还是每一种类型的数据库选择一种国产数据库替换；
* 大数据量存储的适配：某些应用单表可能有T级别的数据，对于国产数据库存储这么大的数据量数据库性能上能否满足、运维管理的稳定性等；
* 应用平滑迁移：国产化替换迁移方案是否支持在线迁移，传统集中式数据库特殊字符集、存储过程、自定义函数等涉及到应用的改造工作量多大也需要评估；
* 高可用架构部署：国产数据库在部署的高可用架构上是否满足业务连续性要求，架构的稳定性和可用性验证、RPO及RTO的保证等；
* 运维功能对接：国产数据库与现有运维流程和平台的适配性对接工作，包括资源交付、监控指标及应急流程、版本和变更管理、升级维护等。
在核心类业务系统的国产化替换建设中，花费大量的人力物力进行应用开发优化、高可用场景验证、国产数据库的兼容性验证以及并网运行测试。而非核心类业务系统往往无法投入这么多成本进行国产化的替换升级，那么对应用改造最小、兼容应用现有功能和SQL特性、自身架构稳定和功能成熟的国产数据库产品是在选型考虑时候相当有必要的。

# 2、非核心类重要系统国产化数据库选型
在非核心类系统国产数据库选型的时候，在兼容现有应用功能的基础之上，满足应用性能和扩展性要求，按照选型标准模板进行评分，选择产品功能和架构成熟稳定的产品。
## 1）国产数据库选型标准
在国产数据库的选型过程中，按照数据库基本功能（35%）、数据库开发功能（20%）、数据库高可用能力（10%）、数据库运维管理（20%）、数据库安全功能（10%）和数据库其它功能（5%）等维度进行评分。同时在产品POC测试或选型测试过程中，按照每个细项维度逐一核对验证，最后对评测结果汇总评分，用于数据库产品的最终评估参考。选型通用标准模板如下表所示，实际参考时功能细项指标要按照每一类指标细分评估：
![表1 国产数据库选型通用标准 ](https://www.talkwithtrend.com/home/attachment/202402/06/922995_170720466150181.png )

## 2）国产数据库推广使用原则
非核心类业务系统由于存在存储过程、复杂SQL、数据量过大、数据库类型过多等特性，在国产化数据库改造过程中，按照以下原则进行推广使用。
* 优先考虑应用开发改造成本，对于存量应用数据库产品能够兼容大部分功能和需求，包括Oracle和MySQL语法的兼容性，对于新增应用应基于国产数据库的标准规范进行功能开发；
* 应用性能和系统架构扩展性保证，在保证存量应用当前的性能、数据存储和高可用架构下，优先使用集中式部署；当数据量或者性能受限于单节点的限制无法满足时，使用分布式数据库进行替换。
* 架构需可持续发展，结合业内的技术演进，确保当前的架构是未来的发展方向，并得到金融行业内部机构的认可。
当前大部分国产分布式数据库已经支持集中式部署，兼具分布式和集中式两种模式，在产品选型推广过程中满足分布式和集中式的部署场景。实际推广使用时候可以参照以下表格进行，利用虚拟化资源池和存储虚拟化满足集中式部署的计算性能和数据存储要求：

![表2 非核心类重要业务国产数据库部署原则 ](/home/attachment/202402/18/922995_170823846930889.png)

# 3、非核心类重要系统国产化数据库多租户架构设计
对于银行非核心类业务系统，集中式部署模式已经满足大部分应用需求，同时利用现在国产分布式数据库的多租户管理能力，按照租户维度进行管理，充分利用管理集群的资源和运维管理能力，减少应用集群的部署资源。如下图所示，应用集群或单元和租户一一对应，统一在数据库管理集群下进行管理和资源隔离。多租户下统一的数据库集群管理有以下好处：
* 租户之间的独立性：包括租户资源管理和资源隔离、用户管理、高可用部署和配置、备份恢复、变更维护和升级等等；
* 统一的运维管理接口：监控指标、性能指标等运维数据通过统一的标准接口对外暴露，便于现有运维平台的对接；
* 集中化的数据库管理集群：多个应用共用一套管理集群，相比较一个应用一套管理集群来说，更利于运维管理，也节约了部署资源，否则的话上百个应用有上百套管理集群。
[![图1 非核心类重要系统国产数据库多租户部署模式 ](https://www.talkwithtrend.com/home/attachment/202402/06/922995_170720471184175.png )

国产分布式数据库大都支持多租户管理模式，以GoldenDB数据库为例（如下图1所示），在同一套管理集群下部署多个租户，每个租户使用信创虚拟机部署（国芯+国产OS）、文件系统使用存储资源池进行分配，满足应用的计算性能和存储空间要求，避免单机PC服务器的性能和存储容量限制。
[![图2 基于GoldenDB数据库国的多租户部署架构 ](https://www.talkwithtrend.com/home/attachment/202402/06/922995_170720475398123.png )

上图2是基于GoldenDB数据库的典型的多租户单中心部署图，各应用按照租户独立部署管理，应用通过DB负载均衡访问数据库。在管理集群部署上，管理节点和全局事务节点是多个租户共用，每个租户的数据节点和计算节点为虚拟化主机、文件系统则是通过虚拟化的华为全闪OceanStor Dorad SAN存储资源池进行划分，整个部署从硬件、操作系统和数据库层完成了全栈信创。
非核心类交易系统有OLTP负载也有OLAP负载，如存储层采用本地盘架构存在如下缺陷：
* 计算存储资源耦合，独立扩容难，资源浪费多：系统容量扩容的时候，需要对节点上的数据进行重新分布，时间较长，影响业务；同时存储和CPU资源强绑定，性能达到瓶颈时候，往往CPU利用率还比较低，导致资源浪费。
* 磁盘故障恢复时间长：数据库服务器中的本地盘故障后，只能依赖重建数据库主备关系，数据复制时间长，同时影响生产数据库性能。
* 采用服务器本地盘部署的数据库存在磁盘利用率低，缺乏磁盘亚健康检测，磁盘坏盘/慢盘/磨损等问题导致数据库故障，并且带来了诊断困难等运维问题。
因此，国产数据库存储层采用全闪SAN存储资源池架构，来支撑OLTP和OLAP混合负载。

# 4、银行非核心类重要系统国产化数据库实施效果
使用分布式数据库集中式部署架构的多租户管理模式，单个数据库管理集群（受限于管理节点的资源）能够支持100+应用系统、1000+数据库实例集群。同时单个租户支持独立部署，在高可用架构以及数据库管理上相对独立，并且利用虚拟机和共享资源池支撑TPS<2000、存储<10T的性能和存储能力。
[![图3 非核心类重要系统国产化数据库多租户高可用架构部署实践 ](https://www.talkwithtrend.com/home/attachment/202402/06/922995_170720478037139.png )

## 1）高可用性
在部署架构上各租户独立部署（如上图3所示），管理节点按照多中心架构部署，各应用根据自己的业务连续性要求部署单站点、同城或异地环境。同时在容灾切换演练时候，各租户也是互不影响，做到了部署资源和架构上的隔离和灵活性。
## 2）性能横向和纵向扩展
各应用根据应用性能和存储空间增长情况，能够进行横向和纵向扩缩容，通过调整计算节点实例数、调整计算节点和数据节点的服务器配置以满足性能要求；调整虚拟机服务器挂载的文件系统，进行存储空间的扩缩容。基于虚拟化的CPU、内存和存储资源部署，实现计算和存储性能的灵活扩展，突破物理服务器的性能容量限制。
## 3）统一运维管理平台
多个租户由统一的数据库集群进行管理，包括资源纳管、高可用管理、用户管理、参数管理、监控告警、性能指标、备份恢复、统一API接口等运维管理功能。实际生产环境中按照不同的网络区域构建数据库运维管理集群，如互联网区、办公区、核心区和开放网络区域，每一类管理区域内部署不同的应用。

# 5、经验总结
本文主要介绍了银行行业非核心业务类系统在国产化数据库选型和优化改造过程中的一些实践分享。首先从非核心业务类系统的现状和特性入手分析，剖析其中应用在数据库国产化改造的难点；然后基于国产数据库选型的通用模型和标准进行选型评估，摸索适合业务和架构特性的部署模式；最终选型采用基于虚拟化集成GoldenDB分布式数据库+全闪SAN存储资源池多租户模式承载OLTP和OLAP混合负载。围绕多租户部署模式，详细介绍了高可用部署架构、功能特性以及实施效果。相比较其它国产集中式或分布式数据库以及使用本地盘方式部署，采用基于专业存储的存算分离架构，使用多租户的集中式部署，应用在部署和管理上更加独立和灵活外，同时复用了管理集群的资源，减少数据库集群的同时，也提升了资源的利用率。

**课题协作：**  
郜斌 某城商行 系统工程师  
李文涛 某城商行 存储工程师  
高剑 贵阳银行 存储工程师  
王之军 某城商行 系统工程师  
朱向东 某银行 高级工程师
**课题审核：**  
申俊杰 桂林银行 系统架构师

全闪数据库国产化 OceanStor Dorado GoldenDB 存储资源池

著作权归作者所有

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