2022云栖内容精选—基于龙蜥与 Koordinator 的在离线混部的实践

简介: 赵 蔚爱奇艺基础架构研究员

lQLPJxbcF2cqNBvMiM0FeLCMz4ifcSGHeANpqgFLAEAA_1400_136.png

一、爱奇艺离线业务混部背景

image.png

与众多互联网公司一样,爱奇艺常见的负载类型包括业务应用、数据库&中间件以及离线任务。其中业务应用包括有状态应用和无状态应用,无状态应用可以借助运维平台在业务团队和运维团队之间做比较清晰的职责划分,适合混部;而有状态应用较为复杂,混部时的运行质量难以保证。数据库和缓存目前并没有运行在混部集群中。离线任务中的非实时性任务,比如夜间转码、数据处理等只关注吞吐量而不关注时效的任务也是混部的对象。

image.png

爱奇艺在混部上经历了长时间的探索。


2013 年,爱奇艺初次进行了计算存储混部。进入容器时代后,爱奇艺在 Mesos 上花费了大量精力,最早把在线任务内容生产、 Spark、Storm 等所有工作负载混部在一个集群里,没有进行任何特殊的隔离性处理。在 Docker 上经历了困境后,爱奇艺将业务按节点、集群进行了拆分;这又导致离线任务集群资源常年不够用,在线业务集群利用率非常低,尤其是夜间利用率甚至只有个位数。因此,爱奇艺考虑将夜间线任务的资源提供给离线任务。


2016 年,通过 Mesos Oversubscription 功能引入根据真实资源做额外计数器的机制,将任务分为了延迟敏感和尽力而为两类进行混部。但由于细粒度的隔离性问题,这条道路也无疾而终。


到了 K8s 阶段,由于在线业务的伸缩能力的增强和普及,第二套计数器不再是强需求,爱奇艺直接在 K8s 上进行了混部,通过引入 Kata 保证服务质量。


2022 年,龙蜥 + Koordinator 一并被引入,用于构建下一步的混部架构。

image.png

从多年的混部经验里,爱奇艺总结出了影响混部的关键因素:

第一,服务质量,尤其是在线业务的质量,脱离了服务质量则混部无意义

第二,获取额外资源。

第三,任务适配。

image.png

获取额外资源存在有两个思路:

其一为使用一套计数器,按固定比例超卖资源,直接混用,或者按经验比例分配给各个类型的负载。

其二为多套资源计数器,一种方式是利用经验数据判断集群的空闲时间和空闲资源,另一种方式是通过类似 Mesos Oversubscription 的方式做空闲资源的实时探测。

image.png

服务质量的策略分为静态动态。动态指在离线业务或具体的进程之间动态进行调整静态一旦下发固定,即便有影响也不变动


二、龙蜥和Koordinator在离线业务混部探索

image.png

Koordinator没有对分布架构做本质上的变动,是在规范性方面,比如业务类型的抽象上做了更多工作,使K8sKoordinator有了做通用分布架构的可能性,而不像之前只能针对特定的业务定向做定制。

image.png

Koordinator 可以简单理解为给 K8s 增加插件或做了增强,首先会增加一个调度器,引入一套资源技术,在节点上有一个 Koordlet,分别负责收集资源和保证任务的隔离性。

image.png

其工作机制为利用计数器在真实利用率基础上进行二次分配。整机的真实使用使用率取决于离线任务的使用率,保证在线业务的质量的前提下,水位线可以根据实践随时调整。

image.pngKoordinator 在任务分配方面分为五种类型(图中只列举了常用的四种),通过不同层级的分类,对在线业务和离线业务进行了不同层级的保障。image.png

为进一步保证服务质量,爱奇艺引入了龙蜥操作系统(Anolis OS)。Group Identity 功能和 CPU Burst 功能对当前的混部效果起到了很大的提升作用。


Anolis OS 通过配置不同的 Group Identity 启用两套进程调度,一套作为在线业务的调度器,另一套作为离线任务的调度器,在线业务优先级整体高于离线任务。此前,在公平调度的机制下,在线业务、离线业务之间在细粒度上存在互抢资源;而引入两套调度器后,这个问题可以被合理规避。CPU Burst 的作用是使公平调度进程之间的切换更平滑,避免出现毛刺。

image.png

第一个试点业务为某类型内容实时生产,已经全量运行在混部资源上。从某种意义上它是零成本的,因为全部复用了其他服务器节省出来的资源。目前运行非常稳定,也没有对在线业务造成无法接受的干扰。


