【百度云原生导读】服务器资源利用率较低,TCO(IT 基础设施的总拥有成本)逐年上涨,对于拥有大量机器资源的公司来说无疑是一个头疼的问题。混部技术就是在这种情况下应运而生,目前,混部技术在业界还属于比较小众的领域,只有一些资源量级较大的公司在研究、发展混部技术,以期获得收益。
对于百度而言,通过应用混部技术,主混部集群数十万台,提升CPU利用率到40+%,累计节约了数十亿人民币。目前百度容器引擎产品 CCE 已支持在离线混部,并完成了大规模业务落地,本文将带大家深入了解百度的在离线混部技术。
混部概念中将应用类型分为在线业务和离线业务两种。
在线和离线业务如何划分?在百度内部,我们认为在线业务特点包括但不限于:运行时间长,延时敏感,对稳定向要求较高,服务不稳定业务会立马感知并且带来损失,有明显的波峰波谷,白天高,深夜低,比如广告搜索业务;而离线业务的特点包括但不限于非延时敏感,可重试,运行时间一般较短在几十分钟左右,内部一般为大数据计算,机器学习等服务。
在线业务以搜索为例,白天用户工作学习时查询量会非常大,但是当大部分用户夜间休息时,查询量相对白天就会变得非常小,此时我们就可以引入离线业务。离线业务没有严格的时间要求,随时都能跑,用户关心的是任务能不能跑完,对于什么时候跑完并没有太大的需求,同时如果单机上资源有冲突,此时我们会压制离线业务,甚至会驱逐离线业务,这对用户是无感的,计算平台重新拉起任务,继续计算。
因此,在线型业务和离线业务具备资源互补的特点,从时间上和对资源的容忍度上可以完美的结合到一起。一方面,在线业务的优先级更高,单机和调度层面会优先保障在线的资源,可能会对离线进行压制和驱逐,另一方面,对于离线任务来说,压制和驱逐对用户是无感的,只需要保证任务顺利完成,有很高的容忍度。
简单来说,将在线业务和离线任务混合混部到相同物理资源上,通过资源隔离、调度等控制手段 , 充分使用资源,同时保证服务的稳定性,我们称这样的技术为“混部”。
纯在线业务集群的平均利用率普遍不高,百度应用混部技术之前,在线业务集群CPU利用率普遍在20%左右,造成这种现象主要由一下几种原因:
2.1 潮汐现象和冗余
在线业务在申请资源的时候,一般是按照最高峰值评估资源去申请资源,同时还会上调一些,这就导致了业务对资源预估不准,申请的资源远大于实际使用资源。甚至可能会部署多个副本作为灾备。
此时的低峰时利用率就会非常低,导致整体利用率不高。
2.2 在离线分池
一般来说机房规划的时候有一个非常大的特点,就是离线机房与在线机房分离做规划。举个例子,假如我们在宁夏做一个机房,这个时候肯定会考虑做一个离线机房,因为在线机房需要考虑网民请求地域分布的问题,要获得最好的访问优化体验以及访问速度,势必需要在一些访问热点上去做自己的在线机房规划,比如北京、上海、广州等。
而对于离线机房来说不用关心这些,它最在乎的是如何提升计算和储存的资源和基础设施的规模,所以在线业务和离线业务本身的资源需求和特点不一样,资源利用率非常不均衡。常态表现就是在线利用率低,离线利用率高,且常态资源不足。
针对以上场景,我们通过在离线混部技术将在离线资源统一资源池,把离线作业部署在在线资源池节点上,充分利用机器资源,达到了提升资源利用率的目的。
随着 Kubernetes(以下简称「K8s」) 生态的蓬勃发展,百度很多业务已经搭建并且运维了自己的诸多 K8s 集群,同时也遇到了一些问题,比如上面所说的资源利用率不高。我们根据内部积累混部经验对 K8s 进行在离线混部原生化改造,做到了零入侵K8s,可移植,可支持大规模集群。
混部系统架构图
3.1 如何做到资源复用?
原生 K8s 基于静态视图分配
上图显示了一个节点的 CPU 使用率和分配率,分配率为89%, 使用率在0-16点之间都在20%以下,17点开始是用量高峰,在30-40%之间。可以看出 request 和 used 之间有大量的资源处于闲置状态,如果想让这部分资源可以重复利用起来,就需要调度更多的 Pod 上去,但是从 K8s 调度器视角来看,已经没有更多的 CPU 分给 Pod了。
如果部署 request 和 limit 都不填写的 Pod,此时它可以被调度,但是 K8s 针对这种 BestEffort 的 Pod 不会根据用量调度,可能会被调度到一个实际很繁忙的节点上,非但无法起到提升使用率的效果,可能还会加剧节点上服务的延迟。
动态资源视图
针对 K8s 无法根据资源使用量分配资源,我们引入了动态资源视图。
在混部调度中,在线和离线使用相同的物理资源,在线看到的资源视图和离线看到的资源视图相互独立。在线业务看到的可用资源依旧为整机资源进行静态分配,离线看到的可用资源为整机资源减去在线作业已经使用的资源。
从图中可以看出,在线申请用量和在线usage之间存在很大的差异,主要是由于研发同学部署业务选择容器资源规格时,带有一定的盲目性,申请量高于实际使用资源量或者按照超出峰值用量申请。混部离线可以复用这部分可回收资源,通过快速填充离线作业,把这部分资源利用起来。
高中优(在线)为静态分配 ∑High request + ∑Medium request <= Host Quota
动态计算低优(离线)可用量 Low Quota = Host Quota - ∑High used - ∑Medium used
注:以上是理想情况下的公式,实际应用中需要对离线使用量设置一个上限,此处排除了上限造成的影响。下面会有单机资源管理的说明。
由于 K8s 是静态分配,在 K8s 的 QOS 模型中 BestEffort 是不占用 request 的,即使一个 node 上即使资源已经分配完,但是 BestEffort 类型的资源依然可以调度上去,所以我们复用了 BestEffort 模型给离线任务使用,如上文架构图所示,这样有以下的优点:
3.2 优先级
由于在离线业务同时部署在相同节点上可能会产生干扰,我们从调度和单机两个方面对在线离线做了优先级区分。
大的优先级分为(高,中,低)三种,其中高优中优为在线业务,低优为离线业务。每个优先级优化分若干小优先级。
首先看一下 K8s 的 QOS 模型
对比 K8s 模型,百度混部调度器做了如下扩展:
3.3 资源隔离
由于在离线混部是将在线业务和离线任务混合混部到相同物理资源上,所以在离线业务由于流量激增,出现资源争抢时,如何保证在线的SLA不受影响,并且在保证在线服务的SLA时,也要保证离线任务的整体质量,保证离线作业的成功率和耗时。
cpuset 编排
针对于需要绑核的在线业务,单机上可以感知到 CPU 拓扑,不需要 kubelet 开启绑核机制,可以直接进行绑核,会将在线业务尽量绑在同一 NUMA node 上,避免跨 node 通信延迟。
NUMA 调度
NUMA 是一种内存管理技术,在 NUMA 架构下 CPU 被划分为多个 node,每个 node 都有各自的 CPU core 和 local memory,node core 中的进程访问 local memory 和 remote memory 的代价是不一样的。节点的所有内存对于本节点所有的 CPU 都是等同的,对于其他节点中的所有 CPU 都不同。因此每个 CPU 可以访问整个系统内存,但是访问本地节点的内存速度最快(不经过互联模块),访问非本地节点的内存速度较慢(需要经过互联模块),即CPU 访问内存的速度与节点的距离有关。
针对开启了 NUMA 的节点,我们感知 NUMA 架构,将在线业务绑在同一 NUMA 上,提升在线业务的性能,并且感知 NUMA 节点的负载,当 node 之间出现明显的不平衡时,进行重调度。
离线调度器
在线业务要求实时性高,延迟低;为了保证低延迟,CPU 负载不会打的特别高,当 CPU 负载升高时,在线间干扰会导致延时增大。而离线业务一般 CPU 利用率高,但是重吞吐不重延时。所以如果能满足在线的延时保障,在线和离线跑在一个核上不会对在线造成干扰,那么可以极大的提升资源利用率。
按照现在通用的 Linux 内核调度器调度算法,无法给在线服务做 CPU 的强保障,无法区分在离线业务,会导致在线无法抢占离线 CPU,并且在负载均衡时,因为无法区分在离线业务,可能在线业务会分配到相同的核上,无法打散。导致性能下降。
离线调度器是一种离线任务专用的CPU调度算法,从调度器上分开,在线调度器看不到离线任务。在线调度器先于离线调度器进行任务调度,存在在线任务时,离线得不到调度。所以对于在线任务来说,可以达到混部前相近的CPU 质量。
Linux 系统会经常执行一些写日志、生成备份文件的工作,当这些文件比较大时相应的 cache 就会占用大量的系统内存,而且这些类型的 cache 并不会被经常访问,所以系统会定期将这些 cache flush 到磁盘中。Linux 会通过cache 回收算法进行回收。这会造成两个问题:
1.容器的 page cache 得不到回收,它依赖于容器管理 page cache 的机制是需要才去回收的方式,即没有后台回收,每次都是分配时候发现到达 limit 了,在 alloc 的时候出发回收,如果业务压力较大,分配的速度大于回收的速度,就可能出现 OOM 的问题
2.cache 回收时并不会区分在线离线业务,会导致在线业务的 cache 可能会被先于离线 cache 回收掉,如果在线有大量的读 cache 行为,会造成 cache 命中降低,直接进行读盘操作,会导致在线业务的性能下降,甚至会导致IO 夯住。
为了解决以上的问题,我们新增了背景回收机制,背景回收指的是异步回收 cache,根据在线离线的 QOS 不同,设置不同的背景回收水位,优先回收离线业务的 cache。
网络层面我们也开发了容器级别的出入网带宽限制和流量打标等 Cgroup 子系统,可以对离线进行流量限制。
更多的内核隔离见下图:
现有的内核隔离策略都是基于 QOS,创建容器时进行 cgroup 配置,由内核进行统一的资源管理,但是某些高敏业务在最高优先级的 QOS 下也无法保证其特定资源,或者需要某一纬度的资源需要高优保证,此时通用隔离策略无法满足。
另外由于隔离调度策略是全局统一的策略,业务如果想根据自身特点修改一些隔离能力,只能由业务反馈平台,平台对底层进行修改,周期较长,并且全局应用的隔离能力可能会对离线或者其他业务造成误伤,所以把隔离提升到用户态更符合业务需求。
针对这样的场景,由于 eBPF 稳定,安全,高效,并有可热加载/卸载 eBPF 程序,无需重启 Linux 系统的特性,我们基于 eBPF 开发了定制策略,可以实时下发,实时生效,侵入性小,不需要对业务既有服务和平台侧进行修改。可以在用户态针对某些业务进行定制化隔离策略更新,达到服务可以无差别混部的目标。
在混部时,离线可以占用多少资源一直是一个问题。机型不同,在线服务的敏感度不同,离线业务占用的资源多少对在线造成的影响也不尽相同,针对这种情况,我们对集群纬度,池(具有相同特性的一批机器)纬度,节点纬度对离线可用资源上限做了限制,其中粒度最小优先级最高。
以 CPU 为例,如下图:
我们设置了整机的 CPU 阀值X,当整机 CPU 用量趋近或超过一定用量,比如X=50%时,会压缩离线使用的CPU资源。
列举一个简单的公式:
Offline Quota = Host Quota * X - ∑NotOffline Used
Offline Free = Offline Quota - ∑Offline used
同样,对于 Memory,IO和网络我们也做了同样的限制。这样我们可以根据不同的机型和业务很方便的调整离线的用量,避免在线用量升高时性能受到影响。
3.4 高性能调度器
在线和离线业务的调度需求是不一样的,在线一般为常驻服务,不会频繁变更,对调度器要求较低。但是离线任务由于具有运行时间短(几分钟到几小时),任务多的特点,以 K8s 默认调度器的调度性能不足以支撑离线任务的调度。所以我们开发了高性能的离线调度器,计算可以达到5000 ops。
如上图所示,我们调度了15W个 Pod,计算性能可以达到5k ops, 为了防止调度速度过快,对 ETCD 和整个集群造成压力,我们限制了binding速度为1500 ops。
3.5 资源画像
单机资源隔离是针对已经调度到节点上的任务进行隔离,如果检测到离线任务对在线产生一定的影响后,会很快响应对离线任务进行压制和驱逐的操作。这样会影响离线任务的稳定性。针对这种场景,如果在调度时可以预测到节点上未来一段时间的在线使用量,可以针对性的调度离线任务。
对比实时计算的资源模型,假设离线作业的运行时间为1小时,如果资源模型使用实时的资源视图,如果在线作业会在半个小时候用量升高,那么当离线作业运行半个小时之后,资源被在线压制,运行质量受影响。
我们预测了未来1小时窗口内的在线资源用量,调度适当的离线任务上去,即可确保任意离线作业运行过程中资源不受任何压制,从而达到提升运行质量的目的。
如何提供更稳定的超发资源,则取决于我们资源预测的准确度是什么样的。
不仅离线调度需要资源画像,在线调度也需要资源画像,通过资源画像可以有效的避免热点产生。
对于在线调度来说,调度的主要目标是提升服务的可用性,在调度时使用资源画像来预测未来一个周期内的用量,可以避免热点问题(某一纬度的资源用量过高),并且在重调度时也可以规避热点问题。
对于离线调度来说,调度的主要目标是提升集群的吞吐,降低作业的排队时间和执行时间,所以资源画像可以提升离线作业的稳定性,避免驱逐重新调度和资源压制导致执行时间过长。
4.未来展望
百度目前混部规模数十万台,它的混部集群 CPU 利用率比在线利用率提升 40%—80%,累计节省近10万台服务器。
未来百度混部的主要目标是继续扩大混部的规模,更大规模地节约资源成本,可以支持更多的负载类型,不局限于在离线混部,要做到无差别混部。
并在以下方向投入更多的力量:
通过 eBPF 可观测技术的创新,实现混部容器负载性能的近距离观察,达到进一步无损高密度混
利用 eBPF 热加载/卸载的特性,可以用户态下发隔离策略,快速的解决高敏的资源质量问题
关于百度容器引擎 CCE
百度容器引擎产品 CCE 提供 Docker 容器生命周期管理、大规模容器集群运维管理、业务应用一键式发布运行等功能,无缝衔接百度智能云其他产品。弹性、高可用的云端Kubernetes 容器运行平台,助力系统架构微服务化、DevOps运维、AI应用深度学习容器化等场景。
目前百度 CCE 已支持在离线混部,并完成了大规模业务落地,
本文由哈喽比特于3年以前收录,如有侵权请联系我们。
文章来源:https://mp.weixin.qq.com/s/yx576r-2PWvuoRiNhnx66A
京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而,京东官方通过微博发言人发布的消息澄清了这些传言,称这些言论纯属虚假信息和蓄意捏造。
日前,据博主“@超能数码君老周”爆料,国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为Mate60系列手机。
据报道,荷兰半导体设备公司ASML正看到美国对华遏制政策的负面影响。阿斯麦(ASML)CEO彼得·温宁克在一档电视节目中分享了他对中国大陆问题以及该公司面临的出口管制和保护主义的看法。彼得曾在多个场合表达了他对出口管制以及中荷经济关系的担忧。
今年早些时候,抖音悄然上线了一款名为“青桃”的 App,Slogan 为“看见你的热爱”,根据应用介绍可知,“青桃”是一个属于年轻人的兴趣知识视频平台,由抖音官方出品的中长视频关联版本,整体风格有些类似B站。
日前,威马汽车首席数据官梅松林转发了一份“世界各国地区拥车率排行榜”,同时,他发文表示:中国汽车普及率低于非洲国家尼日利亚,每百户家庭仅17户有车。意大利世界排名第一,每十户中九户有车。
近日,一项新的研究发现,维生素 C 和 E 等抗氧化剂会激活一种机制,刺激癌症肿瘤中新血管的生长,帮助它们生长和扩散。
据媒体援引消息人士报道,苹果公司正在测试使用3D打印技术来生产其智能手表的钢质底盘。消息传出后,3D系统一度大涨超10%,不过截至周三收盘,该股涨幅回落至2%以内。
9月2日,坐拥千万粉丝的网红主播“秀才”账号被封禁,在社交媒体平台上引发热议。平台相关负责人表示,“秀才”账号违反平台相关规定,已封禁。据知情人士透露,秀才近期被举报存在违法行为,这可能是他被封禁的部分原因。据悉,“秀才”年龄39岁,是安徽省亳州市蒙城县人,抖音网红,粉丝数量超1200万。他曾被称为“中老年...
9月3日消息,亚马逊的一些股东,包括持有该公司股票的一家养老基金,日前对亚马逊、其创始人贝索斯和其董事会提起诉讼,指控他们在为 Project Kuiper 卫星星座项目购买发射服务时“违反了信义义务”。
据消息,为推广自家应用,苹果现推出了一个名为“Apps by Apple”的网站,展示了苹果为旗下产品(如 iPhone、iPad、Apple Watch、Mac 和 Apple TV)开发的各种应用程序。
特斯拉本周在美国大幅下调Model S和X售价,引发了该公司一些最坚定支持者的不满。知名特斯拉多头、未来基金(Future Fund)管理合伙人加里·布莱克发帖称,降价是一种“短期麻醉剂”,会让潜在客户等待进一步降价。
据外媒9月2日报道,荷兰半导体设备制造商阿斯麦称,尽管荷兰政府颁布的半导体设备出口管制新规9月正式生效,但该公司已获得在2023年底以前向中国运送受限制芯片制造机器的许可。
近日,根据美国证券交易委员会的文件显示,苹果卫星服务提供商 Globalstar 近期向马斯克旗下的 SpaceX 支付 6400 万美元(约 4.65 亿元人民币)。用于在 2023-2025 年期间,发射卫星,进一步扩展苹果 iPhone 系列的 SOS 卫星服务。
据报道,马斯克旗下社交平台𝕏(推特)日前调整了隐私政策,允许 𝕏 使用用户发布的信息来训练其人工智能(AI)模型。新的隐私政策将于 9 月 29 日生效。新政策规定,𝕏可能会使用所收集到的平台信息和公开可用的信息,来帮助训练 𝕏 的机器学习或人工智能模型。
9月2日,荣耀CEO赵明在采访中谈及华为手机回归时表示,替老同事们高兴,觉得手机行业,由于华为的回归,让竞争充满了更多的可能性和更多的魅力,对行业来说也是件好事。
《自然》30日发表的一篇论文报道了一个名为Swift的人工智能(AI)系统,该系统驾驶无人机的能力可在真实世界中一对一冠军赛里战胜人类对手。
近日,非营利组织纽约真菌学会(NYMS)发出警告,表示亚马逊为代表的电商平台上,充斥着各种AI生成的蘑菇觅食科普书籍,其中存在诸多错误。
社交媒体平台𝕏(原推特)新隐私政策提到:“在您同意的情况下,我们可能出于安全、安保和身份识别目的收集和使用您的生物识别信息。”
2023年德国柏林消费电子展上,各大企业都带来了最新的理念和产品,而高端化、本土化的中国产品正在不断吸引欧洲等国际市场的目光。
罗永浩日前在直播中吐槽苹果即将推出的 iPhone 新品,具体内容为:“以我对我‘子公司’的了解,我认为 iPhone 15 跟 iPhone 14 不会有什么区别的,除了序(列)号变了,这个‘不要脸’的东西,这个‘臭厨子’。