峰值利用率提升20%，携程离在线资源混部技术实践
周昕毅约 8 分钟一、资源混部技术
离线在线混部技术，顾名思义是指通过将在线服务（通常为延迟敏感型高优先级任务）和离线任务（通常为 CPU 消耗型任务、延迟不敏感）同时混合部署在同一个物理机节点，以期提升物理机的资源利用率。典型的在线服务包括搜索类型服务、web应用，一般白天在线业务流量高，和用户使用行为强相关。最典型的离线任务就是大数据分析和训练任务，此类任务往往是T+1day执行，凌晨启动对CPU算力的需求量很大，延迟不敏感。
随着新业务场景的不断涌现，云计算、大数据、人工智能等技术也随之不断演进发展，数据中心的服务器规模也随之不断增长。在线服务和离线作业都是数据中心资源消耗大户，资源混部技术期望能落地一套错峰资源调度的方式，来实现资源需求1+1<2。数据中心基础设施主要包括计算资源、网络资源、存储资源，其中CPU计算资源相对来说较为昂贵，且根据相关行业数据统计，服务器平均CPU利用率通常情况下低于50%，这也为离线在线资源混部技术的落地提供了空间。
携程在2016年落地了资源混部方案，如上图所示。Java和Nodejs等技术栈的Online服务部署在物理服务器和虚拟机器上，平均CPU利用率在20%-30%之间。基于Yarn调度框架提交的Spark / MapReduce等离线Job同样运行在物理服务器和虚拟机上，离线作业的特点是忙时CPU利用率达到90%以上，也有任务堆积排队的现象。为了解决离线作业堆积排队的问题，我们在凌晨会通过切换虚拟机角色的方式，从在线业务所在的虚拟机集群抢占一批资源用来运行离线任务。
二、携程第一代资源混部技术实践
第一代资源混部技术基于云平台的Openstack + KVM技术栈实现。KVM宿主机在日常时间仅运行Online服务的应用虚拟机。KVM宿主机单台CPU是64核，一般可以调度运行8台8核的虚拟机。宿主机的CPU利用率有着明显的波峰和波谷，凌晨1点-6点的在线业务高峰，宿主机CPU利用率平均小于10%。通过在OpenStack nova组件设置超额配置模式，宿主机在凌晨1点开始额外会拉起一台跑离线业务的虚拟机，启动Yarn node manager服务，注册到Yarn resource manager，供离线作业调度运行使用。离线虚拟机在凌晨6点自动销毁，避免在线业务流量上升后发生CPU资源争抢、影响在线业务的响应时间。该方案是基于CPU超卖实现，因此不具备完全的CPU隔离能力，在极端情况下也会对延迟敏感的在线业务造成影响。
随着在线应用容器化的推进，部署在线应用的宿主机也逐步从KVM资源池迁移到Kubernetes容器宿主机资源池，因此，资源混部的主战场也从KVM转移到容器宿主机资源池。迁移后的第一个混部的版本，除了调度器从OpenStack换成了Kubernetes、虚拟机镜像换成了容器镜像之外，其他和虚拟机的混部方案相比，没有太大区别。运行Yarn的离线容器镜像也做得比较重，通过固定ip的方式运行。由于容器化技术的天然优势，基于胖容器的混部技术的收益包括镜像维护和更新方便（Dockerfile & 自动化CI构建）、扩容速度从分钟级降低到秒级（<30秒）拉起。由于胖容器使用固定的规格进行调度，也依赖于CPU超分进行资源强制，隔离性也不是特别完备。但是凌晨在线业务低峰时能抢占到的CPU资源数量，让我们有动力推动方案的不断演进，遇到问题及时分析解决。
第一代离线在线资源混部技术面临着以下问题：
第一，资源隔离问题是混部技术面临的最大技术难点，尽管在online业务的低峰期CPU抢占发生的概率较低，但如果做不到彻底的资源隔离，混部的覆盖率和规模很难提升；
第二，网络带宽的额外需求，在线资源池和离线资源池如果物理位置分布在不同的机房，需要有控制跨机房带宽和交换机QOS降级的预案，否则就需要加大硬件资源投入、扩大跨机房的线路带宽等；
第三，如果KVM和Kubernetes宿主机在业务高峰、平均分配率和利用率都在较高的水位线时，混部可以利用的资源绝对值就比较低，混部资源规模会受限，不能稳定提供足够的算力资源时，离线job所在集群还是得采购物理服务器提升算力规模；
第四，第一代混部方案本质上是一个依赖人肉运维的方案，定时回收资源一旦失效，就会面临上午高峰online业务受到离线作业冲击的情况，没有自动降级的方案。
三、拥抱云原生
2017年，随着Linux基金会的 Jim Zemlin的一句“Kubernetes is becoming the Linux of the cloud”, 选择Kubernetes作为云原生技术落地的基石已经成为大势所趋。传统的大数据平台通常是指以Hadoop为中心的大数据生态技术，Hadoop集群主要的组件是HDFS分布式文件系统和以Yarn为调度系统的计算框架，周边有一系列软件协助进行数据的存储和计算，包括Hive、Spark、Flink、Kafka等。
2019年开始，主流的大数据开源框架也纷纷推出与Kubernetes的官方native继承，例如Spark/Flink/Kafka/Tensorflow等。传统大数据平台技术拥抱云原生的过程中，也面临了一些技术挑战，包括但不限于：机器学习训练任务存在Gang Scheduling的特殊调度需求；大数据作业数量很大，且频繁创建、删除，容器的交付吞吐量相比于在线应用而言指数级上升；云原生技术默认的版本一般是基于Online Serving的workload来做设计和调优，针对offline作业要做一些配置修改，部分场景下要对默认的quota限制做调整；网络IO和磁盘IO的性能瓶颈和隔离能力，是否能满足offline大作业运行时的资源需求等。
我们的离线在线资源混部技术也需要往云原生的方向演进，更好地和云原生化的调度、云原生化的应用交付、云原生化的大数据平台整体架构相融合，本着不影响在线业务的前提，最大化利用资源。
四、“云原生”资源混部技术的技术储备
为了落地新一代的资源混部技术，云团队和大数据平台团队需要进行相关的技术储备，具体介绍如下：
由于离线作业80%以上使用了Spark计算引擎，做混部之前首先要决策是走Spark on Yarn，还是Spark on K8S 的技术路线。Spark On K8S方案的优点是，Spark相关依赖的打包和发布更新可以实现容器化，资源管控的精细化程度Kubernetes比yarn更高，权限和API group等功能也是Kubernetes的天然优势。但是传统大数据平台的历史负担相对比较重，全面切换到Kubernetes做调度的话，资源quota系统、治理系统、队列管理系统都要做重构，毕竟Yarn统治了大数据workload调度超过十年时间，最终我们选择了折衷方案，部分新业务场景直接采用on K8S提交的模式，传统的Yarn node manager通过K8S进行容器化部署，大数据Spark作业还是通过on Yarn的方式提交。
为了给凌晨离线作业调度预留CPU资源，在线应用的HPA技术落地也是必须要做的技术储备。在线应用的使用方往往是终端用户，那么在线应用对于资源的需求量和实际使用率都会呈现出明显的潮汐现象。Pod 是 Kubernetes 体系中，承载用户业务workload的一种资源。HPA(Horizontal Pod AutoScaler)技术，旨在根据业务流量的大小自动调整Pod数量，忙时启动足够数量的Pod承载业务访问压力，闲时自动降低Pod数量、将资源池腾空留给其他在线应用或者离线解作业使用。在携程的业务场景中，在线应用的集群凌晨1点-6点是资源使用量的最低峰，该时间段正好是离线Job的资源需求最高峰，因此在线应用和离线作业可以完美结合、错峰运行。
为了让离线在线资源混部机制更好地运行，虚拟化网络技术以及宿主机内核技术也要做相应的准备。携程在这个阶段落地了基于Cilium的云原生网络新架构，下线了上一代云平台的集中式IPAM系统，提升了容器拉起的耗时。同时，云团队全面推进宿主机内核升级到5.10及以上版本，解决了数个已知的内核问题、同时也在尝试基于CgroupV2落地IO隔离能力，进一步避免运行高负载离线Job对于在线应用实例的影响。
在线应用在落地HPA机制之后，会存在一些突发流量的场景，需要在短时间内扩容出大量的实例抗住突发业务流量。此时，如果宿主机上的冗余资源已经分配给离线作业运行spark任务了，需要一种自动化的机制来秒级缩容离线作业的pod，腾出资源空间供在线应用使用。为了解决这个问题，云团队专门研发了抢占式调度器，对于宿主机上运行的pod进行基于优先级的抢占式调度，离线作业的pod由于对于延迟不敏感、且不直接影响终端用户体验，其优先级是最低的，被强制抢占之后、调度器会将该pod重新启动运行，相应的离线作业也会自动重跑。
通过在线应用集群混部离线job容器之后，Spark的Remote Shuffle Service技术可以有效改善离线job对于在线应用宿主机的IO压力，Remote Shuffle Service对于扩大离线在线混部的规模也是必要的技术储备。
五、“云原生”资源混部技术的落地实践
截止目前，携程云平台超过半数的机器都曾经参与过混部，混部机器的峰值利用率可以提升20%以上，混部计算资源支撑了大量离线任务的运行。后续我们的优化方向包括内核隔离的进一步优化，cgroup V2 IO隔离能力的落地，提升调度和离线作业运行状态的可观测性，持续助力云与大数据平台的整体降本增效。