本文根据刘风才老师在〖3月11日北京数据库技术沙龙〗现场演讲内容整理而成。点击文末【阅读原文】还能下载PPT哦~ 刘风才 京东资深数据库专家
演讲大纲：
京东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信息，根据DockerIP查询该宿主机及其下所有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集群。 |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
