《原动力 x 云原生正发声 降本增效大讲堂》第四讲——Caelus 全场景在离线混部原创

各位网友大家好，欢迎观看原动力云原生净发生降本增效大讲堂系列技术直播，期待已久的第二期直播来了，第二期聚焦全章井在离线分布Co GPU资源效果提升Co资源拓扑感知调度主题。今天是该大讲堂的第四讲，主播主题是开全场景，在离线分布。8月4日8月11日的晚上八点呢，我们会进行第五讲跟第六讲，欢迎大家预约观看。原动力与原生政发生降本增效大讲堂是由中国信通院、腾讯云非产业标准工作组联合策划，目的是与开发者一同交流提升资源利用率、降本增长的方法与优秀实践。今天我们请到中国信通院云大所云计算部云原生研究员魏博凯老师以及腾讯高级工程师陈东东老师来分享在一线分工意义以及最佳实践案例。

在观看直播过程当中呢，如果有问题可以随时发送弹幕进行提问或者互动，那首先我们有请魏博凯老师为我们解读一下混沌的标准。呃，那各位线上的观众，各位专家，各位老师，大家晚上好，我是来自中国信息通信研究院云计算与大数据研究所的魏博凯。那很高兴今天有机会能跟大家简单分享，介绍一下我们在原生混方面的一些标准化的工作。那今天的介绍主要会分为四个方面，首先第一个是我们的标准编制的背景，第二个是原生混的方案，第三方面是混能力的一些基本要求，第四部分我们的下一步的工作计划。那首先还是想从几组数据来简单聊一下混部，呃，第一组数据来自于美国数据中心能源使用报告，那报告指出，到2020年，全球数据中心的服务器总量将达到1800万台，并且会以每年100万台的速度持续增长，也就是说，到今年全球将会有超过2000万台服务器运行在。

各种大大小小的数据中心中，那在这里面也包括公有云的环境，也包括私有云的环境，根据一些私有云环境的这个统计显示，我们的虚拟化的机器人利用率可能平均不足10%，那这里面还包括比如说因为一些系统长期不运行，可能会导致这个整个资源利用率低于10%~8%，百分之3%，甚至0%的情况。那FLEX2021年的云状态报告数据也显示，企业上云后，将会平均有30%的资源被直接的利用，呃，浪费掉。所以说，在这样的大背景下，我们有大量的云计算的资源被浪费，成本问题迫在眉睫。

大家都知道我们的传统的不管是在线的交易类的任务，还是离线的数据分析类的任务，那它都是跑带相对独立的基础设施环境里面的，那如果我们呃，这一相对独立的基础设施环境里面资源利用率比较低的话，那我们自然而然的会尝试将这些资源进行共享，嗯，也就是说将在线的任务和离线的任务可能会同时运行在一个共享的基础设施里面，那这就是我们最开始的啊，在离线混的这么一个呃初衷，那它的目的呢，就是为了降本增效，降本这里面就是指的是我们能够尽量的去提升资源的利用率，那增效呢，指的是能够保障我们的服务运行质量。嗯，大家可能有了解的都会见过这张图啊，就是我们在描述在离线混的时候会尝试用啊，比如说蓝色的这边小格子和灰色的小格子来代表在线任务它的资源占用情况，那离线的任务用黄色的这个格子来表示，如果我们尝试将二者进行混部呢？那啊很有可能就是嗯，将黄色的这一部分和蓝色这一部分拼拼凑在一起，那可以从图中看到这个灰色的格子的数量变少，也就是说它的这个啊，资源浪费的这个程度降降低了，所以我们也就提高了资源利用率，那这就是一个我们比较理想状态去描述，从资源角度去描述啊混的这么一个效果的图。

那理想比较丰满，通常现实也会比较骨感哈，那因为本部这个事情，它还是要从底层的基础设施，像上层的业务应用完全打通的，所以在这个过程中会面临很多很多复杂的问题，比如说我们的这个业务部门，它和技术部门，那差异化的需求和供给可能会导致我们一些不可避免的资源的荣誉。

那比如说另一方面，比如说各同各种不同的类型，不同不同特点的这个系统，它的差异化也会给步带来一定的难度啊，还有包括监管啊，包括这个我们不同用户单位，不同这个组织里面的这个制度啊，可能这些方面也会从侧面啊，给我们的这个业务应用的匹配，给我们这个技术方案的实施带来一些难度，那从最底层技术层面呢，对于不同的这个技术设施，我们又有资源配置可能会不精准，然后资源的这个扩容的这个速度不够快，存在滞后性，以及资源分配可能会不合理的这么一种情况出现。最后呢，从架构角度讲，我们虚拟传统的这个业务应用通常都是跑在虚拟机上的啊，这种和呃底层基础设施的强绑定关系，也会给我们的混带来一定难度，那么在这样的背景下，我们尝试用原生的方式去解决混的问题。

那我们来看一下云原生的情况，那这里面也是列出了整个云原生概念，从2012年第一次被提出，一直经历了一三年到一五年do项目的这个火热，以及一五年到一七年CNCF基金会的成立，到2008年之后，整个云生概念嗯，基本被大家所熟知，与云原生相关的容器，无服务器不可变的基础设施，微服务，服务网格，生命式API等等这些基础技术的成熟和发展，也给我们的这个呃，应用的混啊奠定了一定的基础。那从架构角度讲，我们可以看到传统的基于虚拟机的啊，业务应用啊，它都是相对独立的，那这种这种独立就带来了我们的这种强绑定的关系，那我尝试将离线任务和在线任务进行混合部署的时候，那可能他就嗯，从架构角度讲就不会那么灵活，那后来随着原生技术的实现，那我们更多的这个不同优先级的业务分别运行在基于docker和Co的环境当中以后。

