背景

招行ACS私有云上线投产后, MySQL作为云上主要服务的RDS数据库服务,规模急剧增长且部分承载着分行核心业务，对业务连续性要求也越来越高，因此迫切需要建立并完善云MySQL支持服务体系和提升MySQL服务能力。

当前行内的MySQL架构，主要是基于VM虚机和Redhat RHCS技术的单实例MySQL，在生产环境经常出现基础环境不稳定，容易仲裁超时、共享盘丢失等问题。

同时也面临资源利用率低，问题定位难，使用成本高，自动化建设无法穿透贯通至PaaS层，部署交付能力低，故障恢复时间长等问题。因此，为了提升资源利用率和提高MySQL数据库服务的交付能力、高可用性、自动化运维能力，我们基于K8s+Docker+MySQL MGR构筑了自研CDD平台, 通过容器特性+K8S成熟的容器集群调度管理能力和容器化数据库的高可用策略，提升数据库服务可用性、故障恢复能力。

同时通过对容器数据库平台调度策略的优化，通过合理配置资源，结合对资源动态数据监控及分析智能化调度等方式，提升资源利用率。

目标

为响应数据中心云化发展战略、配合云数据中心建设，加强MySQL云服务建设，自主可控能力建设, 提高MySQL数据库服务云化敏捷交付能力、高可用能力、自动化运维能力。我们制定以下目标：

1. 加强数据库自主可控能力建设, 提升资源利用率, 提升基础环境稳定性，实现降本增效。

2. 提高MySQL数据库敏捷交付能力、自动化运维能力和运维效率、提升MySQL资源池自构建和管理能力。

3. 通过K8S+Docker+MySQL MGR技术特性提高MySQL数据库服务可用性、同时实现资源快速供给、弹性伸缩等优势，提升业务连续性保障。

4. 实现MySQL同城跨AZ高可用部署架构， 异地容灾一键切换能力，解决MySQL传统高可用架构短板, 实现MySQL高可用架构优化改进。

面临的挑战

近两年来容器技术在我行各业务开发条线和数据中心遍地开花，迅速推广，得到广泛应用。

K8s容器技术生态也是愈发成熟。基于原生k8s的容器paas平台也早已在我行上线，运行着越来越丰富的无状态应用。容器paas平台主要是为无状态应用而设计，无需进行定制适配开发。

K8s+docker技术原生支持无状态应用优势有：极致的资源利用，无虚拟化损耗以及多余内核损耗，灵活的资源共享机制；轻量级，固化的镜像规避了繁琐的依赖安装过程；扩展性强，无论是管理集群扩展性，还是应用扩展性都极强；自修复能力强，自动重调度，自动重启，自动复制；科学的全解耦模块设计。

尽管最近几年原生K8s技术演进发展迅速，新功能特性层出不穷愈加丰富。从技术可行性评估，容器技术早已具备支持有状态应用的能力。但是原生K8S对数据库等有状态的应用的支持，由于数据库应用的特殊性需进行一定的适配开发，以使数据库容器化的整体架构方案和技术优势和价值最优化。

在此背景下，我们基于K8S+docker构筑数据库容器化方案落地过程中，将会面临以下几方面技术难度：

①网络方面

K8s主流的基于隧道技术的网络插件不能承载数据库的大流量；

容器网络技术中的IP和mac地址不固定给数据库带来的困扰；

K8s自带的基于iptables的service技术，不适合数据库对外服务暴露；

②存储方面

容器针对无状态应用的分布式存储，并不适用于数据库应用场景；

数据库是重IO应用，如何避免IO争抢；

③调度方面

容器技术并未解决数据库单点故障的问题，还需要解决数据库本身的高可用问题

数据库应用的特殊编排特点，例如数据库主节点要先启动；

数据库在故障转移过程中产生的数据迁移过程比无状态服务复杂；

④资源利用率方面

有状态应用数据持久化，如何综合评估通盘考虑设计计算存储资源的配比;

有状态服务如何资源利用率指标设计，计算资源超卖能力设计，如何在保障数据库服务性能无影响下合理提升资源利用率;

⑤管理方面

原生K8s主要面向的是CICD应用场景，对数据库的运维场景支撑并不完善;

行内现有数据库运维生态体系及工具与容器化数据库服务之间快速无缝对接融入;

在基于K8S+docker构筑容器化数据库平台预研及建设过程中，我们是如何解决了以上技术难度与挑战的？

解决办法

1. 网络方面

数据库应用对网络性能的需求非常强，数据库通过网络对外提供服务，通过网络去做数据的高可用，因此在数据库业务访问高峰的时候，爆发出的数据流量是非常大；同时，数据库还对网络的时延要求也很高，即使带宽足够，时延过大的网络情况，也很容易造成数据库执行事务失败之类的问题；

