双11特刊 | 全面云原生化,数据库实例独共享混部 最高降低30%成本-阿里云开发者社区

开发者社区> fpl6vycpopyyg> 正文

双11特刊 | 全面云原生化,数据库实例独共享混部 最高降低30%成本

简介: 2021年双十一是阿里巴巴集团的核心应用全面云化的第二年。今年在保证稳定性的前提下,主要探索如何利用云原生的技术优势,降低成本,提升资源利用率。在今年大促中,针对核心集群采用独享共享实例混部,统一了底层资源,结合交易业务云盘化使得混部单元大促成本下降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,一旦分配了独享实例就不再允许分配共享实例,严格划分了两个独立的资源池。


1637044729506-6c229c6f-8611-4457-970c-b8815323abd8.png


一般情况下,资源池由阿里云数据库团队来进行统一调度。由于节点池足够大,区分不同的资源池并不会产生资源利用不佳的情况。但对于服务于企业级的客户而言,由于不与其他客户进行混合部署,这种严格区分的模式资源利用率就不是最佳。举个例子:客户由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能够分开绑定,互不影响。


Kubernetes原生混部实现


在linux中,通过cgroup的cpuset子系统可以实现绑定进程到指定的CPU上面,docker也有相关的启动参数来支持绑定容器到指定的CPU上。


--cpuset-cpus=""    CPUs in which to allow execution (0-3, 0,1)
--cpuset-mems=""    Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems.


Kubernetes 从1.8版本以后,提供了CPU Manager特性来支持cpuset的能力。从Kubernetes 1.12版本开始到目前的1.22版本,该特性还是Beta版。CPU Manager是kubelet中的一个模块,主要工作就是给某些符合绑核策略的containers绑定到指定的cpu上,从而提升这些CPU敏感型任务的性能。


目前CPU Manager支持两种Policy,分别为none和static,通过kubelet --cpu-manager-policy设置,未来会增加dynamic policy做Container生命周期内的cpuset动态调整。


none: 为cpu manager的默认值,相当于没有启用cpuset的能力。cpu request对应到cpu share,cpu limit对应到cpu quota。
static: 允许为节点上具有某些资源特征的 pod 赋予增强的 CPU 亲和性和独占性。kubelet将在Container启动前分配绑定的cpu set,分配时还会考虑cpu topology来提升cpu affinity


static策略管理一个共享CPU资源池,最初该资源池包含节点上所有的CPU资源。可用的独占性CPU资源数量等于节点的CPU总量减去通过 --kube-reserved 或 --system-reserved 参数保留的CPU 。从1.17版本开始,CPU保留列表可以通过 kublet 的 '--reserved-cpus' 参数显式地设置。 通过 '--reserved-cpus' 指定的显式CPU列表优先于使用 '--kube-reserved' 和 '--system-reserved' 参数指定的保留CPU。 通过这些参数预留的 CPU是以整数方式,按物理内 核 ID 升序从初始共享池获取的。 共享池是 BestEffort 和 Burstable pod 运行 的 CPU集合。Guaranteed pod中的容器,如果声明了非整数值的CPU requests,也将运行在共享池的CPU上。只有Guaranteed pod中指定了整数型CPUrequests 的容器,才会被分配独占CPU资源。


Kubernetes作为通用的容器编排平台,其提供的绑核功能,具有一定的局限性:

  • 需要显示开启,且pod的QoS必须是Guaranteed级别,数据库实例资源超卖,pod的request和limit设置不同。
  • kubelet的CPU分配策略固定且不支持灵活扩展,不能满足独共享混部的调度场景。
  • 不支持动态放开绑核限制。在大促的时候,为了提高数据库性能,有时需要临时放开实例的资源限制,kubelet不支持放开绑核。

调度平台混部实现方案


Kubernetes默认的绑核能力,其中绑核策略是放在kubelet里面,不易修改和扩展,而针对不同的业务场景,绑核策略可能不同,放在调度测统一管理更加合适。由于kubelet仅负责执行绑核,而具体的绑核策略需要由上层业务来指定;因此在创建CPUSet模式的pod的时候,我们给pod打上annotaion,kubelet在启动容器之前,就会将pod绑定指定的CPU上。


  annotations:
    alloc-spec: |
      {
        "cpu": "Spread"
      }
    alloc-status: '{"cpu":[0,1]}'