那这时候我们在尝试将这个不同的应用进行的时候，那这就可能呃，有很多的便利。具体来说，我们会将这个混部的具体实现进行一个抽象，那前面介绍了这一这样一张图，它是从资源的角度去描述，那我们能够怎么样提高利呃利用率，那实际上混部它还关于业务，关于我们的不同的优先级，关于整个平台，关于底层资源的调度编排，所以这里面我们用了一张八卦图，也就是说不同时间段，不同资源，然后平台上它需要做的事情可能会是瞬息万变的，所以对应着我们的相应的能力，可能我们也可以把它抽象成比如说业务应用层，针对不同的这个系统，那我们怎么去分类，怎么去选择混合部署的方案，怎么去啊处理这些不同不同对象产生的不同的需求，那从中间整个基于库这个平台层，它关于混可能会做到很多编排、调度，包括资源的管理等等的一些工作。

最下面是基础设施，因为整个云平台我们正在面临从啊虚拟化到原生的这么一个迁移演进的过程，所以在基础设施这一层也有新的关于资源的隔离，然后资源的监控，资源的共享等等方面的一些。技术。那在我们进对整个啊原生混标准的这个能力要求进行抽象之前，我们也尝试对资源的这个占用和它的如何提升利用率这不同的手段进行剖析，那这里面我们也是用柱状图的方式去尝试，就。

解释我们的这个资源到底是怎么被浪费的，然后又有可能会通过什么方式去提升这个利用率，那首先最上面这个黄色这个。区域它代表的是我们说业务，呃，已经申请但是并未使用的量，这里面就刚才给大家介绍过了，可能就是说我我的需求部门可能是业务部门，那我为了保证这个应用能够呃正常稳定的运行，那我提需求的时候，可能对于技术部门就会有一定的冗余，那这对于这一部分的使用量啊，在降本的过程中可能会需要进行适当的缩减，那呃，在原生的世界里面呢，我们现在基于容器实现的更加精细化的资源管理，可能会对这一部分这个资源的这个利用率提升有帮助啊，这就好比说，比如说我们小区里面，这个大家都会面临停车的问题啊，那有很多这个可能装了地锁的固定车位，那长期如果它没有车辆停放的话，那我们需要把这一部分冗余的资源降低，把它这个地座拆掉，然后给大家进行共享。

那这是第一，那第二类就是我们系统已经分配，但是并未使用的了，这个这一部分。资源，那这个指的是就比如说我们传统的基于虚拟机的，那我分配了的资源，呃，只能给这个系统使用，那在不够灵活的情况下，我就没办法把这分资源进行，那现在基于我们刀，基于容器的，我们就可以进行判断，就好比说，比如说我们同样以开车为例啊，那我们开车出去想去某个医院啊就诊，或者你去某个商场购物，那可以看到这个你的目的地的这个停车场，这个使用量比如说已经接近满负荷了，那但是我知道啊，附近的其他的停车场可能还有很多的荣誉，呃，所以我就可以去。

考虑用临近的这些停车场去停车，这个就是意思就是说我能够对通过对于啊一个集群的资源的使用量的观测，然后灵活的进行配置，然后我们针当针对不同的业务应用这个运行需求的时候，可以可以进行资源的共享，最底下就是关于这个应用波峰，波谷效应的一个。呃，空闲量的填充，这个大家可以理解成就比如说我们有双11的大促，这种典型的交易类的场景，那在白天或者说在大促的时候，它的这个呃，资源使用量可能是达到一个波峰的一个状态，那当它出现波谷的候，那这部分资源也同样可以共享出来去给到。

啊，比如说像数据处理啊，然后一些离线的一些业务应用去使用，这就好比我们去这个停车场里面，可能大家能看到呃。有一些车位，它对应的配置这种红色绿色的这个灯那。红灯亮起代表这个资源已经被完全占用了，那如果是绿灯亮起，那对应这部分就相当于是风谷的部分，那我们就可以将自己的车停到这里面，来提升整体的资源利用率。那从这三个角度出发考虑。我们就尝试对。啊，原生混相关的技术方案，还有大家通常能够呃达到的一些能力进行呃归纳和总结，那我们发现可能比如从底层的基础设施出发，有一些呃优先级的抢占，然后负载感知，包括干扰的一些识别保障等等一些方面，可能是通常大家会具备的一些能力，那平台层这样做的比较多，这里面列出来几个，比如说精细化的资源编排啊，比较能智能化的这个资源超卖呃服务化的任务感知，以及定制化的冲突处理等等一些能力，当然这些能力都是为了服务我们上层呃离线或者在线，高优先级或者是低优先级不同任务的这个混合的部署，那么当我们对整个这个架构，以及包括呃。

