金融行业专题｜某头部期货基于 K8s 原生存储构建自服务数据库云平台

为了进一步提升资源交付效率，不少用户都将数据库应用从物理环境迁移到容器环境。而对于 Kubernetes 部署环境，用户不仅需要考虑数据库在性能方面的需求，还要为数据存储提供更安全、可靠的高可用保障。

近期，某头部期货机构基于 SmartX Kubernetes 原生存储 IOMesh 和某国产 RDS 数据库云平台，构建了自服务的云原生数据服务平台，满足应用需求高效交付的同时，以多副本数据保护机制提升了整体架构的可靠性和可用性。自服务的数据库云平台如何建设？支持数据库云平台的存储如何选型？我们将通过下文详细分享。

下载电子书《Kubernetes 持久化存储方案选择：从入门到评估》，深入了解云原生存储解决方案选型与实践

实践背景

某头部期货机构 IT 系统正逐步从传统架构向虚拟化、云原生、微服务、分布式的架构演进。基础架构团队作为核心支撑层需要及时响应业务团队需求，快速提供所需资源并保证系统的稳定和可靠性。目前，通过交付容器资源，期货机构已经完成大量的业务应用容器化部署，满足大部分无状态业务应用需求。但是对于数据库类有状态应用的交付始终无法满足业务场景的需求：

• 资源申请效率低：业务团队每次申请数据类服务资源都需要描述需求，两个团队在需求处理过程中涉及大量重复性沟通工作，效率低。
• 资源交付慢：通常采用物理机部署的形式来为某个业务应用提供数据服务，比如：达梦数据库（1 主 1 备）和 MySQL 数据库（1 主 1 备 1 从）。基础架构团队每次都需要部署物理机，且每一套系统都需要考虑容灾备份的需求，工作量极大，资源交付速度很慢，通常是以“天”为单位。
• 资源利用率低：每一个业务应用都需要一套独立的数据库，每个数据库集群利用率不同，无法合理利用同一套硬件资源，造成明显的资源浪费；同时如果有新的业务应用需要数据服务，由于硬件资源紧缺，势必会进一步降低资源交付速度，形成负向循环。

为了满足不同业务应用的数据服务需求，提升资源申请效率和资源交付速度，期货机构决定以 Kubernetes 集群为底座构建数据库自服务云平台，使得业务团队可以通过此平台的图形化界面自助申请所需要的数据库服务。虽然用户在云原生领域积累了很多经验，但是“数据库上容器”对于他们来说也是一次比较大胆的尝试，尤其是在存储支持层面存在很多挑战：

1. 数据库的虚拟机和容器化的部署方式有很大差异，如何在 Kubernetes 中快速部署生产级别高可用的数据库集群？
2. 不同的存储引擎该如何实现统一管理？
3. 如何在存储层面提升数据冗余性保障数据存储安全，实现数据的双保险? 即使业务团队创建了一个单节点的数据库集群，数据库节点出问题后存储层面也需要能够保证数据安全性。
4. 存储层面如何实现较高的性能来满足未来更多核心应用的需求？
5. 数据库和存储如何无缝融合并提升团队的运维效率？
6. 方案还需符合信创要求。

基于此，该期货机构的基础架构团队计划对支撑数据库自服务云平台的存储方案进行选型和评测。

存储选型：多种方案评估与性能实测

数据库平台

期货机构使用的数据库平台为某国产 RDS 数据库云平台（以下简称“RDS”）。该平台基于 Kubernetes 云原生技术，提供 Oracle、MySQL、达梦等主流数据库服务。

存储

在存储方面，期货机构原有 3 种可供选择的方案，但都存在一些弊端：

传统方案：以 RDS 数据库对接既有分布式存储集群和集中式存储集群。但该方案由于性能低、成本高、运维效率低等问题，在首轮评估时遭到放弃。

新兴方案：

• 使用开源云原生存储：该方案缺乏核心生产环境的长时间使用验证，同时存储核心并非基于自研技术，用户不敢直接拿来承载自服务数据库平台。
• 使用本地存储 LocalPV：数据冗余保护能力不足，运维较为复杂，但性能高，可满足数据库场景需求。

现有方案中，LocalPV 性能很好，但是数据冗余性很低，有很大的数据安全风险。此时用户面临了一个性能与数据安全性的矛盾，期望找到一款既能满足数据安全性，同时性能也可以接近 LocalPV 的存储产品。

在对多种企业级云原生存储方案进行调研的过程中，用户了解到 SmartX 推出的 Kubernetes 原生分布式存储 IOMesh。IOMesh 是具备云原生特征的分布式存储系统，其核心由 SmartX 自主研发，具备生产级别的高可用机制和运维支持功能，同时可为有状态应用提供高性能数据存储服务。深入了解后，用户计划对 IOMesh 与 Local PV 支持 RDS 的性能和可靠性进行对比测试。

