草庐IT

Volcano:在离线作业混部管理平台,实现智能资源管理和作业调度

华为云开发者联盟 2023-03-28 原文
摘要:​本文结合华为CCE团队在混合部署方面的研究和实战,介绍了混合部署的背景、概念、混部技术的设计方案和实际落地情况,以及对未来的计划和展望。

现代互联网数据中心的规模随着应用服务需求的快速增长而不断扩大,但服务器资源利用率却一直很低,导致企业基础设施成本不断上涨。随着云原生技术的发展,混合部署成为了降低成本的一大手段。本文结合华为CCE团队在混合部署方面的研究和实战,介绍了混合部署的背景、概念、混部技术的设计方案和实际落地情况,以及对未来的计划和展望。

云原生与资源利用率现状

云原生概念在2013年由Matt Stine提出并沿用至今,经过不断的总结完善,已经涵盖了DevOps、持续交付、微服务、容器化等主题,成为一套完整的技术方法体系。通过构建易观测、低耦合、容错性高的系统来达成提高效率、加速创新、降低成本的目标。

随着云原生基础技术日渐成熟,在提升效率和加速创新的目标上已经取得了显著的成效。得益于效率提升的优势,如今千行百业都在拥抱云原生,Gartner报告指出,到2022年将有75%的全球化企业在生产中使用云原生的容器化应用。同时伴随着开源项目的不断更新和逐步成熟,其加速创新的优点也促使各企业在AI、大数据、边缘、高性能计算等新兴业务场景不断采用云原生技术来构建创新解决方案。然而在降低成本的目标上,当前仍面临着基础设施成本高昂和资源利用率低下的问题。全球云基础设施服务支出保持千亿美元的年增长,总体规模已经突破万亿美元大关,中国仅IDC业务在2019年就突破了千亿大关,并保持30%的年增长率。根据Dell'Oro市场研究公司于2021年7月发布的预测,未来五年服务器支出将以11%的年复合增长率增长,到2025年将占数据中心资本支出的近一半。《中国“新基建”发展研究报告》称,到2025年,数据中心将占全球能耗的最大份额,高达33%。另一方面,全球服务器平均利用率不到20%,我国大多数数据中心的PUE普遍大于2.2。由此可见,云基础设施在降低成本上还有很大的提升空间。

图 1 中国数据中心市场规模

2021年7月工业和信息化部印发的《新型数据中心发展三年行动计划(2021-2023年)》(简称“计划”)提出,到2021年底,全国数据中心平均利用率力争提升到55%以上,总算力超过120 EFLOPS,新建大型及以上数据中心PUE降低到1.35以下。到2023年底,平均利用率力争提升到60%以上,总算力超过200 EFLOPS,新建大型及以上数据中心PUE降低到1.3以下。

为了帮助达成“计划”的目标,这里简要分析资源利用率低下的原因,并基于HCE(Huawei Cloud EulerOS)制定一套行之有效的解决方案。

在离线混合部署的提出

造成服务器资源利用率低的主要原因可以归为两大类:

1、不同类型业务分开部署在不同的资源池

为了避免业务之间的竞争影响到服务质量,不同类型的业务通常分开部署在不同的资源池。但业务的运行往往存在高峰期和低谷期,例如网购、社交一类的业务在白天的使用量明显高于夜间,但版本构建、测试类的业务则主要集中在晚上运行。分开部署导致服务器普遍存在空闲周期,很多业务空闲期远长于高峰期,导致总体资源利用率很低。

2、服务预留资源与实际使用资源之间存在较大冗余

企业通常采用过量供应资源的方式来保障服务质量,导致预留的资源量与实际的使用量之间存在较大的差距,下图为推特数据中心管理系统30天内的CPU和memory资源预留和实际使用情况,CPU实际使用值在20%上下,但预留值却接近80%,超出了实际使用值的三倍,内存预留则超出了实际使用值的1.5倍。

图 2 推特数据中心资源利用率

基于以上原因,如果能够将业务的波谷时段利用起来,就能减少波谷时间,从时间维度提升效能;同理,将资源预留冗余缩小,就能从空间维度提升效能。因此将不同优先级、不同波动周期的业务进行混合部署,为两个维度提升利用率提供了可能性,即利用低优先级任务占用空闲资源,同时高优先级任务能及时抢占到资源,从而保证关键业务的服务质量。在离线业务在特征上很好的满足了上述条件,本文提到的混合部署特指在离线混合部署。