开源的和一些商业的不同的解决方案进行研究和归纳之后，那我们梳理形成了我们现有的原生混技术能力要求的标准的框架，那这里面也是分刚才的这个三个层级，把我们现在归纳出来，呃，标准。这个能力要求进行了一个展示。那最下面还是基于计算、存储和网络这个S层资源比较近的，可能跟呃资源能力相关性比较高的一些能力要求，那中间是基于实现的一个平台的能力，那最上面就是我们把呃在线和离线任务抽象成高优先级和低优先级的任务，然后对应着有比如说应用怎么能接入我们的混啊，然后应用的优先级如何设置，应用的服务质量怎么设置，然后相应的运行状态的监控等等方面的一些能力，那这些能力能能够呃通过这些能力能够保证我们的这个解决方案能够满足混的要求，那除此之外，我们还会对混的这个效果评价进行相关的规定，也就是说大家都是通过不同的技术方式来实现降本增向这个事情，但是我们还是通过统一的一个，比如说嗯，资源利用率的占比，或者是服务质量，运行的情况等等方面去描述。

整个方案的这个实现的成熟度。那么最后呢，就是，呃，中国新能院也是在原生领域开展了很多工作，那自2016年起，我们也是比如说容器负service，包括安全、数据、中间件等等方面也开展了很多标准化的工作，我们也是依托这些工作来开展我们部相关的研究和这个标准化工作。

下一步的话，呃，我们因为现在标准还在持续的迭代中，所以我们会围绕这个产业侧的一些最新的实践，还有一些行业侧的一些经验，我们也会对标准的内容进行细化，我们计划是八份能够启动首批评测，那在研究方面我们会启动比如说原生混技术的一些行业应用，一些一些研究，以及我们可能会针对原生混的一些成效的一些指南的一些编写。嗯，在后在后期可能我们会基于也会进行原生整个降本增效方面的一些研究的一些扩展。呃相呃相配合着我们也会每每个月都会举办我们的原动力的技术分享，我们这个沙龙的活动，那里面也会有关于和关于降本的一些话题，那除此之外，比如说案例级的一些评选呀，然后一些解决方案的一些专题的研讨啊，那我们也会在呃随后的工作中陆陆续续推荐给大家那。

嗯，以上就是我今天的分享了，那非常感谢大家的聆听，那中国信通院也会积极发积极发挥好我们这个平台作用呢，后面也希望能够跟大家积极的沟通，深入的推进我们原生包括混混部等等方面的一些工作，嗯，非常感谢大家，那今天我的演讲就到这里，谢谢。感谢魏国凯老师的分享，岳老师给我们介绍了大体的背景，很清晰的阐述了为什么要进行在线分布，还对云原生的混部技术进行了分析，引出了云原生混部技术的能力要求标准。

下面我们有请陈东东老师讲解一下具体的基于原生在极线分布的最佳时间案例。大家好，欢迎大家参加原动力云原声正发生建本增效系列直播课程，我叫陈东东，来自腾讯TG数据平台部，目前主要从事在离线混部项目。当前降本增效是一个出现频率非常高的词，每家公司都在采用各种方式实现降本增效的目标。呃，其中在理性混部是一种比较呃重要的技术手段，然而在落地的过程中我们会遇到很多痛点问题，下面就由我来给大家系统的介绍一下腾讯是通过是如何通过在离线混步技术达到降本增效的目标，以及我们其中的一些实践及思考。这是今天演讲的主要内容，主要分为部分，首先是介绍呃代理线混步的背景和意义，这绍介一绍全场景在离线缓步开以及我们在实践过程中的一些关键的技术与思考，主要包括在线服务质量保障、离线服务质量保障。最后介绍。

看一下的实践落地。下面进入正题，首先是代理线缓复的背景和意义啊，各大权威机构呃的调研数据显示，在线资源的利用率普遍很低，平均在15%左右，为什么资源利用率会这么低呢？我们来看这张图，这是一个呃在线的CPU使用曲线，它的潮汐现象非常明显，在白天波峰时段，它的利用率最高可以达到70%，在夜晚波谷时段，它的利用率只有20%，呃，业务方在申请资源的时候，只能按照波峰时段的资源进行申请，在波谷时段的资源就会被浪费，这里我们也列举，呃，我们也。列举了一些，呃，其他的原因会导致资源利用率低。

啊在线非容器化部署，未能利用整机资源，传统的在线服务是直接在物理机上通过进程部署，嗯，可能因为端口中枢的原因，每台机器只能部署一个进程导致。呃，机器的整体资源浪费严重。另外业务容灾也要额外准备一些buffer资源，这些资源在平常也是空闲的。当然随着云云原生化的推进，啊在线通过容器化部署，在一台机箱可以部署多个进程。以及啊原原生化的自动扩收容也可以解决啊业务融资的问题，这呃都这都可以很好的解决一二两个，一二两个问题，利用率也得到了一个很大的提升。然而我们也要看到，因为呃业务方对资源的预估不准，他申请的铝筷的资源会比他的实际实际使用资源之间大很多，导致形成一种暂而不用的现象，以及业务呃以及业务之间啊，物理隔离啊不能弹性，也会造成资源利用率低。

接下来我们看一下离线作业的呃运行特点，这张图展示的是我们在历年来生我们生产和消费的数据量，可以看出每年数据的增速是非常快的。从侧面也反映出我们对大数据的需求也是非常高的。而且对大数据的需求。量大意味着我们需要更多的算力来进行分析，呃，更多的算力也意味着更高的成本，呃，面对成本问题，我们就不得不在成本和收益之间做决策。我们看一下离线作业的特点，CPU密集型，延迟不敏感，实时性不高，它可以重新呃，失败之后它可以重新拉起运行。执行周期短，运行时间为分钟，级别资源申请小，可填充碎片资源等。

