ICode9
精准搜索请尝试： 精确搜索
首页
编程语言>
数据库
系统相关
互联网
其他分享
Python
Java
JavaScript
android
PHP
首页 > 其他分享> 文章详细

Hadoop-第七周

2021-05-11 19:30:00  阅读：245  来源： 互联网

标签：Container 第七 ResourceManager 队列 Hadoop 应用程序 RPC NodeManager


一、理解RM基本职能和内部架构

ResourceManager是整个YARN集群中最重要的组件之一，它的设计直接决定了系统的可扩展性、可用性和容错性等特点，它的功能较多，包括ApplicationMaster管理（启动、停止等）、NodeManager管理、Application管理、状态机管理等

ResourceManager负责集群中所有资源的统一管理和分配，它接收来自各个节点的资源汇报信息，并把这些信息按照一定的策略分配给各个应用程序

1.1 ResourceManager基本职能

1.1.1 ResourceManager需通过两个RPC协议与NodeManager和AppMaster交互,具体如下 :

 

  • ResourceTracker : NodeManager通过该RPC协议向ResourceManager注册、汇报节点健康状况和Container运行状态，并领取ResourceManager下达的命令，这些命令包括重新初始化、清理Container等，在该RPC协议中，ResourceManager扮演RPCServer的角色，而NodeManager扮演RPCClient的角色，换句话说，NodeManager与ResourceManager之间采用了“pull模型”,NodeManager总是周期性地主动向ResourceManager发起请求,并通过领取下达给自己的命令 

  • ApplicationMasterProtocol ：应用程序的ApplicationMaster通过该RPC协议向ResourceManager注册、申请资源和释放资源。在该协议中，ApplicationMaster扮演RPC Client的角色，而ResourceManager扮演RPC Server的角色，换句话说，ResourceManager与ApplicationMaster之间采用了“pull模型”

  • ApplicationClientProtocol ：应用程序的客户端通过该RPC协议向ResouceManager提交应用程序、查询应用程序状态和控制应用程序等。在该协议中，应用程序客户端扮演RPC Client的角色，而ResourceManager扮演RPC Server的角色

 

1.1.2ResourceManager主要完成以下几个功能 ：

 

  • 与客户端交互，处理来自客户端的请求

  • 启动和管理AppicationMaster，并在它运行失败时重新启动它

  • 管理NodeManager，接收来自NodeManager的资源汇报信息，并向NodeManager下达管理指令

  • 资源管理与调度，接收来自AppMaster的资源申请请求，并为之分配资源

1.2 ResouceManager内部架构

1.2.1 内部架构图

