一、背景与使用场景

随着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	2300G，10K(1) 8900G，10K(10)	2240G，SSD(10) 128T，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

创作场景

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