alloc-spec:指定具体的分配策略,支持以下几种模式:

  • Spread:在物理核上打散绑定逻辑核,在同物理核对端的逻辑上适宜放置压力小的应用,统一调度也提供了应用间物理核堆叠约束的编排算法。
  • SameCoreFirst:同物理核绑定优先,尽量讲逻辑核分配在相同的物理核上。
  • BindAllCPUs:绑定所有的 CPU 核。

alloc-status:绑定的具体cpu核数。


当调度器在节点上分配或者释放 CPUSet 模式的 Pod 之后,CPUShare Pod 可使用的 CPU 核数量将发生变化,可以通过修改节点的annotation来告知 kubelet可share节点的范围:


kind: Node
metadata:
  name: xx
  annotations:
    cpu-sharepool: '{"cpuIDs":[0,1,2,3,4,5,6,99,100,101,102,103]}'


要实现独享共享混部,只需要给独享实例指定为CPUSet模式,共享实例指定为CPUShare模式,就可以实现共享和独享实例CPU分开绑定,互不干扰。但该方案有以下限制:对Kubernetes原生的kubelet组件进行了定制开发,这就限制了在通用环境下的部署。


基于调度器和扩展控制器的混部实现方案


上面分析了Kubernetes原生和调度平台的混部实现方案。从分析结果看,都无法完全满足数据库这边对于实现独享共享混部方案的绑核需求,我们希望在不修改Kubernetes源码的基础上,能够支持不同的绑核策略。


在介绍我们的实现方案前,先介绍下混部在数据库管控架构下主要涉及到的三个组件。


  • 调度器:调度器具有全局的资源视图,能够根据业务指定的调度策略,分配不同的CPU核心。当前支持的CPU调度策略包括:独共享、NUMA亲和性和反亲和性,IO多队列分布等
  • 控制器:负责将调度器分配的CPU核心设置到pod的annotation上,并对业务提供查询接口
  • cgroup-controller:以daemonset的方式部署在每个node节点上,watch本节点的pod资源,当发现pod的annotation上有绑核信息时,修改pod对应的cgroup cpuset配置,完成绑核。


这套架构和原生Kubernetes集群相比,最大的区别有两个地方,第一:多Kubernetes集群调度,解决数据库规模化对单集群的约束;第二:数据库资源调度与实例创建逻辑解耦,资源调度发生在pod的创建之前。在实例创建的时候,先通过调度器调度分配资源,成功后,业务才会发起任务流拉起实例。


调度器


调度器的核心流程和Kubernetes调度器流程类似(Filter -> Ranker -> Assume -> Process pod)

  • Filter : 过滤不符合要求的Node
  • Ranker : 计算Node分值并选择分值最高的Node
  • Sync Process Pod :异步处理资源申请(云盘、安全组、ENI等)


在独共享混部中,调度器负责为独享实例分配具体的CPU核心,CPU核心的分配策略支持业务自定义。在集团的独共享混部场景中,主要实现了以下逻辑流程:


Node CPU data/state初始化和同步


IO队列分布信息和具体的物理机型号有关,node节点在上线的时候,会由将node的IO队列信息打到node的annotation上,调度器会watch到node节点的IO队列信息,并进行有效性校验并初始化。当调度器会watch到annotation变化,且满足以下两个条件会更新CPU信息。

  • CPU是弹升
  • 原IO队列CPU分布和新的IO队列相同CPU分布完全一致


独享实例绑核IO队列打散


在选择独享实例CPU核心的时候,会考虑按IO队列打散。


1636979167674-e3dd18bb-a9ea-47db-9f01-2629eb437e49.png


打散策略依赖node的cpu分配优先级(上图箭头指向是优先级由高到低)


混部Filter编排

调度器解耦不同Filter,以插件化编排的方式实现定义不同业务的Pipline


应用维度全部做反亲和处理

无论独享还是共享,同一应用在同一台机器上只有1个节点,确保集群维度在单机故障时的影响最多1/N


resourceSet.spec.scheduleConfig.policy.machineMaxList.N.key = ${APP_NAME}
resourceSet.spec.scheduleConfig.policy.machineMaxList.N.value = 1


申请一个inver业务的Pod(machineMaxKey=inve、value=1)过程如下


1636979855771-c14d9997-10d7-4d10-90cb-acb0422e987e.png


共享独享CPU混合调度


未分配的主机(104C),预留8C,最大可分配是96C。调度两个32C的共享实例,再释迁移一个32C的共享实例流程如下图


1636982307230-b593ac57-cce6-4c35-b8ca-ed27f17791d0-1.png


