• 摘要
• 1. 引言
• 2. 用户视角
  • 2.1 工作负载
  • 2.2 集群和cell
  • 2.3 Job和task
  • 2.4 Alloc
  • 2.5 优先级、配额、管理控制
  • 2.6 命名和监控
• 3. Borg架构
  • 3.1 BorgMaster
  • 3.2 调度器
  • 3.3 Borglet
  • 3.4 可扩展性
• 4. 可用性
• 5. 利用率
  • 5.1 评估方法
  • 5.2 cell共享
  • 5.3 大cell
  • 5.4 资源请求力度
  • 5.5 资源再利用
• 6. 隔离性
  • 6.1 安全隔离
  • 6.2 性能隔离
• 7. 相关系统
• 8. 经验教训与未来
  • 8.1 不足
  • 8.2 优点

摘要

Google的Borg是个集群管理系统，在它上面运行这上千个不同的应用，这些应用被拆分为几十万个job运行在多个集群间。每个集群有上万的机器。

它通过整合控制、高效的任务打包、超售和进程级别的性能隔离来实现高利用率。支持高可用应用程序运行，尽量减少故障恢复时间，减少相关故障概率的调度策略。Borg通过提供声明式Job配置语言、名称服务集成、实时Job监控、分析和模拟系统行为给使用者提供了便利。

论文结构：

[TOC]

1. 引言

Borg 负责管理Google相关应用的调度、启动、重启和监控

Borg系统带来的好处：

1. 隐藏资源管理和故障处理细节，使其用户可以专注于应用开发
2. 在操作和程序运行上保证高可用
3. 程序在数以万计的机器上高效运行

2. 用户视角

Borg的用户是Google开发人员和系统管理员。用户以Job的方式提交他们的运行请求

2.1 工作负载

• Pod：长期运行、请求-响应耗时敏感的应用，如Google搜索、Gmail、Google Docs等
• Non-pod: 批处理任务，比如MapReduce

2.2 集群和cell

一个Cell里面的所有机器都属于单个集群，集群是由高性能的数据中心级别的光纤网络连接起来的。一个cell管理大约一万机器

2.3 Job和task

一个Job属性包含名称、拥有者、几个task。Job可以有些约束处理器架构、OS版本、需要外网IP。Job运行依赖关系

Task 也有属性，包括资源用量，在job中的索引。

Borg运行程序是静态链接，减少运行时对环境的依赖，这些程序被打包成可执行的二进制文件。

用户通过RPC或者命令行工具（常用方式）将Job提交到Borg，大多数job描述文件使用的声明式配置语言BCL编写。

Job和task生命周期

2.4 Alloc

资源管理程序，程序在停止task和重启之前保持资源；聚集不同job的任务到同一台机器运行。同一个Alloc下的task共享资源，当Alloc转移到机器时，那么task也跟随重新调度

2.5 优先级、配额、管理控制

每个job都有优先级，（0-11， 2019年跟踪数据显示已调整为0-450）。优先级高的task可以优先分配资源即使它被kill掉。

2.6 命名和监控

Borg把task的主机名和端口写入到一个持久化高可用文件里，以BNS名为文件名，放在Chubby上

BNS task的DNS，cc cell的ubar用户的jfoo job的第50个task的DNS名称会是50.jfoo.ubar.cc.borg.google.com

几乎所有的task 都内置一个http服务，用于发布健康信息和几千个性能指标

3. Borg架构

3.1 BorgMaster

BorgMaster包括两个进程：主进程和调度进程

主进程负责处理客户端的RPC请求；提供数据读取服务；管理所有的组件，和Borglet通讯，提供webUI

BorgMaster有五个副本，每个副本都在内存中维护cell状态数据，选举、副本恢复自动拉取最新状态数据。

支持快照、恢复以及快照重放。便于Debug

3.2 调度器

任务提交持久化到paxos，然后将任务放到一个pending 队列。这个队列被一个异步的进程扫描，将任务分发到有充足资源的机器上面执行。在同一个优先级内采用轮训方式。调度算法分两部分：可行性检查和打分。

• 可行性检查阶段，找到一组满足task约束和有足够资源的机器（包括低优先级运行占用的资源）
• 打分，参考因素有：用户的偏好，其他内定标准比如：尽量不影响其他任务，任务的程序包已经存在的机器，尽可能分散到跨电源和故障域，尽量保证单个机器高/低优先级任务都有使得高峰期时方便扩容。

Borg 刚开始使用的E-PVM算法来打分，不同的资源生成单一的分数，在调度任务尽量最小化对系统的改变，但是在实践中，E-PVM将任务平均分配到所有的机器，把扩容空间留给高峰期扩容，这样导致了大量的资源碎片化，特别是巨型任务需要大量机器的时候。

这种方式的另一个极端是尽量压缩每台机器的资源，这会影响到事先对自己资源使用预估不足的应用，并且对需要低CPU的批任务不友好。

目前的打分模型是混合的，试图减少搁浅的资源。

如果一台机器的打分没有足够的资源运行任务时，Borg会驱逐低优先级的任务，直到资源够用。被踢的任务任务会放到pending队列中，而不是迁移或者休眠它们。

启动耗时一直持续关注，这个耗时差距很大，一般情况需要25s。包安装花费了80%的时间，一个已知的瓶颈是在包安装过程中本地磁盘的抢占。scheduler希望机器上有足够的包，大部分包是只读的可以共享和缓存。此外包的下载采用BT下载协议