1.2.2 内部功能

 

  • 用户交互模块。ResourceManager分别针对普通用户、管理员和Web提供了三种对外服务，具体实现分别对应ClientRMService、AdminService和WebApp

    • ClientRMService。ClientRMService是为普通用户提供的服务，它处理来自客户端各种RPC请求，比如提交应用程序、终止应用程序、获取应用程序运行状态等

    • AdminService。ResourceManager为管理员提供了一套独立的服务接口，以防止大量的普通用户请求使管理员发送的管理命令饿死，管理员可通过这些接口管理集群，比如动态更新节点列表、更新ACL列表、更新队列信息等

    • WebApp。为了更加友好地展示集群资源使用情况和应用程序运行状态等信息，YARN对外提供了一个WEB界面，这一部分是YARN仿照Haml开发的一个轻量级嵌入式Web框架

  • NM管理模块。该模块主要涉及以下组件 ：

    • NMLivelinessMonitor。监控NM是否活着，如果一个NodeManager在一定时间内未汇报心跳信息，则认为它死掉了，需将其从集群中移除

    • NodesListManager。维护正常节点和异常节点列表，管理exclude(类似于黑名单)和include(类似于白名单)节点列表，这两个列表均是在配置文件中设置的，可以动态加载

    • ResourceTrackerService。处理来自NodeManager的请求，主要包括注册和心跳两种请求，其中，注册时NodeManager启动时发生的行为，请求包中包含节点ID、可用的资源上限等信息；而心跳时周期性行为，包含各个Container运行状态，运行的Application列表、节点资源状况等信息，作为请求的应答，ResourceTrackerService可为NodeManager返回待释放的Container列表、Application列表等信息

  • AM管理模块。该模块主要涉及以下组件 ：

    • AMLivelinessMonitor。监控AM是否活着，如果一个ApplicationMaster在一定时间内未汇报心跳信息，则认为它死掉了，它上面所有正在运行的Container将被置为失败状态，而AM本身会被重新分配到另外一个节点上执行

    • ApplicationMasterLauncher。与某个NodeManager通信，要求它为某个应用程序启动ApplicationMaster

    • ApplicationMasterService。处理来自ApplicationMaster的请求，主要包括注册和心跳两种请求，其中，注册是ApplicationMaster启动时发生的行为，注册请求包中包含ApplicationMaster启动节点；对外RPC端口号和trackingURL等信息；而心跳而是周期性行为，汇报信息包含所需资源描述、待释放的Container列表、黑名单列表等，而AMS则为之返回新分配的Container、失败的Container、待抢占的Container列表等信息

  • Application管理模块。该模块主要涉及以下组件 ：

    • ApplicationACLsManager。管理应用程序访问权限，包含两部分权限 ：查看权限和修改权限。查看权限主要用于查看应用程序基本信息，而修改权限则主要用于修改应用程序优先级、杀死应用程序等

    • RMAppManager。管理应用程序的启动和关闭

    • ContainerAllocationExpirer。当AM收到RM新分配的一个Container后，必须在一定的时间内在对应的NM上启动该Container，否则RM将强制回收该Container，而一个已经分配的Container是否该被回收则是由ContainerAllocationExpirer决定和执行的

  • 状态机管理模块。ResourceManager使用有限状态机维护有状态对象的生命周期，状态机的引入使得YARN设计架构更加清晰。ResourceManager共维护了四类状态机，分别是RMApp、RMAppAttempt、RMContainer和RMNode

    • RMApp。RMApp维护了一个应用程序的整个运行周期，包括从启动到运行结束整个过程。由于一个Application的生命周期可能会启动多个Application运行实例，因此可认为，RMApp维护的是同一个Application启动的所有运行实例的生命周期

    • RMAppAttempt。一个应用程序可能启动多个实例，即一个实例运行失败后，可能再次启动一个重新运行，而每次启动称为一个运行尝试，用“RMAppAttempt”描述，RMAppAttempt维护了一次运行尝试的整个生命周期

    • RMContainer。RMContainer维护了一个Container的运行周期，包括从创建到运行结束整个过程。RM将资源封装成Container发送给应用程序的ApplicationMaster，而ApplicationMaster则会在Container描述的运行环境中启动任务，因此，从这个层面上讲，Container和任务的生命周期是一致的

    • RMNode。RMNode维护了一个NodeManager的生命周期，包括启动到运行结束整个过程

  • 安全管理模块。ResourceManager自带了非常全面的权限管理机制，主要由ClientTOAMSecretManager、ContainerTokenSecretManager、ApplicationTokenSecretManager等模块完成

  • 资源分配模块。该模块主要涉及一个组件 -- ResourceScheduler。ResourceScheduler是资源调度器，它按照一定的约束条件将集群中的资源分配给各个应用程序，当前主要考虑内存和CPU资源。ResourceScheduler是一个插拔式模块，YARN自带了一个批处理资源调度器 -- FIFO和两个多用户调度器 -- Fair Scheduler和Capacity Scheduler

 

二、理解NM基本职能和内部架构

 

NodeManager是运行在单个节点上的代理,它需要与应用程序的的ApplicationMaster和集群管理者ResourceManager交互: 从ApplicationMaster上接收有关Container的命令并执行之(比如启动,停止Container);

向ResourceManager汇报各个Container运行状态和节点健康状况,并领取有关Container的命令(比如清理Container)。

NodeManager是YARN中单个节点上的代理,它管理Hadoop集群中单个计算节点,功能包括与ResourceManager保持通信,管理Container的生命周期,

监控每个Container的资源使用(内存,CPU等)情况,追踪节点健康状况,管理日志和不同应用程序用到的附属服务

 

2.1 NodeManager基本职能

NodeManager需通过两个RPC协议与ResourceManager服务和各个应用程序的ApplicationMaster交互

