书签 分享 收藏 举报 版权申诉 / 21

类型星汉未来:在离线混部解决方案白皮书(2022)(21页).pdf

  • 上传人:吱**
  • 文档编号:107209
  • 上传时间:2022-11-24
  • 格式:PDF
  • 页数:21
  • 大小:6.84MB
  • 配套讲稿:

    如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。

    特殊限制:

    部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。

    关 键  词:
    星汉 未来 离线 解决方案 白皮书 2022 21
    资源描述:

    1、星汉未来在离线混部解 决 方 案 白 皮 书Copyright 2022 北京星汉未来网络科技有限公司 版权所有,保留一切权利。非经本公司书面许可,任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部,并不得以任何形式传播。本文档中的信息可能变动,恕不另行通知。http:/galaxy-目录前言一、在离线混部简介1.1 什么是在离线混部1.2 在离线混部的适用场景1.3 在离线混部的成本价值1.4 在离线混部的技术挑战1.4.1 资源隔离1.4.2 任务调度1.4.3 资源复用1.4.4 资源保障三、在离线混部方案解析3.1 分类维度3.2 维度组合解析3.3 方案推荐场景3.2.1 内核隔

    2、离+容器底座+业务决策3.2.2 内核隔离+物理机底座+业务决策3.2.3 共享内核+物理机底座+业务决策3.2.4 共享内核+容器底座+自动调配二、一线大厂在离线混部架构及方案2.1 Google2.2 腾讯2.3 百度2.4 字节跳动2.5 快手2.6 阿里巴巴五、总结四、星汉未来在离线混部方案4.1 星汉未来产品矩阵4.2 星汉未来在离线混部方案0102020203030303030411111115121314150404060708091017161617CONTENTS01前言移动互联网高速发展的早期,企业更多关注业务扩张,用成本投入来换取市场占用率。但如今移动互联网经历了近十年的

    3、高速发展,互联网人口红利逐渐消退,几乎没有公司能够再忽视成本。无论是苹果公司的供应链、库存管理,还是特斯拉通过国产化降低成本,又或者是各大云厂商对企业 IT 成本的优化,都是企业保持高速发展的重要因素。企业在早期的资源使用上以满足业务需求为第一要务,资源的使用率管理相对粗放。中国信息通信研究院调查数据显示,在云原生技术给企业带来的各项价值中,“提升资源利用率以节约成本”已经连续两年排名第一,2021年有九成用户认可该项价值。随着企业用云程度加深,已经有越来越多应用迁移到云原生架构上,然而 2021 年 CNCFFinOps Kubernetes Report调研报告显示,迁移至 Kuberne

    4、tes 平台后,68%的受访者表示所在企业计算资源成本有所增加,36%的受访者表示成本飙升超过 20%,调查结果如图所示。这些都说明,即使是资源利用率更高的云原生架构也需要合理的资源成本管理。而在离线混部技术作为提升资源利用率,降低成本的理想方案,受到业界的一致认可和推荐。图1 云原生技术给企业带来的各项价值图2 迁移至 Kubernetes 平台后成本变化调查结果一、在离线混部简介02随着微服务、大数据、人工智能的不断发展,为了满足业务需求,企业的 IT 环境通常运行两大类服务,一类是在线服务,一类是离线作业。在线服务:一般长时间运行,服务流量存在周期特性,整体资源使用率不高,但有时延敏感,

    5、资源有潮汐特征,对服务 SLA 有着极高的要求,如微博 Feed 服务、电商交易服务等。离线作业:一般是资源密集型服务,计算需求大、容错率高、时延不敏感,中断允许重运行,典型的是 Hadoop 生态下的 MapReduce、Spark 作业。这两种类型的服务负载在分时复用、资源互补上存在极大的优化空间,使得它成为混部的首选场景,所谓在离线混部,指的就是将离线作业和在线服务部署到同一个节点,以此来提高资源利用率,减少企业对与日俱增的成本开支。因为在线服务资源利用率有更明显的的起伏特征,所以混部要解决的主要问题一般是如何通过填充离线作业把集群各个时段的在线空闲资源利用起来。图3 在离线混部场景1.

    6、1 什么是在离线混部业务流量周期性,对于在线服务,为了保证其流量高峰期的业务 SLA,往往按照最高峰值评估资源,但实际业务大都具有明显的潮汐特征,导致大部分时间段资源利用率都很低,造成浪费。集群资源碎片,服务器还有一定的静态资源没有被分配,但是由于此时各个维度的资源(如 CPU 和 Memory)不均衡,导致没有办法再继续分配资源。比如,一个有 1000+节点的集群,在分配率达到 80%后,常常会因为集群碎片的原因,很多大规格的 Pod 就无法再被创建出来。在离线机房隔离,资源池划分粒度太粗,有些企业会将在线机房、离线机房完全隔离开,在这么粗的粒度划分下,在线机房有大量资源闲置,也无法被离线服

    7、务利用,反之亦然,离线机房空闲的时候,在线业务也无法充分利用,无法实现不同 IDC 之间资源池的互通。1.2 在离线混部的适用场景03简单估算下提升 20%的资源利用率,可以大致节省的预算:假设当前所有的机器有 10w 核 CPU,平均每台机器的资源使用率是 20%,那么实际使用的 CPU 资源是 0.2*10w=2w 核,在业务规模不变的情况下,假设资源平均使用率提高到 40%,那么只需要 5w 核就可以满足业务需求,假设 CPU 的平均价格是 300 元/核/年,就可以节省 5w*300=1500w 元/年。对于有成本控制诉求的企业,在离线混部是降本增效的首选,比如谷歌利用混部技术将资源利

    8、用率提升到 60%,每年可以节省上亿美金。1.3 在离线混部的成本价值在离线混部虽然能带来巨大的成本收益,但是本身的技术复杂度还是比较高的,主要包括:容器的本质是一个受限制的进程,进程之间通过 namespace 做隔离,Cgroup 做资源限制,在云原生时代,所有的业务负载都是通过容器来控制隔离和资源限制。在离线混部场景下,虽然可以通过 Cgroup 来限制在线和离线业务的资源使用,但是在资源超售和在离线场景下,CPU、Memory、网络和磁盘 IO 都存在一定竞争。为了保证在线服务稳定性,普遍做法是进行 CPU 绑核,将在线服务绑定在某个逻辑核心上,避免其他业务占用。另一方面,绑核以后,对

    9、于有并行计算要求的服务,都会受到并行度的影响。在 Memory 方面,离线业务往往会读取大量文件数据,导致操作系统会做 page cache,而原生操作系统对 page cache 的管理是全局的,不是容器维度的。1.4 在离线混部的技术挑战1.4.1 资源隔离由于在线业务和离线业务在工作模式上的差异,往往采用不同的调度器进行调度。混部场景下,在线调度器和离线调度器同时部署在集群中,当资源比较紧张的时候,调度器会发生资源冲突,只能重试,此时调度器的吞吐量和调度性能会受到较大影响,最终影响调度的 SLA。同时,大规模批量调度场景下,原生的 Kubernetes 是无法支持的,它只支持在线业务的调

    10、度1.4.2 任务调度传统的资源复用方式,往往会采取分时复用,就是在固定的时间点跑离线业务,比如凌晨以后,就开始调度运行离线业务,在白天开始调度在线业务。这种模式下的资源复用,往往时间粒度过粗,虽然可以在一小段时间内复用在线资源,但是有比较严格的时间限制。另一种是资源预留,将一个机器的资源整体划分为在线资源、离线资源以及在离线共享资源,该方式采用了静态划分的方法,将整机资源进行了划分,无法进行弹性复用,而是只能将在线业务和离线业务的资源进行提前预留。虽然通过部署离线业务能够一定程度的提高资源利用率,但是复用不够充分,并且需要资源规格大的机器才能将资源进行静态划分。要想高效的、自动化的进行细粒度

    11、的资源分时复用,就必须拥有及时准确的资源预测手段、快速响应资源变化的能力,以及一套可以在资源水位变化的时候进行的服务保障措施。1.4.3 资源复用04在线业务和离线业务属于不同的工作类型,将这两种负载部署在同一个节点上,会出现资源干扰,当资源紧张或者流量突发的时候,在线业务在资源使用上会受到离线业务的干扰。在离线混部最重要的目标,就是在保障在线和离线业务的服务 SLA 的同时,最大限度提高单机资源利用率。-针对在线业务,需要保证其服务在流量高峰时期与之前的波动变动控制在 5%之内。-针对离线业务,不能因为优先级不如在线业务,就一直处于饥饿或者频繁驱逐状态,影响离线业务总的运行时间和 SLA。除

    12、了上面的几个技术难点之外,还包括混部之后整个运维流程的改变,甚至包括组织结构上的相应变革等,这些都给中小厂商使用在离线混部技术带来了不小的挑战。1.4.4 资源保障二、一线大厂在离线混部架构及方案Google 内部是通过 Borg 系统实现在离线混部功能的。Borg 系统是 Google 内部自研的资源管理系统,针对集群资源进行管控,分配和调度。Borg 通过 Job 和 Task 来管理资源,大致对应于 K8S 的 Service 和 Pod。Borg 架构由 BorgMaster、Scheduler 和 Borglet 组成,如下图所示:2.1 Google图4 Google Borg 架

    13、构图05Borg Allocs:物理资源的抽象,包括 CPU、Memory、IO 和磁盘空间。Alloc set 集合多个 Alloc,形成一套可用资源组合,为一个或多个 Job 服务。Priority:Job 的优先级。比如 Routine Job 为生产环境的例行任务,优先级最高。Batch Job 为离线场景的批处理作业,优先级最低。当出现资源竞争时,按 Priority 解决冲突问题,竞争失败的 Job 返回调度队列重排,Quota:具体资源的配额限制,用以判断 Job 最大可占用资源量。对于 Routine Job,Quota 一般是实际可用物理资源。对于 Batch Job,Quo

    14、ta 一般设置为无限,以尽量利用一切闲置资源(超卖)。Schedule:调度决策模块。Borgmaster 负责将提交的 Job 放入任务等待队列。Schedule 负责将队列中的任务和满足资源需求的机器进行匹配调度。调度决策步骤为先 Filter 再 Score。Filter 用于判断机器资源和 Job 的需求及限制是否匹配,属于硬性筛选。Score 则是保证在多个同时满足条件的 Job 中,实现更优调度,属于软性推荐。Borg 关于混部提高资源利用率主要有以下经验总结:1.将不同优先级的任务运行在同一集群中可以提高 20-30%左右的资源利用率2.通过资源重新声明,动态根据业务实际运行情况

    15、进行资源调配。初始时资源等于业务指定的 resource limit,后期会根据业务资源画像外加一定的安全边际来调整资源使用。(a)图表明,采用 Task 隔离的部署方式会增加对机器的需求。(b)图是对额外机器需求的分布函数。图5 将prod Job和non-prod Job分开部署会消耗更多的物理资源06腾讯在离线混部系统 Caelus 以 k8s 为依托,在 k8s 节点以容器的方式部署离线任务,实现在线服务节点转让资源给离线服务,支持特性包括:任务定级:制定了任务级别标准,用于对应不同优先级资源。调度增强:因离线任务量大,运行时间短,原生的 k8s 调度器无法满足大批量需求,同时也缺少一

    16、些批量调度特性,如 gang scheduling。基于此增加一个批量调度器,跟原生调度器并行,通过一个协调器进行协调,防止资源被重复调度。资源复用:每个 k8s 的 kubelet 节点通过 daemonset 部署一个 agent 组件,用于实现负载预测、闲置资源回收、离线资源配额分配和资源隔离等功能。资源画像:预测在线作业的各类资源使用情况,指导离线作业调度和隔离。存算分离:通过 Ceph 或 CBS 分布式存储技术,解决离线作业需要大量存储空间及磁盘 IO 问题。任务避让:解决节点负载不均衡问题,重新调度离线作业到低负载节点和实现负载升高按优先级驱逐任务功能。干扰检测:分析在线作业的时

    17、延数据,如本身暴露的时延指标、CPI 数据或硬件指标数据,来判断在线作业是否是否受影响。腾讯的方案具基于 k8s 容器调度,无业务侵入性,接入成本低,并且兼容 Hadoop 生态。不支持离线服务转让资源给在线服务。Caelus 混部方案在腾讯内部已经被大规模应用到广告、存储、大数据、机器学习等多个 业务,平均提升 30%资源利用率,节省了上亿成本。通过混部 hadoop 类离线作业,大约提高了 60%的 cpu 使用率。2.2 腾讯图6 腾讯Caelus系统架构图07百度内部对 K8s 进行在离线混部原生化改造,支持的特性包括:NUMA 调度:针对需要绑核的业务,可以使用 cpuset 直接进

    18、行绑核,避免跨 node 通信延迟。针对开启了 NUMA 的节点,感知 NUMA 架构,将在线业务绑在同一 NUMA 上,提升在线业务的性能,并且感知 NUMA 节点的负载,当 node 之间出现明显的不平衡时,进行重调度。离线调度器:因为无法区分在离线业务,可能在线业务会分配到相同的核上,无法打散。导致性能下降。离线调度器是一种离线任务专用的 CPU 调度算法,从调度器上分开,在线调度器看不到离线任务。在线调度器先于离线调度器进行任务调度,存在在线任务时,离线得不到调度。所以对于在线任务来说,可以达到混部前相近的 CPU 质量。基于 eBPF 的动态策略:基于 eBPF 开发了定制策略,可以

    19、实时下发,实时生效,侵入性小,不需要对业务既有服务和平台侧进行修改。可以在用户态针对某些业务进行定制化隔离策略更新,达到服务可以无差别混部的目标。高性能调度器:在线和离线业务的调度需求是不一样的,在线一般为常驻服务,不会频繁变更,对调度器要求较低。但是离线任务由于具有运行时间短(几分钟到几小时),任务多的特点,以 K8s 默认调度器的调度性能不足以支撑离线任务的调度。所以百度开发了高性能的离线调度器,计算可以达到 5000 ops。百度的方案做到了零入侵 K8s,可移植,可支持大规模集群;支持 NUMA 架构服务器调度,NUMA 架构服务器更加节约成本;实现了在线业务优先级高于离线业务的线程调

    20、度器,使在线业务更加稳定;仅支持容器部署,方案未开源,其他公司无法使用。2.3 百度图7 百度在离线混部架构图08字节跳动依托于 k8s 与业务 quota 做整机腾挪的在离线混部,以集群转让节点的方式提高整体资源利用率,主要实现思路为:当在线服务的波谷来临后,几乎所有服务都会因为弹性缩容而导致副本数降低。从整体上看,集群里节点上的 Pod 会变得非常稀疏,集群整体资源部署水位也随之降低。当集群的部署水位低于设置的阈值后,控制面会通过一定规则选取部分在线节点,将该节点上的 Pod 驱逐到别的节点上,并标记该节点不可调度,最后通过某种机制将该节点加到离线的集群中实现资源的转让。同理,当在线服务的

    21、波峰来临后,会发生一个逆向的控制过程,控制面在通知并确保离线任务撤离后,重新将节点加回到在线集群中设置为可调度状态,实现资源的回收。字节跳动的方案基于公司自身的业务复杂度,使用自定义 quota,而没有使用 k8s 通用的 hpa;部署方式两阶段混部:白天离线服务器给在线服务使用出,晚上在线服务器转让给离线服务;仅支持容器部署,方案并未开源。2.4 字节跳动图8 字节跳动在离线混部架构图09快手基于 k8s 实现在离线系统,支持的特性包括:在离线资源单机同存:全时段生效、秒级发现空闲资源、百毫秒量级快速退避保障在线业务;主机“在线”-“离线”转换:通过 HPA 实现整机腾挪。资源动态调整:可以

    22、调整离线容器资源,比如 OOM Score、网络限速轻压力:提供接口透传整机状态及预测数据,离线进程执 行 GC、暂停子任务等策略。重压力:按优先级 KILL 离线实例,强制释放资源。惩罚系数:指数级退避等待,规避振荡。快手的方案提供了整机腾挪与单机混部两种混部方案,更加灵活;仅支持容器部署,方案并未开源。2.5 快手图9 快手在离线混部架构图10阿里在离线混部系统层次化较为清晰,由下到上主要分为:基础设施层:整个集团的数据中心是统一的,机器、网络等的硬件设施及配套都是同一套。资源层:作为混部的基础,把资源放在一起管控。调度层:分为服务端和客户端。把各业务自己的资源调度平台称为“一层调度器”,

    23、在线是 Sigma,离线是Fuxi。同时在混部架构中,引入“零层调度器”,主要负责协调两个一层调度器的资源管控和资源分配决策。资源调度与管控层:主要面向业务,有些经一层调度器直接交付资源给业务,有些还会涉及更深层级的调度器再次分发。阿里巴巴的方案实现了大促资源退让机制与日常资源的时分复用,尤其适合电商场景;方案并未开源。2.6 阿里巴巴图10 阿里在离线混部架构图三、在离线混部方案解析11通过对以上一线大厂的在离线混部方案的分析,我们可以抽象出在离线混部方案的三个划分维度:从在离线混部的隔离类型上,可以分为内核隔离和非内核隔离。从在离线混部的部署底座上,可以分为物理机部署和容器部署。从在离线混

    24、部的调度决策上,可以分为业务决策和自动调配。业界在离线混部方案按上述维度划分如下:结合业界通用实践,下面分析下常见几种在离线混部方案特性组合的技术细节。表1 大厂在离线混部方案维度划分3.1 分类维度3.2 维度组合解析12在这种模型下,业务开发人员将服务部署在云原生部署平台,选择某些指标(大部分伴随着流量潮汐特性)衡量服务负载,平台会按照业务指定规则对服务节点数量扩缩容。当流量低峰期来临时,随着业务节点数量的减少,在线服务会有大量碎片资源释放,部署平台对碎片资源整理,将碎片资源化零为整后以整机的方式,将资源租借给离线业务使用。比较典型的是字节跳动的方案,业务在部署服务的同时制定扩缩容规则,当

    25、流量低谷时,平台按照规则减少服务节点数量,此时在线资源会释放碎片资源。当碎片资源达到阈值,会触发在线到离线的转让逻辑,转让逻辑中首先整合碎片资源,然后将碎片资源整合为物理机,最后将物理机整体租借给离线使用。当流量逐渐恢复后,会触发在线回收转让资源逻辑,在该逻辑下,会逐渐驱逐离线任务,将资源回收。由于在线业务有很强的潮汐特性,可以通过定时定量的方式,比如晚高峰 19 点-23 点,将指定数量的离线资源转让给在线业务使用,当 0 点时将转让的资源返还给在线使用。图11 内核隔离+容器底座+业务决策3.2.1 内核隔离+容器底座+业务决策13在这种模型下,与容器底座不同的是,业务人员将服务部署在物理

    26、机上,同样选择某些指标衡量服务负载,平台会按照规则对服务节点数量扩缩容。当流量低峰期来临时,随着业务节点数量的减少,会有空闲物理机释放出来,平台可以将资源租借给离线业务使用。比较典型的方案是微博,将在线服务部署在混合云平台,一部分部署在私有云,一部分部署在公有云。初始情况,私有云资源大部分用来支撑在线业务,当流量低峰期来临时,有大量私有云机器空闲,此时将空闲的私有云机器租借给离线业务使用。离线向在线转让的流程是可选的,因为当热点或者流量高峰期来临时,可以通过公有云的弹性资源支撑流量尖峰,当流量趋于平稳时,将公有云计算资源退还给公有云。这种方案的优点在于稳定性高,成本可控,实施成本低。具体实施方

    27、案可以通过打通公有云和私有云资源管理平台,打通在离线服务资源转让流程。星汉未来开源的Bridgx 旨在提供统一的算力管理平台,屏蔽私有云,各个公有云平台接口的差异,基于 Bridgx 构建的系统具有更大的想象空间。图12 内核隔离+物理机底座+业务决策3.2.2 内核隔离+物理机底座+业务决策 14在这种模型,是基于高配服务器+硬件虚拟化的解决方案。目前大部分云厂商都在开发裸金属服务器,裸金属服务器采用硬件虚拟化,多 NUMA 架构,相对于传统的 ECS 服务器性能更高(硬件虚拟化具有 10%的性能提升),成本更低。这种模型下,用户可以按照原有运维系统部署服务,制定扩缩容规则,把裸金属看作一个

    28、资源池,不管在线服务还是离线作业,压力增大时可以直接从资源池获取,当压力降低时可以缩容归还。图13 共享内核+物理机底座+业务决策3.2.3 共享内核+物理机底座+业务决策15与上述几种方案最大的不同在于,转让的资源规则是自动调配的。在一个大企业中,服务数量数以万计,要求所有在线服务制定扩缩容决策是很难做到的。同时,业务在部署服务时更关注服务稳定性,常常按照最大流量评估资源,这样就导致流量低峰期有大量的资源浪费。比较典型的是百度,腾讯,快手的方案,这类方案有两种资源视角,在线服务资源视角,看到的是节点资源容量,比如当前物理机上总共有 126 核 CPU 离线服务资源视角,看到的是节点的负载,比

    29、如当前物理机还有 64 核 CPU 是空闲的服务部署时:在线服务按照资源容量调度服务 离线业务按照节点负载调度服务这类模型实施的难度在于资源隔离,如何避免或者降低离线对在线的影响是混部方案是否成功的关键。各大厂在资源隔离方面都做了很多努力,比如更全面的指标收集,更智能的负载预判,更合理的在线资源冗余度,更精细的 eBPF 等。即使在资源隔离方面做了非常多的努力,还是难以避免共享内核模型中离线对在线的影响,方案中一般都搭配着干扰探测,当探测到在线服务受到影响时,及时止损。图14 共享内核+容器底座+自动调配3.2.4 共享内核+容器底座+自动调配 如果有比较强的研发实力和在离线混部方面有一定的技

    30、术积累,可以挑战共享内核+容器底座+自动调配组合的方案。如果公司研发团队在底层技术积累比较少,想快速安全低成本的用上在离线混部,内核隔离+容器底座+业务决策组合的方案是首选。星汉未来结合业界目前在离线混部的方案,基于云原生方式提供了一套通用的解决方案。3.3 方案推荐场景四、星汉未来在离线混部方案16星汉未来(Galaxy-Future)是一家云原生基础引擎提供商,提供三大算力引擎:算力调度引擎 BridgX https:/ 智能运维引擎 CudgX https:/ 数据物流引擎 DTExpress基于三大基础引擎,提供了 Web 智能运维产品 SchedulX(https:/ ComandX

    31、(https:/ 可以在算力层面为在离线混部提供基础的算力调度能力,包括跨云调度能力,K8s 容器及大规格裸金属服务器切割能力以及快速弹性伸缩能力。SchedulX 可以提供服务编排、镜像管理、算力调配等服务治理能力。CudgX 可以为在离线混部提供自动化压测、服务指标度量、容量评估等能力,精准刻画在离线服务的资源使用画像。而运维可观测平台 ComandX 可将服务能力和指标进行 Web 可视化,方便感知服务情况。图15 星汉未来产品矩阵4.1 星汉未来产品矩阵17如图所示,CudgX 引擎服务收集服务指标,通过配置冗余度规则完成服务和节点的冗余度保持。当流量低峰时,CudgX 对服务节点缩容

    32、,触发在离线整合模块转让逻辑。当流量高峰时,CudgX 对服务节点扩容,触发在离线整合模块回收逻辑。同时 CudgX 还评估在线资源的冗余度,当在线资源冗余度过低时,CudgX 会触发 K8s 扩容逻辑,借助于 BridgX 申请资源,完成在线资源扩容。当资源冗余度回归正常时将资源退还,保证资源充足的情况下,成本可控。在离线整合模块负责完成转让和回收逻辑,当在离线整合模块发现在线资源有足够多的碎片资源可以回收时,会进行一次碎片资源整理统计,将碎片资源整合为完整物理机转让给离线业务使用。当在离线整合模块发现在线资源冗余度不足时,会触发资源回收逻辑,将转让给离线业务的资源回收,完成回收逻辑。本方案

    33、通过内核进行资源隔离,优点是在离线服务彻底分离,不存在离线服务影响在线服务的可能。在离线混部带来的效果是不言而喻的,对资源利用率提升、降低成本都有公认的明显的作用。但在离线混部是一个庞大而复杂的项目,涉及多个组件,需要多个团队的协同合作,如底层 OS 支持、存储计算分离、离线框架优化减少 IO 等。在离线混部也是一个持续优化的过程。各家大厂都投入了相当长的时间研究,才开始放量铺开。随着技术的发展,k8s 混部也越来越成熟,将来也会有更多的场景落地。我们期望通过借鉴业界成熟的混部方案和相关开源组件,以云原生的方式让在离线混部在更多企业落地,帮助业务集群降低资源成本、提升资源效能。图16 星汉未来在离线混部方案4.2 星汉未来在离线混部方案五、总结参考1.Caelus全场景在离线混部解决方案 2.自动化弹性伸缩如何支持百万级核心错峰混部3.深入理解百度在离线混部技术4.揭开阿里巴巴复杂任务资源混合调度技术面纱5.快手大规模在离线混部平台的容器实践之路6.深入浅出 Google Borg

    展开阅读全文
    提示  三个皮匠报告文库所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
    关于本文
    本文标题:星汉未来:在离线混部解决方案白皮书(2022)(21页).pdf
    链接地址:https://www.sgpjbg.com/baogao/107209.html
    联系我们 - 网站声明 - 网站公告 - 侵权处理 - 免责声明 - 版权申诉 - 关于我们 - 常见问题 - 网站地图 - 用户协议 - 认证协议

    copyright@ 2008-2013        长沙景略智创信息技术有限公司版权所有
    公安局案号:湘公网安备 43010402001071号 | 工信部备案号:湘ICP备17000430号-2 | ICP经营许可证:湘B2-20190120 | 出版物经营许可证:新出发岳文字第43010420211号