本帖最后由 pig2 于 2014-4-7 19:41 编辑
ResourceManager作为资源的协调者有两个主要的组件:Scheduler和ApplicationsManager(AsM)。 Scheduler负责分配最少但满足application运行所需的资源量给Application。Scheduler只是基于资源的使用情况进行调度,并不负责监视/跟踪application的状态,当然也不会处理失败的task。RM使用resource container概念来管理集群的资源,resource container是资源的抽象,每个container包括一定的内存、IO、网络等资源,不过目前的实现只包括内存一种资源。 ApplicationsManager负责处理client提交的job以及协商第一个container以供applicationMaster运行,并且在applicationMaster失败的时候会重新启动applicationMaster。下面阐述RM具体完成的一些功能。 Scheduler从所有运行着的application收到资源请求后构建一个全局的资源分配计划,然后根据application特殊的限制以及全局的一些限制条件分配资源。 Scheduler会周期性的接收来自NM的资源使用率的监控信息,另外applicationMaster可以从Scheduler得到属于它的已完成的container的状态信息。 client向AsM获得一个applicationIDclient将application定义以及需要的jar包 client将application定义以及需要的jar包文件等上传到hdfs的指定目录,由yarn-site.xml的yarn.app.mapreduce.am.staging-dir指定 client构造资源请求的对象以及application的提交上下文发送给AsM AsM根据application的信息向Scheduler协商一个Container供applicationMaster运行,然后启动applicationMaster 向该container所属的NM发送launchContainer信息启动该container,也即启动applicationMaster、AsM向client提供运行着的AM的状态信息。 AsM负责系统中所有AM的生命周期的管理。AsM负责AM的启动,当AM启动后,AM会周期性的向AsM发送heartbeat,默认是1s,AsM据此了解AM的存活情况,并且在AM失败时负责重启AM,若是一定时间过后(默认10分钟)没有收到AM的heartbeat,AsM就认为该AM失败了。 关于ResourceManager的可用性目前还没有很好的实现,不过Cloudera公司的CDH4.4以后的版本实现了一个简单的高可用性,使用了Hadoop-common项目中HA部分的代码,采用了类似hdfs namenode高可用性的设计,给RM引入了active和standby状态,不过没有与journalnode相对应的角色,只是由zookeeper来负责维护RM的状态,这样的设计只是一个最简单的方案,避免了手动重启RM,离真正的生产可用还有一段距离。
YARN/MRv2 ResourceManager代码结构分析 ResourceManager相当于整个系统的master,主要功能是启动application的ApplicationMaster和分配系统资源。
ResourceManager的核心代码在java包 org.apache.hadoop.yarn.server.resourcemanager中的ResourceManager类中,主要涉及到三种 对象:事件处理器,RPC服务和普通服务,其中事件处理器实现EventHandler接口,并被注册到统一的事件调度器AsyncDispatcher 中,由该调度器进行统一管理和调度:
……
private EventHandler<SchedulerEvent>schedulerDispatcher; //实际上是AsyncDispatcher
……
this.rmDispatcher.register(RMAppEventType.class,
new ApplicationEventDispatcher(this.rmContext));
……
Register函数有两个参数,第一个是事件类型,另一个是事件处理器。
每种事件对应一种事件处理器,一旦该事件发生,事件调度器会直接交由其对应的事件处理器处理,而事件处理器实际上是一个状态机,事件会使一个对象从一种状态变为另一种状态,并触发相应的行为;
RPC服务主要功能是创建一个RPC server,供远程客户端调用提供的服务(接口)。实现时,会继承AbstractService抽象类,实现某个RPC协议,并调用YarnRPC中 的getServer接口创建一个server以供客户端RPC调用。主要涉及四个RPC服务,分别是 ApplicationMasterService(实现AMRMProtocol协议),ResourceTrackerService(实现 ResourceTracker协议),ClientRMService(实现ClientRMProtocol协议)和AdminService(实现 RMAdminProtocol服务)
普通服务继承AbstractService抽象类,一般为一个后台线程或者普通对象。RPC服务和普通服务会被组装到组合服务对象CompositeService中,以便统一进行管理(启动、停止等)。
【四种actor】 四个概念,每个代表一个actor,对应一个状态机。
RMApp:application的状态信息,由org.apache.hadoop.yarn.server.resourcemanager.rmapp/RMAppImpl.java实现。
RMAppAttempt:运行application的一次尝试(每个application从1开始逐步尝 试运行,如果失败,则继续尝试运行,直到成功或者到达某个尝试上限,如果成果,则该application运行成功。一个RMApp可能对一个多个 RMAppAttempt),由org.apache.hadoop.yarn.server.resourcemanager.rmapp.attempt/
RMAppAttemptImpl.java实现
RMContainer:各个container的状态信息,由org.apache.hadoop.yarn.server.resourcemanager.rmcontainer/RMContainerImpl.java实现。
RMNode:YARN集群中每个节点的状态信息,由org.apache.hadoop.yarn.server.resourcemanager.rmnode/RMNodeImpl.java
【PRC服务】
ClientRMService:实现ClientRMProtocal协议,负责与client交互,接收来自client端的请求并作出响应。
ApplicationMasterService:实现了AMRMProtocol通信协议,负责与ApplicationMaster交互,接收来自ApplicationMaster的请求并作出相应。
ResourceTrackerService:实现了ResourceTracker协议,主要负责管理各个NodeManager,如新NodeManager注册,死NodeManager的剔除,会调用NMLivelinessMonitor的一些接口。
AdminService:实现RMAdminProtocol协议,主要负责整个系统权限管理,如哪些client可以修改系统中队列名称,给某些队列增加资源等。
【其他类】
ApplicationMasterLauncher:创建ApplicationMaster
NMLivelinessMonitor:监控各个Nodemanager是否存活,默认情况下,如果某个NodeManage在10min内卫汇报心跳,则认为该节点出现故障。
RMAppManager:application管理者,client端提交的作业会最终提交给该类。
ResourceScheduler:非常核心的组件,application调度器,当某个节点出现空闲资源 使,采用某种策略从application队列中选择某个application使用这些空闲资源。当前有两种调度器: FIFO(First In First Out,默认调度器)和CapacityScheduelr(与Hadoop MapReduce中的Capacity Scheduler思想相同)。
ApplicationACLsManager:Application权限管理,即:对于某个application,哪些用户可以查看运行状态,哪些可以修改运行时属性,如优先级等。
NodesListManager:node列表管理,可以动态往集群中添加节点或者减少节点。
【代码整体划分】
下图是整个ResourceManager相关代码的java package注释:
|