在线业务通常是处理用户请求的服务,包含交易、购物、搜索、网页浏览等对于实时响应要求高、延时敏感的业务。离线业务通常是计算密集型的批处理任务,包含大数据分析、机器学习训练、算法运算、统计报告等优先级较低、相应要求不高的业务。在离线任务的主要特征如下表所示:

表 1 在离线业务特征

从表1可以看出,在离线业务在很多特征上具有互补性,将二者进行混合部署也已经成为数据中心提升整体资源利用率的主流方法。

方案设计

方案介绍

在离线业务混合部署对容器管理平台提出了更高的要求,这些要求包括:

  1. 调度器需要同时支持在线任务和离线任务的调度,离线任务对调度器提出了更高的性能要求、更多的调度特性需求,比如大数据或AI任务需要支持gang-scheduling、binpack等。
  2. 工作节点支持同时运行在线和离线容器,在离线业务统一管理。
  3. 超卖特性支持,根据节点实时和预测的空闲资源进行调度,提升资源利用率的同时减少在离线运行干扰以达到单次调度最优。
  4. 多维度资源隔离与抢占,确保离线任务充分利用空闲资源的前提下,支持在线任务对资源百毫秒级抢占。
  5. 节点可观测性增强,对在离线任务资源布局动态优化,识别在线业务是否受到干扰,对干扰进行定位和控制。
  6. 集群可观测性增强,对集群任务布局动态优化,减少集群资源使用不均衡问题。
基于Volcano混合部署解决方案如下图所示:

图 3 基于Volcano混合部署架构

Volcano混部调度能力

目前Kubernetes的默认调度器是以Pod为单位进行调度的,不区分Pod中运行的业务类型。因此无法满足混部场景对资源分配的特殊要求。针对上述问题,Volcano实现了基于应用模型感知的智能调度算法,根据用户提交的作业类型,针对其应用模型对资源的诉求和整体应用负载的情况,优化调度方式,通过资源抢占,分时复用等机制减少集群资源的空闲比例。

Volcano应用模型感知分为两种:

1.作业类型感知:能够识别在线作业和离线作业。

2.Pod类型感知:能够识别作业中不同类型的Pod,例如Tensorflow作业中的PS和Worker,Spark作业中的Driver和Executor等。

针对作业类型感知,Volcano通过作业混合部署+资源超卖的方式,实现集群资源利用率的提升,示意如下:

图 4 混合调度超卖示意图

资源超卖是指将集群资源申请量与使用量的差值进行再次分配,进而提升集群的资源使用率,参考如下方式进行:

图 5 资源超卖示意图

其中request-used为资源超卖部分,Volcano调度器会将这部分资源再次分配。由于超卖资源的稳定性不能保证,因此只能用于运行SLA较低的离线作业。

用户提交多种类型作业时,Volcano进行统一调度,优先保证在线作业运行(如图4所示)。当在线作业压力较低时,意味着节点上物理资源的使用率较低,此时Volcano会进行资源超卖,将离线作业调度到相应的节点上运行。当在线作业压力变大时,Volcano会驱逐掉当前节点上的离线作业,保证在线作业能够正常运行。

针对Pod类型感知,Volcano根据应用模型对资源的诉求和整体应用模型本身运行的要求,进行优化调度。以Tensorflow作业为例,一个Tensorflow作业中包含若干PS Pod和若干Worker Pod,当PS Pod和Worker Pod能够均匀分配时,TF作业的运行效果更优。例如,对于一个包含2个PS Pod和4个Worker Pod的TF作业,默认调度器和Volcano对比如下:

图 6 作业类型感知调度

可以看出,在资源充足的情况下,默认调度器会出现PS Pod和Worker Pod分别被调度到不同节点的情况,Volcano能够保证将1个PS Pod和2个Worker Pod调度到一台节点上,从而提升作业整体运行效率。

目前K8S提供的默认调度器,仅根据节点资源请求数量调度Pod。该方式并未考虑到节点实际资源使用情况,可能会出现各个节点资源申请率相同,而实际负载差别较大的情况。对于高负载的节点,可能会导致应用响应速度变慢,无法满足SLA。对于低负载的节点,则存在资源浪费的情况。

针对该问题,Volcano提出了基于节点物理资源使用率的预测及调度功能,提供以下三方面的能力:

1.预测调度:接入集群监控系统,根据节点及Pod历史资源使用率,预测未来节点及Pod资源使用率的变化趋势,根据预测结果进行合理调度。

2.负载均衡调度:根据集群各节点当前负载情况,结合未来使用趋势的预测,将pod调度到使用率较低的节点,进而提升整个集群资源使用的均衡性。

