实战案例:京东到家MySQL容器化实践

本文介绍了京东到家MySQL容器化的实践,包括基于容器的底层资源平台、监控系统及数据库自动化运维平台。同时也详细介绍了具体的技术实现,包括软硬件选型、容器调度算法、数据库高可用实现、监控系统及数据库自动化运维平台开发。

1、背景

2、技术方案

3、技术实现

  • 3.1 数据库底层资源平台的搭建
    ①软硬件选型
    ②容器调度算法
    ③MySQL的高可用实现

  • 3.2 监控系统

  • 3.3 开发自动化运维平台
    ①MySQL申请及交付
    ②配置变更
    ③MySQL工具

4、总结

1.背景

随着京东到家业务的快速发展,MySQL数据库的访问量越来越大,在云主机上搭建MySQL越来越无法满足我们的 要求。

  • 云主机的云硬盘IO性能并不能满足MySQL所需的高并发访问需求。
  1. 云主机所在宿主机使用不透明,当发生网络或者硬件故障时无法及时定位问题。
  2. 搭建在云主机上的MySQL在有变更规格的需求时,需要关机才能变更配置。
  3. 云主机上搭建MySQL成本高,采购云MySQL成本更高。

基于上述原因,我们最终选择采购物理机,在物理机上将MySQL容器化部署来解决 以上问题。

2.技术方案

我们认为一套完善的数据库运维方案包括以下几个部分:数据库底层资源平台、监控系统及 数据库自动化运维平台。

实战案例:京东到家MySQL容器化实践_第1张图片

数据库底层资源平台

  • 在物理机上搭建Docker环境,将MySQL实例部署在Docker内,基于Docker的特性,实现资源隔离和资源超卖。
  • 自定义规则算法来进行容器的调度。
  • 在高可用方面,针对MHA和Zabbix进行二次开发,实现宕机后快速切换。

监控系统

监控系统采用Zabbix,其中每个容器的监控数据(CPU、内存等)通过Docker Api来获取。

数据库自动化运维平台

基于Python和Flask框架,开发MySQL自动化运维平台,实现MySQL完整生命周期自动化运维,提高运维人员的工作效率。

3.技术实现

3.1 数据库底层资源平台的搭建

软硬件选型

MySQL运行的场景需求为高并发高IO,我们在软硬件上做了如下选择:

  • 物理机: 64核、256G内存、16*960G SSD组成RAID10 or 4T NVME RAID0
  • 操作系统:CentOS 7.5
  • 容器:Docker版本1.13.1 、网络模式选择host模式。(从这也可以看出,我们主要是对CPU和内存进行了资源隔离,网络层面没进行资源隔离)
  • 镜像:自定义的MySQL5.6.36镜像、MySQL5.7.22镜像

对基于容器的MySQL实例和基于云主机的MySQL实例,同规格下进行了压测对比,云主机中MySQL QPS最大值23K。

实战案例:京东到家MySQL容器化实践_第2张图片

