Borg论文读后感

标签: 架构 borg | 发表时间:2015-05-05 12:34 | 作者:bluedavy
出处:http://hellojava.info

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

相关 [borg 文读] 推荐:

Borg论文读后感

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

浅谈Borg/YARN/Mesos/Torca/Corona一类系统

- - 董的博客
Dong | 新浪微博: 西成懂 | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及 版权声明. 网址: http://dongxicheng.org/mapreduce-nextgen/borg-yarn-mesos-torca-corona/. Borg(来自Google), YARN(来自Apache,属于Hadoop下面的一个分支,开源), Mesos(来自Twitter,开源), Torca(来自腾讯搜搜), Corona(来自Facebook,开源)一类系统被称为资源统一管理系统或者资源统一调度系统,它们是大数据时代的必然产物.

一文读懂Apache Kylin - 简书

- -
                              —— 中国古谚语. 随着移动互联网、物联网等技术的发展,近些年人类所积累的数据正在呈爆炸式的增长,大数据时代已经来临. 但是海量数据的收集只是大数据技术的第一步,如何让数据产生价值才是大数据领域的终极目标. Hadoop的出现解决了数据存储问题,但如何对海量数据进行OLAP查询,却一直令人十分头疼.

一文读懂容器存储接口 CSI

- - DockOne.io
来源 | 阿里巴巴云原生公众号. 导读:在 《一文读懂 K8s 持久化存储流程》一文我们重点介绍了 K8s 内部的存储流程,以及 PV、PVC、StorageClass、Kubelet 等之间的调用关系. 接下来本文将将重点放在 CSI(Container Storage Interface)容器存储接口上,探究什么是 CSI 及其内部工作原理.

[原]一文读懂直播卡顿优化那些事儿

- - 字节跳动技术团队官方博客
希望本文可以带给大家一个相对全局的视角看待卡顿问题,认识到卡顿是什么、卡顿的成因、卡顿的分类、卡顿的优化和一些经验积累,有的放矢地解决 App 流畅性问题. 接下来会从以下五个方面进行讲述:. 卡顿,顾名思义就是 用户体感界面不流畅. 我们知道手机的屏幕画面是按照一定频率来刷新的,理论上讲,24 帧的画面更新就能让人眼感觉是连贯的.

一文读懂ChatGPT模型原理 - 知乎

- -
本文是ChatGPT原理介绍,但没有任何数学公式,可以放心食用). ChatGPT模型真可谓称得上是狂拽酷炫D炸天的存在了. 一度登上了知乎热搜,这对科技类话题是非常难的存在. 不光是做人工智能、机器学习的人关注,而是大量的各行各业从业人员都来关注这个模型,真可谓空前盛世. 我赶紧把 OpenAI 以往的 GPT-n 系列论文又翻出来,重新学习一下,认真领会.

一文读懂数据库优化之分库分表

- - IT瘾-dev
作者:tayroctang,腾讯 PCG 后台开发工程师. 本文从 5W1H 角度介绍了分库分表手段,其在解决如 IO 瓶颈、读写性能、物理存储瓶颈、内存瓶颈、单机故障影响面等问题的同时也带来如事务性、主键冲突、跨库 join、跨库聚合查询等问题. anyway,在综合业务场景考虑,正如缓存的使用一样,本着非必须勿使用原则.

一文读懂BI商业智能与大数据应用的区别

- - 人人都是产品经理
      之所以要区分大数据应用与BI(商业智能),是因为大数据应用与BI、数据挖掘等,并没有一个相对完整的认知. BI(BusinessIntelligence)即商务智能,它是一套完整的解决方案,用来将企业中现有的数据进行有效的整合,快速准确的提供报表并提出决策依据,帮助企业做出明智的业务经营决策.

一篇文读懂19款数据分析软件,解救选择困难症!

- - 运维派
欧阳辰,超过15年的软件开发和设计经验,目前就职于小米公司,负责小米广告平台的架构研发. 曾为微软公司工作10年,担任高级软件开发主管. 热爱架构设计和高可用性系统,特别对于大规模互联网软件的开发,具有丰富的理论知识和实践经验. 数据分析(Data Analytics)从来都不是一个寂寞的领域,每一个时代都赋予其新的内容.

一文读懂智能语音前端处理中的关键问题

- - 雷锋网
雷锋网编者按:本文由极限元(微信号:极限元)智能科技语音算法专家、中科院-极限元“智能交互联合实验室”核心技术人员、中科院自动化所博士刘斌整理分享,后续将会为大家分享更多智能语音技术的研究、应用等一系列的优质内容. 随着深度学习技术的快速发展,安静环境下的语音识别已基本达到实用的要求;但是面对真实环境下噪声、混响、回声的干扰,面对着更自然随意的口语表达,语音识别的性能明显下降;尤其是远讲环境下的语音识别,还难以达到实用的要求.