ApplictionMaster管理部分主要由三个服务构成,分别是AMLivelinessMonitor、ApplicationMasterLauncher和ApplicationMasterService,它们共同管理ApplicationMaster的生存周期,接下来我们依次介绍这三个服务。

AMLivelinessMonitor

该服务周期性遍历所有ApplicationMaster,如果一个ApplicationMaster在一定时间(可通过参数yarn.am.liveness-monitor.expiry-interval-ms配置,默认为10min)内未汇报心跳信息,则认为它死掉了,它上面所有正在运行的Container将被置为运行失败(RM不会重新执行这些Container,它只会通过心跳机制告诉对应的AM,由AM决定是否重新执行,如果需要,则AM重新向RM申请资源),AM本身会被重新分配到另外一个节点上(管理员可通过参数yarn.resourcemanager.am.max-retries指定每个ApplicationMaster的尝试次数,默认是1次)执行。

ApplicationMasterLauncher

ApplicationMasterLauncher既是一个服务,也是一个事件处理器,它处理AMLauncherEvent类型的事件,该类型事件有两种,分别是请求启动一个AM的“LAUNCH”和请求清理一个AM的“CLEANUP”。ApplicationMasterLauncher维护了一个线程池,从而能够尽快地处理这两种事件。

如果ApplicationMasterLauncher收到了“LAUNCH”类型的事件,它会与对应的NodeManager通信,要求它启动ApplicationMaster。整个过程比较简单,首先创建一个ContainerManager协议的Client,然后向对应的NodeManager发起连接请求,接着将启动AM所需的各种信息,包括命令,Jar包、环境变量等信息,封装成一个StartContainerRequest对象,然后通过RPC函数ContainerManager. startContainer()发送给对应的NM。

如果ApplicationMasterLauncher收到了“CLEANUP”类型的事件,它会与对应的NodeManager通信,要求它杀死ApplicationMaster。整个过程与启动AM的过程类似。

ApplicationMasterService

ApplicationMasterService负责处理来自ApplicationMaster的请求,主要包括三种请求:注册、心跳和清理,其中,注册是ApplicationMaster启动时发生的行为,请求包中包含AM所在节点,RPC端口号和tracking URL等信息;心跳是周期性 行为,包含请求资源的类型描述、待释放的Container列表等,而AMS则为之返回新分配的Container、失败的Container等信息;清理是应用程序运行结束时发生的行为,ApplicationMaster向RM发送清理应用程序的请求,以回收资源和清理各种数据结构。

       ApplicationMasterLauncher启动AM后,AM做的第一件事是向RM注册,这是通过RPC函数AMRMProtocol. registerApplicationMaster()实现的。

       AM运行过程中,需要周期性地通过RPC函数AMRMProtocol.allocate()与RM通信,这主要有以下三个作用:1) 请求资源       2)获取新分配的资源    3)形成心跳,告诉RM自己还活着。        AM运行结束后,需要通过RPC函数AMRMProtocol.finishApplicationMaster()告诉RM自己运行结束,可以回收资源(AM所占用的Container)和清理各种数据结果(比如将该AM从AMLivelinessMonitor监控列表中删除。)

原创文章,转载请注明: 转载自董的博客

本文链接地址: YARN/MRv2 Resource Manager深入剖析—AM管理

微信公众号:hadoop-123,专注于大数据技术分享,欢迎加入!

说点什么

avatar
  Subscribe  
提醒