单个ECS独享实例可售最大CPU比例为2/3:即96核物理CPU可售卖的最大独享CPU为64核,剩余32核按固定超卖比超卖给其他实例 (独享实例不可占用整台机器)


1636982334421-0da0a484-274c-4ea3-a73d-3972c068762e.png


可售独享实例CPU计算: 可售CPU=min(a,b)

a.   可售CPU规格=单机可售物理CPU-max(共享实例规格)*2
b.   可售CPU规格 = 【单机可售CPU - sum(共享实例已售CPU)】/超卖比


控制器


控制器为业务屏蔽了底层Kubernetes资源接口,业务所有的操作全部由控制器来统一进行转换。在独共享混部方案里面,控制器负责将调度器分配的绑核信息更新到pod的annotation上,并在pod启动的时候校验启动的绑核信息是否正确。同时在大促场景中,一旦独享实例出现性能瓶颈,需要能够临时占用整机的cpu资源,控制器负责向业务提供临时放开CPU绑核的限制的接口。


  #独享实例pod需要指定的annotation
  annotations:
    cpu-isolate-mode: exclusive #指定为独享实例
    custom-cgroup-info: '{"engine":{"cpuset":"2-3"}}' #指定具体容器绑定的cpu核心
    exclude-reserve-cpuset: "true" #是否需要扣除node上预留的cpu核心
    release-isolate-mode: "true" #是否需要临时放开绑核限制,如果设置了可以绑定除了预留所有cpu核心,大促时候的应急预案


cgroup-controller


cgroup-controller是Kubernetes里面的一个扩展控制器,它通过daemonset的方式部署在Kubernetes集群里面,它将宿主机上的/sys/fs/cgroup/目录挂载到容器内,在watch到pod需要绑核时,根据pod的qos等级,找到对应的cgroup配置路径,直接修改cgroup的配置文件。


     volumes:
        - hostPath:
            path: /var/run/
            type: "Directory"
          name: docker-sock
        - hostPath:
            path: /sys/fs/cgroup/
            type: "Directory"
          name: cgroups


在独共享混部的方案里面,cgroup-controller除了需要能够为独享实例绑定CPU核心以外,还需要维护共享实例的CPU资源池。cgroup-controller会记录当前节点上独享CPU和共享CPU的核心分布,当节点上的独享实例发生变化时,动态调整node上共享pod的可用的CPU列表。例如,当前node节点预留CPU:[0-1],调度了一个独享实例占用CPU:[2-3],cgroup-controller会计算当前node节点上的共享CPU=总的CPU-node预留-独享CPU,并将共享pod全部绑定到共享CPU核心上。当再调度一个独享pod,cgroup-controller会更新共享CPU核心,并刷新主机上所有共享POD绑定的CPU核心。


1637068774721-2cb49843-ddeb-4456-aad0-1ccf053395f4.png


cgroup-controller通过直接修改pod的cgroup配置来实现动态调整pod的资源配额,虽然不需要浸入kubernetes源码,但也存在以下几个问题:

  • cgroup-controller只能在容器启动后,才能修改容器的资源配额
  • 当独享实例发现变化时,会动态刷新共享实例的CPU绑核,对共享实例的性能可能存在一定的影响


cgroup-controller能够直接操作DB实例cgroup的资源限额,能够直接影响DB实例的数据面,所以在具体执行修改时会做一些必要的安全检查。比如在设置独享实例的绑定的CPU时,会校验绑定的核心是否满足IO队列分布,绑定的CPU核心是否超过单节点可售卖独享CPU的核心数等。


相关阅读:

独家 | 揭秘2021双11背后的数据库硬核科技

双11特刊|购物车实时显示到手价,看云原生内存数据库Tair如何提升用户体验?

双11特刊|十年磨一剑,云原生多模数据库Lindorm 2021双11总结

