京东MySQL数据库Docker化最佳实践（附PPT）

刘风才

京东资深数据库专家

 

 

• 2012年加入京东，担任MySQL DBA一职，负责数据库架构设计、数据库性能优化等日常运维工作，参与过分布式数据库项目、多中心交易项目等。

• 2013~2016连续4年作为MySQL数据库618、11.11项目DBA负责人，负责相应备战工作，为大促平稳护航。

演讲大纲：

京东MySQL数据库Docker化的推进之路，从开始如履薄冰的使用，到目前占比超过70%以上的大规模部署，下面给大家一一讲解这期间的发展历程。

Docker技术的发展为MySQL数据库部署环境能够容器化奠定了基础。京东Docker技术的发展可以归纳为3个阶段：

1、初出茅庐

京东从2013年开始规划虚拟化平台项目。可以说，一切从零开始，组建团队，架构采用当时主流的OpenStack+KVM架构，在发展初期，只有一些非核心的应用服务开始跑在kvm上。虚拟化研发团队在技术上很快掌握了OpenStack核心代码，当时来说，OpenStack对VM支持可以说是天生的好，在各方面认为成熟的时期，虚拟化团队满怀信心地接入了一个核心业务，不幸的是，正是这个核心业务给虚拟化团队带来了不小的打击，在性能上tp99无法缩短到40ms以内，无法满足应用服务的性能要求，在2013年夏天-2014年夏天研发尝试了各种方法，进行改造优化，最终仍无法达到物理机的性能水平。这一年对于虚拟研发团队来说是压抑、苦闷，也是积攒经验的一年。

2、小试牛刀

2014年9月，公司安排首席架构师刘海峰带领虚拟化团队。他提出一套新的方案、新的思路，Docker由此进入京东。2014年6月 Docker1.0发布，当时Docker还非常单薄，只有镜像和对cgroup简单的操作功能是可用之处，由于虚拟化研发团队在过去一年的压抑，这一新的思路对于团队来说无疑是希望，经过简单的二次开发后，进行了基本性能测试，惊喜地发现TP99可以部分降低到40ms以内，虽不完美，但对于团队来说，这已经看到了曙光。

经过研发团队的不谢努力，性能问题终于完全解决了。但另一个问题接踵而来，如何管理众多的Docker容器？自己开发时间成本太大，基于团队过去一年里在Openstack方面经验的积累，团队最终选择OpenStack + Docker的架构，并命名为京东第一代容器引擎平台JDOS1.0(JD DataCenter OS)。

3、驾轻就熟

解决了性能问题、批量管理的问题后，京东第一代容器引擎平台推广速度极快，从15年起步到 16年618已完成100%应用业务环境容器化，并经受住了618大促的考验。到目前为止，京东Docker部署已近15万个左右，可以说是规模最大的Docker集群。

先谈一下京东MySQL数据库发展的历程。京东从2011年开始使用 MySQL数据库，在此之前以SQL Server为主。2012年以后，MySQL数据库迅速在京东崛起，爆炸式增长，到2013年 MySQL数据库就占了京东交易系统的一半，发展到2014年、2015年，MySQL已经成为京东主流的数据库。并且数据库服务器规模不断增大。下面看看选择Docker化会带来哪些收益呢？

1、快速部署

数据库服务器实例创建只需要1分钟，和物理机os安装相比，速度提升了几十倍。

2、动态扩容

空间问题对于DBA来说，可以说是比较常见的问题。随着业务的发展，磁盘使用超出了预先的评估，使用Docker在一定条件下可以在线扩容，方便快捷。但这并不是解决空间问题的最佳方案，数据可能不断增长，但磁盘空间不可能无限扩容；基于性能、长远考虑，建议进行数据结转、数据清理或者库表拆分等操作。

3、提升资源利用率

随着SSD硬盘成本的降低，SSD服务器使用越来越普遍，IO性能也有了很大提高，对于数据量小的数据库系统单独部署在物理机，在成本上考虑存在着浪费，但如果采用多库合用或多实例部署，这虽然可以提升了资源利用率，但无法避免物理资源竞争、相互影响问题，而Docker在物理资源上良好的隔离性，恰恰可以解决这一难点。

