Borg:G家最重要的基础设施

即使是在Borg论文发表前,从各种渠道了解也都能知道G家有一个挺神秘,非常重要的系统叫Borg,在Borg论文发表后,更是让人可以确信,再加上近两年和G家的朋友们的接触,更加可以知道对于G家的研发人员而言,说Borg是G家最重要的基础设施应该不为过,如果有看过《Google SRE》书的同学,可以看出有一点是在G家对Borg的认识是深入各研发同学的,Google SRE书里讲到G家的编译打包这种临时性任务,其实都是提交一个临时性的任务到borg来完成,而我想在传统或者说目前多数的做法里都会采用固定的机器资源来做这些事。

对Borg带来的收益,我想只用摘取Borg论文里这一小段就足以说明:
“Since many other organizations run user-facing and batch jobs in separate clusters, we examined what would happen if we did the same. Figure 5 shows that segregating prod and non-prod work would need 20–30% more machines in the median cell to run our workload.”
G家的服务器数量是百万数量级,20-30%这数量级的节省简直了…

既然Borg这么的好,为什么现在在其他互联网公司还没看到采用一样的方式去做呢(要知道Borg差不多是2003年就开始做了),从我的接触来看,我了解到的原因主要是这两个:
1.技术难度,有一些声音是觉得Borg这条路线太难走了,里面要解决的技术问题太多;
2.离线任务的规模量还不够大,这个时候Borg采用的user-facing and batch jobs混合在一台机器上运行的方式的优势就不存在了。
从上面这两个原因可以看到,要去打造一套Borg这样的系统,基本上只有机器到达一定规模,以及大数据也发展到比较大规模的公司才能有足够的收益比,当然,以现在大数据、AI的火热程度,排行前十甚至前几十的互联网公司其实都已具备这样的前提条件。

那么要打造Borg这样的系统,要突破哪些技术难度呢?

1.容器化
Borg把所有的task都放在cgroup里运行,这种方式相比Docker基于的LXC的差别在于没有namespace的隔离,简单来说就是当你登录到机器上,看到的是整个物理机的状况,这对于运维来说其实是相当痛苦的,从Borg论文也可以看到Borg为了方便对task进行运维,做了很多辅助工具和系统,所以在容器化这个方面我会更加倾向于LXC,具备namespace的隔离,对运维来说就会友好非常多。
为什么一定要容器化呢,原因在于如果对资源的需求都是物理机,那资源的调度的灵活性将会大幅下降,所以容器化是非常重要的一个基础前提,容器化的难题一方面是对LXC的掌握,另一方面则是任何类型的软件都要放在LXC中跑,会碰到各种问题,无论是性能还是namespace隔离不完整带来的支持问题。

2.复杂的调度器
当一家大规模的公司的所有业务都要通过同一个调度层来分配资源时,这个调度层所要面临的业务复杂性是非常可怕的,再加上batch jobs的调度,各种调度需求混合在一起,以及要管理巨大的机器规模,如何在保证业务需求满足的同时的规模、效率、稳定,绝对不是一件容易的事,现在业界有的其他的例如swarm、k8s、mesos、yarn等等,离borg这种级别的调度器是有巨大差距的。

3.资源隔离
Borg需要把不同优先级的任务跑在同一台机器上,non-prod优先级的任务会share prod优先级任务的资源,这个时候如何保障好non-prod任务不影响到prod任务的性能等就非常非常重要了,而这个目前业界并没有什么很成熟的方案,无论是cpu、内存、IO(磁盘/网络),离要成熟的支撑这样的资源隔离都还有非常大的差距。

4.历史包袱
Borg在2003年开始做的话,我想那个时候G家的历史包袱应该是不大的,但现在其他的大的互联网公司要做的话,显然都有不小的历史包袱,例如通常都会需要面临多种不同的基础设施、运维模式等,怎么在背着巨大的历史包袱走到期望的那步,其实是一件非常不容易的事。

可以说,这四点技术难度都是世界级的,因为碰到这样的技术难度的机会其实本来就很少,显然只有巨大的收益才能产生这样的驱动力,所以说这种类型的系统只有大规模的公司才会投入力量去做,而现在阿里就在投入力量打造这样的系统,如果你正好对这些领域有兴趣,并且在这些领域有一定的积累,我想这样的好的难得的机会(就像一直说,只有少数几家公司有做这样的系统的动力)不容错过,应该毫不犹豫的来加入我们,直接发送消息来联系我吧,期待你的加盟!

=============================
欢迎关注微信公众号:hellojavacases

公众号上发布的消息都存放在http://hellojava.info上。

Borg论文读后感

Borg之前号称是G家内部和PageRanking可以相提并论的同等重量级的东西,在之前终于是对外发论文了,这篇论文一出就引起了很多人的关注,我的团队在这个方面也做了几年,尽管之前从各种渠道也对Borg有一定了解,但论文揭露的很多内容还是我以前都完全不知道的,个人觉得这篇论文还算挺实在的,G家把自己的很多数据、经验都公开出来了,所以确实值得做资源管理和调度的同学看看。

G家内部所有要放到生产环境运行的东西都称为任务,任务到底放到哪台机器执行由Borg来调度和管理,因此Borg掌握了所有生产环境资源的管理,管理的高效就可以极大程度的节省成本,而这也是Borg出名的原因。

论文里讲到的以下一些内容是我自己印象比较深刻的,同样也是我认为一套优秀的资源管理平台很需要学习的:

1. Prod & Non-Prod Tasks
很早以前就知道Borg是把离线的任务和在线的任务放在一起跑的,当时有点好奇的就是那borg是怎么区分像Gmail之类在线应用的,论文里的Prod(Production)和Non-Prod的划分就直接回答了这个问题。