3.3 Borglet

Borglet部署在每台机器上，是Borg的代理程序，负责启停任务、通过修改内核管理资源、滚动debug日志、将本机状态上报到Borgmaster或者其他监控系统。

状态上报是被动的，这种方式可以控制沟通频率、避免拥塞控制、避免恢复时的雪崩。

为了性能可扩展，Borg Master会将固定的Borglet分配给某个副本处理（重新分配会在选举的时候触发），master主要负责状态的更新。副本会对状态数据进行聚合和压缩

容错处理：如果Borglet几次没有响应轮询请求，将会被标记为挂了，然后将上面跑的任务重新分配到其他机器运行，当Borglet恢复时，Borg master会让Boglet杀掉已经分配出去的task。

3.4 可扩展性

单个BorgMaster可以管理一个cell里面几千台机器，几个cell可以一分钟处理10000个任务。做了哪些优化：

• 将scheduler独立成一个进程，和其他BorgMaster功能并行运行。scheduler重复：从master获取状态变化信息；更新本地拷贝；调度分配task到机器运行；将分配信息通知到master。
• 为提高响应时间，增加一些线程和Borglet通讯、处理只读RPC请求。为了更高的性能，将这些事分享(分区)给5个Borgmaster副本处理
• 分数缓存，直到机器或者任务改变，忽略小的资源变化
• 等价处理，对于相同需求一组task，Borg只进行一次可行性和打分
• 适当随机，一个大的Cell里面的所有机器都去衡量一遍可用性和打分是比较浪费的，随机找到足够多的机器就停止打分，从找到的机器中找最优解

实验中，调度整个cell里面的workload需要花费几百秒，但是不使用上述技术需要3天以上的时间。正常情况，一个调度从任务pending到running只需半秒时间。

4. 可用性

Borg期望应用具备这些能力：支持副本、数据持久化到分布式存储、定期快照。

• 在一台新机器上面调度被驱赶的task
• 将一个job的任务分散到不同的可用域
• 在机器或者OS升级时，降低同一时刻一个job的关闭率
• 使用声明式的期望状态和幂等操作，这样有故障的任务可以无损重新处理遗忘的请求
• 对于不可达的机器上面的任务重新调度率要有限制，因为很能区分是大规模的机器故障还是网络故障
• 避免task::manhine 匹配，task可能会是特定的机器挂掉
• logsaver任务将数据写到本地，后期可恢复

5. 利用率

5.1 评估方法

主要通过cell compaction，即：给定作业压力，缩减机器，直到不能缩减为至。这里通过Fauxmaster来直接镜像线上的机房，从而再测试环境进行测试。通过实验，可以很明显的看出，更好的调度策略需要的资源更少

5.2 cell共享

几乎所有的机器都同时跑着prod和non-prod的task。中等大下的cell把两者分开需要增加20-30%的机器。

主要是因为prod的作业会预留很多资源，如果将预留的空闲资源临时分配给non-prod作业，就会节省很多资源。

池化思想

5.3 大cell

大cell更省资源

5.4 资源请求力度

Borg支持千分之一CPU、bytes级别的磁盘和内存，这样会更加的节省资源。

5.5 资源再利用

一个作业可以指定一个limit，表示它会被授予资源的上限。为了合理利用申请但没使用的资源，borg会评估作业实际使用，并且把剩余资源留给batch作业来使用，这被称为资源回收（resource reclamation），评估值被称为reservation，每隔几秒钟计算一次。

6. 隔离性

6.1 安全隔离

使用Linux chroot隔离

6.2 性能隔离

一开始使用监听资源，终止使用过多的资源的task。

目前通过Borglet修改OS内核参数（ Linux cgroup-based）

为了缓解过载，Borg task定义了应用级别（appclass），用与区分是否是延迟敏感型任务，延迟敏感task拥有优待权。

区分可压缩资源（比如CPU，磁盘IO速率）这个可以通过降低速率回收资源无需kill task；不可压缩资源（比如内存，磁盘）这种回收只能通过kill task到达目的。如果一个机器的不可压缩资源耗尽，Borglet会开始从优先级低的task开始kill直至自留资源够。如果一个机器的可压缩资源被耗尽，Borglet会卡住使用率当短期高峰来临时可以不用kill task。如果情况没有改善BorgMaster会移除一个或多个task。

7. 相关系统

• Apache Mesos
• YARN
• 伏羲

8. 经验教训与未来

8.1 不足

• Job是task的唯一分组不灵活，在k8s引入了label
• 所有容器共享机器的IP。这会导致port管理的复杂，比如分配、隔离、耦合等。为此，k8s支持了pod和service都自定义IP（得益于Linux namespaces, VMs, IPv6, and software-defined networking）
• 给资深用户优化而忽略了初级用户。复杂的API接口（BCL有230个参数）

8.2 优点

• Allocs是有用的，k8s里面的pod相当于allocs，是一个多容器共享的资源封装
• 集群管理多于作业管理。尽管borg也是一个作业管理系统，但是它了更多的集群管理功能，包括dns、负载均衡、pod deployment等
• 提供丰富的作业运维工具，比如log读取、事件记录等，尽可能将内部细节运行细节暴露给用户，因为用户太多了不可能帮他们一个一个排查问题
• 将master节点的组件进行功能拆分，核心是borgmaster。k8s则是将API server作为master核心，其他像replication controller、node controller则作为微服务与API server交互