e-works数字化企业网  »  文章频道  »  基础信息化  »  云计算和虚拟化

解析阿里云分布式调度系统伏羲

2017/3/10    来源:36大数据    作者:陶阳宇      
关键字:阿里云  云计算  
本文涉及阿里云分布式调度团队在分布式调度系统的设计、实现、优化等方面的实践以及由此总结的分布式系统设计的一般性原则,具体包括分布式调度的任务调度、资源调度、容错机制、规模挑战、安全与性能隔离以及未来发展方向六部分。
    本文涉及阿里云分布式调度团队在分布式调度系统的设计、实现、优化等方面的实践以及由此总结的分布式系统设计的一般性原则,具体包括分布式调度的任务调度、资源调度、容错机制、规模挑战、安全与性能隔离以及未来发展方向六部分。
 
    云计算并不是无中生有的概念,它将普通的单台PC计算能力通过分布式调度软件连接起来。其最核心的问题是如何把一百台、一千台、一万台机器高效地组织起来,灵活进行任务调度和管理,从而可以像使用台式机一样使用云计算。在云计算中,最核心的模块是分布式调度,它好比云计算的中央处理器。目前,业界已存在多种分布式调度实现方案,如伏羲、Hadoop MapReduce、YARN、Mesos等系统。
 
    阿里云伏羲
 
    伏羲系统在前人的基础上进行了一系列改造,首先与YARN和Mesos系统类似,将资源的调度和任务调度分离,形成两层架构,使其具备以下优势:
 
    规模:两层架构易于横向扩展,资源管理和调度模块仅负责资源的整体分配,不负责具体任务调度,可以轻松扩展集群节点规模;
 
    容错:当某个任务运行失败不会影响其他任务的执行;同时资源调度失败也不影响任务调度;
 
    扩展性:不同的计算任务可以采用不同的参数配置和调度策略,同时支持资源抢占;
 
    调度效率:计算framework决定资源的生命周期,可以复用资源,提高资源交互效率。
 
    这套系统目前已经在阿里集团进行了大范围的应用,能支持单集群5000节点、并发运行10000作业、30分钟完成100T数据terasort,性能是Yahoo在Sort Benchmark的世界纪录的两倍。
 
    伏羲的系统架构
 
    伏羲的系统架构如图1所示,整个集群包括一台Fuxi Master以及多台Tubo。其中Fuxi Master是集群的中控角色,负责资源的管理和调度;Tubo是每台机器上都有的一个Agent,负责管理本台机器上的用户进程;同时集群中还有一个叫Package Manager的角色,因为用户的可执行程序以及一些配置需要事先打成一个压缩包并上传到Package Manager上,Package Manager专门负责集群中包的分发。
 
伏羲的系统架构
 
图1 伏羲的系统架构
 
    集群部署完后,用户通过Client端的工具向Fuxi Master提交计算任务;Fuxi Master接收到任务后首先通知某一个Tubo启动这个计算任务所对应的APP Master;APP Master启动之后,它获知了自己的计算任务,包括数据分布在哪里、有多少的任务需要计算等等信息;接着APP Master会向Fuxi Master提交资源申请,表明它需要多少计算资源;Fuxi Master经过资源调度以后,将资源的分配结果下发给APP Master;APP Master在这个资源的基础之上进行它的任务调度,来决定哪些机器上运行哪些计算任务,并且将这个计算任务发送给对应机器上的Tubo进程;Tubo接受到命令之后就会从Package Manager中下载对应的可执行程序并解压;然后启动用户的可执行程序,加载用户的配置(图1中的APP Worker);APP Worker根据配置中的信息读取文件存储系统中的数据,然后进行计算并且将计算结果发往下一个APP Worker。其中,数据的切片称之为Instance或者叫计算实例。
 
    Fuxi Master与Tubo这套结构解决了分布式调度中的资源调度,每个计算任务的APP Master以及一组APP Worker组合起来解决任务调度的问题。
 
    任务调度
 
    伏羲在进行任务调度时,主要涉及两个角色:计算框架所需的APP Master以及若干个APP Worker。
 
     伏羲在任务调度时涉及的主要角色
 
    图2 伏羲在任务调度时涉及的主要角色
 
    APP Master首先向Fuxi Master申请/释放资源;拿到Fuxi Master分配的资源以后会调度相应的APP Worker到集群中的节点上,并分配Instance(数据切片)到APP Worker;APP Master同时还要负责APP Worker之间的数据传递以及最终汇总生成Job Status;同时为了达到容错效果,APP Master还要负责管理APP Worker的生命周期,例如当发生故障之后它要负责重启APP Worker。
 
    而APP Worker的职责相对比较简单,首先它需要接收App Master发来的Instance,并执行用户计算逻辑;其次它需要不断地向APP Master报告它的执行进度等运行状态;其最为主要的任务是负责读取输入数据,将计算结果写到输出文件;此处的Instance是指输入数据的切片。伏羲任务调度系统的技术要点主要包括数据的Locality、数据的Shuffle以及Instance重试和Backup Instance三点。
 
    数据Locality
 
    数据Locality是指调度时要考虑数据的亲近性,也就是说APP Worker在处理数据时,尽量从本地的磁盘读取数据,输出也尽量写到本地磁盘,避免远程的读写。要实现这一目标,在任务调度时,尽量让Instance(数据分片)数据最多的节点上的AppWorker来处理该Instance。
 
    数据Shuffle
 
    数据Shuffle指的是APP Worker之间的数据传递。在实际运行中,APP Worker之间是有多种传递形态的,如一对一、一对N、M对N等模式。如果用户去处理不同形态的传输模式,势必会带来较大的代价。伏羲分布式调度系统将数据传递的过程封装成streamline lib,用户无需关心数据传递的细节。首先Map进行运算,将结果直接交给streamline,streamline底层会根据不同的配置将数据传给下游计算任务的streamline;然后streamline将接到的数据交给上层的计算任务。
 

责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