Yarn
Yarn是第二代的Hadoop,为解决原来Hadoop中的问题而重新开发的云计算平台
l 与编程模式耦合得紧密,迫使程序员过度使用MapReduce的编程模式
l 过于集中处理jobs的控制流程,使得扩展性不佳
这两个问题是上一版本Hadoop中的主要问题。第一个问题很好理解就是Hadoop原本就是为了MapReduce框架而开发的,所以他一开始只支持MapReduce框架
第二个问题由它的结构而来:
这张图是第一代Hadoop的任务执行过程的示意图
简单地说就是:
1. 用户提供job给 jobtracker
2. Jobtracker给用户提交的job分配资源,拆分成task的形式分发到各个机器
3. 各个机器上的tasktracker负责监视它们的运行状况,以心跳的形式发给jobtracker
4. 而且tasktracker提交给jobtracker的信息不光是,任务的运行状况。还有自己的资源利用状况以便于jobtracker给新的job分配资源。
这里面的问题就是
´ Jobtracker 是MapReduce的集中处理点,存在单点故障。而且可扩展性不行,根据经验MapReduce 最大支持4000节点
´ tasktracker把资源强制划分为map task slot 和reduce task slot, 如果当系统中只有 map task 或者只有 reducetask 的时候,会造成资源的浪费
那么在开发过程中为了能够适应未来的开发环境还是提出了10条开发的需求。
1. Scalability 扩展性
2. Multi-tenancy 多路租用
3. Serviceability 可用性
4. Locality awareness 本地化
5. High Cluster Utiltization 集群使用率
6. Reliability/Availability 可靠性
7. Secure and auditable operation 安全
8. Support for Programming Model Diversity 编程模式多样化
9. Flexible Resource Model 资源的可伸缩性
10. Backward compatibility 后向兼容
新的结构如下:
´ Resource Manager:负责资源管理的主服务,负责资源管理、调度和监控
´ Node Manager:负责单个节点的资源管理和监控,它定期将资源使用情况汇报给Resource Manager,并接收来Application Master的命令以启动Container(YARN中对资源的抽象),回收Container等
´ Application Master:负责管理单个应用程序,它向Resource Manager申请资源,并使用这些资源启动内部的任务,同时负责任务的运行监控和容错等
´ Container:对资源的抽象,它封装了某个节点上的CPU、内存等资源,Application Master只有获得一个Container后才能启动任务,另外,Application Master本身也是运行在一个Container之中。
新的yarn在Yahoo上得到了验证!
Mesos
Mesos是以一种细粒度的方式实现了资源的共享资源调度器。允许各种框架的数据本地化。为了支持多种现有的框架,Mesos采用了两级调度机制,以一种resource offer的方式实现资源调度。Mesos决定分配那些资源给框架,框架决定接受那些资源。
设计时应对的需求:
´ 解决方案要能支持现有以及未来可能的多种编程框架,每一个都会有不同的调度需求(编程模式,通信模式,任务依赖以及数据的存储(本地化))。
´ 方案是可扩展的,来应对规模越来越大的集群。
´ 调度系统必须是容错能力强的,具有高可用性的。
它的架构:
´ Mesos-master:负责管理接入mesos的各个framework和slave,并将slave上的资源分配给framework
´ Mesos-slave:slave负责接收并执行来自master的命令、管理节点上的task,并为各个task分配资源。slave将自己的资源量发送给master
´ Excutor:属于salve的一部分,主要用于启动框架内部的task
´ Framework :指外部的计算框架,如Hadoop,MPI等,这些计算框架可通过注册的方式接入mesos,以便mesos进行统一管理和资源分配。
上面提到的resource-offer形式的任务分配时这样的:
还有就是Mesos在资源分配,隔离和容错的一些特点(这是一部分稍后我还会针对每一篇文章做个完整一些的总结出来,现在看的只是个大概)
´ 资源分配:会在任务完成时重新分配资源,如果长时间没有free,这个任务会被注销(kill)
´ 隔离:通过操作系统之中的container做隔离,container可重新配置。相比hadoop只是使用不同的进程要先进一些
´ 容错方面: master采用zookeeper管理;
同一mesos可注册多个 framework-scheduler,有一个出错马上替换
slave,executor出错误,由相应的framework-schedule处理
Borg
Borg是google的集群管理系统,用它管理、调度、开始、重启和监控应用程序的生命周期。
有三大特点:
1) 隐藏资源管理和故障处理细节,使其用户可以专注于应用开发;
2) 高可靠性和高可用性的操作,并支持应用程序做到高可靠高可用;
3) 在数以万计的机器上有效运行
其实这三大特点是所有的云计算平台所共有的,也是所有云计算平台的目标,但是他最大的不同点就是它能够在google的数据中心这样大的规模上管理集群运行。别的还没又在这么大的规模的集群上运行的示例。虽然meso也是被twitter采用的。下面这样图是从用户角度看borg的一些关注点,这里面的用户指的是google开发人员(比如一些应用开发)和系统管理员。了解这个有助于理解后面的Borg的结构。
下面是Borg的结构:
´ Borgmaster:修改状态(创建job),提供数据读取服务(查找job)。同时管理系统中所有组件(机器、task、allocs等等)的状态机,和Borglet通信,并且提供一个叫Sigma,Web UI。用户可也可以看到任务的执行情况
´ Scheduler:实际上是Borg上的的另一个进程,而且调度的是task而不是job。调度涉及两个步骤:1.可行性检查(挑一些服务器出来)2.评分(找到一台合适的)
´ Borglet :部署在cell的每台机器上的本地Borg代理程序。它启动,停止task。如果task失败就重启。通过修改OS内核设置来管理本地资源;滚动debug日志;把本机的状态上报给Borgmaster
它的性能上的特点很多,我只跳出来几个我现在好理解的。(之后我也会分开详细总结论文里面的详细内容)
• 可用性:就算Borgmaster或者Borglet挂了,task也会继续运行下去。但是,保持master运行也很重要,因为在它挂的时候新的jobs不能提交,或者结束的无法更新状态,故障的机器上的task也不能重新调度
• 效率:共享cell(运行多种类型的task):在效率(CPI)上并没有太大提升,但减少的服务器的数量
大cell:大量减少了服务器的数量
• 隔离:
• 安全隔离:Borg使用Linuxchroot监狱作为同一台机器不同task之间主要的安全隔离机制。
• 性能隔离:区分Prod和Non-prod应用