- A+
传说中，Borg之前号称是Google内部和PageRanking相提并论的同等重量级的东西，现在公布了论文。
Kubernetes是Borg的开源实现。
Borg简介
Borg的作用是：提供一个标准任务规格语言，集成名字服务，实时任务监控，以及工具来分析和模拟系统行为。
Google内部的集群管理系统调用都是用Borg来admits(准入)，schedules(调度)，starts，restarts，Borg监
控了所有Google所有范围运行的应用。
Borg的目标
- 隐藏资源管理和故障处理细节，让用户可以专注于应用开发。
- 高可靠性和高可用性。支持做相同事情的应用。
- 让Google成千上万的机器运行在有效的工作负载。
名词解释
先列一下Borg中的一些高大上的名词。
job（服务）
Borg的job对应的是一整套服务。比如Gmail，Bigtable这样的服务，有直接面向用户的，也有内部服务。整套服务包括了服务中的master和worker，它们全部都跑在job上。
Borg jobs的属性包括： 名字，所有者，tasks的数量。jobs能强制tasks运行在特定的机器上。比如，指定处理器架构，OS版本，或者是一个外部IP地址。可以硬约束或者软约束。软约束更像偏好，而不是需求。
job根据优先级分类为两大类
production(prod)：高优先级的job，一般是那些对响应延时要求比较高的。比如Gmail这种直接用户交互的服务。
non-production(non-prod)：相对与高优先级job而言，优先级较低的job，大部分是批处理服务。
cell(机器集合)
Each job runs in one Borg cell, a set of machines that are managed as a unit.
每个job都运行在一个cell上，这是一组机器，作为一个管理单元。
cell这块，我一直没理解。主要是第一句，每个job运行在一个cell上。一开始理解为一个cell对应一个job。但是后面觉得不对啊，如果一个cell就一个job，则没有混部的必要。所以这个应该是说，一个job只运行在一个cell中，一个cell能运行多个job。（不知到这个理解对不对，望知道的人解答。）
那么，cell就应该是一个逻辑上的集群概念。一个物理集群可能有一个或多个的cell，大多情况应该只有一个cell。（貌似中等的cell是10w台机器的规模）
论文中也提到，他们建议cell规模不应过大，适当的保持一定规模，宁可设置多个cell，这样可以减少故障和误操作的影响。有点类似淘宝现在的单元化设计。
tasks(任务)
task是服务在机器上的实体进程。每个task映射到一组运行在机器上某个容器里的Linux进程集合。
所有在borg上跑的程序都是打成二进制包的，并且全部静态链接，不允许有依赖。
每一个tasks只属于一个job。
alloc(配额)
alloc 是机器上的一组资源，一个或多个tasks能在里面运行。资源无论是否使用都会保持着。
这个指的就是一个容器。当然，每个alloc肯定只属于一个job。一组alloc对应一个job。alloc是task的资源配额,alloc set是job的资源配额。
BorgMaster（Borg的管理系统）
BorgMaster是集中化的管理系统。使用paxos组成的管理系统。选主出一个BorgMaster后，由BorgMaster负责操作。
类似于一套状态管理机。元数据并没有存在这里，元数据放在Chubby上，选主出来的master会获得Chubby的锁。属于一种，单点写入多点读取的架构。
Scheduling（Borg任务调度系统）
这个是从BorgMaster分离出来的部分，专门做任务分发的任务队列。BorgMaster在判断task可以加入，就会把task加入到Scheduling中。scheduler会异步扫描它，然后分配task到合适机器上。
异步处理，减轻BorgMaster的压力，也缓解故障的影响。
Borglet（Borg客户端）
在每个主机上负责操作的进程。负责给borg提供各种监控，配置信息。接受borgmaster的指令进行各种操作。
FauxMaster（Borg模拟器）
FauxMaster是BorgMaster的模拟器，可以读取BorgMaster的日志文件，然后重现出BorgMaster的场景。
主要用于调试BorgMaster，以及容量规划。
Borg的部分运行机制
任务分配
- 每个jobs都会被定级，最简单的是prod和non-prod两类。但其实有更细致的定级。比如同一个jobs中，master的级别会比worker高一点。
- non-prod可能会被prod的任务抢占掉。即资源被剥夺。
- 在borg中，为了防止用户故意多申请资源而造成浪费，所以borg的non-prod是超卖的。当然，是时候会被回收掉。
通信机制
Borg的通信机制是使用的HTTP协议。包括任务分发以及日志采集，全部采用的是HTTP协议实现。不知道是不是Borg开发者借鉴了Unix程序设计艺术里说的文本化传输。
Borg的心跳等探测，都是BorgMaster去扫描Borglet的，为的是防止failover时，造成通信风暴，也能让BorgMaster控制压力。在Borg开发者的优化下，大概一个集群扫描完只需要10多秒。
BorgMaster中，Master不会直接去链接Borglet，而是Slave去收集Borglet，然后合并，把增量传递给Master。以减少Master的压力。
程序容灾
整个Borg就像一个大型操作系统。在分配过程中，Borg也会自动把同一个job的Task分摊开，比如不放在同一台服务器，不放在同一个机架上。以减少故障带来的影响。
此外，Borg也会自动迁移和重启挂了的任务。如果一台主机宕机了，那么主机上的任务就会被重新分配到新的机器。如果主机失联，断开一会之后，又链接回来了。此时，如果主机上的任务已经被迁移到新的机器上了，这个机器上的任务会被Borglet给干掉。
大多数应用程序存储计算分离。所以可以随时启动和kill掉。Google的应用大多都使用了共享存储GFS。
容量规划
Google的容量规划也是非常有创意的办法。
前面说了，cell是一个集群管理的单元。所以cell的规模需要进行容量规划。Google工程师的办法很简单粗暴，就是在相同的工作负载（不是系统负载）下减机器。看cell在减少了多少机器后，集群承受不了。
为了防止某些特殊情况，这种测试会做上10多次，每次减机器还必须是随机的（机器也有不同）。
这个容量规划没法直接在生产环境做，所以都是依托FauxMaster来做的。FauxMaster不是能读取BorgMaster的日志么，应该是把日志重放来模拟工作负载。
学习总结
- 整个Borg系统就像是大型的操作系统一样。每个服务，包括在线的和离线的，都能被分解为Task，下发到服务器运行。
- Borg团队使用了模拟器FauxMaster来模拟负载，用于容量规划。