当我们看到这些离线作业的运行特点之后，我们很容易想到是否可以在在线资源的波谷时段来运行离线任务，从而达到节省离线任务呃离线机器成本的目标。呃，离线任务呢？它的执行周期短，所以对离线任务的影响也相对较少。尤其是当前的大环境背景下，随着芯片、能源、电力紧缺以及碳综合策略的提出，更加剧了我们的成本意识，这也推动了恐怖的发展。在离线混部的意义在于，我们通过利用波谷时段的空闲资源来运行离线任务，达到提升机器资源利用率、优化成本的目标，从而可以充分释放资源的价值，降降低能源消耗。呃，混步看似简单的在在线的波谷时代运行离线任务，但我们在实际的落地过程中会遇到呃很多痛点问题，这里列举了几条，首先是定制化，这里的定制化是指稳步的一些特性，依赖平台的一些功能或组件，跟平台强绑定。呃，比较典型的是入侵K8S原生的代码逻辑，这里带来的问题是。

啊，恐怖跟平台强绑定，不宜推广到其他的平台，同时如果平台需要进行版本升级，恐怖也要随着跟着适配，维护成本是非常高的。恐怖场景大一，目前主流的在线任务都已经进行了容器化，但我们也要呃，但我们也看到目前很多的在线呃。但我，呃，目前很多的在线任务其实还未来得及容器化或不适合容器化，这部分量是非常大的，就说我们如果把这部分资源充分利用起来的话，也利用率也可以得到，也可以挖掘，呃，也可以挖掘更多的，也可以挖掘很多的资源。大数据任务是非常适合哄部的，然后很很多的哄部方案也直接兼容了云原生大数据，然而目前呃大部分的呃大呃大数据任务还是运行在哈都布场景，所以说呃现在目前的混步方案对这部分的支持也是比较缺失的。

第二点是粉部资源。呃，粉部对资源价值挖掘不充分，主要体现在两点，一是资源复用策略不够精细，利用率提升有限。比如我们为了呃保证呃，为了不影响在线，我们可能会采用CPU核隔离的方式，让离线任务只能复用部分核的空闲资源，而不能利用整机盒的空制资源，导致利用率提升有限，以及我们只在波谷时段进行红布，而不是24小时全天进行红布。二是浪费无效算力。因为恐怖资源具有不稳定性，所以说可能会导致离线失败率很高，我们看着资源利用率可能可能是呃，资源利用率是被提升了，但实际上这部分算力是无效的，反而浪费了算力的，呃，算力反而浪费了这部分资源。

第三点是技术深水区。很多的恐怖方案缺乏干扰检测与处理机制。呃，缺乏干扰检测就像一个混部，就像一个黑盒子，我们不知道在线是否受到了干扰，只有当发生故障的时候，我们才意识到在线受到了影响。资源隔离是恐怖的基础，所以说我们需要更完善的资源隔离的机制。而对于离线，我们首先要评估你在离恐怖场景下的调度性能，是否看满足离线的高并发的需求，以及。当离线作业被受到资源压制的时候，是否有一种方式，比如说容器热线仪器制，让离线作业可以继续进行而不被Q而重新导致重啊，重新开始运行？接着我们介绍一下全程的在离线混部colors colors是腾，呃，是腾讯基于多年的混部经验打造的在离线混部系统，它兼容多种在线和离线的分步场景。呃，目前刚正如我们刚才提到的，当前很呃主流的在线任务都已经容器化了，但我们也看到目前很多公司还有很多未容器化的在线任务，或一些在线任务不适合容器化，比如存储类的服务，如果我们把这部分的资源给挖掘出来，这部是这部分量也是非这部分量是非常大的。

嗯。这也可以打破恐怖在很多公司以及很多场景下的限制。对于离线任务啊，我们要兼容所有的大数据任务，以及任何在K8S运行的离线任务，呃，大数据任务中目前很多还是通过哈杜普来提交的，呃，云对于云原生大数据目前也得到了一个很不错的发展，就是说我们这两部分都是需要兼容的。

在这里也列举了我们在它的设计的过程中遵循的几个设计原则，一是不改变用户的使用方式，对于在线用户来说，它对于恐怖资源，对于离线任务是啊无感知的，而对于离线用户来说，他对于恐怖资源是无感知的。二是技术通用一致性强，他要与平台结耦，可以在平台其他的平台上进行运行，但是非耦合扩扩展，便于后续的功能叠加。这里展示了在离线混部的架构图，从这里可以看出我们的在离线混部包括一些通用的组件，包括资源预测指标收集资源画像、干扰检测资源画像。有了资源画像之后，我们可以告知master节点对于卡S来说是API server，对于哈来说是resource manager，这个节点能接收多少离线任务，防止接收过多的离线任务而导致。被压制，离线资源抑制可以实施呃一呃呃限制离线的总呃资源使用，对在线做一个更好的保护，干扰检测可以对在线的服务质量做一个更好更好的保障。

同时我们也看到，除了啊恐怖的一些基本的组件之外，我们也联动了其他层面的一些组件，比如说呃，大数大数据存储的HDFS存算分离，嗯，Electric存储加速，以及运行时容器热迁移，内核的资源隔离。同时还还包括上层的大数据，大数据框架优化，例如高性能调度器，底线作业助理，云生大数据等。下面我们也详细的会介绍一下cars是如何联动这些组件，来在保证在线和离线服务质量的同时，最大化的提升资源利用率。

