深入理解百度在离线混部技术( 三 ) _离线混部技术

离线调度器是一种离线任务专用的CPU调度算法，从调度器上分开，在线调度器看不到离线任务。在线调度器先于离线调度器进行任务调度，存在在线任务时，离线得不到调度。所以对于在线任务来说，可以达到混部前相近的CPU 质量。

文章插图

内存
Linux 系统会经常执行一些写日志、生成备份文件的工作，当这些文件比较大时相应的 cache 就会占用大量的系统内存，而且这些类型的 cache 并不会被经常访问，所以系统会定期将这些 cache flush 到磁盘中。Linux 会通过cache 回收算法进行回收。这会造成两个问题：

1.容器的 page cache 得不到回收，它依赖于容器管理 page cache 的机制是需要才去回收的方式，即没有后台回收，每次都是分配时候发现到达 limit 了，在 alloc 的时候出发回收，如果业务压力较大，分配的速度大于回收的速度，就可能出现 OOM 的问题

2.cache 回收时并不会区分在线离线业务，会导致在线业务的 cache 可能会被先于离线 cache 回收掉，如果在线有大量的读 cache 行为，会造成 cache 命中降低，直接进行读盘操作，会导致在线业务的性能下降，甚至会导致IO 夯住。

为了解决以上的问题，我们新增了背景回收机制，背景回收指的是异步回收 cache，根据在线离线的 QOS 不同，设置不同的背景回收水位，优先回收离线业务的 cache 。

文章插图

每个容器后台周期自动回收自己产生的 page cache
每个容器都可以设置开关和自己的高低水位线

网络层面我们也开发了容器级别的出入网带宽限制和流量打标等 Cgroup 子系统，可以对离线进行流量限制。

更多的内核隔离见下图：

文章插图

基于 eBPF 的动态策略
现有的内核隔离策略都是基于 QOS，创建容器时进行 cgroup 配置，由内核进行统一的资源管理，但是某些高敏业务在最高优先级的 QOS 下也无法保证其特定资源，或者需要某一纬度的资源需要高优保证，此时通用隔离策略无法满足。
【深入理解百度在离线混部技术】
另外由于隔离调度策略是全局统一的策略，业务如果想根据自身特点修改一些隔离能力，只能由业务反馈平台，平台对底层进行修改，周期较长，并且全局应用的隔离能力可能会对离线或者其他业务造成误伤，所以把隔离提升到用户态更符合业务需求。

针对这样的场景，由于 eBPF 稳定，安全，高效，并有可热加载/卸载 eBPF 程序，无需重启 Linux 系统的特性，我们基于 eBPF 开发了定制策略，可以实时下发，实时生效，侵入性小，不需要对业务既有服务和平台侧进行修改。可以在用户态针对某些业务进行定制化隔离策略更新，达到服务可以无差别混部的目标。
单机资源管理
在混部时，离线可以占用多少资源一直是一个问题。机型不同，在线服务的敏感度不同，离线业务占用的资源多少对在线造成的影响也不尽相同，针对这种情况，我们对集群纬度，池(具有相同特性的一批机器)纬度，节点纬度对离线可用资源上限做了限制，其中粒度最小优先级最高。

以 CPU 为例，如下图：

文章插图

我们设置了整机的 CPU 阀值X，当整机 CPU 用量趋近或超过一定用量，比如X=50%时，会压缩离线使用的CPU资源。

列举一个简单的公式：
Offline Quota = Host Quota * X - ∑NotOffline Used
Offline Free = Offline Quota - ∑Offline used

同样，对于 Memory，IO和网络我们也做了同样的限制。这样我们可以根据不同的机型和业务很方便的调整离线的用量，避免在线用量升高时性能受到影响。

3.4 高性能调度器
在线和离线业务的调度需求是不一样的，在线一般为常驻服务，不会频繁变更，对调度器要求较低。但是离线任务由于具有运行时间短(几分钟到几小时)，任务多的特点，以 K8s 默认调度器的调度性能不足以支撑离线任务的调度。所以我们开发了高性能的离线调度器，计算可以达到5000 ops 。