MySQL 云原生方案在携程开发测试场景中的实践

一、背景与使用场景

随着 Kubernetes 平台在容器云计算领域的一统天下，云原生 (Cloud Native) 一词也被提的越来越频繁。各类应用纷纷走上了容器化、云原生化的道路，无状态服务应用在 Kubernetes 平台上的运行，已经得到了大规模生产级别的实践认可。

相比之下，有状态应用就没有那么顺利了，特别是那些十分重要却又 " 历史悠久 "、不是按照分布式架构理念设计的有状态服务，尤其困难。MySQL 就是其中的代表，为此我们做了诸多尝试，从一开始的 MySQL 单实例容器化使用本地存储，到计算存储分离的方案，走了一些弯路。最终在开发测试场景下找了一个合适的切入点，实现了一套计算和存储分离，以 Kubernetes Operator 为核心，以 CEPH RBD 为后端存储，以数据库版本化管理为特性的可行方案。

我们典型的使用场景是这样的：测试人员需要构造一个生产环境批量订单数据异常的测试场景， 他使用安全工具从生产环境拉取大量脱敏后的数据写入测试数据库，但只运行一次测试用例， 数据库就 " 脏了 "。特别是每次上新功能还要回归测试一次这种场景，又要重复耗时在构造新数据库，真的是“构造 2 小时，运行 5 分钟”。

而有了这一套完整的 MySQL 实例服务后，可以快速启动任意版本的数据库实例，前面所述的痛点就彻底消失了。同时有了 MySQL 实例服务，对 CPU 内存资源的使用也可以节省一大笔，毕竟大量的测试数据库都只要以快照的形式存储在集群中即可，实际使用时可以在一两分钟内快速启动。

二、可行性方案分析和性能评估

首先要解决的是计算和存储分离的问题，如果使用容器宿主机本地磁盘存储的话，MySQL 实例必须和宿主机绑定，这就丧失了资源的灵活性，而且使用本地存储， 对于磁盘容量的规划会是个不小的问题。

我们团队早在 2015 就开始使用 CEPH 存储服务，主要是对象存储和块存储，运维经验和集群稳定性方面相对有保证。结合这一实际情况，我们选择使用了 CEPH 块存储服务作为 MySQL 容器实例的存储。