2.1.1 ResourceTrackerProtocol协议

NodeManager通过该RPC协议向ResourceManager注册,汇报节点健康状况和Container运行状态,并领取ResourceManager下达的命令,包括重新初始化,清理Container占用资源等.在该RPC协议中,ResourceManager扮演RPC Server的角色,而NodeManager扮演RPC Client的角色

ResourceTrackerProtocol协议主要提供了以下两个RPC函数

(1) registerNodeManager

NodeManager启动时通过该RPC函数向ResourceManager注册,注册信息由RegisterNodeManagerRequest封装的,包括如下三部分内容 :

  • httpPort : 该NodeManager对外提供的HTTP端口号,ResourceManager会在界面上提供一个可直接访问NodeManager Web界面的超链接
  • nodeId : 该NodeManager所在的host和对外的RPC端口号
  • totalResource : 该NodeManager所在节点总的可分配资源,当前支持内存和虚拟CPU两种资源,管理员可通过参数yarn.nodemanager.resource.cpu-vcores和yarn.nodemanager.resource.memory-mb配置

ResourceManager将通过registerNodeManager函数向NodeManager返回一个RegisterNodeManagerResponse类型的对象,主要包含以下信息 :

  • MasterKey : 新生成的Container Token和Node Token的Master Key
  • NodeAction : ResourceManager向该NodeManager返回的下一步操作,主要包括NORMAL,RESYNC,SHUTDOWN三种,分别表示正常,重新同步信息和停止运行
  • rmIdentifier : ResourceManager的标示符,NodeManager通过该标识符判断ApplicationMaster发送的Container来自原始的还是新启动的ResourceManager
  • diagnosticsMessage : NodeManager注册失败时,将收到一段诊断信息,告知具体的失败原因

(2) nodeHeartbeat

NodeManager启动后,定期通过该RPC函数向ResourceManager汇报Container运行信息和节点健康状况,并领取新的命令,比如杀死一个Container

2.1.2 ContainerManagementProtocol协议

应用程序的ApplicationMaster通过该RPC协议向NodeManager发起针对Container的相关操作,包括启动Container,杀死Container,获取Container

ContainerManagementProtocol协议主要提供了以下三个RPC函数 :

  • startContainer : ApplicationMaster通过该RPC要求NodeManager启动一个Contaienr.该函数有一个StartContainerRequest类型的参数,封装了Container启动所需的本地资源,环境变量,执行命令,Token等信息.如果Container启动成功,则该函数返回一个StartContainerResponse对象
  • stopContainer : ApplicationMaster通过该RPC要求NodeManager停止(杀死)一个Container.该函数有一个StopContainerRequest类型的参数,用于指定待杀死的Container ID.如果Container被成功杀死,则该函数返回一个StopContainerResponse对象
  • getContainerStatus : ApplicationMaster通过该RPC获取一个Container的运行状态.该函数参数类型为GetContainerStatusRequest,封装了目标Container的ID,返回值为封装了Container当前运行状态的类型为GetContainerStatusResponse的对象

 

