作者简介
Alex，专注于云计算领域数年，目前主要从事容器云平台的建设，推进各类基础设施服务的云原生化。
小石川，目前主要从事容器云平台监控系统建设，对分布式、性能以及优化感兴趣。
一、背景与使用场景
随着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 (github.com/ceph/ceph-c… )，其中RBD 部分早已GA，还有提供了snapshot，resize等功能，完全满足我们的使用场景。
为了验证MySQL实例后端挂载CEPH块存储服务能否满足开发测试环境的数据库基本使用需求，我们基于已有的硬件情况， 做了两个场景的性能压测。主要是对比使用本地SAS磁盘存储的MySQL实例和使用CEPHRBD的MySQL实例，在性能方面是否有明显差异。其次则是测试MySQL实例后端挂载CEPH RDB存储的性能上限。
基本硬件信息如下 ：
|
使用本地磁盘的容器宿主机 |
CEPH 集群所用物理机 |
|
|
CPU |
2Socket / 32Core / 64Thread Intel(R) Xeon(R) CPU E5-2650 v3 @ 2。30GHz |
2Socket / 32Core / 64Thread Intel(R) Xeon(R) 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等组件都是使用原生官方镜像，在这里不做详细表述，可以参考文档(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官方定义的持久卷快照声明(kubernetes.io/zh/docs/con… )。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)， 字面上早已经有了明确的定义(github.com/cncf/toc/bl… )，但是在工程实践中，基于Kubernetes这个巨大的平台，仍然有大量的宝藏等着我们去持续探索挖掘。
【推荐阅读】
携程技术新上市图书
《携程架构实践》《携程人工智能实践》
本周满100-50元优惠活动进行中，
扫下方二维码进
↓↓↓
“携程技术”公众号
分享，交流，成长
