转载

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上。

正文到此结束