对比测试：多种数据库场景下 IOMesh 与 Local PV 性能相当，可靠性更佳

测试环境

硬件配置

软件版本

性能对比

分别创建 32C128G 的达梦数据库集群（主备）、MySQL 数据库集群（主备从）和 PostgreSQL 数据库集群（一主两备），进行标准压力测试，通过 sysbench 压测数据库，验证 Local PV 和 IOMesh 两种存储方案下的数据库性能。结果显示，在达梦数据库、MySQL 数据库和 PostgreSQL 数据库场景下，IOMesh 性能均与 Local PV 非常接近，IOMesh 的性能表现超出用户预期，可充分满足用户使用需求。

可靠性对比

此外，为了验证 IOMesh 的可靠性，用户在达梦数据库场景下模拟了节点故障场景，验证数据库主备切换和主备集群恢复的过程。

• 当主库运行节点故障，主库 HA 漂移且拉起时间小于数据库主备切换时间，主备没有发生切换。此时后台可自动完成主备修复，由于多副本数据保护，主备修复时间较快。
• 当主库运行节点故障，主库 HA 漂移且拉起时间大于数据库主备切换时间，主备发生切换。此时后台亦可自动完成主备修复，由于多副本数据保护，主备修复时间较快。

除了多副本机制，IOMesh 还可提供 PV 的秒级快照能力、业务优先的智能恢复策略，以及优化的 Pod HA 机制，进一步提升容器环境的可靠性。欲深入了解，请阅读：Kubernetes 节点故障而 Pod HA 失败？IOMesh 优化机制提供高级别高可用存储。

平台建设：以 IOMesh+RDS 构建自服务数据库云平台

基于以上测试，期货机构对 IOMesh 的性能和可靠性非常满意，最终决定以 IOMesh 作为 RDS 数据库平台的存储方案。目前，用户已在生产环境和测试环境分别部署若干套 IOMesh 集群，为 RDS 数据库服务提供高性能、高可靠的存储支持。利用 IOMesh 和 RDS，用户实现了自服务的云原生数据服务平台，业务团队仅需要三步就可以自主实现数据库服务的部署：

1. 登录数据管理平台。
2. 选择需要部署的数据库服务、高可用架构。
3. 提交部署。

得益于 IOMesh 卓越的性能、可靠的数据保护机制和丰富的运维支持功能，整套数据库云平台为用户带来了如下收益：

• 提升资源申请效率：自服务式的数据平台提升了资源申请的效率，原来需要人工申请、跨部门沟通操作，现在仅需数秒点击即可实现服务的自主部署。
• 提升资源交付速度：数据类服务的交付速度从原来的以“天”为单位，提升到以“分钟”甚至“秒”为单位，满足了业务的需求。
• 提升数据存储可靠性：Local PV 具备单点故障风险，缺少可靠的数据保护机制；IOMesh 通过多副本数据保护机制、快照保护等生产级高可用功能，可进一步加固存储数据安全。
• 提高架构可用性：借助 IOMesh 多副本（本地优先、局部化和容量均衡）能力，支持数据库节点按需切换、主备切换等操作，无需应用方配合。
• 提升资源利用率：引入 IOMesh 前，用户需要部署 22 节点物理机支持 8 个达梦数据库主备集群和 2 个 MySQL 数据库主备从集群；引入 IOMesh 后，仅需 3 个 IOMesh 节点即可支撑 10 个 RDS 数据库，且仍有资源余量。
• 实现资源与基础设施监控：IOMesh 通过统一的 UI 界面即可查看系统的 I/O 性能情况和所有磁盘的健康状态，帮助运维人员及时发现问题并优化运维方案。
• 提升管理效率：IOMesh 和 RDS 可无缝对接统一管理，并且由基础架构部门统一运维，无需跨部门沟通和运维。
• 整套方案符合信创要求。

在 IOMesh 的支持下，用户的云原生数据服务平台已稳定运行近 1 年的时间。用户也在同时使用 IOMesh 支撑 KubeVirt 容器虚拟化场景，为虚拟机和容器提供统一的存储服务。未来，用户还计划使用 IOMesh 集群支持更多核心类业务系统，以及消息中间件等应用场景。关于 IOMesh 支持 KubeVirt 的方案与实践，请参考：利用 IOMesh 为 KubeVirt 提供高效稳定的存储支持（附用户实践）。

目前，IOMesh 已发布 1.1 版本，提供了全新的可视化管理界面和存储性能的增强，进一步提高运维效率，并为生产应用提供更强大的支持。我们将在未来分享更多关于新版本的技术解读与用户实践，敬请期待！

您还可下载阅读电子书《Kubernetes 持久化存储方案选择：从入门到评估》，深入了解面向 Kubernetes 的持久化存储的相关概念、技术路线、产品对比与选型建议。