每天对热点视频进行二次或更多次编码也是爱奇艺一项较重的非实时离线计算任务,目的在于通过再生产降低码率或提高质量。该任务目前正在灰度验证阶段,期待接入Anolis OS 和 Koordinator 之后能带来足够大的惊喜。


大数据离线计算方面,出于综合考虑,爱奇艺目前依然选择 Kata 作为运行时,因此也正在积极和龙蜥社区进行探索,尝试 Kata 和 Koordinator 的合作。

image.png上图为试点前后的效果对比,在验证环境设计比较保守的情况下,利用率整体提升 50% 以上。图中任务高峰期 CPU 使用率低于水位线的主要原因是BE任务申请的资源量没有被充分利用导致,涉及到离线任务的运营。当然,如何通过技术手段将真实的资源进行三次、四次甚至无限次的分配,也是爱奇艺期望尽快解决的。

三、未来工作展望

image.png

未来,爱奇艺将与龙蜥社区携手同行。首先,争取将 CPU 利用率提升到 50% 甚至更高。其次,因为涉及多租户,需要进行资源分配,尤其是离线任务资源总量不稳定,离线池内资源分配不合理和资源抢占问题时有发生,期望能够在未来规避此类问题。最后,爱奇艺在离线任务质量保障方面继续探索。


关于龙蜥峰会云原生专场课件获取方式:


【PPT 课件获取】:关注微信公众号(OpenAnolis),回复“龙蜥课件” 即可获取。有任何疑问请随时咨询龙蜥助手—小龙(微信:openanolis_assis)。


【视频回放】:视频回放可前往龙蜥官网https://openanolis.cn/video 查看。

lQLPJxbcF2cqM2TM-M0CnrCgW_7LDpyh1wNpqgFKAPsA_670_248.png

相关文章
|
7月前
|
安全 Cloud Native Java
龙蜥白皮书精选:机密计算平台技术
龙蜥社区为推动机密计算技术的应用,提供若干机密计算创新项目,目的是降低机密计算技术的使用门槛。
|
3天前
|
安全 Dubbo 应用服务中间件
活动回顾丨云原生开源开发者沙龙北京站回放 & PPT 下载
4 月 13 日,云原生开源开发者沙龙在北京顺利开展。阿里云一线工程师围绕《微服务面临的安全挑战、趋势与解决方案》、《通过 Dubbo 构建零信任安全体系》、《零信任策略下 K8s 安全监控》、《如何构建零信任的网关》、《RocketMQ ACL 2.0 全新升级》、《Nacos安全零信任实践》6 个当下热门议题与现场的百余位开发者展开交流。
|
4月前
|
Cloud Native IDE 中间件
活动回顾丨云原生技术实践营北京站回放 & PPT 下载
活动回顾丨云原生技术实践营北京站回放 & PPT 下载
|
8月前
|
人工智能 运维 监控
龙蜥白皮书精选:SysAK—大规模复杂场景的系统运维利器
SysAK 在功能集上会进行全方位覆盖,垂直打通整个应用的生命周期。
|
8月前
|
存储 运维 监控
万人在线,一站式自动化运维 SysOM 3.0重磅发布!龙蜥社区系统运维 MeetUp 回顾来了
万人在线,一站式自动化运维 SysOM 3.0重磅发布!龙蜥社区系统运维 MeetUp 回顾来了
|
8月前
|
Cloud Native Linux 数据中心
龙蜥白皮书精选:云原生混部资源隔离技术
不论是源码透明度,还是技术深度,以及场景的广度,龙蜥在资源隔离技术都是用户第一选择。
|
编解码 运维 Kubernetes
爱奇艺:基于龙蜥与 Koordinator 在离线混部的实践解析 | 龙蜥技术
在 2022 云栖大会龙蜥峰会云原生专场上,来自爱奇艺的基础架构研究员赵慰分享了《基于龙蜥与 Koordinator 的在离线混部实践》技术演讲,以下为本次演讲内容:
爱奇艺:基于龙蜥与 Koordinator 在离线混部的实践解析 | 龙蜥技术
|
Dragonfly Kubernetes Cloud Native
|
Dragonfly Kubernetes Cloud Native
龙蜥云原生社区未来展望
黄韶宇 龙蜥社区云原生SIG
龙蜥云原生社区未来展望