双11特刊 | 一文揭秘云数据库RDS如何顺滑应对流量洪峰

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
阿里云服务器怎么设置密码?怎么停机?怎么重启服务器?
如果在创建实例时没有设置密码,或者密码丢失,您可以在控制台上重新设置实例的登录密码。本文仅描述如何在 ECS 管理控制台上修改实例登录密码。
9575 0
申通快递 双11 云原生应用实践
一年一度的 “双11” 大促中,交易额每年都在刷新,承接这些交易商品的快递包裹的数量也在成倍增长。这些快速的增长对物流系统带来了巨大的挑战,让物流管理更加敏捷来应对 “双11” 成为了必须解决的问题。
755 0
订单峰值激增 230%,Serverless 如何为世纪联华降本超 40%?|双11 云原生实践
导读:2020 年 双11,世纪联华基于阿里云函数计算 (FC) 弹性扩容,应用于大促会场 SSR、线上商品秒杀、优惠券定点发放、行业导购、数据中台计算等多个场景,业务峰值 QPS 较去年提升 230%,研发效率交付提效超过 30%,弹性资源成本减少 40% 以上。当 双11 走过 11 个年头,传统企业正在凭借云原生技术悄然逆势崛起,参与到这场全球购物狂欢节中。
296 0
阿里云服务器如何登录?阿里云服务器的三种登录方法
购买阿里云ECS云服务器后如何登录?场景不同,阿里云优惠总结大概有三种登录方式: 登录到ECS云服务器控制台 在ECS云服务器控制台用户可以更改密码、更换系.
13278 0
阿里 双11 同款流控降级组件 Sentinel Go 正式 GA,助力云原生服务稳稳稳
微服务的稳定性一直是开发者非常关注的话题。随着业务从单体架构向分布式架构演进以及部署方式的变化,服务之间的依赖关系变得越来越复杂,业务系统也面临着巨大的高可用挑战。
4742 0
阿里云ECS云服务器初始化设置教程方法
阿里云ECS云服务器初始化是指将云服务器系统恢复到最初状态的过程,阿里云的服务器初始化是通过更换系统盘来实现的,是免费的,阿里云百科网分享服务器初始化教程: 服务器初始化教程方法 本文的服务器初始化是指将ECS云服务器系统恢复到最初状态,服务器中的数据也会被清空,所以初始化之前一定要先备份好。
11580 0
重磅发布 | 《不一样的 双11 技术,阿里巴巴经济体云原生实践》电子书开放下载
2019 双11,订单创新峰值达到 54.4 万笔/秒,单日数据处理量达到 970PB,面对世界级流量洪峰,今年的阿里巴巴交出了一份亮眼的云原生技术成绩单,并实现了100% 核心应用以云原生的方式上云: 双11 基础设施 100% 上云 支撑 双11 在线业务容器规模达到 200 万 采用神龙弹性裸金属服务器计算性价比提升 20%  这些数据背后是对一个个技术问题的反复尝试与实践。
28691 0
申通快递 双11 云原生应用实践
一年一度的 “双11” 大促中,交易额每年都在刷新,承接这些交易商品的快递包裹的数量也在成倍增长。这些快速的增长对物流系统带来了巨大的挑战,让物流管理更加敏捷来应对 “双11” 成为了必须解决的问题。
4310 0
阿里云服务器如何登录?阿里云服务器的三种登录方法
购买阿里云ECS云服务器后如何登录?场景不同,云吞铺子总结大概有三种登录方式: 登录到ECS云服务器控制台 在ECS云服务器控制台用户可以更改密码、更换系统盘、创建快照、配置安全组等操作如何登录ECS云服务器控制台? 1、先登录到阿里云ECS服务器控制台 2、点击顶部的“控制台” 3、通过左侧栏,切换到“云服务器ECS”即可,如下图所示 通过ECS控制台的远程连接来登录到云服务器 阿里云ECS云服务器自带远程连接功能,使用该功能可以登录到云服务器,简单且方便,如下图:点击“远程连接”,第一次连接会自动生成6位数字密码,输入密码即可登录到云服务器上。
21998 0
阿里云ECS云服务器初始化设置教程方法
阿里云ECS云服务器初始化是指将云服务器系统恢复到最初状态的过程,阿里云的服务器初始化是通过更换系统盘来实现的,是免费的,阿里云百科网分享服务器初始化教程: 服务器初始化教程方法 本文的服务器初始化是指将ECS云服务器系统恢复到最初状态,服务器中的数据也会被清空,所以初始化之前一定要先备份好。
6993 0
17
文章
0
问答
来源圈子
更多
阿里云数据库:帮用户承担一切数据库风险,给您何止是安心!支持关系型数据库:MySQL、SQL Server、PostgreSQL、PPAS(完美兼容Oracle)、自研PB级数据存储的分布式数据库Petadata、自研金融级云数据库OceanBase支持NoSQL数据库:MongoDB、Redis、Memcache更有褚霸、丁奇、德哥、彭立勋、玄惭、叶翔等顶尖数据库专家服务。
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载