• 0

  • 537

CTO越来越高的情况下,我是如何帮老板省下400万的?

云哥

关注云计算

1 month ago

上篇链接:juejin.im/post/686596…  

混部系统设计

我们基于 Kubernetes 实现了在/离线业务混部系统,遵循以下设计原则:

  • 动态调度:根据节点的真实负载实现离线业务的动态调度
  • 动态资源分配和隔离:根据在线业务的负载,动态调整分配给离线业务的资源量,动态执行资源隔离策略,降低甚至消除彼此之间的性能干扰
  • 插件化:不对k8s做任何in-tree的侵入式改动,所有组件要基于k8s的扩展机制开发,并且混部系统本身扩展性强
  • 及时响应:当混部节点资源利用率过高,或者对在线业务产生影响时,能够及时发现,并驱逐离线业务,以保证在线业务的SLA
  • 可运维、可观测:对用户和运维人员友好,接入成本低,使用成本低 image
    在这里插入图片描述

图6 系统架构

Resource Reclaim

Resource Reclaim是指回收在线业务已申请的,但是目前还空闲的资源,然后给离线业务使用。这部分资源是low-quality的,没有太高的可用性保证.

我们自定义了扩展资源colocation/cpu和colocation/memory(分别对应原生的cpu和memory),来表征上述 reclaimed resource,实现离线任务的动态调度。

在这里插入图片描述
图7 resource reclaim

节点上在线业务CPU Usage高,则我们分配给离线业务的资源就会减少;在线业务CPU Usage低,则我们就可以将更多的资源分配给离线业务。

动态调度

基于扩展资源colocation/cpu和colocation/memory 实现离线任务的动态调度,优先将离线任务调度到节点负载较低、离线任务较少的混部节点上,均衡不同节点之间的负载、减少业务之间的资源竞争。

动态资源分配和动态资源隔离

Google 在数据中心资源管理领域,很多年以前就开始投入大量人力、物力。由于硬件在性能隔离上的局限性,Google在软件层面做了大量的改造,率先提出了多项资源隔离技术,包括cgroups、Container等(内核的很多功能特性都是业务需求触发的,而不是凭空想象出来的)。我们对于在/离线业务的性能隔离也是主要通过cgroup来实现的。

kubelet cgroup manager 没有可扩展点,直接修改kubelet代码又会给后续的运维升级带来比较大的成本,因此我们单独开发了一个zeus-isolation-agent运行在每个混部节点上,通过定时动态更新cgroup来实现在/离线业务资源隔离。

在这里插入图片描述
图8 在/离线业务资源隔离

从CPU、内存、缓存、磁盘到网络,我们实现了多维度的隔离策略,显著降低在/离线业务之间的互相干扰。以缓存为例,我们对内核进行了定制化改造,给在/离线业务设置不同的缓存回收优先级,优先回收离线业务使用的缓存。

离线业务的重调度

存在这样一种场景,刚开始时混部节点上的在线业务较少、负载较低,能够分配给离线业务的资源较多,因此用户能够调度较多的离线业务上去。但是,后来用户调度了更多的在线业务上来或者在线业务的流量飙升,导致节点上能够给离线业务的资源非常有限,离线任务执行效率会很低。假如此时,其他混部节点比较空闲,为了避免离线任务的饥饿、减小业务之间的资源竞争,我们会重调度离线任务到其他node上。

离线任务的重调度,主要有如下优点:

  • 均衡各个混部节点的负载情况,避免有的节点负载较高而有的节点又过于空闲
  • 避免某个节点负载过高,以至于影响到在线业务性能和稳定性
  • 提高离线业务的执行效率

但是,重调度也有缺点,如果没有远程checkpoint机制,会导致重调度之前的算力被浪费。影响程度有多大,是跟单个任务的处理时长有关系的。如果处理一个任务的时长是秒级,那么重调度的影响是微乎其微的。如果处理一个任务的时长是天级别的,那么重调度的影响还是比较大的。因此,是否使用重调度功能、重调度的触发阈值等用户都是可以实现workload级别的配置的。

落地成果

上述在/离线业务混部方案已经集成到网易轻舟容器平台NCS中,在网易内部得到广泛应用,大幅提高了服务器资源利用率,取得显著成果。