2.2 NodeManager内部架构

  • NodeStatusUpdater : NodeStatusUpdater是NodeManager与ResourceManager通信的唯一通道
  • ContainerManager : ContainerManager是NodeManager中最核心组件之一,它由多个子组件构成,每个子组件负责一部分功能,协作共同管理运行在该节点上的所有Container.各个子组件如下
    • RPC Server : 该RPC Server实现了ContainerManagementProtocol协议,是ApplicationMaster与NodeManager通信的唯一通道
    • ResourceLocalizationService : 负责Container所需资源的本地化.它能够按照描述从HDFS上下载Container所需的文件资源,并尽量将它们分摊到各个磁盘上以防止出现访问热点.此外,它会为下载的文件添加访问控制限制,并为之施加合适的磁盘空间使用份额
    • ContainersLauncher : 维护了一个线程池以并行完成Container相关操作,比如启动或者杀死Container,其中启动Container请求是由ApplicationMaster发起的,而杀死Container请求则可能来自ApplicationMaster或者ResourceManager
    • AuxServices : NodeManager允许用户通过配置附属服务的方式扩展自己的功能,这使得每个节点可以定制一些特定框架需要的服务
    • ContainersMonitor : ContainersMonitor负责监控Container的资源使用量
    • LogHandler : 一个可插拔组件,用户可通过它控制Container日志的保存方式,即是写到本地磁盘上还是将其打包后上传到一个文件系统中
    • ContainerEventDispatcher : Container事件调度器,负责将ContainerEvent类型的事件调度给对应Application的状态机ApplicationImpl
    • ApplicationEventDispatcher : Application事件调度器,负责将ApplicationEvent类型的事件调度给对应Application的状态机ApplicationImpl
  • ContainerExecutor : ContainerExecutor可与底层操作系统交互,安全存放Container需要的文件和目录,进而以一种安全的方式启动和清除Container对应的进程
  • NodeHealthCheckerService : NodeHealthCheckerService通过周期性地运行一个自定义脚本和向磁盘写文件检查节点的健康状况,并将之通过NodeStatusUpdater传递给ResourceManager
  • DeletionService : NodeManager将文件删除功能服务化,即提供一个专门的文件删除服务异步删除失效文件,这样可避免同步删除文件带来的性能开销
  • Security : 安全模块是NodeManager中的一个重要模块,包含两部分
    • ApplicationACLsManager : NodeManager需要为所有面向用户的API提供安全检查,如在Web UI上只能将Container日志显示给授权用户.该组件为每个应用程序维护了一个ACL列表,一旦收到类似请求后会利用该列表对其进行验证
    • ContainerTokenSecretManager : 检查收到的各种访问请求的合法性,确保这些请求操作已被ResourceManager授权
  • WebServer : 通过Web界面向用户展示该节点上所有应用程序运行状态,Container列表,节点健康状态和Container产生的日志等信息

 

三、理解资源调度器FairScheduler调度原理

3.1 代码

各个类作用的简要描述:

1. AllocationConfigurationException, 如果配置文件出错会抛出此异常.

2. AppSchedulable 一个可以提交task的实体, 继承于Schedulable,

3. FairScheduler 调度器的主体部分

4. FairSchedulerConfiguration的配置常量和默认值

5. FairSchedulerEventLog 封装了LOG, 用于把调度事件写到指定的log文件中

6. FifoAppComparator 继承于Comparator, 对比两个AppSchedulable的大小, 首先是Priority, 然后是startTime, 最后对比ApplicationId.

7. FSQueue, fairscheduler中的组信息 类

8. FSQueueSchedulable继承于Schedulable, 一个可以提交task的实体

9. FSSchedulerApp继承于SchedulerApp, 从调度器的角度来看, 每个在RM中正在运行的应用程序都是此类的实例.

10. NewJobWeightBooster, 实现了WeightAdjuster接口, 用于更新AppSchedulable的权重, Weight.

11. QueueManager, 维护一个组队列, 并提供更新方法, fairscheduler调用.

12. Schedulable一个可以提交task的实体

13. SchedulingAlgorithms, 工具类, 包括fair scheduler使用到的调度算法.

14. SchedulingMode, enum类型, 包括FAIR, FIFO. 每个组内的调度模式.

15. 接口WeightAdjuster, 权重修改接口

3.2 Fairscheduler的原理

当 NM (NodeManager的简称)向RM (ResourceManager的简称)发送心跳后, 会调用调度器的nodeUpdate()方法,流程如下:

1. Processing the newly launched containers

2. Process completed containers

3. Assign new containers

a) Check for reserved applications

Reserved, 预留的意思, If we have have an application that has reserved a resource on this node already, we try to complete the reservation.

b) Schedule if there are no reservations. schedule at queue which is furthest below fair share.

    i. 这里首先获取所有组(getQueueSchedulables), 然后对他们排序, 使用SchedulingAlgorithms. FairShareComparator类排序.

    ii. 然后从第一个组开始, 把资源分配给它, 并开始组内分资源,

    iii. 如果未分配给第一组, 则分给下一组, 如果分给了第一组, 则继续到第一步. 若未分配给第一个组, 或重复分配给某一组, 或大于maxAssign, 则退出循环.

 

3.3 SchedulingAlgorithms.FairShareComparator排序算法

两个组, 排序的规则是:

1. 一个需要资源, 另外一个不需要资源, 则需要资源的排前面

2. 若都需要资源的话, 对比 使用的内存占minShare的比例, 比例小的排前面, (即尽量保证达到minShare)

3. 若比例相同的话, 计算出使用量与权重的比例, 小的排前面, 即权重大的优先, 使用量小的优先.

4. 若还是相同, 提交时间早的优先, app id小的排前面.

3.4 配置方法

首先在yarn-site.xml中，将配置参数yarn.resourcemanager.scheduler.class设置为org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler。

Fair Scheduler的配置选项包括两部分，其中一部分在yarn-site.xml中，主要用于配置调度器级别的参数，

另外一部分在一个自定义配置文件（默认是fair-scheduler.xml）中，主要用于配置各个队列的资源量、权重等信息。

3.4.1 配置文件yarn-site.xml\

（1） yarn.scheduler.fair.allocation.file ：自定义XML配置文件所在位置，该文件主要用于描述各个队列的属性，比如资源量、权重等，具体配置格式将在后面介绍。

（2）  yarn.scheduler.fair.user-as-default-queue：当应用程序未指定队列名时，是否指定用户名作为应用程序所在的队列名。如果设置为false或者未设置，所有未知队列的应用程序将被提交到default队列中，默认值为true。

（3）  yarn.scheduler.fair.preemption：是否启用抢占机制，默认值是false。

（4）  yarn.scheduler.fair.sizebasedweight：在一个队列内部分配资源时，默认情况下，采用公平轮询的方法将资源分配各各个应用程序，而该参数则提供了另外一种资源分配方式：按照应用程序资源需求数目分配资源，即需求资源数量越多，分配的资源越多。默认情况下，该参数值为false。

（5）  yarn.scheduler.assignmultiple：是否启动批量分配功能。当一个节点出现大量资源时，可以一次分配完成，也可以多次分配完成。默认情况下，该参数值为false。

（6）  yarn.scheduler.fair.max.assign：如果开启批量分配功能，可指定一次分配的container数目。默认情况下，该参数值为-1，表示不限制。

（7）  yarn.scheduler.fair.locality.threshold.node：当应用程序请求某个节点上资源时，它可以接受的可跳过的最大资源调度机会。当按照分配策略，可将一个节点上的资源分配给某个应用程序时，如果该节点不是应用程序期望的节点，可选择跳过该分配机会暂时将资源分配给其他应用程序，直到出现满足该应用程序需的节点资源出现。通常而言，一次心跳代表一次调度机会，而该参数则表示跳过调度机会占节点总数的比例，默认情况下，该值为-1.0，表示不跳过任何调度机会。

（8）  yarn.scheduler.fair.locality.threshold.rack：当应用程序请求某个机架上资源时，它可以接受的可跳过的最大资源调度机会。

（9）  yarn.scheduler.increment-allocation-mb：内存规整化单位，默认是1024，这意味着，如果一个Container请求资源是1.5GB，则将被调度器规整化为ceiling(1.5 GB / 1GB) * 1G=2GB。

（10）  yarn.scheduler.increment-allocation-vcores：虚拟CPU规整化单位，默认是1，含义与内存规整化单位类似。

3.4.2 自定义配置文件

Fair Scheduler允许用户将队列信息专门放到一个配置文件（默认是fair-scheduler.xml），对于每个队列，管理员可配置以下几个选项：

（1）  minResources ：最少资源保证量，设置格式为“X mb, Y vcores”，当一个队列的最少资源保证量未满足时，它将优先于其他同级队列获得资源，对于不同的调度策略（后面会详细介绍），最少资源保证量的含义不同，对于fair策略，则只考虑内存资源，即如果一个队列使用的内存资源超过了它的最少资源量，则认为它已得到了满足；对于drf策略，则考虑主资源使用的资源量，即如果一个队列的主资源量超过它的最少资源量，则认为它已得到了满足。

（2）  maxResources：最多可以使用的资源量，fair scheduler会保证每个队列使用的资源量不会超过该队列的最多可使用资源量。

（3）  maxRunningApps：最多同时运行的应用程序数目。通过限制该数目，可防止超量Map Task同时运行时产生的中间输出结果撑爆磁盘。

