6.1 YARN的架构

6.1 YARN的架构

  下图展示了基于YARN的集群的架构，这个集群的模块主要有以下5种类型。

• 资源管理器（Resource Manager，RM）：每个集群里面都有一个RM守护进程，专门负责集群中可用资源的分配和管理。
• 节点管理器（Node Manager，NM）：每个节点都有一个NM守护进程，负责节点的本地资源管理。在RM中，NM代表本地节点。
• Application Master（AM）：每个应用都有一个AM的守护进程，它封装了应用的所有逻辑结构和依赖的库信息。AM负责于RM进行资源协商，并协同NM工作以完成应用的功能。
• 容器（container）：这是分配给具体应用的资源的抽象表现形式。AM是一个用来启动和管理整个应用生命周期的特殊容器。
• 客户端（client）：这是集群中的一个能向RM提交应用的实例，并且指定了执行应用所需要的AM类型。

6.1.1 资源管理器

  资源管理器有以下两个主要组件：

• 调度器（scheduler）
• 应用管理器（ApplicationsManager）

  调度器负责为集群中执行的各种应用分配资源，而且它执行纯粹的分配资源功能，不会关注应用内部状态相关的任何信息。在应用失败或者硬件故障的时候，调度器不保证能够重启应用。调度是基于RM所了解的集群的全局状态进行的，分配资源的过程中使用了配置的队列和容量参数信息。

  调度的策略可以作为插件参与到调度器中。Hadoop 1.x中，容量调度器（CapacityScheduler）和公平调度器（FairScheduler）是两种很受欢迎的调度策略，它们同样存在于Hadoop 2.x中。

  应用管理器这种组件负责处理客户端提交的应用。另外，它还根据应用的要求和AM协商所需要的容器，并启动应用程序。在应用失败的情况，应用管理器还提供重启AM的服务。

  RM的耦合度是很低的，它使用两个公共接口和一个私有接口与其他组件通信，接口包括：

• 为客户端提交作业的公共接口（Application-Client Protocol）
• 为AM请求资源的公共接口（Application-Master Protocol）
• 与NM交互使用的内部接口

  资源是动态分配的，并且不感知应用的内部状态或者优化措施，这样便可以实现对集群资源的有效利用。AM使用如下参数发送资源申请的请求：

• 请求的容器的数量，例如，100个容器
• 每个容器的详细资源规格信息，例如，2个CPU和4GB内存
• 容器在主机或机架上位置分布的偏好
• 提出的请求在当前应用中的优先级

  RM的调度器获得请求后，基于心跳信息获得的集群状态为AM分配容器，然后将容器转交给AM。在集群资源不足的情况下，RM可能要求AM归还一些容器。如果等待超过一定时间后依然没有容器释放，RM可以终止容器的运行。RM请求AM释放资源可以看成是警告正在执行的AM保存关键数据和工作状态。

6.1.2 Application Master

  当一个应用被提交时，应用管理器（ApplicationsManager）与调度器协商得到一个容器，这个容器为这个特定的应用启动一个AM。AM生成后，会定期向RM发送心跳信息，以实现下面两个操作：

• 通知RM这个AM是否处于活动状态
• 为这个应用申请资源

  在回应心跳信息时，RM分配容器给AM，并且AM可以自由使用这些容器。AM完全负责对容器终止的解释和处理，以及其他应用相关的故障。

  AM使用Application-Master协议与RM进行交互，并且AM直接从NM处获取容器的状态。AM也能通过与NM的交互来启动和停止分配给它的容器。AM与NM之间的交互是通过ContainerManager协议完成的。

  在YARN中，资源管理器使用了延时绑定的模式。容器的产生可能和AM的请求没有关系，而仅仅是与AM给出的一个租约（lease）绑定。AM请求所获得的资源状态可能会随着时间而变化，且申请的资源可用于各种目的而不仅仅是原来计划的用途。

  让我们通过一个虚构的例子，使用MapReduce的AM来展示资源的延时绑定。我们都知道HDFS是在集群的节点之间复制文件的每个块。一个Map任务优先选择在输入数据所在的节点执行。到那个MapReduce的AM请求容器后，它分配一个Map任务到该容器，并且该容器的主机和数据所在的主机是同一台，或离得很近。这个决定仅在AM获得容器后才发生，并且是以一种动态的方式进行的。Hadoop 1.x的JobTracker有一个Web接口(通常是50030端口），由于在Hadoop 2.x中JobTracker已经不存在了，所以这个Web接口也就不可用了。

6.1.3 节点管理器

  NM是每个节点的守护进程，负责本地容器的管理，管理范围从认证到资源监控。它们使用心跳信息向RM汇报状态。容器启动上下文（Container Launch Context，CLC）记录被用于指定容器的配置信息，例如依赖、数据文件路径、环境变量等。NM可以根据CLC中的配置信息启动容器。

  同一AM（AM作为资源的承租人，或者说使用者）的容器间的资源可以共享，另外，只要提供外部资源的URL，也可以下载这些资源及其依赖。NM负责容器的终止操作，依据的是来自AM或RM的请求。如果一个容器超出了它的租约，NM还有权终止这个容器。终止容器的操作包括清理操作，例如删除容器生成的本地数据。

  NM的职责还包括监控本地的物理资源，例如CPU、内存和磁盘的健康状态，并且还将这些状态汇报给RM。RM的调度器会根据NM的负载情况和健康状态做出如何分配容器的决定。

  NM向应用提供日志聚合的服务。标准输出和错误日志会在应用完成的时候输出到HDFS上。NM也能通过配置添加插件式辅助服务（auxiliary service）。例如，一项辅助服务可以让应用的本地数据直到应用结束后才被删除，而不是在容器终止的时候就删除，这对于某些应用场景是很有用的。例如，在MapReduce使用场景下，map任务的输出需要被传输到reducer，这时就可以使用辅助服务来完成。这类服务需要的任何额外配置都可以通过CLC来指定。

6.1.4 YARN客户端

  YARN客户端负责为AM提交合适的CLC。正如之前所说，AM本身也是运行在容器中的，这个容器资源也需要有客户端与RM协商而得到。YARN客户端同时还负责AM的注册，并且可以自由提供其他服务给它的消费者。