谷歌Borg论文阅读笔记(二)——任务混部的解决

简介: BorgMaster在全局进行任务调度和分配资源,Borglet管理主机层面的资源隔离。

总算又往下读了一部分。Google的Borg论文中,前面部分讲的都是Borg的架构。后面有讲了一些资源隔离,安全隔离等的技术方案和策略。

主机层面的资源隔离,都是由是Borglet来操纵的。

Google的混部情况:

Google几乎所有的机器都是混部的,在一台机器上,可能运行着不同jobs的tasks。根据论文中所说,Google的50%的机器运行了9个甚至更多的tasks。90%的机器运行着25个tasks,达到4500个线程。

因此,Google有完善的隔离技术来保证task之间不相互影响。目前,Google使用的隔离技术是Chroot和CgroupCgroup本来就是Google最先提交到内核社区的,应该就是为了解决Borg的隔离。

对于外部的软件,比如GAE和GCE,Google的做法是让它们运行在虚拟机(KVM)上,KVM进程被作为Borg的task运行。也就是说,Borg是作为下层的,KVM运行在它之上

资源共享的问题:

资源共享带来的问题主要就是两个,一个是安全,一个是资源之间的性能影响

安全方面:

系统采用了Chroot隔离了文件系统。对于程序的调试,全都通过Borg来操作,Borg会让用户的命令在和被操作的tasks同一个容器下的shell中运行。

性能影响:

对于性能的影响,Google使用了很多技术来减少影响,这个是文章后面详细讲的。这里主要讲的是Google对任务混部对CPU性能影响的研究。

Google为了评估不同任务部署到同一个机器的CPU干扰影响做了一个实验。他们使用CPI(每条计算机指令执行所需的时钟周期)来衡量性能干扰。CPI增加一倍,CPU密集型程序运行时间就会增加一倍,对应于即时相应的程序,可能就是延时增加了一倍

实验发现,CPI和2个相同时间间隔的测量成正相关机器的整体CPU使用率,以及运行在机器上的tasks

  1. 添加一个task到一台机器上,会增加别的任务0.3%的CPI(使用线性模拟合数据)。
  2. 增加10%的CPU利用率会增加2%的CPI。

这是CPU密集型的程序测量的结果,事实上干扰存在于各种资源。

相对而言,专用的cells的CPI要低于混用的cells。据Google的统计,共享cells的CPI平均值为1.58(σ = 0.35)。在专用cells中,CPI平均值为1.53(σ = 0.32),CPU性能在共享cells中有大约下降3%。

但这也表明,使用共享的cells并没有大幅度增加程序运行的成本,而在机器需求方面,共享的cells更节约机器。另外。共享的优势适用于所有资源,包括内存和磁盘,而不仅仅是CPU。当然,Google还是有些特别的服务是放在专用的cell上的。

Google也对cell的大小进行了评估,发现cell越大越节约机器

任务分类:

Google对jobs是分类为prod和non-prod的。prod指的是面向应用这类jobs,non-prod指的是批处理这类jobs。对于主机上的tasks,则是分为延迟敏感型(latency-sensitive)批处理(rest)。因为non-prod的jobs中的master应该也是延迟敏感的,所以需要在task上进行分类。

个人理解:non-prod和prod是在BorgMaster调度时看的,是一个全局的维度。而latency-sensitive和rest是Borglet在主机的task层面上看的,是一个资源分配的维度。

另外,Borg中,主机的资源其实是超卖的(不然怎么节约资源),包括可压缩和不可压缩的资源。因此,可能会出现所有tasks都没有超过限制值,而主机资源不足的情况。此时,就需要根据task的分类来进行取舍。

延迟敏感型(latency-sensitive):

未作特殊说明,下面采用缩写LS tasks来表示延迟敏感型的任务。

LS tasks用于面向用户的应用,以及共享设施服务,它需要快速响应请求。高优先的LS tasks享受最好的待遇。能暂时让批处理饥饿几秒钟。

批处理(rest):

用于离线计算的进程,用于利用那些再生资源。基本是说被kill就被kill。

资源分类:

混部的一大问题是某个资源不足的情形。但是,不同的资源有不同的特点,有的资源能快速调整,而有的则需要很大的代价来调整。因此,Borg将资源分为两大类:可压缩资源(compressible resources)不可压缩资源(non-compressible resources)

可压缩资源(compressible resources)

这种资源指的是CPU,磁盘IO这类资源。它们是基于比例的,可以通过降低服务质量来调整资源分配,这种调整消耗的代价极少,几乎可以忽略