（4）  minSharePreemptionTimeout：最小共享量抢占时间。如果一个资源池在该时间内使用的资源量一直低于最小资源量，则开始抢占资源。

（5）  schedulingMode/schedulingPolicy：队列采用的调度模式，可以是fifo、fair或者drf。

（6）  aclSubmitApps：可向队列中提交应用程序的Linux用户或用户组列表，默认情况下为“*”，表示任何用户均可以向该队列提交应用程序。需要注意的是，该属性具有继承性，即子队列的列表会继承父队列的列表。配置该属性时，用户之间或用户组之间用“，”分割，用户和用户组之间用空格分割，比如“user1, user2 group1,group2”。

（7）  aclAdministerApps：该队列的管理员列表。一个队列的管理员可管理该队列中的资源和应用程序，比如可杀死任意应用程序。

3.4.3 管理员也可通过以下参数设置以上属性的默认值：

 

（1）  userMaxJobsDefault：用户的maxRunningJobs属性的默认值。

（2） defaultMinSharePreemptionTimeout ：队列的minSharePreemptionTimeout属性的默认值。

（3）  defaultPoolSchedulingMode：队列的schedulingMode属性的默认值。

（4）  fairSharePreemptionTimeout：公平共享量抢占时间。如果一个资源池在该时间内使用资源量一直低于公平共享量的一半，则开始抢占资源。
 

3.4.4 举例

yarn-site.xml

<property>
  <name>yarn.resourcemanager.scheduler.class</name>
  <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>
fair-scheduler.xml

<?xml version="1.0"?>
<allocations>
  <queue name="sample_queue">
    <minResources>1000</minResources>
    <maxResources>9000</maxResources>
    <maxRunningApps>50</maxRunningApps>
    <weight>2.0</weight>
    <schedulingMode>fair</schedulingMode>
    <aclSubmitApps> sample_queue,yuling.sh</aclSubmitApps>
    <aclAdministerApps> sample_queue,yuling.sh</aclAdministerApps>
  </queue>
  <queue name="default">
    <minResources>1000</minResources>
    <maxResources>9000</maxResources>
    <maxRunningApps>50</maxRunningApps>
    <weight>2.0</weight>
    <schedulingMode>fair</schedulingMode>
    <aclSubmitApps> yuling.sh</aclSubmitApps>
    <aclAdministerApps> a</aclAdministerApps>
  </queue>
 
  <userMaxAppsDefault>5</userMaxAppsDefault>
</allocations>

3.4.5 疑问解答

1、fair-scheduler.xml中的weight的作用是什么？怎么样能测出来weight的作用？

 weight主要用在资源共享之时，weight越大，拿到的资源越多。比如一个pool中有20GB内存用不了，这时候可以共享给其他pool，其他每个pool拿多少，就是由权重决定的

2、使用fair调度策略，会不会出现负载不均衡的现象？网上说：默认批处理会出现负载不均衡，但每次都是均衡的， 涉及到yarn.scheduler.fair.max.assign 和yarn.scheduler.assignmultiple 两个配置项。这块到底是什么样的？

fair也会出现，均衡不均衡是相对的，只不多这两个参数可以缓解。

3、动态更新资源配额
Fair Scheduler除了需要在yarn-site.xml文件中启用和配置之外，还需要一个XML文件来配置资源池以及配额，而该XML中每个资源池的配额可以动态更新，之后使用命令：yarn rmadmin –refreshQueues 来使得其生效即可，不用重启Yarn集群。

需要注意的是：动态更新只支持修改资源池配额，如果是新增或减少资源池，则需要重启Yarn集群。
 

四、理解资源调度器CapacityScheduler调度原理

4.1 基本思想


容量调度器以队列为单位划分资源，每个队列都有资源使用的下限和上限。每个用户也可以设定资源使用上限。一个队列的剩余资源可以共享给另一个队列，其他队列使用后还可以归还。管理员可以约束单个队列、用户或作业的资源使用。支持资源密集型作业，可以给某些作业分配多个slot（这是比较特殊的一点）。支持作业优先级，但不支持资源抢占。