3.资源抢占调度:节点资源不足时,调度器实时驱逐部分离线作业,保证在线作业的资源使用。

节点管理

混合部署的节点管理主要包括两个部分,一是资源配置管理,二是干扰控制管理。资源配置组件主要负责在pod创建时配置相关的优先级用于资源隔离。干扰控制组件主要负责在容器运行时动态检测异常并进行相关处理。

图 7 cgroup控制层级

虽然kubernetes支持多种QoS类型的Pod,如Guaranteed、Burstable和BestEffort,但是这些类型并不能和在离线任务直接对应。HCE通过新增cgroup接口来控制pod的优先级,如cpu cgroup下的cpu.qos_level用于控制当前Pod对CPU资源抢占的优先级。当前通过kubelet执行相关配置操作,保证Pod各资源配置的一致性。

资源超卖及在离线作业混部必然会导致不同作业之间的相互干扰,因此除了通过cgroup进行资源隔离之外,kubelet同时会实时采集节点上物理资源使用率,根据不同的情况驱逐离线作业,提前释放相应资源,防止对在线作业的SLA产生影响。

节点资源隔离

资源隔离技术涉及的资源包括CPU、内存、网络和IO等等,针对每一种资源,需要结合已有隔离技术来应对混合部署场景下的新需求。在离线混合部署对资源的需求可归纳为两点:对于资源分配情况优先供应给在线任务,对于资源回收情况优先从离线任务回收资源。

对于CPU资源,目前内核已经提供丰富的隔离和带宽控制技术,例如调度类、调度策略、进程优先级、cpu.shares等,但这些技术并非为混合部署设计,使用上存在如下一些问题。

  • 调度类:不同的调度类优先级不同,并且支持快速抢占,这一特点和混合部署的需求吻合。但由于系统进程运行在CFS类上,离线任务就只能用优先级更低的IDLE调度类,而IDLE调度类不能用于普通进程调度,因此不能通过设置不同调度类来支持CPU抢占。
  • 调度策略:CFS支持多种调度策略,不同策略优先级也不同,这也是混合部署所需要特性。由于通用进程运行在SCHED_NORMAL策略,因此离线任务可以选择优先级更低的SCHED_BATCH或SCHED_IDLE策略。使用调度策略的关键问题是没有提供cgroup控制接口,用户无法通过cgroup配置Pod的调度策略。
  • 权重(优先级&cpu.share):进程优先级和cpu.shares通过虚拟时间片来控制CPU权重,只能保障总体运行时间比例,本质上属于公平调度的范畴,不能保障在线进程实时抢占离线进程。
HCE目前的做法是在SCHED_IDLE上进行修改以满足离线进程调度:

  1. 新增cgroup接口cpu.qos_level来控制Pod中所有进程的优先级。
  2. 引入throttle机制对离线任务进行进一步压制,使得在线任务能够独占CPU。
  3. 增加kill boost机制避免当在线业务100%占用CPU时,杀死离线任务无法释放资源的问题。
  4. 对在线任务进行高负载检测,超时后对内核态离线任务放行,防止离线进程在内核态发生优先级反转导致系统假死。
在内存资源方面,HCE通过如下能力支持内存分级保障:

  1. 新增cgroup接口memory.qos_level来控制Pod优先级。
  2. 分级回收:通过内存回收水位分级和OOM回收分级来保障在线任务内存需求。
  3. kill快速回收:该技术可以使得分配内存触发大量离线任务OOM的情况下仍能具有较高的内存分配性能。
  4. 页缓存限制:避免因page cache使用过多导致内存不足从而影响业务功能。
网络资源原生可以使用TC HTB规则控制优先级,但该方法配置繁琐,规则数量增加时会导致性能损耗变大,对于在线小报文离线大报文情况,在线任务性能会受到干扰。

HCE对此提出以下网络隔离优化机制:

  1. 基于eBPF和EDT技术实现动态限速分配策略,根据业务优先级自动调整带宽,实现per-cgroup级别的带宽隔离。
  2. 网络带宽优先级抢占机制,当在线业务占用带宽比较低时,空闲带宽能够分配给离线业务使用;而当在线业务需要更多带宽时,能够迅速(<100ms)将带宽从离线业务上抢占回来。
  3. 对离线业务提供最低带宽保障,避免饥饿导致的业务中断。

落地效果

CPU隔离效果

这里使用CloudSuite验证CPU隔离效果,使用web-serving模拟在线业务,in-memory-analytics模拟离线业务。使用三种部署方式进行验证:只运行在线、在离线混合部署、在离线混合部署(开启QoS隔离特性)。测试数据如下所示,利用CPU抢占能力可以让在线任务达到接近独立部署的性能。