可用的方案:

  • CPU:Cgroup中的cpu子系统,可以限流CPU执行周期,也可以调整调度权重。
  • IO:Cgroup中的disk子系统,可以在块设备层面限流IOPS和流量。也能在更底层的IO调度层调整权重(权重调整只支持CFQ,但是注意CFQ并不适合SSD)。

对LS tasks的优待:LS tasks可以保留完整的CPU核心,阻止其它LS tasks使用它们。批处理tasks可以运行在任何CPU核心下,但它被给予相对于LS tasks很小的调度份额。Borglet动态调整LS tasks的资源限制,为了确保它不会把批处理tasks饿死几分钟,在需要的时候,选择性的应用CFS控制带宽。

CFS改进:Cgroup中,CPU子系统是依赖于CFS调度算法,这是目前Linux的默认任务调度算法。Google为了减少调度延时和高利用率,调优了CFS调度程序。另外,Google的程序多采用多线程模型,这能减轻持续负载失衡的影响。

  • 允许对LS tasks抢占批处理的tasks。
  • 在多个对LS tasks在一个CPU下运行时,减少调度量。

主机资源超配:如果机器用尽了可压缩资源,Borglet会对某些task进行限流处理(给对LS tasks足够的资源)。这样,短负载峰值就可以被处理,而不需要kill掉任何tasks。如果情况没有改善,Borgmaster会从这台机器上迁移掉一些tasks。

不可压缩资源(non-compressible resources)

这种资源的典型代表就是内存,还有就是磁盘容量。此类资源的调整是很难的,比如内存,在内存不足的时候,Linux会进行内存回收,该刷盘的刷盘,写swap的写swap。如果这还不行,就会进入OOM-KILL流程。这个代价是很大的。

因此,如果不可压缩资源不足,就只能kill掉进程来回收资源,Google也是这么干的(操作系统也只能这么做)。

可用的方案:

  • 内存:Cgroup的memory子系统可以支持限制内存使用。Cgroup内的内存有自己的LRU链,所以Cgroup内部也会自动换页。此外,在Cgroup内的内存用尽之时,也会触发Cgroup内的OOM-KILL流程。另外,系统自身的OOM-KILL级别是高于Cgroup的。
  • 磁盘:这块不清楚Google是怎么做的,Cgroup也没有支持这个。有的软件是quota磁盘限额,可以限定文件夹内使用磁盘空间的大小,超过了就禁止写入。最早听说这是间隔扫描的方式,觉得不靠谱,现在应该改进成用inotify了。

主机资源超配:当不可压缩资源不足时,Borglet会从优先级最低的task开始kill,直到资源足够。

资源分配:

细粒度资源请求:

Google的资源分配是由用户申请的,用户可以指定各种资源的所需大小。而不是类似售卖虚拟那样有固定的规格。

Google对此做过实验,使用固定规格容器,根据CPU核心和内存两个维度的限制,四舍五入到下一个大于等于资源需求的规格。最小规格为0.5个CPU核心,1G内存。实验的结论是,这么做会增加30%-50%的资源开销。而且这还是在cell被压实之前的,压实后cell的资源开销更低。此外,cell还能支持CPU和内存的独立伸缩。

资源分配方法:

每个tasks和资源有3个相关的数据。分别是:申请值,估值,使用值

  1. 申请值:也就是限制值申请资源时,用户填写的值。
  2. 估值:Borg对程序使用资源量的估计,也被称为预定(reservation)。一般是使用值加上一定保护缓冲区。
  3. 使用值:当前task使用的资源值,是采集的数据。

估值是为了能回收利用那些没被用到的资源。每过几秒,BorgMaster会进行一次计算。

最初的估值会等于申请值,300秒之后,允许启动瞬变(startup transients),它会缓慢的向实际使用加上安全边缘靠拢如果使用量超过了估值,估值会迅速增加。

Borg调度者使用申请值(限制值)来计划prod tasks(分配时按照限制来算),因此它们从不依靠再生资源,也不会超额分配资源。对于non-prod tasks,它使用现有tasks的预定,所以新的任务能调度到再生资源(分配时按照现有估值来算)。

资源超限制值:

Tasks允许使用资源量通常在限制值内。但只要主机资源足够,就可以使用超出限制值的资源。当然,这会增加tasks被Kill掉的可能性。当BorgMaster分配任务时发现资源不足时,它会优先回收超过限制值的tasks的资源。

大多数tasks允许使用可压缩资源超过限制值。比如CPU,Borg以此来利用未被利用的(松弛)资源。在Google中,只有5%的LS task禁止使用资源超过限制值,大概是为了获得更好的可预测性。只有少于1%的批处理tasks这么做(禁止资源使用超过限制值)。