下面我们介绍一下呃我呃，Cars在缓步实践过程中，为保证在线和离线的服务质量而采取的一些关键的技术手段及思考。第一个技术手段是多维度指标。首先我们了解一下为什么需要指标，因为有了指标之后，我们可以清晰的了解当前的混部是一种什么状态，比如说节点资源使用了多少，在线和离线分别使用了多少，以及业务运行的健康度如何，在线是否受到了影响，离线是否正常运行。同时混部的一些基础的组件，如预测、干扰检测也是以指标为基础的。那指标有什么要求呢？首先是多维度指标，因为只有有了多维度指标之后，才能把这个黑盒子变得透明化。这包括呃节点节点节点级别的资源指标，硬件指标以及在线时间指标或EBPF呃收集的内核指标。另外我们也要要求指标的存储周期要长以及不能丢失，这也是干扰检测所要求的。

为了实现这这些要求，我们应该如何实现呢？首先，我们通过采取各种机制，从各个方层面来收集多维度的指标，如通过CC的weather来收集C股级别的指标，通过EBPF来收集内核级别的指标，以及通过支持自定义的指标接口来收集用户的实验指标。同时为了满足指标的长周期存储以及不丢失，我们集成了TSB时间序列，它占用空间少，而且它的支持时间范围查询，查询效率很高。同时呢，我们也集成了普罗米修斯的查询接口，这样用户可以在官方的前台页面直接查询，很方便的溯源。另外我们也支持表达式强行，比如说我们可以支持一段时间内的求一段时间的均值，最大值和最小值，这样数据统计可以也更加借助，借助呃普罗米修斯这种呃接口的功能也更加方便。

在混部过程中，预测可以指导我们离线使用了多少资源。若没有预测，我们可能会根据历史的经验来预估一个离线可用的资源量。如果这个值配置的过低，那机器的利用率会提升有限，如果这个值配置的过高，那可与在线资源产生竞争。呃，同时随着时间的推移，在线进在线的版本升级，我这台我这台机器上运行更多的在线进程，这个预估值也要跟着变化，同时为了保护更好的保护在线，我们可能只是在波谷时代来运行离线任务，而不是24小时同步。而有了预测之后，我们就可以。对离线的资源，让离线的资源量随着在线资源的变化而变化，并且不以不挤占在线呃以不挤不挤占在线资源为前提，同时我们也可以做到24小时同步来最大化的提升资源利用率。那预测应该怎么做呢？我们看一下预测方式，预测方式分为两种，分为呃集中式预测和分布式预测。集中式预测对应的是全局预测，它全局考虑下应呃全局考虑应用下所有实例的资源使用情况进行统一预测。

这个这种预测的好处是，新扩容的机器可以根据历史数据立即获取到预测资源。分布式预测对应的是本地预测，每个节点都是独立预测的，那根据节点的资源使用情况，包括在线和系统的进进程的资源来预测离线可用资源。这种预测的好处是当在线资源、在线作业资源发生突变的时候，我可以迅速的做出反应来降低离线资源，来更好的保啊保啊，保障在线的服务质量。

同时，为了量化预测的精准性，我们提出了一个公式，然后以标准误差呃与呃标准标呃标准误差为基础，分为高估和低估。所谓的高估是指所有数据中预测值比实际值高的所有数据的标准啊，标准误差几乎是。预测值低于实际值的所有数据的标准误差，因为在恐怖场景下，我们为了更好的保护在线，我们希望预测在线的预测值是高于在线的实际使用资源的，但我们也不想这个值过高，呃，导致它的预测会呃预测准确率降低。所以说我们最终的结果是想要的结果是它的高估系数大于零，并且越接近零越好。

在这个算法的指导下，我们也探索了一些比较常用的呃预测算法，比如说适合长周期预测的head，以及适合短周期预测的v PA autopilot以及机器学习算法。其中VPA算法它的计算简单高效，这也是我们正在采用的本地预测的算法。干扰检测与处理，它是混播的放大器，同样的，我们先介绍一下为什么需要呃干扰检测与处理。前面提到粗放式的资源管理方式，以CPUCPU资源管理为例。我们可以采取，为了更好的保护在线，我们可以采用CPU set和隔离的方式，让离线任务只能运行在部分和上。这个图中所示离线任务只能运运行在共享池，而不能复用绑定池上的资源。被带来的问题是绑定池的共享资源无法被利用，呃，共享池的资源会被一线作业严重挤压。那么我们接着采用另外一种更稍呃呃，更稍微精细化的资源管理方式，基于权重的CPU共享CPU方式。

让离线任务可以复用所有盒的空闲资源，并且我们把离线任务的群众调调的很低。嗯，并采用扩大和P的方式来限制离线的总体的资源使用，来对在线做一个更好的保护。那在这种模式下，在线是不是一定不会受到干扰呢？答案是否定的。我们看一下这个图，在线和离线是共享盒，他们也共享底层的L3K，当离线任务开始运行的时候，我们看到在线任务的L3开始是下降，当离线任务结束的时候，在线任务的L3开始恢复。所以说，呃，在线其实是受到影响的，这里也列举了一些其他的原因，会导致在线受到干扰。