在CDD平台开发初期进行选型测试的时候，对现有的主流的Kubernetes平台容器网络方案，如Flannel、OpenvSwitch等进行了全面的调优和测试，发现这些网络插件的原理都是通过隧道技术进行网络传输，即先将已经封装好的数据包，进行基于VXLAN或者BGP协议的再封装，在网络并发高的情况下，很容易造成带宽占满、延时高的现象；

同时在测试验证的过程中，还发现现有的数据库高可用方案（MGR、MHA），数据库监控方案（zabbix、Prometheus），数据库备份方案（NBU、CV备份），普遍使用IP作为数据库的身份标识，而上述的网络插件，都是基于宿主机虚拟网关实现的容器网络互通，因此在容器发生宿主机迁移的时候，IP会发生改变，不利于数据库的运行；

针对上述情况，在仔细调研了行业内现有的网络虚拟化SDN技术方案，并和同样在进行数据库容器化开发的同行业单位进行技术交流和讨论后，我们选择了SR_IOV单根虚拟化技术，SR_IOV单根虚拟化技术是Intel网卡的硬件虚拟化技术，其基本原理是在物理网卡上预留虚拟网卡的硬件，并共用一条总线，极大的提升了虚拟网卡的带宽和性能；

SR_IOV技术简介

由于行业性质，对数据库的备份有极高要求，目前行内的备份周期为每日全备，但容器内默认只有一个网卡，因此可能出现在备份过程中，出现一个很大的网络流量，直接把网卡带宽占满，造成数据库业务的中断；

同时，在k8s集群中，有很多功能，需要通过容器原生的Overlay网络完成，如监控自动纳管、服务自动发现等功能，因此，CDD平台对Kubernetes原生的CNI网络插件进行了定制，实现了容器内多网段；

在实现容器内多网段后，又出现了一个新的问题，由于SR_IOV技术的硬件虚拟化特性，一张万兆网卡上的虚拟网卡（VF）数量是有限的，一般为63个，一些高端网卡是126个，因此，容器如果不是运行的数据库，或者运行的数据库为小型需求的低配数据库，占用虚拟网卡就会非常浪费虚拟网卡资源，为了解决这个问题，CDD平台引入了MacVLAN网络虚拟化技术，通过操作系统虚拟化出网卡，给低配mysql使用；因此，CDD平台中，为Pod设计了三种网络模式

容器内只有一个网卡，为Overlay网络，该模式适合一些监控容器等非数据库业务容器使用；

容器内有3个网卡，一个网卡为Overlay网络，两个网卡分别用于备份和业务，为MacVLAN虚拟网卡，适用于低配数据库容器；

容器内有3个网卡，默认网卡为Overlay网络，另外两个网卡分别用于备份和业务，使用SR_IOV虚拟网卡，适用于高配的数据库容器；

SR_IOV网络容器网络方案图

数据库应用为重IO应用，磁盘负载很重，因此，如何保障数据库容器的磁盘IO和吞吐量，成为了容器数据库方案设计的重中之重；在目前行业通用的Kubernetes方案中，一般会使用GlusterFS、CephFS、HDFS等分布式文件系统实现共享存储；但是经过测试，发现这些分布式文件系统并不适合数据库使用，主要是存在以下两个问题：

为了给数据库容器提供足够的磁盘IO和吞吐，CDD平台选择使用本地内储，同时存储插件也支持 SAN存储、S2D分布式存储的混合使用，实现容器存储的高效和高可用，由于数据库容器普遍是多副本数据，因此，可以使用混合方式来节省存储成本，例如SAN存储混合本地存储，S2D存储混合本地存储使用，兼顾数据高可用性和存储成本优化；

CDD混合存储方案图

由于Kubernetes本身的调度非常简单，不适用于有状态应用调度实际需求，因此，我们引入了scheduler extender 扩展功能，开发了CDD-scheduler框架，该调度框架主要实现以下功能：

将数据库主节点均匀分布到各个物理机，避免主节点扎堆导致的性能问题。

均匀分布上文提到的Overlay、MacVLAN、SR_IOV三种网络类型，避免网络类型分布不均匀而导致的网络问题。

由于CDD平台中的数据容器存储为混合存储，有的会占用本地存储IO，有的会占用专用存储网络IO，CDD-Scheduler会尽可能的均匀分布这些存储类型，确保一个物理机上的存储IO最优化。

根据Prometheus、zabbix等监控数据，可以得到数据库的性能曲线，CDD-Scheduler内置了数据库画像分析，针对数据库的业务高峰时段，对数据库进行均匀分布，达到在资源超卖的情况下，通过MGR切换、跨节点调度、资源隔离等方式确保数据库服务本身的稳定性。

