带你读《2022龙蜥社区全景白皮书》——6.1.3 资源混部场景的内核隔离实现方案(上)

本文涉及的产品
Serverless 应用引擎免费试用套餐包,4320000 CU,有效期3个月
性能测试 PTS,5000VUM额度
云原生网关 MSE Higress,422元/月
简介: 带你读《2022龙蜥社区全景白皮书》——6.1.3 资源混部场景的内核隔离实现方案(上)

6.1.3 资源混部场景的内核隔离实现方案


概述


2014年,阿里巴巴开始了第一次探索混部,经过七年磨练,这把资源利用率大幅提升的利剑正式开始商用。通过从计算资源、内存 资源、存储资源、网络资源等全链路的隔离以及毫秒级的自适应调度能力,通过智能化的决策与运维能力,支撑着内部百万级的 Pod混部,不管是CPU与GPU资源,普通容器与安全容器,包括国产化环境各种异构基础设施,都能实现高效混部,这让核心电商 业务生产集群成本下降了50%以上,同时核心业务受到的干扰小于5%。在商用化输出的版本里面,资源混部能力完全基于云原生社 区标准,以插件化的方式无缝的安装在k8s集群作为输出交付形态。其中核心的OS操作系统层隔离能力,已经发布到支持多架构的 开源、中立、开放的Linux操作系统发行版-龙蜥(Anolis OS)中。


场景挑战


资源混部就是将不同类型的业务在同一台机器上混合部署起来,让它们共享机器上的CPU、内存、IO等资源,目的就是最大限度地 提高资源利用率,从而降低采购和运营等成本。混部通常是将不同优先级的任务混合在一起,例如高优先的实时任务(对时延敏感, 资源消耗低;称为在线)和低优先级批处理任务(对时延不敏感,资源消耗高;称为离线),当高优先级业务需要资源时,低优先级任 务需要立即归还,并且低优先级任务的运行不能对高优先级任务造成明显干扰。


假设我们现在有一台服务器,上面运行了高优的在线业务,以及离线任务也在上面运行运行。在线任务对响应时间(Response  Time, RT)的需求是很明确的,要求尽可能低的RT,故被称之为延迟敏感型(Latency-Sensitive, LS)负载;离线任务永远是有多 少资源吃多少资源的,故此类负载被称之为Best Effort(BE),如果我们对在线和离线任务不加干涉,那么离线任务很有可能会频 繁、长期占用各种资源,从而让在线任务没有机会调度,或者调度不及时,或者获取不到带宽等等,从而出现在线业务RT急剧升高 的情况。所以在这种场景下我们一定需要必要的手段来对在线和离线容器进行资源使用上的隔离,来确保在线高优容器在使用资源 时可以及时的获取,最终能够在提升整体资源使用率的情况下保障高优容器的QoS。


通过一个例子,说明在线和离线混着跑的时候,可能出现的情况:


首先最有可能发生在离线竞争的,可能是CPU,因为CPU调度是核心,在线和离线任务可能分别会调度到一个核上,相互抢执行时间;

当然任务也可能会分别跑到相互对应的一对HT上,相互竞争指令发射带宽和其他流水线资源;

接下来CPU的各级缓存必然是会被消耗掉的,而缓存资源是有限的,所以这里涉及到了缓存资源划分的问题; 再接下来,假设我们已经完美解决了各级缓存的资源划分,后面还是有问题。首先是内存是CPU缓存的下一级,内存本身也类似, 会发生争抢,对于在线和离线任务分别来说都是需要像CPU缓存一样进行资源划分的;

另外当CPU最后一级缓存(Last Level Cache, LLC)没有命中的时候,内存的带宽(我们称之为运行时容量,以有别于内存大小划 分这种静态容量)会变高,所以内存和CPU缓存之间的资源消耗,是相互影响的;

然后我们假设CPU和内存资源都没问题,对于本机来说现在隔离已经做得很好了,但是在线高优的业务和离线任务的运行过程中都 是和网络有密切的关系,那么很容易理解,网络也可能是需要隔离的;

最后,线上部分机型对IO的使用可能会发生抢占,我们需要有效的IO隔离策略。


以上就是一个很简单的资源隔离流程的思路,可以看到每一环都有可能会出现干扰或者竞争。


方案特色


把集群混合起来,将不同类型的任务调度到相同的物理资源上,通过调度,资源隔离等控制手段 , 在保障SLO的基础上,充分使用资 源能力,极大降低成本,我们称这样的技术为混部(Co-loaction)。


image.png


混部在一起的任务有两个比较重要的特征:

1、可以划分优先级:一定需要优先级比较低的任务,它们能像水和沙子一样,随时能被赶走,而不会受到不可承受的影响,让优先 级高的任务不受干扰。在线的特点是:峰值压力时间不长,对延时比较敏感,业务的压力抖动比较厉害,典型的如早上10点的聚划 算活动,就会在非常短的时间内,造成交易集群的压力瞬间上升10几倍,对于稳定的要求非常高,在混部的时候,必须要保证在线 的通畅,需要有极强的抗干扰能力。而计算任务的特点是:平时的压力比较高,相对来说计算量可控,并且延迟不敏感,失败后也 可以重跑。至少需要几分钟跑完的计算任务,相对于几秒甚至几十秒的延迟,并不会产生严重的问题,正好可以承提起水和沙子的 角色。


2、资源占用互补性:两种任务在不同的时间点对水位的占用不一样。如在线服务是,平时比较低,大促时比较高;凌晨比较低,白 天比较高。而计算任务则反过来,平时比较高,大促时可以降级;凌晨非常高,白天却要低一些。


这种方式带来的成本节省是非常巨大的:假设数据中心有N台服务器,利用率从R1提高到R2,不考虑其他实际制约因素的情况下, 节约X台,那么理想的公式是:

N*R1 = (N-X)*R2

=> X*R2 = N*R2 – N*R1

=> X = N*(R2-R1)/R2


也就是说如果企业有10万台服务器,利用率从28% 提升到40%,代入上述公式,就能节省出3万台机器。假设一台机器的成本为2万 元,那么节约成本就有6个亿。

混部调度架构:


image.png


《2022龙蜥社区全景白皮书》——06 “龙蜥+”精选方案与案例——6.1 精选典型方案——6.1.2 系统安全场景的加解密加速方案(下) https://developer.aliyun.com/article/1229105


相关实践学习
CentOS 7迁移Anolis OS 7
龙蜥操作系统Anolis OS的体验。Anolis OS 7生态上和依赖管理上保持跟CentOS 7.x兼容,一键式迁移脚本centos2anolis.py。本文为您介绍如何通过AOMS迁移工具实现CentOS 7.x到Anolis OS 7的迁移。
相关文章
|
3月前
|
存储 资源调度 Serverless
阿里巴巴经济体核心调度系统“伏羲”设计问题之伏羲系统的功能如何解决
阿里巴巴经济体核心调度系统“伏羲”设计问题之伏羲系统的功能如何解决
85 0
|
12月前
|
缓存 监控 Anolis
|
资源调度 分布式计算 Kubernetes
给 K8s 装上大数据调度引擎:伏羲架构升级 K8s 统一调度
飞天伏羲作为有着十多年历史的调度团队,在服务好 MaxCompute 大数据平台的过程中,一直在不断通过自我革新赶超业界先进水平,我们经历了 Fuxi 2.0 的这样的大规模升级,今天通过 K8s 统一调度项目又再次实现了系统架构的蜕变,将大数据平台强大的调度能力赋予 K8s 系统,同时去拥抱 K8s 周边丰富的生态。除了集团弹内集群,将来我们在公共云、专有云等多个场景,也会以 K8s 统一调度的方式进行输出,以更好地服务云上的用户,敬请期待!
1690 10
给 K8s 装上大数据调度引擎:伏羲架构升级 K8s 统一调度
|
资源调度 运维 监控
带你读《2022龙蜥社区全景白皮书》——6.1.3 资源混部场景的内核隔离实现方案(下)
带你读《2022龙蜥社区全景白皮书》——6.1.3 资源混部场景的内核隔离实现方案(下)
279 7
|
缓存 运维 Java
带你读《2022龙蜥社区全景白皮书》——5.3.4 跨处理器节点内存访问优化
带你读《2022龙蜥社区全景白皮书》——5.3.4 跨处理器节点内存访问优化
188 7
|
缓存 Dragonfly 人工智能
带你读《2022龙蜥社区全景白皮书》——5.3.1 跨云-边-端的只读文件系统EROFS
带你读《2022龙蜥社区全景白皮书》——5.3.1 跨云-边-端的只读文件系统EROFS
109 7
|
Cloud Native 网络性能优化 调度
带你读《2022龙蜥社区全景白皮书》——5.3.2 资源隔离技术
带你读《2022龙蜥社区全景白皮书》——5.3.2 资源隔离技术
174 6
|
测试技术 Shell Anolis
带你读《2022龙蜥社区全景白皮书》——5.10.4 ancert:硬件兼容性验证与守护
带你读《2022龙蜥社区全景白皮书》——5.10.4 ancert:硬件兼容性验证与守护
121 1
|
存储 Dragonfly 人工智能
带你读《2022龙蜥社区全景白皮书》——6.1.4 云原生应用场景下的镜像分发加速方案
带你读《2022龙蜥社区全景白皮书》——6.1.4 云原生应用场景下的镜像分发加速方案
258 6
|
运维 Cloud Native 微服务
带你读《云原生架构白皮书2022新版》——组织能力视角
带你读《云原生架构白皮书2022新版》——组织能力视角
143 2