也许有人会问Docker和虚拟机的区别？其实这两者是有本质区别的。虚拟机的本质上是模拟。通过模拟物理机上的硬件，向用户提供资源。容器的基石是经过隔离与限制的linux进程。容器提供的是性能损失更小的原生物理机的计算能力，容器之间唯一共享的是linux内核。

4、降低成本

资源利用率提高了，节约了服务器资源、机架位资源，提升经济效益，降低了成本。

5、成熟的Docker技术

最重要的一点，京东在Docker技术上的逐步成熟，应用部署环境100%容器化，有了丰富的经验，有专业的团队的技术支持，并经历618、双11大促的考验。

1、Docker管理页面的开发

实现Docker申请创建、暂停、开启、在线扩容等功能，方便DBA日常操作。

2、制定Docker容器分配算法

数据库高可用是不容忽视的。在Docker容器分配时如何保障主从不在同一宿主机上呢？

下面介绍一下分配算法原理：如果一个集群申请的数据库服务器大于1，调度时会为每一个容器选择合适的宿主机，主要是根据宿主机的状态（是否正常可用）、宿主机上的可用资源（cpu、内存、磁盘容量）是否满足申请的容器规格，将集群中所有的服务器都筛选完后，会计算服务器的权值，从中选择最适合的服务器作为宿主机，然后在内存中记录下这个宿主机，下一个容器选择宿主机时，会在筛选服务器的过程中加上一个判断，如果这个服务器已经被选中过作为宿主机，则过滤掉这个服务器。

3、Docker模板的制定、调度算法优化

提升磁盘IO性能。灵活的调度算法，如某系统对IO性能要求高，在Docker容器创建时，根据传入的参数，调度算法会在筛选合适的宿主机时，根据宿主机负载情况，选择压力最小的作为宿主机。

4、Docker 管理平台与数据库管理平台结合

实现Docker容器批量申请、下线等一键化操作。实现Docker日常运维查询工作，例如：根据宿主机IP查询该宿主机下所有Docker信息，根据Docker IP查询该宿主机及其下所有Docker信息等功能。

5、监控项调整

监控对运维来说是重中之重，京东MySQL 数据库监控采用的是Zabbix监控。在监控负载值获取上Docker与物理机是有区别的。在Docker上我们无法通过os系统命令抓取系统负载情况，目前京东的实现方式：在宿主机上通过专门开发监控程序，把计算结果实时存储到Redis中，Zabbix从Redis中读取对应监控值。

随着Docker集群规模越来越大，在推广中也经历了些痛点，下面我们来扒一扒踩过的坑，以及是如何解决的：

1、OpenStack集群规模受限。OpenStack遇到集群规模的问题，发生严重的信息不可靠问题；如：创建容器消息在MQ传输过程丢失，容器状态挂起，DB连接数过大，计算节点各种agent定时任务hang住，部署升级无法核对升级结果。

解决方案：由于社区暂时没有遇到这么大规模，没有任何现成的解决方案，研发团队只能自己动手创造。设计目标为单个集群1万台物理节点，开发了一个python版本的RPC（brood）框架，解除对MQ依赖。特别是依赖MQ操作DB的部分，全部改为使用京东自研的Python版本RPC框架，对数据库的全部操作均使用RPC自带支持的京东JIMDB（内存缓存集群）进行处理。成功解决了集群规模受限的问题。

2、性能、稳定性问题。规模壮大之后，遇到很多低概率但是实实在在发生了性能和稳定性问题，mac表满导致无法网络通信，UDP大报文硬塞，丢包，中断异常，系统slab集中回收性内存申请锁住时间过长。

解决方案：发现问题的根源在于Linux kernel，意识到做容器就是做Linux kernel，即刻组建了Linux Kernel 团队，修改内核代码，最终解决并维护了京东自己的Linux Kernel分支。

3、Zabbix监控agent不自动重启，加到rc.local里的任务不生效，虽不是难点，但往往容易忽视。

4、磁盘IO隔离性不太好，一台Docker磁盘繁忙程度比较高，会影响该宿主机上其他Docker 性能。避免性能要求敏感的系统与磁盘IO使用较高的在同一宿主机上。

5、Zabbix监控负载取值问题，Docker与物理机有区别，上面提及过，避免取值错误。

目前生产环境中70%的MySQL数据库都运行在Docker容器上。已顺利支撑了两个618、一个双11大促，经住了大流量的考验。京东Docker部署已近15万个，成为全世界规模最大的Docker集群。