另一个考量则是受益于 Kubernetes 这个强大的平台基座，社区已经定义好了容器存储接口 （CSI），且实现了 CSI driver for CEPH ( https://github.com/ceph/ceph-csi )，其中 RBD 部分早已 GA，还有提供了 snapshot，resize 等功能，完全满足我们的使用场景。

为了验证 MySQL 实例后端挂载 CEPH 块存储服务能否满足开发测试环境的数据库基本使用需求，我们基于已有的硬件情况， 做了两个场景的性能压测。主要是对比使用本地 SAS 磁盘存储的 MySQL 实例和使用 CEPHRBD 的 MySQL 实例，在性能方面是否有明显差异。其次则是测试 MySQL 实例后端挂载 CEPH RDB 存储的性能上限。

基本硬件信息如下 ：

使用本地磁盘的容器宿主机 CEPH 集群所用物理机 CPU 2Socket / 32Core / 64Thread Intel® Xeon® CPU E5-2650 v3 @ 2。30GHz 2Socket / 32Core / 64Thread Intel® Xeon® Gold 6130 CPU @ 2。10GHz Memory 188GB 256GB Disk 2*300G，10K(1)
8*900G，10K(10) 2*240G，SSD(10)
12*8T，7。2K(JBOD)

构造了两个测试场景，使用 sysbench 执行压测：

sysbench 参数如下：

参数名 参数值 备注 oltp-tables-count 64 测试表的个数 64 张 oltp-table-size 1000000 单表数据量 100W num-threads [8，16，32，64，128，256] 测试线程数 times of test 3 每个线程下的测试次数 warmup time 120 预热时间，避免冷数据对测试结果的影响 max-time 120 每次压测耗时 120s，重复 3 次

测试场景 A：分别压测 MySQL docker with CEPH RBD 和 MySQL docker with local disk，并发数 threads 从低到高，8→256，对比 QPS。

测试场景 B：同时压测五个 MySQL docker with CEPH RBD，保持并发数恒定在 256，观察 CEPH 集群 IOPS 和最终 MySQL QPS。

测试场景 A 结果：

OLTP 模式压测 MySQL，对于磁盘主要是随机读写操作，CEPH RBD 使用了 SSD 作为缓存盘，随机写速度约 110MB/s，而本地机械磁盘随机写速度只有 48.6MB/s，所以最终性能指标 QPS，使用了 CEPH RBD 的容器实例反而更好。

测试场景 B 结果：

压测 CEPH RBD 集群的磁盘 IO 上限，约算测试环境的集群能提供的 QPS 上限为 80K。

结论是在开发测试环境使用 CEPH RBD 为后端存储的 MySQL 实例服务，不会比使用本地磁盘更差，可以满足应用功能测试的性能需求。

三、MySQL 容器化实例方案及实现细节

介绍一下这套方案的简单架构设计和基本工作原理，如下图：

所有相关服务都部署在 Kubernetes 集群上，这里只重点描述我们开发的 MySQL-Operator 和自定义资源 CRD。关于 CSI driver 以及 provisioner，attacher， snapshotter 等组件都是使用原生官方镜像，在这里不做详细表述，可以参考文档 ( https://kubernetes-csi.github.io/docs/ )。

MySQL-Operator 作为自定义的控制器，管理两种自定义资源 (CRD)，通过 Kube-api 为上层的 PAAS 平台和 CI 等系统提供 MySQL 实例服务。两个 CRD 分别是 MySQLInstance 和 DatabaseSnapshot。其中 MySQLInstance 是基于 StatefulSet 的一层封装，添加了一些 metadata，MySQL-Operator 只需要根据 MySQLInstance 的声明来创建对应的 StatefulSet 和 PVC 即可， 所以 MySQLInstance 暴露出来的 spec 并不多，大致如下：

根据 spec.init 的类型，MySQLInstance 既可以是基于生产数据库 Schema 生成的空数据库实例，也可以是基于已有的 DatabaseSnapshot 生成的带有基准数据的实例。

在创建的过程中，MySQL-Operator 会为这个 MySQLInstance 申请域名，同步账户密码以及 Schema 等。一个 MySQLInstance 的整个生命周期在有限的七个状态之间跳转。需要特别提一下 Paused 状态，当基于该实例的 DatabaseSnapshot 创建时，MySQLInstance 会进入 Paused 状态。状态机如下：

另一个 CRD，DatabaseSnapshot 则是基于 VolumeSnapshot 的封装，其中 VolumeSnapshot 是 Kubernetes 官方定义的持久卷快照声明 ( https://kubernetes.io/zh/docs/concepts/storage/volume-snapshots/ )。MySQL-Operator 根据它的声明来关联 MySQLInstance 和 PVC 即可。

由于 CEPH RBD 的读写独占模式 RWO(read write once)， 我们为 DatabaseSnapshot 定义了两个常态 InUse 和 Ready。简单来讲就是一个数据库快照同一时间只允许一个数据库实例使用，并且 DatabaseSnapshot 在创建过程中需要暂停对应的 MySQLInstance，状态机如下：

四、小结与展望

在有了 MySQLIntance 服务之后，数据库的版本管理变得和代码版本管理一样灵活。特别是重复构造测试数据的场景，节省了大量的时间和管理成本。另外用户也不再需要长期占用计算资源，仅在有使用需求时即可快速创建 MySQLInstance，有效提高了整体容器宿主机资源的使用率。除此之外，上层 CI/CD 平台服务也可以通过 Kube API 调用的方式来管理这两种 CRD，进一步提升测试自动化程度。

一般来说，应用云原生化完成后最重要的是获得两个能力：弹性和分布式，目前我们的这套方案落地于 Kubernetes 平台，释放出了一部分平台计算和存储的弹性，让用户对于数据库实例有了更多的选择和灵活管理的能力。

何谓云原生 (Cloud Native)， 字面上早已经有了明确的定义 ( https://github.com/cncf/toc/blob/master/DEFINITION.md )，但是在工程实践中，基于 Kubernetes 这个巨大的平台，仍然有大量的宝藏等着我们去持续探索挖掘。

作者介绍：

Alex，专注于云计算领域数年，目前主要从事容器云平台的建设，推进各类基础设施服务的云原生化。

小石川，目前主要从事容器云平台监控系统建设，对分布式、性能以及优化感兴趣。

本文转载自公众号携程技术（ID：ctriptech）。

原文链接：

https://mp.weixin.qq.com/s?__biz=MjM5MDI3MjA5MQ==&mid=2697269592&idx=2&sn=2ebc6e51909422ae573fafcf943500c7&chksm=8376ee6cb401677a803bd57cb8e3859ee0a635ce965449d7cf3b81b6a2b7cb1f14b973580da2&scene=27#wechat_redirect