使用内存超过限制值默认是被禁止的,因为这增加了task被kill掉的机会。但即使如此,10%的LS tasks重写了这个(允许内存使用超过限制值)。79%的批处理任务这么做,因为这是MapReduce框架的默认设置。

总结:

总的来说,Google节约资源其实就是在合理的情况下,对资源进行了超分配。因为很多任务其实并不是任何时刻都会用很多资源的。

另外,Google对任务和资源进行了分类。总体上,以高优先的LS task为核心批处理任务以一个填坑的角色来吃掉剩余的资源。尽可能不kill掉tasks,万不得已情况下先拿低优先级开刀。

这确实是个很成熟的资源隔离方案,值得借鉴。

转载请注明:云计算技术手札 » 谷歌Borg论文阅读笔记(二)——任务混部的解决

目录
相关文章
|
2月前
|
机器学习/深度学习 人工智能 自然语言处理
社区供稿 | 元象发布255B大规模MoE开源大模型,落地应用登顶港台榜
元象XVERSE发布 中国最大MoE开源模型:XVERSE-MoE-A36B,加速AI应用低成本部署,将国产开源提升至国际领先水平。
社区供稿 | 元象发布255B大规模MoE开源大模型,落地应用登顶港台榜
|
4月前
|
人工智能 算法
等不来OpenAI的Q*,华为诺亚探索LLM推理的秘密武器MindStar先来了
【7月更文挑战第13天】华为诺亚方舟实验室推出MindStar,一种增强LLM推理能力的搜索框架。MindStar通过PRM奖励模型和Beam/Levin Search策略选择最佳推理路径,提升开源模型如LLaMA-2-13B、Mistral-7B的性能,与GPT-3.5等闭源模型媲美,但成本更低。尽管推理成本高和需预训练PRM,MindStar为LLM推理研究开辟新途径。[论文链接](https://arxiv.org/pdf/2405.16265v4)
88 9
|
4月前
|
人工智能
ACM最新论文戳破大公司开源谎言,GenAI时代到底如何定义开源模型
【7月更文挑战第2天】ACM论文揭示GenAI开源真相,指出开源模型常缺乏开放数据集、完整代码与功能,质疑大公司仅借开源名义吸引利益。论文倡导重新定义开源,提议全面评估框架、加强监管及教育,确保真开源,促进领域健康发展。[链接:https://dl.acm.org/doi/3630106.3659005]
76 16
|
6月前
|
机器学习/深度学习 人工智能 自然语言处理
2024 年最强?!深度剖析 OpenAI 最新 Sora 王炸模型!
2024 年最强?!深度剖析 OpenAI 最新 Sora 王炸模型!
62 1
|
人工智能 搜索推荐 算法
AAAI 2023杰出论文一作分享:新算法加持的大批量学习加速推荐系统训练
AAAI 2023杰出论文一作分享:新算法加持的大批量学习加速推荐系统训练
294 0
|
达摩院 算法 调度
阿里达摩院KDD 2022最佳论文线上分享:核心作者解读FederatedScope-GNN
阿里达摩院KDD 2022最佳论文线上分享:核心作者解读FederatedScope-GNN
159 0
|
存储 人工智能 文字识别
【OpenVI—论文解读系列】开源低成本大规模分类框架FFC CVPR论文深入解读
图像分类是当前AI最为成功的实际应用技术之一,它已经融入了人们的日常生活。它被广泛的应用到了计算机视觉的大部分任务中,比如图像分类、图像搜索、OCR、内容审核、识别认证等领域。目前已形成一个普遍共识:“当数据集越大ID越多时,只要训练得当,相应分类任务的效果就会越好”。但是面对千万ID甚至上亿ID,当下流行的DL框架下,很难低成本的直接进行如此超大规模的分类训练。
420 0
|
Web App开发 人工智能 自然语言处理
ChatGPT自己会选模型了!微软亚研院+浙大爆火新论文,HuggingGPT项目已开源
ChatGPT自己会选模型了!微软亚研院+浙大爆火新论文,HuggingGPT项目已开源
207 0
|
机器学习/深度学习 人工智能 自然语言处理
史上最全Transformer合集!LeCun力推:给60个模型建目录,哪篇论文你错过了?
史上最全Transformer合集!LeCun力推:给60个模型建目录,哪篇论文你错过了?
394 0
|
机器学习/深度学习 自然语言处理 搜索推荐
机器学习新宠:对比学习论文实现大合集,60多篇分门别类,从未如此全面(一)
机器学习新宠:对比学习论文实现大合集,60多篇分门别类,从未如此全面(一)
287 0
机器学习新宠:对比学习论文实现大合集,60多篇分门别类,从未如此全面(一)
下一篇
无影云桌面