Q1：MySQL Docker使用的标准？

A1：将MySQL数据库部署环境Docker化，首先是技术成熟，并且有了一定经验。我们是从非核心重要程度低的开始，逐步接入。目前已经有超过70%的系统都部署到Docker上了。

但是对于一些空间上要求比较大的系统，由于业务发展的需求，数据库不可能拆得特别大，数据文件多于1T多的情况下是不太合适部署在Docker上的；再有就是在性能上要求特别高的，特别重要的核心系统目前仍跑在物理机上，后面随着Docker技术不断的改进，会陆续地迁到Docker上。

Q2：我是一个独立核算的部门，公司有其他产品要到Docker上跑，怎么衡量它应用的成本，按部门进行核算，需要考虑哪些因素？

A2：对于数据库来说，主要是CPU核数、内存、硬盘这三项。因为每个Docker配置不一样，数据库这边有8C、12G、500G，12C、24G、500G，12C、48G，1000G和16C、48G、1000G等类似模板，分别对应CPU核数、内存、硬盘。

Q3：刚才您遇到了两个问题里面，一个是IO在用的问题，我想部署Docker时，能不能指定Docker只能占用多少IO这种呢？

A3：内存CPU这个是Docker上通过宿主机可以严格进行控制隔离，IO其实是底层共用一块资源，在隔离性上不好，其实在Docker创建时，是指定了IO的使用情况，但还会存在互相影响和干扰的情况。

Q4：有可能其中一台会引起整个宿主机使用的情况，可能会产生这种干扰。您之前说那个模板，如果定好了500G，如果发现之前的不够用，这个时候可以对之前的模板进行更改吗？如果可以，是批量还是？

A4：这个是完全可以的，并且不影响应用的正常运行，但是有一定的条件，就是当前宿主机上有足够的剩余资源。比如当前是16C、32G、500G配置的Docker，打算升级成16核、32G、1T配置的的docker,需要保证当前宿主机上需要有大于500G的空闲硬盘。

对于扩容来说，目前是通过web触发来进行扩容操作的，完全满足当前的工作场景；对于批量来说，目前没有实现。主要是由于前期已经进行了容量划不会产生大批量的扩容情况。

Q5：数据量比较大，表增长肯定也会增大的，后期数据的归档问题怎么做？

A5：这个问题，普通物理机也有遇到。一般分两种情况：一个是业务上需要继续访问的，一般是通过程序，将历史数据归档道一个历史集群中，这样保证业务上也可以继续访问；另外一种是业务上历史过期数据，业务上不需要访问的，可以放到HBase或者Hadoop里，根据具体业务而定。  

Q6：我想了解一下Docker在MySQL备份怎么管理的？

A6：在Docker和物理机使用上没有太多区别。主要是通过dump或者xtrabback备份到本地，同时上传到存储中，并且定期的刻盘保存。

Q7：我想问一下你们做OLAP这一块，因为MySQL是不适合数据分析大查询这种东西的。我们公司也考虑把数据转到MySQL上，这还需要在线分析吗？我想问一下你们怎么做的？

A7：如果数据量比较小，也是可以考虑MySQL的，单独的从库做统计的查询，也可以考虑MySQL；另外，在选型的时候一定要根据实际考虑最适合的方案，不一定非要使用MySQL。

如果数据量达到一定规模的话，就需要单独的大数据团队来搞了。现在我们那边除DBA团队外之外，还有一个大数据部门，他们会定期地从MySQL抽取数据，两种模式，一种是实时，一种是离线，每天会把数据拉到大数据那边进行处理。

Q8：你们前面做一个中间件吗？

A8：有些系统采用了中间件，但有些系统分库分表是在应用端实现的，主要是这两种情况。

Q9：刚才你说Docker模板后续会不会考虑自动扩容？

A9：由于我们采用的是非共享存储模式，因此我们的自动扩容是有一定限度的，主要是受限于宿主机剩余的资源。在线扩容这块，目前我们已经做到了，但是是需要人工介入的触发，完全自动的扩容，暂时还没有考虑。

Q10：有一种方式就是数据卷容器的挂载。

A10：这个是有一定的适用场景，但对于数据库来说，并不适用，一般统一宿主机上的Docker不需要共享数据。

原文发布时间为：2017-03-16

本文来自云栖社区合作伙伴DBAplus