首先是资源隔离，依赖某些硬件功能或系统配置啊，比如前面提到的共享开始和内存开宽带带宽，尤其是在虚拟机场景下，如果这些硬件的特性不能透传给虚拟机，那在虚拟机场景下是不能通过硬件资源隔离来对在线做更好的保护。而系统配置，比如说现在很多的，呃呃。呃，磁盘IO的权重是基于啊BFQ这个调度策略的，目前很多的在线机器的调默认的IO调度策略可能不是BFQ，这就可能会涉及到对机器配置的修改。二是内核版本低，隔离能力弱，因为内核升级也是一个长期的过程，所以说嗯，在为了就是说为了更好的保护在线的服务质量，我们需要干扰检测与处理，那干扰检测与处理应该怎么做呢？首先是指标，指标是干扰检测与处理的基础，我们需要在线应用提供。

提供能反映其性能的指标，尤其是实验指标，或者我们需要从侧面收集一些能反映出在线实呃在线实验的一些指标，所有的这些指标统一存入TSGB时间序列，有了有了这个数据库之后，我们就可以来筛选。呃，任意时间维度以及任呃任意时间呃时间范围以及任意维度的指标来进行对比，来做更好的检呃异常节点的发现。上层我们采用了插件式的干扰检测跨件，所谓插件式的干扰检测跨件，它的实现原理跟K8S的调度器framework它的原理是类似的，它可以让用户实现各种自定义的啊干扰检测逻辑，这里我们也集成了一些通用的干扰检测逻辑，比如说节点检测，检测节点级别的资源是否有异常，容器检测，检测容器级别的，呃呃。

资源是否有异常，以及APP检测检测用户提供的实验指标是否有异常。同时我们也与也也欢迎用户可以自定义一些干扰检测逻辑，比如说我们可以集成一些TRTC的干扰检测逻辑，以及我们可以为游戏场景下定制一个干扰检测。这里展示了干扰检测啊与处理的流程，首先是也是收集各种指标，包括节电指标、容器指标、容器指标，如呃C级别的内存set波动情况，Ebpf指标、epf指标。这里我们对于内存，我们会收集在内存分配的过程中，如果出现内存不足而进入慢速分配路径上的一些关键函数的处理实验，对于磁盘IO，我们收集的是IO系统调用的读写实验，而对于网络，我们收集七层协议处理路径上的一些关键函数的处理验。

任务指标是指呃用户提供的呃实验指标。有了指标之后，我们可以再配合各种检测算法，比如说指数加权平均或阈值检测以及检测规则，如在多长时间内有多少个点超过某个阈值。通过指标检测算法和检测规则，我们如果检测出某个节点异常，我们就要采取一定的行为处理。呃，所有的行为处理都呃统一会干扰状态，这个组件由干扰，由干扰状态来执行。真正的呃处理操作包括禁止调度，因为这个节点已经出现干扰了，新调度的任务可能会被受到压，受到压制以及更新master资源，告知呃让其少调度一些人。离线任务对于KS来说是通知epso来降低扩展资源量。呃对于哈政府任务来说是通知resource manager。

来降低NM在2M端的capacity。另外是调整本地资源，呃。让离线呃，让离线呃压呃，对离线任务做压制，包括CPU、内存、磁盘和网络lo，以及我们可能会驱需要驱逐离线任务呃。驱逐离线任务的过程中，我们首先要对离线任务进行排序，我们可以按照它的资源使用量，它的优先级以及它的运行时间，比如说优先驱逐运行时间最短的离线任务。总总的目标是Q影响最呃Q影响最小的离线任务，离线任务运行在在线机器上，复用在线机器的空闲资源，尤其在语音原生场景下，那离线认为应该如何管理呢？我们还是以CPU资呃CPU资源为例。

在在云行场景下，我们的节点的空闲资源是以扩展资源的形式上报给APS server的离线任务申请扩展资源，且不且不携带白色的effort，也不携带request的资源，那它是一个白色的effort的类型。从这个图中我们可以看出，离线任务只能复用Bo和best effort共享的呃呃共享的盒上的空闲资源，而不能复用guarantee盒上的空闲资源。而对于内存来说，也有同样的道理，尤其当Q开启QS与reserve的策略的时候。这时我们会会考虑是否可以为离线任务新建一个c group目录，这个c group目录的使用范围是整机的资源。

而白，而离线作业是是白色F的作业，它的任务提交的时候已在，尤其在呃容器创建的时候，它的进程的PID都已经被放在best effort这个目录下了，那我们只能周期性的把从把离线任务的进程PID从白色effort目录。啊，移动到新建的这一部分目录，但这里会有一个问题是时效性差，尤其是当这个离线任务它刚启动的时候，就消耗了大量的CPU，这段时间是不可控的，所以说我们需要采取一些其他的方式。来保证离线任务在刚启动的时候，它的进程的PI就可以直接放在新建的C库目录下，这里我们采用拦截的方式啊，当离线任务在呃，离线任务在离线，离线任务在容器创建的时候，我们通过拦截的方式修改它的C目录，改为新的，改为指向一个新建的C部目录，我们称之为offline offline目录，这个offline目录它是独立于cub管理范围呢，它可以复用全部。

