传说中，Borg之前号称是Google内部和PageRanking相提并论的同等重量级的东西。现在公布了篇论文，读了一部分，还是有些地方没理解。
求讨论。
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映射到一组运行在机器上某个容器里的Linux进程集合。
所有在borg上跑的程序都是打成二进制包的，并且全部静态链接，不允许有依赖。
alloc(配额)：
alloc 是机器上的一组资源，一个或多个tasks能在里面运行。资源无论是否使用都会保持着。
这个指的就是一个容器。当然，每个alloc肯定只属于一个job。一组alloc组成一个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的部分运行机制：
任务分配:
1. 每个jobs都会被定级，最简单的是prod和non-prod两类。但其实有更细致的定级。比如同一个jobs中，master的级别会比worker高一点。
2. non-prod可能会被prod的任务抢占掉。即资源被剥夺。
3. 在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都是使用了共享存储的。
容量规划：
觉得Google的容量规划挺有意思的。
前面说了，cell是一个集群管理的单元。所以cell的规模需要进行容量规划。Google工程师的办法很简单粗暴，就是在相同的工作负载（不是系统负载）下减机器。看cell在减少了多少机器后，集群承受不了。
为了防止某些特殊情况，这种测试会做上10多次，每次减机器还必须是随机的（机器也有不同）。
这个容量规划没法直接在生产环境做，所以都是依托FauxMaster来做的。FauxMaster不是能读取BorgMaster的日志么，应该是把日志重放来模拟工作负载。
总结：
整个Borg系统就像是大型的操作系统一样。每个服务，包括在线的和离线的，都能被分解为Task，自动下发下去运行。不愧是大Google，领先行业10年。
总的来说，Borg的好处就是方便管理，省机器。为了省钱，Borg也是全部跑的容器，没有使用虚拟机。
不过，别的公司要想直接把这一套拿过来用，可能还是没那么简单。无状态的应用可以这么弄，但是有状态的，比如数据库这类的有状态的系统，恐怕还不能直接这么放上去。除非使用共享存储。不过，即时用了共享存储，有状态的问题还是不能完全解决，而且还会带来延时的问题。
恐怕最后还是要结合业务来。Google也是有特殊的服务跑在Borg外的。
推荐阿里毕大师关于borg的感想： http://hellojava.info/?p=411
转载请注明：云计算技术手札 » 谷歌Borg论文阅读笔记（一）——分布式架构