图 8 混合部署响应时间

网络隔离效果

网络通过netperf进行测试,分别在不同优先级Pod执行发包测试,在离线发包时序如下图所示,时间轴单位为s,在第5秒验证离线对在线的性能影响,在第15秒验证在线任务对网络的抢占能力。

图 9 网络发包时序

采样数据如下图所示,启动离线任务对在线任务网络性能影响较小,在线任务可以在100ms时间内完成网络性能从0到最大的抢占。

图 10 网络抢占性能

计划与展望

虽然混合部署解决方案是提升资源利用率的重要技术手段,但该方案目前没有形成业界统一标准,存在重复设计,通用性不强等问题。后续计划向kubernetes和linux内核提交贡献来推进生态标准化。

未来,混合部署的含义也将随着技术的发展而逐渐丰富,例如多种类型任务的混合部署,异构资源的混合部署等等。因此需要在两级优先级设计的基础上,探索多级优先级场景和扩展方案,以支持更丰富任务类型。异构和跨代硬件资源的混合部署对传统基于资源部署的方式提出了新的需求,让业务的部署不再需要感知底层硬件资源才能提供更智能的调度、更精准的资源匹配。

此外,仍有部分资源没有分级抢占能力,例如L1/L2缓存、缓存带宽等,因此混合部署的性能干扰不可避免。为了让混合部署后仍能提供优质的服务质量,不仅要从芯片微架构到上层调度层进行全面设计,还需要一种预测、反馈和校正机制。

参考资料

1. ​​云原生2.0白皮书​

2. ​​数据中心产业发展指数2021年​

3. ​​新型数据中心发展三年行动计划(2021-2023年)​

4. ​​中国数据中心行业研究报告2020年​

5. 王康瑾,贾统,李影.在离线混部作业调度与资源管理技术研究综述.软件学报,2020,31(10):3100-3119

6. ​​Interference-Aware
Scheduling for Inference Serving​


点击关注,第一时间了解华为云新鲜技术~

