京东MySQL数据库Docker化最佳实践(附PPT)

刘风才 2017-03-16 09:34:15
  

本文根据刘风才老师在〖3月11日北京数据库技术沙龙〗现场演讲内容整理而成。点击文末链接还能下载PPT哦~

 

讲师介绍
 

刘风才

京东资深数据库专家

 

 

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

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

 

演讲大纲:

  1. 京东Docker技术发展历程

  2. MySQL数据库为何要Docker化

  3. MySQL数据库Docker化前准备工作

  4. 遇到的问题与解决方案

  5. 总结与展望

 

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

 

一、京东Docker技术发展历程

 

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数据库为何要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大促的考验。

 

三、MySQL数据库Docker化前准备工作

 

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集群。

 

Q&A
 

 

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不需要共享数据。

PPT下载链接:http://pan.baidu.com/s/1bQauxK

最新评论
访客 2017年07月21日

写得好,打赏!

访客 2017年07月21日

那什么是分割relay日志的正确姿势呢

访客 2017年07月20日

有思想的dba

访客 2017年07月20日

应该在延伸一下,慢查询的监控,告警和优化提示,类似…

访客 2017年07月19日

赞一个

活动预告