节点，呃，这个节点下全部的空闲资源。以及我们这个offline这个的它的它的资源也不是啊，是也不是可以无限制用的，它受开来进行统，它受开呃管理，然后开实时的设置这个所有离线任务的可用资源的总量，同时所有的离线任务采用离线大框的弹性管理方式，从而避免了单个炮的来受压制的概率，这也可以极大的提升离线资源的整体的利用率。我们采用拦截操作的拦截点可以在两个，可以在两处，一个是在cub和docker或contain之间，或者在肯地和呃，Docker和与RAC之间，这两个数都是可以的。那拦截操作不入侵K8S原生的代码逻辑，兼容性强，也可以方便移植到其他平台。另外它可以丰富容器化的个性配置。

如我们现在只是通过拦截操作来修改了离线任务的C目录，其实我们可以来增加更多的特性，比如说修改离线任务的共享内存的大小，或者修改它呃对呃，增加PID呃，离线任务的PID限制等一些特性。资源隔离是混固的基础，任何单一维度的资源隔离都会缺失，都可能会在线造成影响。所以说我们需要全维度的资源隔离，包括CPU、内存、磁盘IO、网络IO、磁盘空间、文件、句柄、进程数、硬件资源等。呃，资源隔离它要我们是要遵循两个原则，一是离线资源要严格的被限制，保证在线资源的充裕。以磁盘IO为例，我们需要严格限制离线的读写磁盘的IO的速率，任务就需要我们对buffer buffer right的支持。

另外，当在线需要资源的时候，它可以通过优先级抢占来实时的抢占离线资源，这样可以更好满足的在线临时需要大量资源的需求。比如说以内存为例，我们可以对内存呃按呃分，按照呃进行划分优先级，当内存回收的时候，优先回收离线的呃，离线内存的cash。这样可以更好的对在线的开始做保护啊，对于网络IO来说。当在线的流量突增的时候，在线的高于优先级可以抢实时抢占离线低优先级的网络带宽，恐怖场景下，那如何保证离线的服务质量呢？首先我们想到的是调度，因为离线任务都是短任务，它的数据呃数量大，变发度高，对调度的要求也非常高。而K8S原生的调度逻辑，它是面向在线的呃在线任务，注重在线的调度功能，比如说呃节点的亲和性，POS间的反亲和性等，所以说呃对呃对，对于离线任务它是满足不了其需求的。所以说我们自研了离线调度器，注重啊调度的高高性能，我们采用批量调度的方式，相对于K8S原生的调度器来说，它会有数量级的提升。同时如果在整个呃离线任务填充满了整个集群，当此时有大量的在线任务调度的时候。它可以采用批量抢占的方。

是。来迅速的抢占离线任务，从而可以大大提高在线调度的调度效率。呃，提升调度的性能的同时，我们也注重功能迭代，采用插件式的机制呃，可进行高高扩展性，这样可以允许用户自自定义自己的调度逻辑插件。

在离线场景下，主调度刚上的基本是一个标准的需求了，这呃，我们的调度器也是支持的。总步场景下调在线调度和如如呃离线调度该如何协同呢？我们嗯之前我们调研了几种方案，首先是呃，整个机群只有一个调度器，带线调度和离线调度都集中在一起，那这个调度器的逻辑会会非常复杂，而且它的调度性能可能会成为瓶颈。第二种方案是。啊，也是多个调度器，但是它是有一个基于全局锁来进行协调，在调度器在调度之前先获得锁，然后再这种再调度，这种方式它的并发度低，资源利用率也也比较低，这种方式也称为悲观并发。第三另外一种方式，也是我们现在正在采用的方案，是基于共享状态的乐观并发。

如图中所示，我们增加了一个协调器，各个电路器在这个集群中单独进行调度，但在调度真正调度之前，我们需要都需要向协调器申请资源。同时我们对这种调度冲冲突进行了呃专门的优化，目标是最小化冲突检测的时间消耗，从而可以不影响呃整个调度时延。协调啊，多调度器加协调器的架构，它可不入侵在线调度的调度逻辑，而且它可以在呃兼顾在线调度的功能和离线调度的性能需求。

可火部的离线任务可分为大数据任务、AI任务以及任何可以在K8S上运行的离线任务。大数据任务可以分为云原生大数据，这这里喀勒斯是原生支持的，以及哈图布下哈特布场景下的大数据任务。因为这部分任务是通过亚来提交的，而不是通过K8S提交，所以我们采取了一种渐进式的方案及亚行K8S，把呃亚的S6组件NM进行容器化，并以POS的形式提交到K8S平台。这里我们也做了一些优化来，目标是更好的保证NM的呃稳NM在容器中稳定的运行，如呃镜像热升级。因为呃亚的离线任务其实也是在NM的容器里面的，如果我们对NM的镜像进行升级，那NM所在的容器就会被重启，此时里面的离线任务都会被kill掉，这对于离线任务来说是不可接受的。

而镜像热升级可以在保证不kill呃，NM容器里面的离线任务。呃的前提下，可以对NM的镜像进行升级。另外，我们也实现了一些其他的功能，比如说热更新、capacity。因为混部资源它是动态变化的，所以说它在RM端的资源也会动态变化，就是说呃，热热更新开的功能可以动态的，可以在不重启NM进程的情况下来动态的更新NM在2M端的资源，从而减少了NM重启带来的性能开销。恐怖资源具有不稳定性，大数据任务如果直接运行在恐怖资源上，会产生啊较高的失败率，导致无效算力，尤其是。大数据任任务运行过程中，它是呃有sa服务的呃，恐怖资源上恐怖，恐怖节点单节点的挂掉可能会影响其他节点上离线任务的正常运行。另外在恐怖节点的，也就是在线机器，它的磁盘空间一般都比较少，而。

