谷歌超大规模集群管理系统Borg详细解读

0. 前言

文本根据谷歌15年发表的论文整理得到，论文连接：http://research.google.com/pubs/pub43438.html

• Borg是谷歌内部的大规模集群管理系统，在谷歌内部经历数十年的打磨，应该是与谷歌三驾马车（MR,GFS,BigTable）的同时代产物，直到今天才发表论文公布其中的细节。
• 谷歌其实很早就宣称可以在同一个集群中同时调度在线任务和离线任务，足可见谷歌在科技方面要领先行业一大步。
• Kubernetes被任务时Borg的开源版本（研发团队有重合、功能简化聚焦、架构类似），很多工程师现在投身K8S的系统研究，推进K8S的发展。就在2019年5月4日，Twitter宣布弃用使用了长达数十年的Mesos系统，全面拥抱K8S，足可见K8S在目前云计算生态和环境下的重要地位。越来越多的服务以docker的方式进行运行通过K8S进行编排。

1. Abstract&Introduction

Borg是一个集群管理系统，上面运行着十万级的任务，数千个不同的应用，管理着数万台机器。其通过权限管理、资源共享、性能隔离等来达到高资源利用率。它能够支持高可用应用，并通过调度策略减少出现故障的概率，提供了任务描述语言、实时任务监控、分析工具等。

Borg主要有三大优势：

• 隐藏了资源管理和错误处理的细节，让用户关注应用的开发；
• 具备高可用性和高可靠性，并支持应用的高可靠和高可用；
• 能够在数万个节点上高效运行任务；
• 解读：易用性、可用性、可靠性、可扩展性、高利用率是所有云平台都需要解决的问题，Borg在这几个方面做得更好。

2. 用户视角

Borg的用户主要是谷歌的开发人员和管理人员，主要运行谷歌内部的应用和服务。用户以job的方式提交作业，一个job可以包含一个或多个task。每个作业运行在同一个cell中，cell是由一组机器构成的一个处理单元。

2.1 工作负载

• borg中运行的异构工作负载主要分为两类：长服务类型和批处理任务。长服务几乎不会停止，处理短期且延迟敏感的请求，例如gmail、web search、Google docs、bigtable等。批处理任务运行时间在几秒到几天不等，对短期的性能波动不敏感。这些工作负载混合部署在集群中。
• 很多应用框架已经运行在Borg上多年，包括内部的MapReduce、FlumeJava、Millwhell、Pregel。Google的分布式存储系统也都运行在Borg之上，包括GFS、BigTable、Megastore等。
• 论文将高优先级的作业称为“生产型作业”（prod），将其他作业称为“非生产型作业”（non-prod）。大部分长时间运行的服务都是生产型作业，生产型作业被分配了大约70%的CPU资源并占用了大约60%的利用率；同时被分配了大约55%的内存资源并占用了大约85%的内存利用率。
• 个人解读：谷歌通过prod和non-prod来对在线任务和离线任务进行区分，以达到混合调度的目标。

2.2 集群和单元

在谷歌集群中，通常包含一个大规模的cell和若干个用于测试或者特殊用途的小cell。cell的规模大约是10K个机器，其中的机器在资源大小、处理器型号、性能、容量等方面异构。

• 个人解读：cell是集群和机器的中间层，这种方式在实践中被广泛使用，通常一个集群中都会预留一部分资源作为测试集群。

2.3 job&task

一个Borg作业Job具有name、owner、task数量等属性。Job具有约束（constraint）来强制其任务运行在具有特定属性的机器上，例如处理器架构、OS版本、IP地址等。约束可以分为硬约束和软约束，前者是需求，必须满足；后者是偏好，尽量满足。每个任务，可以映射为一个container中的一组Linux程序。Borg绝大部分工作负载不运行在虚拟机中，这主要是由于虚拟机性能开销较大，此外一些硬件不支持虚拟化。

一个任务也具有属性，例如资源需求和task index。Borg程序采用静态链接库，以减少对运行环境的依赖，软件包中主要包括二进制程序和数据文件。 用户向Borg发送RPC用以操作作业。用户可以提交作业、查询作业ÿ