Borg论文翻译及理解

Borg论文翻译及理解

1. Abstract

Google的borg使用大量机器支持着数千个应用的10W个作业，其中部分单个集群规模超过万台机器。

其通过

1. Adminition control
2. Task-packing
3. Over-commitment
4. Machine sharing with process level isolation

提供

• Declarative job specification lauguage
• Naming service integration
• Real time job monitoring
• Tools to analyze and simulate system behavior

2. Introduction

Borg 主要得益于三点：

1. 他隐藏了Resource Management以及Failure Handling的细节，所以保证他的用户可以focus在应用开发本身。
2. 其本身就具有高可用性以及高可靠性，与此同时，也保证运行其上的应用具有同样的特性。
3. 很好的保证我们可以在数万台机器上运行应用。

Borg当然不是第一个提出这些问题的软件，但是的确是第一个在如此规模运行的软件。

3. 用户眼中的Borg

在Google开发工程师眼中，他们将作业提交到Borg，Borg将他们的作业运行在Borg Cell中。每个Borg Cell可能有多达上万台机器构成。本节主要介绍在开发者眼中的borg。

3.1 Work Load

Borg支持异质的workload，其主要包括两种：

• 一种是never goes down Service 如 Gmail Google Doc，这些服务是latency-sensitive的（ms level）
• 另外一种是Batch Job 如Mapreduce作业。这些任务可能运行几天后完成，这些相比之前的服务对延时并没有那么敏感。

在此文当中，我们将高priority任务称之为Prod（production），其他的则称为non-prod。大部分第一种任务是prod任务，而batch任务大部分则为none-prod任务。

在一个典型的Cell中，prod类型任务占有70%的CPU资源，并利用了其中的60%，同时占用了55%的内存，并使用了其中的85%。

3.2 Clusters and Cells

一个Cluster往往用于描述处在同一个机房中的一部分机器，一个Cluster往往具有个Cell，部分Cluster还具有Test Cell以及其他具有其他功能的Cell。

一般一个中等规模的Cell具有1w个左右的机器，而且其中的机器并非同构架机器，可能different in cpu mem dist network。但Borg屏蔽了这些特异性，对于developer而言，一切都是一样的，包括故障处理，监控以及依赖等等。

3.3 Jobs and Tasks

每个Job在一个Cell中进行执行，与此同时，可以为每个job分配名字，以及该job希望其所属的task执行的环境（包括CPU类型，IP，System arc等等）。

每个job在执行过程会会映射到多个机器的多个进程上。值得注意的是，大部分作业并没有映射到一个虚拟机上，因为我们不希望因为虚拟机的原因付出更多的资源，另一个原因是Borg产生在一个虚拟化还不那么流行的年代-。-！

对于每个task而言，每个task同样可以指定希望执行的环境，当然，其中但部分内容还是继承自job，但允许被overriden。在每个机器上，我们并不使用类似slot的方式约定每个机器上可执行的task数量。Borg程序在运行环境被静态链接了以减少执行依赖，且这些borg程序会以package或者binary file的形式由Borg系统进行传递。

对于每个borg程序，Borg具有监控工具以及commandline供需以支持用户对自己的job进行操作以及监控。大部分作业描述是以BCL的方式进行描述的，该方式类似GCL，同时BCL也支持lambda函数。图2展示了job的生命周期

对于一个运行中的Job而言，用户可以通过向Borg推送一个新的配置文件来对Job的（配置、属性、甚至执行文件）进行更改，而后命令Borg针对新的配置文件update。这种update是一种轻量级的非原子性的操作，因此在完成之前很容易被撤销。其中一些更新可能需要task重启，而一些更新使得job不再适配原来所在的机器，因此这些job会被停止并reschedule，而其他一些任务则可以直接继续执行。

这些task会首先通过Unix的 SIGTERM进行通知，而后进行SIGKILL。所以他们有时间进行 clean up，save status，完成请求响应以及拒绝新的请求。

3.4 Alloc

对Borg而言，Borg Alloc是机器上被预留出的一批资源，从而保证真正的task可以运行在其中。因此alloc可以用于预留出一部分资源给未来的task，或者在task重启的过程中为其一直保持资源，还或者把运行在不同机器上的task移动到一起。

对于Alloc中的资源的使用，如同一台机器一样，如果有多个任务在一个alloc中，则他们会共享其中的资源。

因此Alloc set更像是一个job，一大堆alloc在不同的机器上都预留了资源。当alloc set被建立之后，一个或者多个任务就可以在alloc set中进行执行。

为了简洁起见，我们用task来表示单个的alloc或者alloc其中运行的任务，而使用job来表示一个alloc set 或者大型的运行其中的任务。

3.5 Priority, quota, and admission control

在多任务管理过程中，我们主要使用优先级以及quota（配额）对作业进行控制。

对每个任务而言，我们都使用一个整数来表示其优先级。相比较而言，高等级的任务更容易获得资源，甚至不惜以杀掉低等级的任务为代价。在Borg中，我们使用非重叠的优先级策略（从高到低）：Monitoring，Production，batch，以及best effort（即test 或者free）。在本文中我们所指的prod类型程序即为monitoring或者production级别。

同时，严格的等级问题以及允许kill可能会带来优势震荡（preemption cascades），即：在一个机器上，Monitoring级的task为了资源，试图kill一个prodcution级的任务，而后者为了资源继续kill一个batch类型task，从而导致对资源的大量浪费。
为了处理此类问题，我们禁止了production level 及之上级别的任务的kill掉同级任务的情况。

这种细粒度的priority还是有好处的，比如MR master的的优先级就会比MR worker稍微高一点。

priority表示运行以及等待中作业的优先级，用于解决作业之间的竞争关系。此外还是用配额（Quota）对每个Cell进行了限定。配额的概念更像是硬性要求（Admission Control）而非调度算法。Quota的表示形式是使用一个Vector的资源限定（CPU，内存硬盘），例如“20TiB of RAM at prod priority from now until the end of July in cell xx”。无法满足该需求的job会在提交的时候就被拒绝。

其实在使用priority时就存在这样一个问题，如果高priority的job可以kill低priority的job，会不会所有user都申请尽可能高priority的job呢？所以，针对同样地资源，高权限的quota cost more than 低权限quota。而且会对高权限的quota资源有限（例如production权限的计算资源只占整个Cell的20%，而更低权限的计算资源Quota可能更多）。我们鼓励用户在申请资源的时候仅仅足够运行的资源，而非申请额外富裕的资源。但还是会有很多用户overbuy资源，因为这样可以杜绝在未来因为用户的增长而增长的资源使用。

对于最低权限的作业，其具有无限的quota。然并卵，很多时候底level的作业可能虽然通过了quota审核，但是却因为没有实际资源而无法被调度上cell。

对于Quota如何分配的问题，是在Borg之外进行的。而且这与机器，以及我们对机器的预期密切相关。更多请去看参考文献[29, 35, 36, 66]

3.6 Naming and monitoring

当然仅仅是