谷歌Borg论文阅读笔记(一)——分布式架构

传说中,Borg之前号称是Google内部和PageRanking相提并论的同等重量级的东西。现在公布了篇论文,读了一部分,还是有些地方没理解。

求讨论。

Borg简介:

Borg的作用是:提供一个标准任务规格语言,集成名字服务,实时任务监控,以及工具来分析和模拟系统行为。

Google内部的集群管理系统调用都是用Borg来admits(准入),schedules(调度),starts,restarts,Borg还监控所有Google所有范围运行的应用。

Borg的好处:

  1. 隐藏资源管理和故障处理细节,让它的用户可以专注于应用开发。
  2. 高可靠性和高可用性。支持做相同事情的应用。
  3. 让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论文阅读笔记(一)——分布式架构

上一篇:java设计模式(四)--单例模式


下一篇:Go语言的几个注意点