全场景在离线混部解决方案

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. Caelus-全 场 景 在 离 线 混部解决方案 陈凌鹏 腾讯高级工程师
2. 目录 CONTENT 01 背景概述 03 Caelus 介绍 02 设计目标 04 落地实践
3. 01 背景概述 请混部及意义
4. 混部的背景 – 资源需求与成本 data created and consumed worldwide(in zettabytes) DATA CENTER COSTS server 200 147 150 100 50 other 181 15.5 18 26 33 41 64.2 79 97 120 other 43% server 57% 0 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 data source: statista released in June 2021 资源需求大 • 离线大数据需求 • AI,IoT,5G data source: perspectives.mvdirona.com 资源成本高 • 电力成本 • 维护成本
5. 为什么混部 在线服务利用率低 • • • • • 单实例部署,使用不充分 request > usage 业务存在潮汐现象 节点资源碎片 集群资源碎片 离线任务特点 • 运行时间短 • 可使用碎片资源 • 能容忍一定程度的受损, 通过重试保证
6. 02 设计目标 请混部面临的场景与设计原则
7. 全场景混部 全场景在离线混部,不止K8S 在线场景 1、容器化作业。基于K8S和Mesos,目前都 在向K8S汇集,Mesos就不考虑了 2、非容器化作业。量很大,尤其是不适合容 器化类的在线作业,如存储类作业CEPH 离线场景 1、K8S云原生大数据 2、Hadoop生态大数据
8. 混部的原则与目标 设计原则 通用技术,公司内外都可以使用,方 便开放到社区以及输出到腾讯云客户 符合云原生方式 降低对应用的依赖,不能引入太多假 设 兼容生态,K8S和Hadoop 设计目标 在线作业SLO受保证,离线作业不能 无限填充 离线作业能快速上线下线,在线作业 需要更多资源时,能及时避让 离线作业的成功率受保证,不能因为 频繁受限,导致失败率很高 在保证在线和离线服务质量的前提下, 尽可能提升资源利用率
9. 03 Caelus方案 请开源解决方案Caelus简介
10. 混部的架构 cost priority quota federation 架构设计: storage metric-server Prometheus K8S App Admission webhook 历史数据 OS coordinator Kube scheduler 应用画像 caelus 干扰检测 资源画像 Prometheus Hadoop Job caelus nm caelus kubelet kubelet kubelet caelus caelus caelus kubelet kubelet kubelet 资源回收 数据采集 资源隔离 Apiserver Batch scheduler 不改变用户使用方式 非耦合,可扩展架构 兼容各种混部场景 实时数据 caelus 干扰处理 ① ② ③ descheduler 资源更新 NM/Kubelet YARN ResourceManager
11. 适配Hadoop生态 • Nodemanager容 器化 • Daemonset部署 Hadoop生态下的离线 作业非常适合混部,零 入侵适配。 • 节点高负载,冷 却避免更多离线 任务 • 通过api操作 YARN命令 K8s云原 生部署 YARN命令 API化 禁止调度 热更新上 报资源 • 离线资源随在线 使用动态变化 • 无需重启NM
12. 服务画像 - 资源预测 远程预测: ① VPA(veritcal pod autoscaler)组件 ② 全局考虑应用下所有pod资源使用情况, 进行统一预测 ③ 新扩容pod根据历史数据立即获取到预 测资源 本地预测: ① 根据节点资源实际使用量预测,包括 在线和系统进程 ② 在线作业资源突变,可快速作出反应 ③ 支持多种本地预测算法
13. 全维度资源管理 全维度资源隔离 全维度资源隔离: 1. 2. 3. 4. 5. 6. 资源隔离是混部的核心。依赖底层OS支持,主 要是Cgroup 全维度资源隔离,及细粒度的L3 Cache、内存 带宽 采用非入侵方式,离线作业的进程直接放入 offline cgroup目录下 (/sys/fs/cgroup/kubepods/offline) 离线作业统一受Caelus管理,独立于K8S管理 离线大框,所有离线作业共享可用资源。弹性 控制所有离线作业资源,提高资源使用率 资源QoS支持 离线cgroup目录
14. 在线服务质量保证 干扰检测: 1. 2. 3. 4. 混部资源管理策略不够完善 无法保证所有竞争资源都被管理 检测干扰的方式: ① 指标 ② 资源 指标获取方式: ① 需要应用配合 ② 无需应用配合,系统自动采集 ③ eBPF采集: io, memory, 请求 处理延时 冲突处理: 1. 2. 调整资源,快降低慢恢复 处理离线进程 ① 不同类型资源处理不同: Kill/throttle ② 按离线作业重要性排序驱逐 资源隔离 干扰检测 CPI 实际资源 时延 eBPF 禁止调度 恢复调度 冲突处理 NM Capacity减少更新次数 AdustResource process offline task throttle kill 优先级、启动时间 离线作业排序 listAll, kill Kill离线作业
15. 离线服务质量保证 – 容器热迁移 2. 创建 PodMigration CRD PodMigration Spec Pod1 Spec Kubernetes master Annotition: Migration- webhook Native contorllers live.migrate.io/mi gration- timestamp=XXX 1.资源紧张时为Pod打迁移标记 galaxy caelus HostA kubelet PodName: Pod1 SrcNode: HostA DestNode: HostB Status 6. 更新迁移状态 4. 迭代迁移 状态 miglet 3. Checkpoint状态 miglet 5. Restore Pod Pod1 (task manager) Pod1’ (task manager) Pod2 Pod2 PodN PodN 容器热迁移流程图 kubelet galaxy caelus 背景: 容器热迁移技术旨在解决某些 离线作业因在线资源需求增大或受到 干扰而被驱逐问题,进一步保障离线 作业SLO。这些离线作业包括: • 长时间运行的离线作业 • 比较重要的离线作业 效果: • • • HostB 非入侵Kubernetes/Docker 迁移过程网络链接不断,IP地址不 变(overlay、FloatingIP) 业务中断时间短(~10s数量级) • 迭代迁移 • 数据压缩 • 并发传输 • 按需迁移(Lazy migration)
16. 高性能调度器 • • • 多调度器+协调器架构,维持K8S原生在线调度属性 支持gang schedule等离线调度特性 高性能调度,调度吞吐从300+提升到3000+,满足了大规模离线业务场景
17. 04 落地实践 请caelus实践
18. 落地实践 非容器化场景 (1) 广告非容器化集群 广告业务需要大量的计算资源,受成本限制,资源有限。在 线作业非容器化部署,有典型波峰波谷现象,资源利用率达标 率低。考虑在波谷时段混部离线作业,来解决资源需求问题。 (2)CEPH存储集群 某存储类CEPH集群,cpu使用率很低,不到1%,为 磁盘消耗类型作业。通过混部离线作业,cpu使用率最高 可以提升50%。 某CEPH集群混部CPU利用率提升 0:00-5:00混部前后使用率对比 某CEPH集群混部时延指标对比 0:00-5:00混部前后时延对比
19. 落地实践 K8S场景 某K8S集群的业务方主要是AI训练任务,不定时使用资源,导致资源繁忙时利用率100%,空闲时就 完全空闲。通过混部离线作业,把空闲时段资源利用起来,总体使用率提升了15%。因受磁盘空间限制, 提升有限。若增加远程盘,如挂载CEPH RBD盘,其使用率可进一步提高,可到60%。 混部之后使用率 混部之前使用量 挂载CEPH RBD盘增加存储资源
20. 未来规划 容器热 存算 分离 迁移 autopilot cgroups V2 容器 运行 时 数据 编排 Ocean kubernetes Remote Shuffle Service 应用 画像 底层资源管 理 eBPF无 入侵监控 云原生 大数据 大规模集 群 应用服务质量保 证 干扰检测 和避让 超 发 高效调 度器
21. 欢迎加入 https://github.com/Tencent/Caelus 腾讯大数据团队在计算、存储、调度等多方 面招聘人才,北京/深圳/上海都可以,欢迎 感兴趣的同学投递简历到 forrestchen@tencent.com
22. 非常感谢您的观看

trang chủ - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-18 02:25
浙ICP备14020137号-1 $bản đồ khách truy cập$