深度译文｜Google的大规模集群管理系统Borg

编者按：本文是对Google在分布式底层架构的经典文章的翻译，原文可以查看这里，由于原文较长，建议先收藏本文，再下载英文原文，对照译文仔细阅读，可事半功倍。

摘要：Google的Borg系统是一个运行着成千上万项作业的集群管理器，它同时管理着很多个应用集群，每个集群都有成千上万台机器，这些集群之上运行着Google的很多不同的应用。Borg通过准入控制，高效的任务打包，超额的资源分配和进程级隔离的机器共享，来实现超高的资源利用率。它通过最小化故障恢复时间的运行时特性和减少相关运行时故障的调度策略来支持高可用的应用程序Borg通过提供一个作业声明的标准语言，命名服务的集成机制，实时的作业监控，以及一套分析和模拟系统行为的工具来简化用户的使用。

我们将通过此论文对Borg系统的架构和主要特性进行总结，包括重要的设计决定，一些调度管理策略的定量分析，以及对十年的使用经验中汲取的教训的定性分析。

1.简介

图1 Borg的高级架构。仅显示了成千上万工作节点中的一小部分。

这个在我们内部称为Borg的集群管理系统，它负责权限控制、调度、启动、重新启动和监视全部的Google中运行的应用程序。本文将解释它是如何做到的。

总的来说，Brog主要提供了三个主要的好处：（1）隐藏资源管理和故障处理的细节，因此其用户可以专注于应用程序开发; （2）提供高可靠性和高可用性操作，支持的应用也是如此; （3）使我们能够有效地在数万台机器上运行工作负载。 Borg不是解决这些问题的第一个系统，但它是在能够保证最大弹性和完整性情况下，以大规模运行的少数几个系统之一。 本文将主要围绕这些主题进行组织，并从Borg投入生产，这十多年来的使用经验作为总结 。

2.用户视图

Borg的用户是运行Google应用和服务的Google开发人员和系统管理员（网站可靠性工程师或SRE）。 用户以作业的形式将他们的工作提交给Borg，每个作业包括一个或多个任务，它们都运行相同的程序（二进制）。 每个作业在一个Borg单元中运行，一组机器组织为一个单元。 本节的剩余部分描述了Borg用户视图中展现的主要功能。

2.1 工作负载

Borg的所有单元都同时运行着两种类型的异质工作负载。第一个是“永远运行下去”的长服务，他们对延迟和性能波动敏感， 此类服务用于面向终端用户的产品，例如Gmail，Google文档，web搜索和内部基础设施服务（例如，BigTable）。 第二个是批处理作业，需要花费从几秒到几天完成，这些任务对短期性能波动的敏感性要小得多。 这些工作负载混合运行在Borg的各个运行单元中，其根据其主要租户（例如，一些单元是专门用来运行批量密集任务的）运行不同的混合应用，并且也随时间变化：批处理作业完成和重新运行，许多面向终端用户的服务作业看到日常使用模式。 Borg同样需要处理好所有这些情况。

Borg的代表性工作负载情况可以从2011年5月的一个公开的月份跟踪中找到[80]，已经进行了广泛分析（例如[68]和[1,26,27,57]）。

在过去几年中，许多应用程序框架已经建立在Borg之上，包括我们内部的MapReduce系统[23]，FlumeJava [18]，Millwheel [3]和Pregel [59]。 大多数都有一个控制器提交一个主作业和一个或多个工作作业; 前两者对YARN的应用程序管理器[76]起类似的作用。 我们的分布式存储系统如GFS [34]及其后继CFS，Bigtable [19]和Megastore [8]都运行在Borg上。

对于本文，我们将优先级较高的Borg作业分为“生产”（prod）作业，其余作为“非生产”（non-prod）作业。 大多数长期运行的服务器作业是prod;大多数批处理作业是非prod的。在代表性单元中，分配给prod作业大约总CPU资源的70％，大约占总CPU使用量的60％; 分配给它们约总内存的55％，约占总内存使用的85％。在§5.5节，将看到分配和使用之间的差异将是很重要的。

2.2 集群和单元

单元中的机器属于单个集群，由连接它们的高性能数据中心规模的网络架构定义。

一个集群位于单个数据中心大楼内，大厦集合构成一个站点。一个集群通常承载一个大型单元，可能有一些较小规模的测试或特殊用途单元。 我们努力避免任何单点故障。

中央单元大小是排除测试单元后约10k机器; 有些会更大。一个单元中的机器在许多维度上是异构的：大小（CPU，RAM，磁盘，网络），处理器类型，性能和功能（比如外部IP地址或闪存存储器）。Borg通过确定单元中的运行任务，为任务分配资源，安装程序和其他的依赖，监控任务状态并在失败时重启，将用户从大多数差异中隔离出来。

2.3 作业和任务

Borg作业的属性包括名称，所有者及其拥有的任务数量。作业可能具有限制，使其任务在具有特定属性（例如处理器体系结构，操作系统版本或外部IP地址）的计算机上运行。限制可以是硬的或软的; 软限制就像是偏好而不是要求。作业的开始能被推迟到直到前一个作业完成。 一个作业仅在一个单元中运行。

每个任务映射到在机器上的容器中运行的一组Linux进程[62]。 大多数Borg工作负载不在虚拟机（VM）内运行，因为我们不想支付虚拟化的成本。此外，该系统是在我们对没有硬件的虚拟化支持的处理器进行大量投资的时候设计的。

