谷歌Borg论文阅读笔记(一)—— 集群操作系统

传说中,Borg之前号称是Google内部和PageRanking相提并论的同等重量级的东西,现在公布了论文
Kubernetes是Borg的开源实现。

Borg简介

Borg的作用是:提供一个标准任务规格语言,集成名字服务实时任务监控,以及工具来分析和模拟系统行为。
Google内部的集群管理系统调用都是用Borg来admits(准入),schedules(调度),starts,restarts,Borg监
控了所有Google所有范围运行的应用。

图片[1] | 谷歌Borg论文阅读笔记(一)——  集群操作系统 | x64

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是服务在机器上的实体进程。每个task映射到一组运行在机器上某个容器里的Linux进程集合。
所有在borg上跑的程序都是打成二进制包的,并且全部静态链接,不允许有依赖。
每一个tasks只属于一个job

alloc(配额)

alloc 是机器上的一组资源,一个或多个tasks能在里面运行。资源无论是否使用都会保持着。
这个指的就是一个容器。当然,每个alloc肯定只属于一个job。一组alloc对应一个job。
alloctask的资源配额,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的部分运行机制

任务分配

  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的应用大多都使用了共享存储GFS。

容量规划

Google的容量规划也是非常有创意的办法。

前面说了,cell是一个集群管理的单元。所以cell的规模需要进行容量规划。Google工程师的办法很简单粗暴,就是在相同的工作负载(不是系统负载)下减机器。看cell在减少了多少机器后,集群承受不了

为了防止某些特殊情况,这种测试会做上10多次,每次减机器还必须是随机的(机器也有不同)。

这个容量规划没法直接在生产环境做,所以都是依托FauxMaster来做的。FauxMaster不是能读取BorgMaster的日志么,应该是把日志重放来模拟工作负载。

学习总结

  1. 整个Borg系统就像是大型的操作系统一样。每个服务,包括在线的和离线的,都能被分解为Task,下发到服务器运行。
  2. Borg团队使用了模拟器FauxMaster来模拟负载,用于容量规划。
© 版权声明
THE END
广告
喜欢就支持一下吧
点赞0 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情

    暂无评论内容