容器中的MySQL充分利用了本地SSD硬盘的高IO, QPS最大值达90K。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yB6A154M-1622809129544)(https://img0.tuicool.com/yArIZjj.png!web)]

容器化后MySQL性能远超云主机上的MySQL,完全可以满足京东到家当前的MySQL性能需求。

容器调度算法

MySQL作为一种有状态的服务,DBA不需要对之进行频繁的操作,要保持相对稳定和健壮,我们自行定义了规则算法来进行容器的调度。

  • 同一集群的实例分布在不同可用区。
  • 同一集群的实例分布在不同宿主机。
  • 根据业务级别不同MySQL分布不同宿主机,核心业务在一台宿主机上不能部署过多。
  • 分库系统,各分片MySQL分布不同宿主机。
  • 优先分配CPU、内存、磁盘空间资源最空闲的主机。
  • 通过Docker超卖CPU,超卖的倍数不超过实际CPU核数2倍。

基于以上原则,我们开发了容器调度系统,对容器的分配进行整体调度。

实战案例:京东到家MySQL容器化实践_第3张图片

MySQL的高可用实现

到家应用服务器访问MySQL是通过域名方式来进行连接的 ,我们对 MHA和 Zabbix监控系统进行二次开发,故障时通过快速更改域名解析来进行故障切换。整个切换过程在10秒内可以完成。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CvS2MxWr-1622809129552)(https://img2.tuicool.com/QBve2yU.png!web)]

Zabbix监控系统发现MySQL发生宕机后,首先判断是主库还是从库,如果主库宕机由MHA Manager来进行处理,从库宕机由Zabbix监控调用脚本来进行处理。

主库宕机:MHA Manager将Master_Log_File和Read_Master_Log_Pos最高的从库提升为新主库,同时MHA Manager也会调用DNS解析接口将主库域名解析到新主库IP。 由于域名DNS解析可能存在缓存,域名更新生效时间可能比较长。故障切换系统同时会根据宕机的MySQL数据库域名查找连接的所有应用服务器IP,通过Saltstack批量修改/etc/hosts文件绑定域名到新IP,下发到各应用主机上,缩短域名解析生效时间,能达到秒级解析生效。

从库宕机: 由Zabbix调用DNS解析接口,将宕机从库绑定的域名解析到主库上,后续操作与主库宕机操作流程类似。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YMcgi3S9-1622809129554)(https://img0.tuicool.com/i2Ifuii.png!web)]

3.2 监控系统

到家的监控系统采用的是Zabbix,使用自定义模板对MySQL运行状态进行监控。 需要注意的是Docker内部CPU和 内存 的监控数据从OS层的获取值并不准确,我们通过调用Docker Api的方式进行采集,再汇总到Zabbix。

实战案例:京东到家MySQL容器化实践_第4张图片

Zabbix通过设置触发器,当出现告警时自动执行自定义脚本,利用这个功能,可以实现MySQL故障后自愈的功能。

  • MySQL实例触发所在磁盘空间不足报警时,自动执行脚本删除占冗余的文件从而释放空间。
  • MySQL实例触发CPU使用率过高报警时,自动执行脚本将当前运行的sql及所有连接发邮件给DBA及相关研发,以便快速找到CPU报警的原因。
  • 前面提到的MySQL宕机后自动进行域名切换,也是利用Zabbix的这个功能。

3.3 开发自动化运维平台

我们基于Python和Flask开发了MySQL自动化运维系统,从MySQL资源申请、实例创建、销毁、主从架构部署、集群不同角色备份策略的选择、监控添加、销毁等,将MySQL整个生命周期实现流程化和自动化。

MySQL申请及交付

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VcuAGlR3-1622809129557)(https://img0.tuicool.com/QF3uquI.png!web)]

研发通过数据库运维平台申请MySQL资源,经DBA审批后,程序根据容器调度算法,后端会自动创建一套主从架构的MySQL数据库集群。 并为MySQL自动添加相应的账号及授权,账号类型包含: 监控、备份、主从、工具类等。 同时容器创建之后就包含: MySQL服务端、Zabbix客户端、Saltstack客户端、Percona Toolkit、备份脚本、慢日志切割脚本等。

整个过程已实现自动化,并且基于镜像快速创建容器,5分钟内可交付一套完整可用的MySQL集群。

配置变更

得益于容器的特性,调用Docker的update命令可实时改变对应容器的CPU和 内存 配额。从而可以不停机进行MySQL实例规格变更,实现快速扩容或缩容。

实战案例:京东到家MySQL容器化实践_第5张图片

MySQL工具

MySQL 交付之后,我们提供了大量的MySQL工具: 语法分析工具、当前慢日志分析工具、MySQL连接数查询工具、从库延迟查询工具、主从关系查询工具、正在运行SQL查询工具、MySQL快速健康检查、物理机监控、错误日志等。 这些工具方便了研发的平时使用,可以借助这些工具进行排查解决。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Gl4QUITo-1622809129559)(https://img0.tuicool.com/URjEniB.png!web)]

4.总结

目前到家的MySQL实例有95%以上都运行在了容器中,容器化后的MySQL平台经受住了415周年庆、618、1020等所有大促考验,对于我们来说,目前的容器化MySQL平台给我们带来了三大好处:

  • 满足性能: 运行在物理机Docker内的MySQL实例性能高,能满足到家多个业务场景的性能需求。
  • 降低成本: Docker容器之间可进行资源隔离,可以在同一台机器上部署多个MySQL实例。而且通过Docker超卖CPU资源,可提高资源利用率,相比在云主机上搭建MySQL成本降低了50%,比采购云MySQL成本降低了100%。
  • 提高效率: 所有MySQL流程自动化,5分钟内可以交付一套可用的MySQL主从集群,运维效率得到很大提高。

你可能感兴趣的:(Java,MySQL,数据库,linux,java,mysql,程序人生)