Yarn与ZooKeeper
Posted shi_zi_183
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Yarn与ZooKeeper相关的知识,希望对你有一定的参考价值。
Yarn与ZooKeeper
Yarn是MapReduce引入的资源管理器,它的出现为集群在资源利用率、资源统一管理和数据共享等方面带来了巨大好处。ZooKeeper是一个分布式的、开源的协调服务框架,ZooKeeper出现就是为例减轻分布式应用实现协调服务的负担。
Yarn资源管理与调度
Yarn产生背景
在早期的Hadoop中,MRv1采用Master/Slave(M/S)框架,主要包括Client、JobTracker、TaskTracker和Task几个部分。其中JobTarcker负责整个系统的作业调度和资源管理,TaskTracker负责将本节点上资源的使用情况、节点健康状态和任务的运行进度汇报给JobTracker,同时接受JobTracker发送过来的命令并执行相应操作。
M/S架构的设计具有一定的缺陷,MRv1中存在的问题如下。
1)单点故障。JobTracker只有一个,如果JobTracker发生故障则整个集群就无法使用,削弱了集群的高可用性。
2)资源利用率低。MRv1采用的是基于槽位的资源分配模型,将槽位分为Map Slot和Reduce Slot,两种Slot由Map和Reduce任务独立使用,不能实现资源共享,导致资源利用率低。
3)JobTarcker任务过重。JobTracker既要负责作业的调度和监控,又要负责资源的管理和分配。随着集群节点规模的扩大,JobTracker主节点压力过大,成为影响性能的瓶颈,限制了集群的扩展。
4)仅支持MapReduce计算框架。近几年出现了一些新的计算框架,如内存计算框架、流式计算框架和迭代式计算框架等,而MRv1不能支持这些新的计算框架。
为了克服上述问题,Hadoop2.0对MRv1进行了重新设计,将资源管理和任务调度两个功能交给独立的模块负责,提出了MRv2和Yarn(yet another resource negotiator)。MRv2是计算框架,而Yarn独立负责资源管理和分配。通过这种功能划分,有效地降低了JobTracker的压力。Tarn为分布式应用提供了通用的资源管理框架,不但支持MapReduce应用,也支持几乎所有的其他分布式应用。
在Yarn命令行中同样包含很多功能,用于日常运维、查看日志和提交作业。在终端,可输入yarn,查看各种选项。
Yarn的体系结构
Yarn体系结构
Yarn体系结构,Yarn同样采用Master/Slave结构,主要由ResourceManager(简称RM)、NodeManager(简称NM)、ApplicationMaster(简称AM)和Container等几部分组成。ResourceManager负责资源管理,ApplicationMaster负责任务监控和调度,NodeManager负责执行原TaskTracker的任务。
一个集群中通常有一个ResourceManager和多个NodeManager。
1)ResourceManager是一个全局的资源管理器,负责整个系统资源管理和分配,整个集群只有一个。ResourceManager主要由两个组件构成:Scheduler和Applicaitons Manager。
Scheduler是一个纯粹的调度器,负责为各种运行中的应用程序分配资源,它不负责应用程序的监控和状态跟踪等于应用程序相关的工作。Scheduler根据资源容量、队列以及其他因素的限制条件,将资源进行分配。
Applications Manager是应用程序管理器,负责管理整个系统中所有应用程序的运行,包括应用程序的提交,与调度器协商资源以启动ApplicationMaster以及监控ApplicationMaster运行状态并在失败时重新启动等工作。
2)NodeManager。NodeManger是每个节点上的资源和任务管理器。NodeManager定时地向ResourceManager汇报本节点上地资源使用情况和各个Container的运行状态。NodeManager接受并处理来自AM的启动和停止任务等各种请求。
3)ApplicationMaster。用户提交的每个应用程序均会产生一个用于对其追踪和管理的ApplicationMaster。当用户提交作业时,ApplicationMaster与ResourceManager调度器协商从而获取资源(以Container形式)。将获得的资源进一步分配给内部的各个任务,如Hadoop平台上的Map任务和Reduce任务。ApplicationMaster与NodeManager通信,进行任务的启动、运行和停止。ApplicationMaster监控申请到的资源使用情况、任务的运行进度和状态,并在任务运行失败时进行恢复(重新为任务申请资源、重启任务等)。ApplicationMaster定时向ResourceManager发送“心跳”信息,汇报资源的使用情况和任务的执行状态。作业完成时,ApplicationMaster向ResourceManager注销容器。
不同的ApplicationMaster分布在不同的节点上,它们之间不会互相影响。
4)Container。Yarn以Container作为动态分配资源的单位。Container对任务运行环境进行抽象,封装CPU、内存等多维度的资源以及环境变量、启动命令等任务运行相关的信息。Yarn会为每个任务分配一个Container,且该任务只能使用该Container中描述的资源。
一个应用程序所需的Container分为两种:一种是运行ApplicationMaster的Container,由ResourceManager向内部资源调度器申请;另一种是运行各类的Container,它由ApplicationMaster向ResourceManager申请,并通过ApplicationMaster与NodeManager通信来启动。
ResourceManager Restart
ResourceManager作为Yarn上的Master,负责集群的资源和调度管理,一旦发生单点故障,整个集群的资源将无法使用。为此,在Yarn中引入了新特性——ResourceManager Restart(重启)和ResourceManager HA(高可用性)。
当发生故障时,应尽可能快地自动重启ResourceManager,另外,ResourceManager重启过程用户是感知不到的,ResourceManager Restart主要分为两个阶段。
1)阶段1——非工作保留RM重启。在Hadoop2.4.0版本之前,只有ResourceManager Restart阶段1是实现完成的。
在Client提交Application时,RM会将应用程序元数据(ApplicationSubmissionContext)保留在可插拔的状态存储中,并保存应用程序的最终状态,例如,完成状态(失败、终止、已完成)和诊断时的诊断应用程序完成。此外,RM还会保存安全密钥、令牌等凭据,以便在安全的环境中工作。任何时候RM关闭,只要在状态存储中可以获取所需的信息(应用程序元数据以及在安全环境中运行的凭据),当RM重新启动时,它可以从状态存储中获取应用程序元数据并重新提交申请。如果Application在RM关闭前以及完成(Failed、Killed、Finished),RM不会重新提交Application。
NodeManager和Cilent在RM的宕机时间内保持轮询RM状态知道RM恢复。当RM重新启动之后,他会通过心跳发送re - sync命令到所有的NodeManager和ApplicationMaster。到Hadoop2.4.0发布为止,NodeManager和ApplicationMaster处理此命令的行为是,NM会杀死它管理的所有Container,然后重新注册到RM。在RM看来,这些重新注册上来的NodeManager就相当于新加入的NM。AM(如MapReduce AM)在收到re-sync命令之后会关闭。在RM重新启动并加载所有应用程序元数据,并将状态存储的凭据填充到内存中之后,他将为尚未完成的每个应用程序创建一个新的ApplicationMaster并像往常一样重新启动该应用程序。
2)阶段2——保持工作的RM重启。从Hadoop2.6.0版本开始,进一步增强了RM重启功能来解决RM重启时可以不杀死任何在集群中运行的Application的问题。
除了阶段1已经完成了基础性工作,即Application持久化和重新加载Application状态,阶段2主要侧重于重新构建完整的集群运行状态,主要是RM内部的中心调度器保持跟踪所有容器的生命周期、Application的余量和资源请求使用情况等。在这种方式下,RM不再需要像在阶段1中那么杀死AM并重新运行,Application就能够简单地与RM重新同步(re-sync),并从终端处继续它剩下的工作。
RM利用NM发送的Container状态信息恢复自身的运行状态。当NM与重新启动的RM重新同步时,NM不会杀死容器。在重新注册之后,NM继续管理容器,并在重新注册时发送容器状态到RM。RM通过这些容器的信号重新构建容器实例和相关Application的调度状态。与此同时,AM需要重新发送未完成的资源请求到RM,因为RM可能会在关闭时丢失未完成的请求。Application利用它的AMRMClient库与RM通信,不用担心AM在重新同步时发送资源请求,因为它自动由库本身处理。
另外,在Spark2.4.0之后,增加了高可用性功能。ResourceManager的高可用性可以"Active/Standby"的形式增加一个节点冗余,并利用ZooKeeper集群,把Active的ResourceManager状态信息写入ZooKeeper用于启动Standby状态的ResourceManager,以消除这个单点故障。
Yarn通信协议
在Yarn中,任何两个需要相互通信的组件之间都需要RPC协议,并且有且仅有一个。Yarn采用的是拉式(pull - based)通信模型,因为对于任何一个RPC协议,Clien总是主动连接Server。
1)JobClient与RM之间的协议:JobClient通过该协议提交应用程序,查询应用程序状态等。
2)Admin与RM之间的协议:admin通过该RPC协议更新系统配置文件。
3)AM与RM之间的协议:AM通过该RPC协议向RM注册和撤销自己,并为各个任务申请资源。
4)AM与NM之间的协议:AM通过该PRC协议要求NM启动或者停止Container,获取各个Container的使用状态等信息。
5)NM与RM之间的协议:NM通过该RPC协议向RM注册,并定时发送心跳信息汇报当前节点的资源使用情况和Container运行情况。
Yarn执行过程
第一阶段:提交作业
1)在客户端通过创建JobClient实例,启动作业Job。
2)向ResourceManager请求获取一个新的作业ID(JobID),然后检查作业输出。例如,是否指定输出路径或输出路径是否已经存在,如果未指定输出路径或输出路径已经存在则放弃提交作业。计算作业的输入数据分片,若输入路径不存在则放弃提交作业。
3)如果输入输出检查没有错误,JobClient将作业运行所需要的资源复制到HDFS分布式文件系统中以JobID命名的目录下。这些资源包括本次作业相关的配置文件,计算所得的输入数据分片已经包含Mapper和Reducer类的jar文件等。
4)完成上述准备后,JobClient通过调用ResourceManager的submitApplication()方法发出作业提交请求。
第二阶段:初始化作业
5)ResourceManager接受到调用它的submitApplication()请求后,将该作业提交请求传递给调度器。调度器为该作业分配一个容器Container,然后ResourceManager在该Container内启动应用管理器ApplicationMaster进程,由NodeManager监控。
以上是关于Yarn与ZooKeeper的主要内容,如果未能解决你的问题,请参考以下文章