全面云原生化，数据库实例独共享混部 最高降低30%成本

引言

2021年双十一是阿里巴巴集团的核心应用全面云化的第二年。今年在保证稳定性的前提下，主要探索如何利用云原生的技术优势，降低成本，提升资源利用率。在今年大促中，针对核心集群采用独享共享实例混部，统一了底层资源，结合交易业务云盘化使得混部单元大促成本下降30%+。

云原生数据库管控

随着云原生技术的普及，越来越多的应用开始运行在Kubernetes上，Kubernetes有一统应用交付界面的趋势。数据库产品内部也在全面推进云原生，期望通过资源池化及与云基础设施深度集成释放数据库产品能力，数据库管控本全面基于Kubernetes来编排DB实例。由于单一的Kubernetes集群规模限制无法满足DB实例的部署规模，所以我们设计了一套多集群的调度编排系统，能够支持多个Kubernetes集群的资源调度。

接入Kubernetes集群的Node，数据库不同的产品会在以下2种模式下根据业务特定自行选择：

• 单实例独占ECS Node：节点实例独占，资源调度工作有ECS完成，特点是节点间隔离性较好，但是由于ECS的资源严格限制，也导致了一些在稳定性和性能的问题
• ECS资源池模式：数据库团队维护一个由较大规格的ECS组成的资源池，由数据库的二次调度在资源池内进行调度。特点是可以在多Pod间协调资源，提升产品的稳定性和性能。

对于第二种，构建ECSPool由数据库团队进行二次调度的场景下，要求采用cgroup隔离组的模式进行实例Pod的资源限制，对于云上的客户而言，存在两种实例形态：

• 独享：采用cgroup里面cpu-set的模式来进行cpu资源的绑定
• 共享：采用cgroup隔离组的里面的cpu-share来进行资源隔离，并一定程度上镜像cpu资源的超卖。

底层的ECS资源池会根据两种不同隔离模式严格划分，分为独占资源池和共享资源池。某一个Node，一旦分配了独享实例就不再允许分配共享实例，严格划分了两个独立的资源池。

一般情况下，资源池由阿里云数据库团队来进行统一调度。由于节点池足够大，区分不同的资源池并不会产生资源利用不佳的情况。但对于服务于企业级的客户而言，由于不与其他客户进行混合部署，这种严格区分的模式资源利用率就不是最佳。举个例子：客户由4个实例，2个采用共享模式，2个需要采用独占模式；按照之前的调度逻辑，客户则必须采购4台机器才能完成实例的部署。因此，为了解决上面的问题，我们希望能够将核心实例和非核心实例混部部署在同一台机器上。同时核心实例采用CPUSet的方式保证独享部分CPU核心，非核心实例采用CPUShare的方式共享剩余的CPU核心，实现资源的充分利用。

CPUSet和CPUShare模式混部方案

独享共享混部的前提是独享实例的性能不受影响，因为必须对共享实例使用的资源进行限制。在Kubernetes中，通过cgroup可以限制pod可以使用的cpu和memory的上下限。其中，对于内存的限制比较简单，给pod设置一个内存最大可用内存，一旦超过内存上限就会触发OOM。对于cpu的限制，Kubernetes采用cfs quota来限制进程在单位时间内可用的时间片。当独享和共享实例在同一台node节点上的时候，一旦实例的工作负载增加，可能会导致独享实例工作负载在不同的cpu核心上来回切换，影响独享实例的性能。所以，为了不影响独享实例的性能，我们希望在同一个node上，独享实例和共享实例的cpu能够分开绑定，互不影响。