大数据任务运行过程中需要产生大量的数据，所以说磁盘空间可能会成为一个资源瓶颈。稳步节点和存储节点位于不同的城市，这种跨城的网络传输也会带来一些实验的高开销以及网络成本。针对这些问题，我们在实践中也总结了几条经验，首先是我们需要对大数据任务做画像，我们收集离线任务运行过程中的资源消耗，包括CPU、内存，磁盘IO和网络IO。有了这些画像之后，我们就可以对。筛选出一些可以巩固的离线任务，比如说可以先选一下磁盘O运行小的，来避免对呃和在线的磁盘O产生竞争。存算分离，我们把S的数据统一写到远端，从而避免了单一节点的呃挂掉而影响其他节点上的离线任务的正常运行。

诶。把这个sale的数据统一写到远端，也可以尽下的降低提现入在本地磁盘的数据存储的容量。存储加速，我们通过Alex来实现了呃热点数据的缓存，这样可以减少呃网络的呃传传输的时延和网络成板。云盘扩展，通过挂载云盘，比如说C的RPD盘解决磁盘空间问题，从而可以混固更多的离线任务，而为离线单独挂载磁盘也可以避免磁盘IO的竞争，对在线可以做一个更好的保护。AI任务的运行时间一般都比较长，为小时级别甚至天级别，而混步利用的是在线资源的潮汐特点，尤其是潮汐周期是天级别的时候，那当在线高峰时段的时候，AIAI任务可能就会被压制。

对于CPU资源而言，我们可以降低呃离线的CPU的资源使用量，让它运行的慢一点，它的服务质量可能会下降。而对于内存这种不可压缩之言，我能，我们只能驱逐离线任务，导致AI任务重新运行，呃，拉长了它的运行时间，呃呃呃，离离线任务的运行时间的拉长，对于离线资源的廉价性，这种优势反而体现不出来。呃，容器热迁移是指在保证离线任务正常运行的前提下，从一个节点迁移到另外一个节点，让其继续运行，同时它也可以支持本地迁移，即它可以给离线任务很少的资源，保证其正常运行，当在线波峰时段过去之后，离线任务获取获获得资源之后可以恢复运行。从这个热迁移的描述可以看出，容器热迁移可以很好的解决AI任务这种长时间运行的离线任务被驱逐的问题。那么当前基于CVM的热迁移技术已经相当成熟的，但是基于容器热迁移的技术就是探索是比较少的，真正落地也就更少了。我们现在已经基于容器热迁移在腾讯内部进行了诸多的实践，也进行了多项的优化，比如说以内存迁移为例。

常规的内存迁移方式是我们先停掉原节点的呃任离线任务。然后再把。嗯，说把机器上的把离线任务的内存一次性迁移到目标节点，然后再在目标节点重新拉起任务，这种方式的问题是对会对离线任务的中断时间很长，尤其是这种大内存的离线任务，而对于对于呃。

如呃对离线任务的中断时间长可能会导致离线任务被重新被拉起，尤其是对于那种呃有master和slave架构的离线任务来说，比如说啊，如果说呃，Slave的呃任务的它的中断时间过长，那master可能认为这个slave是运行失败的，它会重新拉起一个slave任务。就是说为了保证中断时间优先，我们采取按内存按需迁移策略，即我们在现在目标节点拉起离线任务。当离线任务需要内存的时候，我们通过网络传输的方式从延节点来传输内存，然是为了保证这种迁移时间呃最短，我们在传输的过程中，我们采用压缩以及并发的方式加大内存的传输速率。另外，我们也可以采取迭代迁移的方式，所谓的迭代迁移是指离线任务还是在原节点运行。只是说我们对离线任务内存的迁移分。

多次迭代，每次迭代可以对离线的任务的中断时间最少。当最后一次迭代的时候，我们才把离线任务停掉，并把最后的内存一次性迁移到目标节点，然后重新拉起。这种策略的好处是相对来说比较稳定，也比较均衡。容器热迁移是解决长时间运行的离线任务的在巩步场景下运行的利器，尤其是类似机AI机器学习这种这种任务我们也会持续的进行深耕容器热线与技术。最后我们介绍一下开乐斯的呃实践落地，目前开乐斯已在腾讯内部多个场景落地，涵盖了呃时效性比较高的广告业务啊呃社交新闻、QQ等社交娱乐业务以及游戏业务等，还覆盖了一些存储类的服务，包括CFHDF等存储类服务以及h base数据库业务。我们的在线场景包括了容器化和非容器化离线任务包括大数据和机器学习等。目前colors也已开源，也欢迎大家进行点赞和fo，也同时更欢迎大家来贡献代码，我们也希望cars可以在更多的场景落地。

呃，谢谢大家，我的演讲就到这里。好的，非常感谢陈东东老师的讲解，陈老师呢给我们讲解了在线业务和离线业务的特点，以及为什么要将他们进行混，如何使用cans将它们进行混补。相信大家听完陈老师的讲解后呢，对在离校婚部有一个更清晰的认识。知道如何去落地，在离线分布，也再次感谢魏博凯老师的精彩分享，那感谢大家的观看，我们当前的回放地址也也是我们的直播地址，我们后续呢，还会在8月4日8月11日的晚上八点进行第五讲跟第六讲的直播，欢迎大家到时预约观看，那好，我们本次直播结束，我们下期再见。