2. Jobs and tasks
每个Job的描述里可以有很多约束性的一些描述,例如操作系统版本,处理器的架构等,这个真心比我们现在内部的资源分配系统强不少,通用能力自然也就好很多,job通过优先级来做资源抢占,级别划分为:monitoring,production,batch and best effort(also known as testing or free),prod jobs也就是monitoring and production级别。
每个task对应的就是一台机器上的一个container(linux container),task描述所需的资源,不过这个资源信息竟然还包括了tcp端口什么的。

3. Utilization
这是我最关心的部分,在这个部分前论文里还讲了不少关于Borg的架构,以及它是如何保障自己的可用性的等等,这块我就不在这讲了。
Borg最主要的一个目的就是通过一个全局的资源管理系统来提升资源的使用率,在这个部分中论文阐述了Borg通过哪些方法来提升使用率。
第一个方法是离线在线任务混部,论文里有讲到大部分其他的公司都是将离线集群和在线集群分开,G家的一个研究分析表明如果G家把它的离线任务和在线任务集群分开,那么G家会大概需要增加20%-30%的机器,G家的机器数应该在500w+,20%就是100w台机器,这这算到成本的话是非常非常夸张的,所以可以看到离线在线混部是节省资源的一个关键手段,当然每家公司这么做带来的成本节省会不一样,论文里写到之所以离线在线混部能达到这么好的效果,主要原因是prod任务通常是为高峰负载来申请的机器数,而事实上高峰时间通常都是非常短的,就意味着prod任务申请的资源大部分时候其实是空闲的,所以Borg的做法是利用prod任务空闲的资源来跑non-prod任务,从而大幅减少机器数,我自己觉得这是Borg区别于目前大部分其他类似东西的最主要的地方,而且也是最本质的地方。

在给任务分配资源时,Borg采用的方法是prod任务直接占用资源,prod任务互相之间不共享资源,Borg会预估这些prod任务能空闲出的资源,分配给non-prod任务使用,之所以很多公司都不这么做,是担心non-prod任务的执行影响到了prod任务。

Borg在资源的隔离上采用的做法为:
Borg按照两种方法来控制overload和overcommitment,overload通过将任务分为Latency-sensitive(LS)和batch两种来控制资源;overcommitment则通过任务对资源的占用划分为compressible(例如cpu、I/O带宽)和non-compressible(例如内存、磁盘空间)。
如果机器上non-compressible的资源不够用了,那么Borglet会立刻按照优先级杀掉本机上优先级低的任务释放出资源;如compressible的资源不够用,那么Borglet会先尝试控制batch任务对cpu的使用来度过高峰,如果还不行,就会由borgmaster拿掉机器上的一个或更多的低优先级任务。
Borglet里面还有一个用户态的程序来控制分配给prod和non-prod任务的内存,如内存超过了task的限制,或本机的内存不够用了,内核中处理OOM事件的部分将按照优先级来kill task。
在CPU方面,在资源的分配上,对于LS tasks允许占用整个cpu核,而batch tasks则可以在任何核上运行,但batch tasks会在较低优先级上,Borg修改了内核的CPU调度器,允许根据每个container的load状况来动态决定是否要kill batch tasks,同时避免多个LS tasks在一个cpu上争抢,目前Borg仍然在尝试的是在cpu调度时更好的考虑线程亲和、NUMA亲和之类的。

可以看到Borg为了能实现离线在线混部,在资源的分配、隔离上还是做了很多改进的,如果这些patch能公开出来就好了,否则的话其实多数公司做的话也只能是重新尝试,靠不断摔跤来绕过这些问题。

论文的最后有总结下Borg的好和不好的地方,其中竟然也提到了一台物理机一个ip所有container共享的问题,从我们实际对container的使用来看,运维更友好的话其实还是每个container一个ip比较好。

尽管论文中有提到其他很多相似的系统,例如mesos,yarn,facebook’s tupperware,ms autopilot,甚至还提到了alibaba的fuxi,但我始终觉得这些和Borg的巨大区别就是Borg是用来管理所有资源,并且离线在线混部的,而上面这些相似的基本都只是某一款软件的资源管理,这在资源的利用率上相比的话会完全不是一个档次。

据之前的信息,Borg在G家内部应该在2005年左右就相当成熟了,而我们看到论文的时候已经是2015年了,这个差距…

国内腾讯、百度也都尝试过类似Borg的方向,目前腾讯基本是不玩了,百度的Matrix则成功了,同样是离线在线混部,由于给百度节省了巨多的成本,所以这个团队之前得到过百度的100w大奖,不过百度的Matrix其实和Borg实现上的话还是不太一样的,从Borg论文可以看出Borg的话是所有的调度器,这样实现的话有一个坏处是会比较重,百度的Matrix选择了一条更轻量的改造路线,对于一个有不少历史包袱的公司来说是不错的选择,对Matrix感兴趣的同学可以看看这篇文章

我自己这边的话其实是在去年下半年才想明白我们原来所做的提升资源利用率的方向一定程度是错误的,现在我是比较坚信在线离线混部,区分好prod、non-prod,内核改造是比较好的提升资源利用率的方向,我的团队今年在这块需要重点突破,欢迎有兴趣的同学加盟,:)

=============================
欢迎关注微信公众号:hellojavacases
题目来源:http://www.wired.com/wiredenterprise/wp-content/uploads/2013/03/borg.gif

关于此微信号:
分享Java问题排查的Case、Java业界的动态和新技术、Java的一些小知识点Test,以及和大家一起讨论一些Java问题或场景,这里只有Java细节的分享,没有大道理、大架构和大框架。

公众号上发布的消息都存放在http://hellojava.info上。