和15岁女儿做很舒服网站,爱采购卖家版下载,创意极简logo,中国网是什么级别的媒体一、背景与使用场景随着Kubernetes平台在容器云计算领域的一统天下#xff0c;云原生 (Cloud Native) 一词也被提的越来越频繁。各类应用纷纷走上了容器化、云原生化的道路#xff0c;无状态服务应用在Kubernetes平台上的运行#xff0c;已经得到了大规模生产级别的实践认可…一、背景与使用场景随着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还有提供了snapshotresize等功能完全满足我们的使用场景。 为了验证MySQL实例后端挂载CEPH块存储服务能否满足开发测试环境的数据库基本使用需求我们基于已有的硬件情况 做了两个场景的性能压测。主要是对比使用本地SAS磁盘存储的MySQL实例和使用CEPHRBD的MySQL实例在性能方面是否有明显差异。其次则是测试MySQL实例后端挂载CEPH RDB存储的性能上限。基本硬件信息如下 构造了两个测试场景使用sysbench执行压测sysbench参数如下测试场景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 以及provisionerattacher snapshotter等组件都是使用原生官方镜像在这里不做详细表述可以参考文档(https://kubernetes-csi.github.io/docs/)。MySQL-Operator作为自定义的控制器管理两种自定义资源(CRD)通过Kube-api为上层的PAAS平台和CI等系统提供MySQL实例服务。两个CRD分别是MySQLInstance和DatabaseSnapshot。其中MySQLInstance是基于StatefulSet的一层封装添加了一些metadataMySQL-Operator只需要根据MySQLInstance的声明来创建对应的StatefulSet和PVC即可 所以MySQLInstance暴露出来的spec并不多大致如下根据spec.init的类型MySQLInstance既可以是基于生产数据库Schema生成的空数据库实例也可以是基于已有的DatabaseSnapshot生成的带有基准数据的实例。在创建的过程中MySQL-Operator会为这个MySQLInstance申请域名同步账户密码以及Schema等。一个MySQLInstance的整个生命周期在有限的七个状态之间跳转。需要特别提一下Paused状态当基于该实例的DatabaseSnapshot创建时MySQLInstance会进入Paused状态。状态机如下另一个CRDDatabaseSnapshot则是基于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专注于云计算领域数年目前主要从事容器云平台的建设推进各类基础设施服务的云原生化。小石川目前主要从事容器云平台监控系统建设对分布式、性能以及优化感兴趣。’更多携程技术人一手干货请关注“携程技术”微信公众号。