任务也具有属性，例如资源需求和任务在作业中的索引。 大多数任务属性对作业中的所有任务是相同的，但是可以被重写 - 例如，以提供指定任务的命令行标志。每个资源维度（CPU核，RAM，磁盘空间，磁盘访问速率，TCP端口，等）以细粒度独立指定; 我们不强加固定大小的桶或槽（§5.4）。静态链接Borg程序以减少对其运行时环境的依赖，并且Brog程序被打包为二进制文件和数据文件，由Borg负责安装。

用户通过向Borg发出远程过程调用（RPC）来操作作业，最常见的是通过命令行工具，其他Borg作业或监视系统（§2.6）。大多数作业描述都是用声明性配置语言BCL编写的。BCL是GCL的一个变体[12]，它生成protobuf文件[67]，并扩展了一些Borg特定的关键字。GCL提供lambda函数以允许计算，应用程序可以使用它们来调整环境配置; 成千上万的BCL文件超过1k行长，我们已经积累了数千万行的BCL。Borg作业配置与Aurora配置文件相似[6]。

图2说明了作业和任务在其生命周期中经历的状态。

图2：作业和任务的状态图。 用户可以触发提交，终止和更新转换。

用户可以通过推送新的作业配置到Borg，再指示Borg将任务更新到新配置，来更改正在运行的作业中的某些任务或所有任务的属性。 这是一个轻量级的非原子事务，可以很容易地被撤销，直到它被关闭（提交）。 更新通常以滚动方式完成，并且可以对更新导致的任务中断（重新计划或抢占）的数量加以限制; 跳过会导致更多中断的任何更改。

某些任务更新（例如，推送新的二进制）总是需要重启任务; 某些更新（例如，增加的资源需求增加或约束改变）可能使得任务不再适合于这台机器，将导致任务停止并重新调度; 而某些更新（例如，改变优先级）却可在不重新启动或移动任务的情况下进行。

任务可以要求在被SIGKILL抢占之前通过Unix SIGTERM信号获取通知，这样任务就有时间进行清理，保存状态，完成当前正在执行的请求并拒绝新的请求。 如果抢占者设置延迟界限，则实际通知可能更少。 在实践中，通知传递约80％的时间。

2.4 分配

Borg alloc（分配的简称）是可以运行一个或多个任务的机器上的一组保留资源;无论资源是否被使用仍然被分配。Alloc可以用于为将来的任务设置资源，在停止和重启任务之间保留资源，以及将不同作业中的任务收集到同一台机器上 - 例如，Web服务实例和相关的日志保存任务， 这个任务将服务的URL日志从本地磁盘复制到分布式文件系统。 alloc的资源以类似于机器资源的方式处理; 多个任务运行在一个alloc中，共享其资源。如果一个alloc必须重定位到另一台机器，它的任务将被重新调度。

一个alloc集合就像一个作业：它是一组在多个机器上预留资源的alloc。 一旦创建了一个alloc集，可以提交一个或多个作业在其中运行。 简单期间，我们一般会使用“task”来引用alloc或顶层任务（在alloc之外的）和“job”来引用一个作业或alloc集。

2.5 优先级，配额和接纳控制

当更多的工作出现而超过可容纳的限度时会发生什么？我们的解决方案是优先级和配额。

每个作业都有一个优先级，它是一个小的正整数。高优先级任务可以以牺牲低优先级任务为代价而获得资源，即使这导致抢占（杀死）后者。Borg将不同种类的作业分为不同的领域，并给每个领域定义了不重叠的优先权重，这些作业组包括：监视作业，生产作业，批处理作业和尽力而为的作业（已知的包括测试程序），他们的优先级依次递减。对于本文，prod作业是监测和生产领域的工作。

虽然被抢占的任务通常将被重新安排在单元中的其他地方，抢占级联可能发生，如果高优先级的任务碰到一个略低优先级的任务，而这个略低优先级任务又引发另一个略低优先级的任务，等等。为了消除大部分这种情况，我们不允许生产领域中的任务相互抢占。 细粒度优先级在其他情况下仍然有用 - 例如，MapReduce主任务以比他们控制的workers更高的优先级运行，来提高其可靠性。

优先级表示单元中正在运行或正等待运行的作业的相对重要性。 配额用于决定允许进行调度的作业。 配额表示为在给定优先级上的一段时间（通常为几个月）内的资源量（CPU，RAM，磁盘等）的向量。 数量指定用户的作业请求可以一次请求的资源的最大量（例如，“从现在直到7月底在单元xx中的prod优先级的20TiBRAM“）。 配额检查是许可控制的一部分，而不是调度：配额不足的作业立即拒绝提交。

较高优先级配额的成本高于较低优先级配额。生产优先级配额仅限于单元中可用的实际资源，因此，提交符合配额的生产优先级作业的用户可以预期运行。 即使我们鼓励用户购买的配额不超过他们的需求，但是许多用户仍然过度购买，因为这帮助他们在应用程序的用户群增长时克服不足。我们通过在较低优先级别上过度销售配额来响应这一点：每个用户具有在优先级零的无限配额，尽管这常常难以执行，因为资源被过度订阅。一个低优先级作业可能被允许了，但是由于资源不足而保持等待（未调度）。

在Borg以外进行配额分配，并且与我们的物理容量规划密切相关，其结果反映在不同数据中心的配额的价格和可用性上。 仅当用户作业具有所需优先级的足够配额时，才允许用户作业。 配额的使用减少了对优势资源公平（DRF）[29,35,36,66]等策略的需要。

Borg有一个能力系统，能给予一些用户特殊的权限; 例如，允许管理员删除或修改单