有关Volcano:在离线作业混部管理平台,实现智能资源管理和作业调度的更多相关文章

  1. ruby - i18n Assets 管理/翻译 UI - 2

    我正在使用i18n从头开始​​构建一个多语言网络应用程序,虽然我自己可以处理一大堆yml文件,但我说的语言(非常)有限,最终我想寻求外部帮助帮助。我想知道这里是否有人在使用UI插件/gem(与django上的django-rosetta不同)来处理多个翻译器,其中一些翻译器不愿意或无法处理存储库中的100多个文件,处理语言数据。谢谢&问候,安德拉斯(如果您已经在ruby​​onrails-talk上遇到了这个问题,我们深表歉意) 最佳答案 有一个rails3branchofthetolkgem在github上。您可以通过在Gemfi

  2. ruby - 完全离线安装RVM - 2

    我打算为ruby​​脚本创建一个安装程序,但我希望能够确保机器安装了RVM。有没有一种方法可以完全离线安装RVM并且不引人注目(通过不引人注目,就像创建一个可以做所有事情的脚本而不是要求用户向他们的bash_profile或bashrc添加一些东西)我不是要脚本本身,只是一个关于如何走这条路的快速指针(如果可能的话)。我们还研究了这个很有帮助的问题:RVM-isthereawayforsimpleofflineinstall?但有点误导,因为答案只向我们展示了如何离线在RVM中安装ruby。我们需要能够离线安装RVM本身,并查看脚本https://raw.github.com/wayn

  3. ruby - 如何根据特征实现 FactoryGirl 的条件行为 - 2

    我有一个用户工厂。我希望默认情况下确认用户。但是鉴于unconfirmed特征,我不希望它们被确认。虽然我有一个基于实现细节而不是抽象的工作实现,但我想知道如何正确地做到这一点。factory:userdoafter(:create)do|user,evaluator|#unwantedimplementationdetailshereunlessFactoryGirl.factories[:user].defined_traits.map(&:name).include?(:unconfirmed)user.confirm!endendtrait:unconfirmeddoenden

  4. ruby-on-rails - 获取 inf-ruby 以使用 ruby​​ 版本管理器 (rvm) - 2

    我安装了ruby​​版本管理器,并将RVM安装的ruby​​实现设置为默认值,这样'哪个ruby'显示'~/.rvm/ruby-1.8.6-p383/bin/ruby'但是当我在emacs中打开inf-ruby缓冲区时,它使用安装在/usr/bin中的ruby​​。有没有办法让emacs像shell一样尊重ruby​​的路径?谢谢! 最佳答案 我创建了一个emacs扩展来将rvm集成到emacs中。如果您有兴趣,可以在这里获取:http://github.com/senny/rvm.el

  5. ruby-on-rails - 事件管理员日期过滤器日期格式自定义 - 2

    是否有简单的方法来更改默认ISO格式(yyyy-mm-dd)的ActiveAdmin日期过滤器显示格式? 最佳答案 您可以像这样为日期选择器提供额外的选项,而不是覆盖js:=f.input:my_date,as::datepicker,datepicker_options:{dateFormat:"mm/dd/yy"} 关于ruby-on-rails-事件管理员日期过滤器日期格式自定义,我们在StackOverflow上找到一个类似的问题: https://s

  6. 华为OD机试用Python实现 -【明明的随机数】 2023Q1A - 2

    华为OD机试题本篇题目:明明的随机数题目输入描述输出描述:示例1输入输出说明代码编写思路最近更新的博客华为od2023|什么是华为od,od薪资待遇,od机试题清单华为OD机试真题大全,用Python解华为机试题|机试宝典【华为OD机试】全流程解析+经验分享,题型分享,防作弊指南华为o

  7. 基于C#实现简易绘图工具【100010177】 - 2

    C#实现简易绘图工具一.引言实验目的:通过制作窗体应用程序(C#画图软件),熟悉基本的窗体设计过程以及控件设计,事件处理等,熟悉使用C#的winform窗体进行绘图的基本步骤,对于面向对象编程有更加深刻的体会.Tutorial任务设计一个具有基本功能的画图软件**·包括简单的新建文件,保存,重新绘图等功能**·实现一些基本图形的绘制,包括铅笔和基本形状等,学习橡皮工具的创建**·设计一个合理舒适的UI界面**注明:你可能需要先了解一些关于winform窗体应用程序绘图的基本知识,以及关于GDI+类和结构的知识二.实验环境Windows系统下的visualstudio2017C#窗体应用程序三.

  8. MIMO-OFDM无线通信技术及MATLAB实现(1)无线信道:传播和衰落 - 2

     MIMO技术的优缺点优点通过下面三个增益来总体概括:阵列增益。阵列增益是指由于接收机通过对接收信号的相干合并而活得的平均SNR的提高。在发射机不知道信道信息的情况下,MIMO系统可以获得的阵列增益与接收天线数成正比复用增益。在采用空间复用方案的MIMO系统中,可以获得复用增益,即信道容量成倍增加。信道容量的增加与min(Nt,Nr)成正比分集增益。在采用空间分集方案的MIMO系统中,可以获得分集增益,即可靠性性能的改善。分集增益用独立衰落支路数来描述,即分集指数。在使用了空时编码的MIMO系统中,由于接收天线或发射天线之间的间距较远,可认为它们各自的大尺度衰落是相互独立的,因此分布式MIMO

  9. 【Java入门】使用Java实现文件夹的遍历 - 2

    遍历文件夹我们通常是使用递归进行操作,这种方式比较简单,也比较容易理解。本文为大家介绍另一种不使用递归的方式,由于没有使用递归,只用到了循环和集合,所以效率更高一些!一、使用递归遍历文件夹整体思路1、使用File封装初始目录,2、打印这个目录3、获取这个目录下所有的子文件和子目录的数组。4、遍历这个数组,取出每个File对象4-1、如果File是否是一个文件,打印4-2、否则就是一个目录,递归调用代码实现publicclassSearchFile{publicstaticvoidmain(String[]args){//初始目录Filedir=newFile("d:/Dev");Datebeg

  10. ruby - Arrays Sets 和 SortedSets 在 Ruby 中是如何实现的 - 2

    通常,数组被实现为内存块,集合被实现为HashMap,有序集合被实现为跳跃列表。在Ruby中也是如此吗?我正在尝试从性能和内存占用方面评估Ruby中不同容器的使用情况 最佳答案 数组是Ruby核心库的一部分。每个Ruby实现都有自己的数组实现。Ruby语言规范只规定了Ruby数组的行为,并没有规定任何特定的实现策略。它甚至没有指定任何会强制或至少建议特定实现策略的性能约束。然而,大多数Rubyist对数组的性能特征有一些期望,这会迫使不符合它们的实现变得默默无闻,因为实际上没有人会使用它:插入、前置或追加以及删除元素的最坏情况步骤复

随机推荐