以网易传媒为例,传媒将视频转码业务作为离线业务混部到了在线业务的机器上,混部后CPU利用率从 6%-15% 提高到 55% 左右。

先了解一下视频转码服务的特点:

  • CPU密集型,大量读写磁盘保存临时数据,有一定量网络IO
  • Long-running pod,而不是一个run-to-complete类型的pod,它会从队列中不断取视频任务进行转码处理,没有任务的话就空闲且保持运行
  • 转码单个视频的时长在秒级,因此重调度对其影响是微乎其微的

redis+视频转码

Redis业务是对于时延比较敏感的在线业务,SLO要求较高,但是其CPU利用率较低,因此我们尝试将视频转码业务混部到了Redis专属节点上,下面我们看一下这两个在/离业务混部的效果。

在这里插入图片描述
图9 Redis节点混部前后CPU利用率

从图9 可以看到,Redis节点混部前CPU利用率在8%左右,混部后达到30~35%,利用率大幅提升。

然后我们再看一下混部前后redis的SET/GET操作的RT对比。

在这里插入图片描述
图10 Redis GET 操作平均响应时间
在这里插入图片描述
表3 Redis GET 操作平均响应时间

从图10 和 表3 可以看出,混部前后GET操作的RT 基本没有变化。

在这里插入图片描述
图11 Redis SET 操作平均响应时间
在这里插入图片描述
表4 Redis SET 操作平均响应时间

从图11 和 表4 可以看出,混部前后SET操作的RT 基本没有变化。

广告推荐+视频转码

广告推荐服务也是一个对稳定性和性能要求很高的时延敏感的在线类型业务,下面我们看一下转码服务和广告推荐服务混部取得的效果(节点上还有其他类型的在线服务,这里我们以时延敏感的广告推荐服务为例)。

在这里插入图片描述

图12 混部前后节点CPU利用率对比

从图12 可以看到,混部之前cpu利用率在10-20%之间,混部之后cpu利用率长时间维持在55%左右,利用率提升幅度较大。

混部的目的是提高资源利用率、降低成本,但是前提是不能对在线业务产生明显的性能影响。因此,我们再看一下该广告推荐服务的某个核心性能指标在混部前后的变化:

在这里插入图片描述
图13 广告推荐服务请求处理时间

从图13 发现,混部前后该核心性能指标是没有任何衰减和恶化的,混部前的平均RT是6.59ms,混部后的平均RT是6.65ms:

在这里插入图片描述
表5 广告推荐服务混部前后的平均RT指标

总结和展望

目前,混部已经在网易得到广泛落地,取得显著成果。接下来,我们会继续探索和实践云原生技术,基于网易轻舟将混部方案落地到更多企业,让更多企业享受到云原生的红利。

参考文献

[1] The Datacenter as a Computer
[2] Overall Data Center Costs
[3] 数据中心成本与利用率现状分析
[4] Quasar: resource-efficient and QoS-aware cluster management
[5] 浅谈混部系统研究
[6] PerfIso: Performance Isolation for Commercial Latency-Sensitive Services
[7] Borg: the Next Generation
[8] Autopilot: workload auto scaling at Google
[9] Improving Resource Efficiency in Cloud Computing

如果你喜欢这篇文章的话,别忘了 转发、收藏、留言互动!

还有,关注我!关注我!关注我!

![在这里插入图片描述](https://img-blog.csdnimg.cn/20200828155048172.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjAzMjQzMQ==,size_16,color_FFFFFF,t_70#pic_center)

大佬们分别是:
张晓龙——网易数帆轻舟技术总监。负责基础设施研发 /运维至今,在虚拟化、网络、容器、大规模基础设施管理以及分布式系统等技术架构有多年经验,当前主要兴趣点在云原生技术方向。
李岚清——网易数帆轻舟业务部资深系统开发工程师。具有多年Kubernetes开发运维经验,负责在/离线业务混部、容器网络编排等多个项目,推动和协助网易内部多个业务实现容器化。
陈林亮——网易数帆轻舟资深云计算开发工程师。具有多年云计算开发,运维及优化经验,参与开发网易云计算1.0至当前3.0多个云平台。目前专注在在/离线业务混部、容器编排资源优化等方向。

免责声明:文章版权归原作者所有,其内容与观点不代表Unitimes立场,亦不构成任何投资意见或建议。

云计算

537

Relevant articles

未登录头像

No more data