YARN是一个资源管理、任务调度的框架，主要包含三大模块：ResourceManager（RM）、NodeManager（NM）、ApplicationMaster（AM）。
YARN的基本思想是将资源管理和作业调度/监控的功能分为独立的守护进程。这个想法是拥有一个全局ResourceManager（RM）和每个应用程序独立的ApplicationMaster（AM）。
ResourceManager和NodeManager组成数据计算框架。ResourceManager有系统中的所有应用程序仲裁资源的最终权力。NodeManager负责容器的每机器架构代理，监视其资源使用情况（cpu，内存，磁盘，网络）并向ResourceManager报告。
ApplicationMaster实际上是一个特定库的框架，任务是从ResourceManager协商资源，并与NodeManager一起执行和监视任务。
概述
RM作为守护进程作为群集中的管理者在专用机器上运行她在各种应用程序之间，负责集群统一的资源管理、调度、分配等。根据应用需求，调度优先级和资源可用性，RM将动态分配所谓的容器，用于在特定节点上运行的应用程序。容器是绑定到特定节点的逻辑资源包（例如，2GB RAM，1个CPU）。为了执行和跟踪这些的操作，RM与NodeManager即NM（每个节点上运行的特殊守护进程）交互。RM和NM之间的通信是可扩展性的心跳。 NM负责监控资源可用性，报告错误和容器生命周期管理（例如开始，杀死）。RM通过各个NM的状态掌握集群整体情况。
通过公共协议向RM提交任务作业。并通过许可证控制阶段，验证安全凭证，并执行各种操作和管理检查。接受的作业将传递给要调度程序。一旦有足够的资源，应用程序将从接受状态变为运行状态。除了内部记录，这涉及为AM分配一个容器，并在集群中的一个节点上部署。 接受的记录会被被写入持久存储器，为了在RM重启或故障的情况下恢复。
ApplicationMaster是作业的管理者。包括：动态增加和减少资源消耗，管理执行流程，处理故障和计算偏差以及执行其他本地优化。 事实上，AM可以运行任意用户代码，并且可以用任何编程语言编写，因为与RM和NM的所有通信都使用可扩展通信协议进行编码实现。 通过将所有这些功能委派给AM，YARN的架构可以获得更大的可扩展性，编程模型的灵活性和更好的支持升级/测试（因为同一框架的多个版本可以共存）。
通常，AM将需要利用多个节点上的资源（cpu，RAM，磁盘等）来完成任务。为了获取容器，AM向RM发出资源请求，这些请求包括对容器配置的要求等。 RM将根据可用性和调度策略尝试满足来自每个应用的资源请求。当为AM分配资源时，RM会为AM生成资源的租赁。当AM将容器租赁提交给NM时，会使用基于令牌的安全机制保证其安全性。一旦ApplicationMaster发现容器可用，它将发送启动请求。在MapReduce中，容器中运行的是map任务或reduce任务。如果需要，运行容器可以通过特定于应用程序的协议直接与AM进行通信，以报告状态和活动并接收特定于框架的命令。总的来说，YARN为容器的生命周期管理和监控提供了一个基本的，强大的基础设施。
ResourceManager（RM）
ResourceManager公开了两个公共接口：1）客户端提交应用程序，2）ApplicationMaster动态协商访问资源。以及一个内部接口，用于NodeManagers，对集群监控和资源访问管理。
RM将集群的全局状态与运行中应用程序报告的资源需求相匹配。它需要调度程序准确了解应用程序的资源需求。通信消息和调度器状态必须紧凑而有效，以使RM能够根据应用需求和集群的大小进行扩展。调度程序仅处理每个应用程序的总体资源配置需求，忽略本地优化和应用程序内部流程。YARN完全脱离了map和reduce资源的静态划分，大大提高了集群利用率
ApplicationMasters发送ResourceRequests请求资源，内容包括：
容器数量（例如，200个容器），
每个容器的资源（2GB RAM，1个CPU），
机架位置偏好
应用程序内的请求的优先级
调度程序通过NM的心跳，跟踪，更新可用资源，响应AM请求。RM生成容器和允许访问资源的令牌。 根据NM的报告，RM将容器完成的退出状态转发给负责的AM。 当新的NM加入时，也会通知AM群集，以便可以在新节点上请求资源
另外，协议也允许RM对应地从应用程序请求资源。这通常发生在集群资源变得稀缺并且调度程序决定撤销已给予应用程序的一些资源时。使用类似于ResourceRequests的结构来发送请求（可能是严格的或可协商的）。 AM在实现这种请求方面具有一定的灵活性，例如，通过产生对其工作不太重要的容器，通过检查任务的状态，或者通过迁移计算到其他运行容器。总而言之，协议允许应用程序保存工作状态，不像有些平台强制地杀死容器以满足资源需求。如果应用程序是非协商的，RM可以在等待一定时间后，通过指示NM强制终止容器来获取所需的资源
如所讨论的，ResourceManager不负责协调应用程序执行或任务容错，但也不负责提供运行中应用程序（现在是ApplicationMaster的一部分）的状态或指标，也不提供已完成作业的报告 （现在委托给每个框架的守护进程）。 ResourceManager应该仅处理实时资源调度。
Application Master (AM)
一个应用程序可能是一组静态的进程，一个工作的逻辑描述，甚至一个长时间运行的服务。 ApplicationMaster用来协调应用程序在集群中执行的程序，但它本身就像其他容器一样在集群中运行。 通过与RM组件协商，申请容器来产生此引导过程。AM定期对RM发送心跳以确认其可用性并更新其需求记录。在构建其要求模型之后，AM将其需求和设置发送到RM的心跳消息中。AM将会收到集群中的特定节点的容器租赁权。 基于从RM收到的容器，AM可以更新其执行计划以适应集群的使用状态。
对于MapReduce，AM在具有相同资源需求的map之间进行了本地优化。 在HDFS上运行时，每个输入数据块都在k台机器上复制。 当AM接收到一个容器时，它将与一组挂起的map任务相匹配，选择一个靠近容器输入数据的任务。 在MapReduce的情况下，需要注意，Hadoop JobTracker 提供的一些服务（例如RPC上的作业进度，状态的Web界面，访问MapReduce特定的历史数据）不再是YARN架构的一部分。 这些服务由ApplicationMaster或框架守护程序提供。
由于RM不解析容器状态，AM确定容器退出的成功或失败是通过NM的报告。 AM本身是运行在一个不可靠的集群容器中，所以它应该是有容错性的。
Node Manager (NM)
NodeManager是YARN中的"worker"守护进程。它验证容器租约，管理容器的依赖关系，监控其执行状态，并向容器提供一组服务。报告节点上可用的内存，CPU和其他资源。在RM注册后，NM会发送心跳状态并接收指令。
YARN中的所有容器（包括AM）由容器启动上下文（CLC）描述。 该记录包括环境变量的映射，远程存储的依赖关系，安全令牌，NM服务的有效负载以及启动进程所需的命令。 验证租约的真实性后，NM会对容器的环境进行配置，包括以租约中规定的资源约束，初始化其监控子系统。 要启动容器，NM将所有必需的依赖（数据文件，可执行文件，tar包）复制到本地存储。 如果需要，CLC还验证下载的凭据。 可以在应用程序中的容器之间，由同一租户发起的容器之间共享依赖资源。
NM还将按照RM或AM的指示杀死容器。 当RM报告应用程序完成时，当调度程序决定将其撤销给另一个租户时，或者当NM检测到容器超出其租约限制时，容器可能会被杀死。当不需要相应的工作时，AM可能会请求杀死容器。每当一个容器退出时，NM将清理本地存储中的工作目录。 当应用程序完成时，其容器拥有的所有资源都将（包括仍运行于集群中的相关进程）被丢弃
NM还定期监控物理节点的运行状况。它监控本地磁盘的任何问题，并运行管理员配置的脚本，这可以发现任何硬件/软件问题。 当发现这样的问题时，NM将其状态改变为不健康，并向RM报告，然后使调度程序决定杀死容器或停止对该节点的分配使用，直到健康问题得到解决。除了上述之外，NM还为在该节点上运行的容器提供本地服务。 例如，日志聚合服务。一旦应用程序完成，就会将应用程序写入stdout和stderr的数据上传到到HDFS。
最后，管理员可以使用一组可插拔辅助服务来配置NM。 当容器退出之后，它的本地存储器将被清理。它允许保留一些输出，直到应用程序退出。 以这种方式，一个进程可以产生超过容器寿命的数据，并由该节点管理。 这些服务的一个重要使用是Hadoop MapReduce程序，中间数据可以使用辅助服务，在map和reduce任务之间传输。
容错和可用性
从一开始，Hadoop被设计为运行在普通硬件上。通过在每一层架构上容错，它隐藏了来自硬件故障检测和恢复的复杂性。 YARN继承了这一理念，尽管责任分布在ResourceManager和ApplicationMasters上。
在写入时，RM是YARN中的单一故障点。RM通过持久化存储自身状态，保证故障恢复。在RM停机时，AM可以继续与现有的容器一起运行，并且可以在RM恢复时与RM重新同步。可以通过增加RM备用节点来解决YARN群集的高可用性。
当NM故障时，RM会通过心跳响应检测到，将该节点上运行的所有容器标记为已失效，并报告给所有运行的AM。 如果故障是短暂的，NM将与RM重新同步，清理其本地状态，并继续运行。 在这两种情况下，AM都负责对节点故障作出反应，重做在故障期间运行在该节点上的容器所执行的任务。
由于AM在集群中运行，故障并不影响集群的可用性。由AM故障而导致应用程序间断的可能性高于Hadoop 1.x。 如果AM失败，RM会重新启动AM，尽管该平台不支持恢复AM状态。例如，Hadoop MapReduce AM将恢复其以完成的任务。但运行中的任务和在AM恢复期间完成的任务将被杀死并重新运行。
最后，容器本身的故障处理完全依赖于框架。RM从NM收集所有容器退出事件，并通过心跳将其传播到相应的AM。MapReduce ApplicationMaster已经监听这些通知，并通过从RM请求新的容器来重试map或reduce任务。