Monday, October 31, 2016

Google Borg


http://dongxicheng.org/mapreduce-nextgen/yarn-mesos-borg/
细数国内外互联网巨头,他们都有自己的资源管理系统,比如Google的Borg,Twitter的Mesos,阿里巴巴的Fuxi,微软的Apollo等。本文涉及到的Google Borg相关内容,主要参考了论文“Large-scale cluster management at Google with Borg”

Google Borg采用了集中式master/slave架构 (Borgmaster和Borglet),其中Borgmaster负责集群资源管理和调度,Borglet负责执行实际的任务,Borgmaster通常有5个实例,通过Paxos协议组成一个高可用分布式集群;Borgmaster会周期性地主动poll各个Borglet以获取其状态和资源使用情况,一旦发现其出现问题,会触发容错,之所以采用poll,而不是像YARN/meso采用心跳机制,主要是考虑到这种方式能够更容易地控制网络通信开销,避免active Borgmaster选举时出现网络风暴等。前面提到Borg中存在5个Borgmaste,他们每个会分管一部分Borglet的状态获取和探测,并将收到的信息压缩和求差后,交给active Borgmaster,以分摊active Borgmaster压力。从这种细粒度的设计可以初探端倪:Borg尽管采用了集中式架构,但扩展性仍很好,对应Borg论文中这句话“We are not sure where the ultimate scalability limit to Borg’s centralized architecture will come from; so far, every time we have approached a limit, we’ve managed to eliminate it.”
开源系统YARN和Mesos均采用了双层调度架构,需要注意的是,google在论文omega和borg中均认为YARN是集中式架构,而把Mesos划归为双层调度架构,个人认为这是不准确的,YARN跟Mesos类似,ResourceManager负责集群调度,ApplicationMaster负责framework和应用程序内部调度,相比Mesos,由于YARN的ResourceManager要维护各个分配出去的Container的状态和位置等信息,因此,要比Mesos Master重一些。YARN和Mesos的Master均采用Zookeeper解决高可用问题,其中active master进行资源管理和调度,而backup master仅仅是backup作用,不会协助active master做任何事情;Slave会主动通过周期性心跳向Master汇报状态信息。
1.1扩展性
Borg对所管理的所有borglet进行了水平分片,让每个 Borgmaster分管一部分,这些borgmaster共享集群元信息,每个Borgmaster均可以为应用程序分配资源,但backup Borgmaster需要将分配信息发送给active Borgmaster进行审批,这个地方与Google Omega中的share state是一致的。在这方面,YARN和Mesos均是做不到,他们只有一个master进行资源管理和调度,在超大集群中,master可能会成为瓶颈,这是YARN和Mesos需要改进的方向。
1.2高可用
应用程序方面:Borg内置了各种错误重试机制,确保在机器故障,网络故障等情况下,应用程序不会失败。
服务方面:Borgmaster和Borglet挂掉后,其上正在运行的应用程序和任务不会受影响,这一点,目前Mesos和YARN已经做到。
2.对批处理作业和长服务的支持
为了简化应用程序分类,Borg把应用程序分成两类,批处理作业和长服务,批处理作业是类似于MapReduce和Spark的作业,在一定时间内会运行结束,长服务则类似于web service,HDFS service等,可能会永久运行下去,永不停止。批处理作业和长服务是绝配,混合部署它们对提高集群利用率是非常有帮助的,长服务占用大块资源,而批处理作业穿插到长服务未使用的小块资源中,当高优先级的应用需要资源时,可直接杀死抢占批处理作业。根据borg和omega论文的描述,在google集群中,长服务占用了集群中70%~80%的资源。
Mesos和YARN均对批处理作业有良好的支持,这类应用的支持也是最简单的,而难点在于长服务,一旦引入长服务,会带来以下问题:
(1)资源竞争与饿死问题。 当一个集群中只存在批处理作业时,资源调度是很容易做的,因为资源释放和申请是不断在进行中的,任何资源的申请都可以得到满足。但存在长服务后则不同,因为目前主流的调度器均采用资源预留的调度机器,比如一个作业需要10G内存,目前没有任何节点存在10GB内存呢,为了避免永远拿不到资源,调度器会找一个存在部分资源的节点,比如node1存在6GB内存,则会为该作业预留着,一直等到再次释放出4GB ,则将node1上的10GB内存分配给该作业,整个过程在批处理场景中能自然的发生,一旦加入长服务后,则可能产生饿死现象,也就是说node1上的4GB内存可能永远等不到,因为可能被长服务占着。在这方面,Borg做得很好,但mesos和YARN均存在饿死问题,目前无法解决。
(2)服务高可用问题。 资源管理系统一旦支持长服务后,应保证系统服务出现故障时,上层的长服务不会受到应用,比如在YARN中,ResourceManager或者NodeManager出现故障后,其上运行的长服务,比如MySQL,不应受到影响,到恢复后,重新接管这些服务。这一点,Borg/Mesos/YARN(本文指的是Hadoop 2.6.0之后的版本)均已经支持。
(3)日志收集和滚动。 长服务永不停止,为了方面排错和监控,长服务的日志收集也是需要解决的,Borg/Mesos/YARN在这一块均有很好地支持,其中mesos/YARN可通过上层框架解决,比如Mesos中的 aurora和Marathon(apache顶级项目),YARN中的Twill和Slider(Apache二级项目)。
(4)服务发现。长服务部署到资源管系统中后,可能被调度运行到任意一个节点上,为了让外界的访问者(客户端)发现自己的位置,需要有一个服务注册组件登记这些长服务,Borg/Mesos/YARN均对服务注册有支持,Mesos可通过上层框架,比如Aurora,YARN内核内置了对服务注册的支持。
(5)资源伸缩。长服务运行一段时间后,由于访问量的增加或减少,可能需要动态调整所使用的资源量。资源伸缩有两个维度:一个是横向的,即增加实例数目;另一方面是纵向的,即原地增加正在运行实例的资源量。这方面Borg/Mesos/YARN均已经支持,其中横向支持是通过上层框架实现的,而纵向支持是通过资源管理系统内核支持的(https://issues.apache.org/jira/browse/YARN-1197 )。
(6)服务配置更新和在线升级。 这一块均与资源管理系统无直接关系,一般通过上层的框架实现。
3.其他实现机制
(1)资源预申请(在borg论文中,称之为“alloc”)。应用程序可以预申请一些资源,可用于快速启动一些低延迟task,动态扩容等方面使用。 这一块mesos和yarn没有直接支持。在mesos和yarn中,应用框架申请到资源后,必须在一定时间内使用,如果未使用,mesos和yarn会进行回收。 实际上,mesos和yarn可以在上层框架层面解决这一问题,比如hive on Tez则实现了资源预申请,具体可参考我的这篇文章:“Tez:运行在YARN上的DAG计算框架”:http://dongxicheng.org/mapreduce-nextgen/tez-yarn-dag/
(2)作业优先级与资源抢占。在一个混合应用部署的集群中,抢占是必须要支持的,为了支持抢占,必须提前合理规划好应用程序的优先级,以便于在一些情况下,为高优先级的作业抢占低优先级作业的资源。 资源抢占在YARN中以及得到了支持,但没能够用在批处理和长服务混合资源调度中。实际上,在YARN中,资源抢占仅仅用于队列回收资源的场景中。
(3)份额限制(Quota)和进入控制(admission control)
为了防止应用程序无限制申请资源,满足长服务的SLA,需要由一套完善的admission control机制,在开源实现中,YARN在2.6.0开始加入了这一套机制,具体参考:https://issues.apache.org/jira/browse/YARN-1051 。
4.总结
目前看来,Mesos/YARN的架构和设计上,与Google Borg仍有一定的差距,但需要注意的是,很多细节之处,都是tradeoff的结果,很难说哪种机制更适合我们的场景,对于搭建中小型的集群和数据中心,Mesos/YARN已经绰绰有余了。
5.参考资料
(5)Apache slider:http://slider.incubator.apache.org/
(6)Apache Twill:http://twill.incubator.apache.org/
(7)Apache Aurora:http://aurora.apache.org/
(8)Apache marathon:https://mesosphere.github.io/marathon/




No comments:

Post a Comment

Labels

Review (554) System Design (293) System Design - Review (189) Java (178) Coding (75) Interview-System Design (65) Interview (60) Book Notes (59) Coding - Review (59) to-do (45) Knowledge (39) Linux (39) Interview-Java (35) Knowledge - Review (32) Database (30) Design Patterns (29) Product Architecture (28) Big Data (27) Soft Skills (27) Miscs (25) MultiThread (25) Concurrency (24) Cracking Code Interview (24) Career (22) Interview - Review (21) Java - Code (21) Operating System (21) Distributed (20) Interview Q&A (20) OOD Design (20) System Design - Practice (19) Security (17) Algorithm (15) How to Ace Interview (15) Brain Teaser (14) Google (13) Linux - Shell (13) Spark (13) Spring (13) Code Quality (12) How to (12) Interview-Database (12) Interview-Operating System (12) Redis (12) Tools (12) Architecture Principles (11) Company - LinkedIn (11) Testing (11) Resource (10) Solr (10) Amazon (9) Cache (9) Search (9) Web Dev (9) Architecture Model (8) Better Programmer (8) Company - Uber (8) Interview - MultiThread (8) Java67 (8) Math (8) OO Design principles (8) SOLID (8) Scalability (8) Cassandra (7) Git (7) Interview Corner (7) JVM (7) Java Basics (7) Machine Learning (7) NoSQL (7) C++ (6) Design (6) File System (6) Highscalability (6) How to Better (6) Kafka (6) Network (6) Restful (6) Trouble Shooting (6) CareerCup (5) Code Review (5) Company - Facebook (5) Hash (5) How to Interview (5) JDK Source Code (5) JavaScript (5) Leetcode (5) Must Known (5) Be Architect (4) Big Fata (4) C (4) Company Product Architecture (4) Data structures (4) Design Principles (4) Facebook (4) GeeksforGeeks (4) Generics (4) Google Interview (4) Hardware (4) JDK8 (4) Optimization (4) Product + Framework (4) Shopping System (4) Source Code (4) Web Service (4) node.js (4) Back-of-Envelope (3) Company - Pinterest (3) Company - Twiiter (3) Company - Twitter (3) Consistent Hash (3) GOF (3) Game Design (3) GeoHash (3) Growth (3) Guava (3) Interview-Big Data (3) Interview-Linux (3) Interview-Network (3) Java EE Patterns (3) Javarevisited (3) Map Reduce (3) Math - Probabilities (3) Performance (3) Puzzles (3) Python (3) Resource-System Desgin (3) Scala (3) UML (3) geeksquiz (3) AI (2) API Design (2) AngularJS (2) Behavior Question (2) Bugs (2) Coding Interview (2) Company - Netflix (2) Crawler (2) Cross Data Center (2) Data Structure Design (2) Database-Shard (2) Debugging (2) Docker (2) Elasticsearch (2) Garbage Collection (2) Go (2) Hadoop (2) Html (2) Interview - Soft Skills (2) Interview-Miscs (2) Interview-Web (2) JDK (2) Logging (2) POI (2) Papers (2) Programming (2) Project Practice (2) Random (2) Software Desgin (2) System Design - Feed (2) Thread Synchronization (2) Video (2) ZooKeeper (2) reddit (2) Ads (1) Advanced data structures (1) Algorithm - Review (1) Android (1) Approximate Algorithms (1) Base X (1) Bash (1) Books (1) C# (1) CSS (1) Chrome (1) Client-Side (1) Cloud (1) CodingHorror (1) Company - Yelp (1) Counter (1) DSL (1) Dead Lock (1) Difficult Puzzles (1) Distributed ALgorithm (1) Eclipse (1) Facebook Interview (1) Function Design (1) Functional (1) GoLang (1) How to Solve Problems (1) ID Generation (1) IO (1) Important (1) Internals (1) Interview - Dropbox (1) Interview - Project Experience (1) Interview Tips (1) Interview-Brain Teaser (1) Interview-How (1) Interview-Mics (1) Interview-Process (1) Jeff Dean (1) Joda (1) LeetCode - Review (1) Library (1) LinkedIn (1) LintCode (1) Mac (1) Micro-Services (1) Mini System (1) MySQL (1) Nigix (1) NonBlock (1) Process (1) Productivity (1) Program Output (1) Programcreek (1) Quora (1) RPC (1) Raft (1) RateLimiter (1) Reactive (1) Reading (1) Reading Code (1) Refactoring (1) Resource-Java (1) Resource-System Design (1) Resume (1) SQL (1) Sampling (1) Shuffle (1) Slide Window (1) Spotify (1) Stability (1) Storm (1) Summary (1) System Design - TODO (1) Tic Tac Toe (1) Time Management (1) Web Tools (1) algolist (1) corejavainterviewquestions (1) martin fowler (1) mitbbs (1)

Popular Posts