这里明确一下用户、队列和作业之间的关系。Hadoop以队列为单位管理资源，每个队列分配到一定的资源，用户只能向一个或几个队列提交作业。队列管理体现为两方面：1. 用户权限管理：Hadoop用户管理模块建立在操作系统用户和用户组之间的映射之上，允许一个操作系统用户或者用户组对应一个或者多个队列。同时可以配置每个队列的管理员用户。队列信息配置在mapred-site.xml文件中，包括队列的名称，是否启用权限管理功能等信息，且不支持动态加载。队列权限选项配置在mapred-queue-acls.xml文件中，可以配置某个用户或用户组在某个队列中的某种权限。权限包括作业提交权限和作业管理权限。2. 系统资源管理：管理员可以配置每个队列和每个用户的可用资源量信息，为调度器提供调度依据。这些信息配置在调度器自己的配置文件（如Capacity-Scheduler.xml）中。关于每个配置文件的常见内容见附录。

 

4.2 整体架构

总体来说，容量调度器的工作流程分5个步骤：

1. 用户提交作业到JobTracker。

2. JobTracker将提交的作业交给Capacity Scheduler的监听器JobQueuesManager，并将作业加入等待队列，由JobInitializationPoller线程初始化。

3. TaskTracker通过心跳信息要求JobTracker为其分配任务。

4. JobTracker调用Capacity Scheduler的assignTasks方法为其分配任务。

5. JobTracker将分配到的任务返回给TaskTracker。

接下，我们结合源代码依次研究上述过程。
 

4.3  实现细节

容量调度器（Capacity Scheduler）原理和源码研究

 

五、熟悉YARN应用程序设计方法

YARN上的应用程序主要分为短应用程序（MapReduce）和长应用程序（Storm）

通常而言，编写一个YARN Appcalition会涉及3个RPC协议：

  1. ApplicationClientProtocol
  2. ApplicationMasterProtocol
  3. ContainerManagementProtocol

5.1  客户端编写流程

步骤一 Client通过RPC函数ApplicationClientProtocol#getNewApplication从ResourceManager中获取唯一的application ID

步骤二 Client通过RPC函数ApplicationClientProtocol#submitApplication将ApplicationMaster提交到ResourceManager上

客户端编程库（Yarnclient）

ApplicationMaster设计

AM需要与RM和NM两个服务交互
通过与RM交互，AM可获得任务计算所需的资源
通过与NM交互，AM可启动计算任务（container），并监控直到运行完成

AM-RM编写流程

  1. AM通过RPC函数ApplicationMasterProtocol#registerApplicationMaster向ResourceManager注册
    一旦ApplicationMaster注册成功，RM会为它返回一个RegisterApplicationMasterResponse类型的返回值，该对象包含应用程序可申请的最大资源量、应用程序访问控制列表等信息
  2. ApplicationMaster通过RPC函数ApplicationMasterProtocol#allocate向RM申请资源（以container形式表示）
  3. Application通过RPC函数ApplicationMasterProtocol#finishApplicationMaster告诉Res应用程序执行完毕，并退出。
    ApplicationMaster将重复步骤2，不断为应用程序申请资源，知道资源得到满足或者整个应用程序运行完成。

AM-NM编写流程

  1. ApplicationMaster将申请到的资源二次分配给内部的任务，并通过RPC函数ContainerManagementProtocol#startContainer与对应的NM通信以启动Container（包含任务描述，资源描述等信息），该函数的参数类型为StartContainerRequest，主要包含一个类型为StartContainerRequest的字段
  2. 为了实时掌握各个Container运行状态，AM可通过RPC函数ContainerManagementProtocol#getContainerStatus向NM询问Container运行状态，一旦发现某个Container运行失败，ApplicationMaster可尝试重新为对应的任务申请资源
  3. 一旦一个Container运行失败后，AM可通过RPC函数ContainerManagementProcotol#stopContainer释放Container。

ApplicationMaster编程库

AM-RM编程库

AM-NM编程库

 

 

Yarn应用程序开发和设计流程

 

标签：Container,第七,ResourceManager,队列,Hadoop,应用程序,RPC,NodeManager
来源： https://blog.csdn.net/weixin_44588186/article/details/116143418

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

关于我们 | 联系我们 | 留言反馈

专注分享技术，共同学习，共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有