数据库容器化的目的之一，就是通过提高物理机的资源利用率，降低数据库的使用成本；而数据库本身的特殊性，不能像无状态应用一样，过分强调资源超售，而降低容器的稳定性，因此，针对数据库本身特性，CDD平台制定了如下的超售原则：不过分追求极致的cpu、内存利用率，但所有容器都有约150%的超卖。网络和存储都引入熔断机制，避免单个容器拖垮整个机器；在极端情况下，可以降低容器批次启动的速率，避免整个集群雪崩。

基于上述原则，在建设过程中, 我们需要思考的是怎样在确保资源利用率合理的情况下，同时保障数据库服务的安全性? 经过团队的观察、计算发现，数据库由于存在一主两从的高可用架构，主节点对外提供主要服务，计算资源占用最高，因此，主节点的均匀分布，对数据库服务的可用性，以及资源利用合理性非常重要。

我们通过建设DBaaS平台协同实现统一架建调度，DBaaS对外提供统一服务接口输出RDS至云管平台，对内对接K8s CDDM平台,实现自动基于规则引擎调度分配基础资源，利用staltstack对接鲁班调度接口实现自动化运维，打通zabbix和prometheus监控和行里统一告警平台对接。

架构先进性

招行CDD容器数据库平台基础架构图

CDD容器数据库平台基础架构，围绕数据库服务适配设计定制开发，架构特点优势总结如下：

应用推广

基于K8s+Docker+MySQL MGR构筑的CDD平台(CMB docker database)于19年第4季度正式上线投产，目前已在ACS私有云给总行和国内44家一级分行提供了容器化MySQL MGR数据库云服务，目前共计上线3000+套，运行稳定。MySQL MGR数据库已深度融入到一系列数据库运维工具平台。围绕MySQL数据库运维生态工具建设已落地的有包括容器化MGR集群、MySQL读写分离中间件、MySQL远程容灾、MySQL数据库管理平台等。

基于CDD平台多层高可用保障，高稳定性、高安全度、高拓展性、高交付效率等技术优势，结合MySQL MGR高可用集群架构的灵活性,可靠性以及原生多副本高可用架构和不依赖外部组件实现的故障自动切换等技术特征，开创性的将两项技术进行高效整合、优势互补，实现MySQL资源快速供给、动态扩容弹性伸缩等能力，提高MySQL运维效率,大幅降低运行成本。解决了MySQL传统高可用架构短板，极大提升mysql数据库可用性，构建了业界领先的MySQL数据库金融级高可用服务能力。不破不立，长期以来困扰数据库的基础环境问题和痛点，需要从根本上去重构解决，基于k8s构筑的容器数据库平台从根本上解决和改善了以下问题：

价值收益

一方面， MySQL MGR基于行冲突检测的并行数据加载，较主从半同步复制并行读高，主从延迟低，主读库数据一致性高, 通过MySQL Router简单灵活配置，更有利于读写分离业务场景。并且MySQL MGR架构凭借RTO、RPO的高标准、数据一致性的高保障，可为关键业务系统提供稳定、高效的数据库服务能力。同时结合K8S+Docker容器化部署的灵活调度、资源流式交付的特性，为高频小事务的交易业务系统、灵活微服务架构的业务系统提供有力支撑。

另一方面，在提高基础环境稳定性基础上，通过多重高可用保障，智能调度，自动伸缩，跨AZ容灾解决方案提升服务可用性。利用资源支持配置上限和下限，随着业务的发展和数据量的持续增加，持续增加资源配置至上限,支持资源超配, 提升资源利用率，降低成本，提升了数据库的业务支撑能力。通过智能化计算资源，自动化部署交付，提高架建效率。操作、流程规范化，使数据库部署交付、运维管理更自助精细、风险更低，提升自助服务和敏捷交付能力。

总结

金融业IT服务建设首要是为业务系统稳定运行和数据资产安全保驾护航，打造极致高可用和稳定性，在此基础上进行自主安全可控和降本增效和创新建设。同时随业务需求发展变化和IT发展战略变革而敏捷响应需求并快速落地。

如今各种新技术和新架构层出不穷，技术演进发展迭代更新快速，对新技术演进的发展方向和发展趋势的把握和前瞻判断至关重要，招行基于K8S构筑容器数据库平台建设能取得一点成果的首要前提是我们积极拥抱云化发展战略方向,在未来我们不断会面临新挑战,积极推动整个行业圈层共建技术生态，才能使技术创新的种子落地开花，使得新技术更好的服务于业务并最终变现为业务价值和业务效能的景象百花齐放。

END