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

本文涉及的产品
MSE Nacos/ZooKeeper 企业版试用,1600元额度,限量50份
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 带你读《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


相关文章
Element UI - el-table 渲染慢,卡的原因
Element UI - el-table 渲染慢,卡的原因
3731 0
|
资源调度 运维 监控
带你读《2022龙蜥社区全景白皮书》——6.1.3 资源混部场景的内核隔离实现方案(下)
带你读《2022龙蜥社区全景白皮书》——6.1.3 资源混部场景的内核隔离实现方案(下)
574 112
|
12月前
|
机器学习/深度学习 传感器 人工智能
智慧无人机AI算法方案
智慧无人机AI算法方案通过集成先进的AI技术和多传感器融合,实现了无人机的自主飞行、智能避障、高效数据处理及多机协同作业,显著提升了无人机在复杂环境下的作业能力和安全性。该方案广泛应用于航拍测绘、巡检监测、应急救援和物流配送等领域,能够有效降低人工成本,提高任务执行效率和数据处理速度。
915 2
智慧无人机AI算法方案
|
JSON API 网络安全
App数据的爬取
App数据的爬取
510 3
|
存储 关系型数据库 MySQL
MySQL数据库锁:共享锁和独占锁
本文详细介绍了`InnoDB`存储引擎中的两种行级别锁:共享锁(S锁)与排他锁(X锁)。通过具体示例展示了这两种锁的工作机制及其在`InnoDB`与`MyISAM`引擎中的表现差异。文章还提供了锁的兼容性矩阵,帮助读者更好地理解锁之间的互斥关系。最后总结了两种锁的特点及适用场景。适合希望深入了解`MySQL`并发控制机制的读者阅读。
471 1
|
消息中间件 Kafka 程序员
Kafka面试必备:深度解析Replica副本的作用与机制
**Kafka的Replica副本是保证数据可靠性的关键机制。每个Partition有Leader和Follower副本,Leader处理读写请求及管理同步,Follower被动同步并准备成为新Leader。从Kafka 2.4开始,Follower在完全同步时也可提供读服务,提升性能。数据一致性通过高水位机制和Leader Epoch机制保证,后者更精确地判断和恢复数据一致性,增强系统容错能力。**
469 1
|
NoSQL 关系型数据库 MySQL
高可用数据库架构:互备(Multi-Master)技术详解
本文介绍了分布式系统中的互备(Multi-Master)机制,特别是在高可用数据库系统中的应用。互备机制超越了传统的主从复制,允许每个Master节点同时进行读写操作并互相同步数据,以提高可用性和负载均衡。文章探讨了主从复制与互备模式的区别,以及互备模式的数据同步和冲突解决策略。还以MySQL的双主复制和MongoDB的副本集为例,展示了MM模式在数据库高可用性中的实践。最后,强调了互备在未来分布式系统中的重要性。
360 7
|
Cloud Native 网络性能优化 调度
带你读《2022龙蜥社区全景白皮书》——5.3.2 资源隔离技术
带你读《2022龙蜥社区全景白皮书》——5.3.2 资源隔离技术
306 75
|
机器学习/深度学习 人工智能 自然语言处理
AIGC的技术架构
【1月更文挑战第18天】AIGC的技术架构
1033 1
AIGC的技术架构
|
tengine 弹性计算 安全
带你读《2022龙蜥社区全景白皮书》——6.1.2 系统安全场景的加解密加速方案(下)
带你读《2022龙蜥社区全景白皮书》——6.1.2 系统安全场景的加解密加速方案(下)
284 58

热门文章

最新文章