1.任务运行失败
首先考虑任务失败的情况。最常见的情况是map任务或reduce任务中的用户代码抛出运行异常。如果发生这种情况，任务JVM会在退出之前向其父application master发送错误报告。错误报告最后被记人用户日志。application master将此次任务任务尝试标记为failed（失败），并释放容器以便资源可以为其他任务使用。对于Streaming任务，如果Streaming进程以非零退出代码退出，则被标记为失败。这种行为由stream.non.zero.exit.is.failure属性（默认值为true)来控制。
另一种失败模式是任务JVM突然退出，可能由于JVM软件缺陷而导致MapReduce用户代码由于某些特殊原因造成JVM退出。在这种情况下，节点管理器会注意到进程已经退出，并通知application master将此次任务尝试标记为失败。
任务挂起的处理方式则有不同。一旦application master注意到已经有一段时间没有收到进度的更新，便会将任务标记为失败。在此之后，任务JVM进程将被自动杀死。任务被认为失败的超时间隔通常为10分钟，可以以作业为基础（或以集群为基础）进行设置，对应的属性为mapreduce.task.timeout，单位为毫秒。
超时(timeout)设置为0将关闭超时判定，所以长时间运行的任务永远不会被标记为失败。在这种情况下，被挂起的任务永远不会释放它的容器并随着时间的推移最终降低整个集群的效率。因此，尽量避免这种设置，同时充分确保每个任务能够定期汇报其进度。参见7.1.5节进度和状态的更新的补充材料"MapReduce中进度的组成”。
application master被告知一个任务尝试失败后，将重新调度该任务的执行。applicationmaster会试图避免在以前失败过的节点管理器上重新调度该任务。此外，如果一个任务失败过4次，将不会再重试。这个值是可以设置的：对于任务，运行任务的最多尝试次数由mapreduce.map.maxattempts属性控制；而对于reduce任务，则由mapreduce.reduce.maxattempts属性控制。在默认情况下，如果任何任务失败次数大于4（或最多尝试次数被配置为4），整个作业都会失败。
对于一些应用程序，我们不希望一旦有少数几个任务失败就中止运行整个作业，因为即使有任务失败，作业的一些结果可能还是可用的。在这种情况下，可以为作业设置在不触发作业失败的情况下允许任务失败的最大百分比。针对map任务和reduce任务的设置可以通过mapreduce.map.failures.maxpercent和mapreduce.reduce.failures.maxpercent这两个属性来完成。
任务尝试（task attempt）也是可以中止的(killed)，这与失败不同。任务尝试可以被中止是因为它是一个推测副本（相关详情可以参见7.4.2节推测执行）或因为它所处的节点管理器失败，导致application master将它上面运行的所有任务尝试标记为killed。被中止的任务尝试不会被计人任务运行尝试次数（由mapreduce.map.maxattenpts和mapreduce.reduce.maxattempts设置），因为尝试被中止并不是任务的过错。用户也可以使用webUI或命令行方式（输人mapred job查看相应的选项）来中止或取消任务尝试。也可以采用相同的机制来中止作业。
如果一个Streaming进程挂起，节点管理器在下面这种情况中将会终止它（与启动它的JVM一起）：yarn.nodemanager.container-executor.class被设置为org.apache.hadoop.yarn.nodemanager.LinuxContainerExecutor或者默认的容器执行器正被使用并且系统上可以使用setid命令（这样，任务JVM和它启动的所有进程都在同一个进程群中)。对于其他情况，孤立的Streaming进程将堆积在系统上，随着时间的推移，这会影响到利用率。
2.application master运行失败
YARN中的应用程序在运行失败的时候有几次尝试机会，就像MapReduce任务在遇到硬件或网络故障时要进行几次尝试一样。运行MapReduce application master的最多尝试次数由mapreduce.am.max-attempts属性控制。默认值是2，即如果MapReduce application master失败两次，便不会再进行尝试，作业将失败。YARN对集群上运行的YARN application master的最大尝试次数加以了限制，单个的应用程序不可以超过这个限制。该限制由yarn.resourcemanager.am.max-attempts属性设置，默认值是2，这样如果你想增加MapReduce application master的尝试次数，你也必须增加集群上YARN的设置。恢复的过程如下。application master向资源管理器发送周期性的心跳，当application master失败时，资源管理器将检测到该失败并在一个新的容器（由节点管理器管理）中开始一个新的master实例。对于Mapreduce application master，它将使用作业历史来恢复失败的应用程序所运行任务的状态，使其不必重新运行。默认情况下恢复功能是开启的，但可以通过设置yarn.app.mapreduce.am.job.recovery.enable为false来关闭这个功能。
Mapreduce客户端向application master轮询进度报告，但是如果它的application master运行失败，客户端就需要定位新的实例。在作业初始化期间，客户端向资源管理器询问并缓存application master的地址，使其每次需要向application master查询时不重载资源管理器。但是，如果application master运行失败，客户端就会在发出状态更新请求时经历超时，这时客户端会折回向资源管理器请求新的application master的地址。这个过程对用户是透明的。
3.节点管理器运行失败
如果节点管理器由于崩溃或运行非常缓慢而失败，就会停止向资源管理器发送心跳信息（或发送频率很低）。如果10分钟内（可以通过属性yarn.resourcemanager.nm.liveness-monitor.expiry-interval-ms设置，以毫秒为单位）没有收到一条心跳信息，资源管理器将会通知停止发送心跳信息的节点管理器，并且将其从自己的节点池中移除以调度启用容器。在失败的节点管理器上运行的所有任务或application master都用前两节描述的机制进行恢复。另外，对于那些曾经在失败的节点管理器上运行且成功完成的map任务，如果属于未完成的作业，那么applicationmaster会安排它们重新运行。这是由于这些任务的中间输出驻留在失败的节点管理器的本地文件系统中，可能无法被reduce任务访问的缘故。
如果应用程序的运行失败次数过高，那么节点管理器可能会被拉黑，即使节点管理自己并没有失败过。由application master管理黑名单，对于MapReduce，如果一个节点管理器上有超过三个任务失败，application master就会尽量将任务调度到不同的节点上。用户可以通过作业属性mapreduce.job.maxtaskfailures.per.tracker设置该阈值。
注意，在本书写作时，资源管理器不会执行对应用程序的拉黑操作，因此新作业中的任务可能被调度到故障节点上，即使这些故障节点已经被运行早期作业的application master拉黑。
4.资源管理器运行失败
资源管理器失败是非常严重的问题，没有资源管理器，作业和任务容器将无法启动。在默认的配置中，资源管理器是个单点故障，这是由于在机器失败的情况下（尽管不太可能发生），所有运行的作业都失败且不能被恢复。
为获得高可用性（HA），在双机热备配置下，运行一对资源管理器是必要的。如果主资源管理器失败了，那么备份资源管理器能够接替，且客户端不会感到明显的中断。
关于所有运行中的应用程序的信息存储在一个高可用的状态存储区中（由ZooKeeper或HDFS备份），这样备机可以恢复出失败的主资源管理器的关键状态。节点管理器信息没有存储在状态存储区中，因为当节点管理器发送它们的第一个心跳信息时，节点管理器的信息能以相当快的速度被新的资源管理器重构。（同样要注意，由于任务是由applicationmaster管理的，因此任务不是资源管理器的状态的一部分。这样，要存储的状态量比MapReduce1中jobtracker要存储的状态量更好管理。）
当新资源管理器启动后，它从状态存储区中读取应用程序的信息，然后为集群中运行的所有应用程序重启application master。这个行为不被计为失败的应用程序尝试（所以不会计人yarn.resourcemanager.am.max-attempts)，这是因为应用程序并不是因为程序代码错误而失败，而是被系统强行中止的。实际情况中，application master重启不是MapReduce应用程序的问题，因为它们是恢复已完成的任务的工作（详见7.2.2节application master运行失败)。
资源管理器从备机到主机的切换是由故障转移控制器（failover controller)处理的。默认的故障转移控制器是自动工作的，使用ZooKeeper的leader选举机制(leader election）以确保同一时刻只有一个主资源管理器。不同于HDFS高可用性（详见3.2.5节HDFS的高可用）的实现，故障转移控制器不必是一个独立的进程，为配置方便，默认情况下嵌人在资源管理器中。故障转移也可以配置为手动处理，但不建议这样。
为应对资源管理器的故障转移，必须对客户和节点管理器进行配置，因为他们可能是在和两个资源管理器打交道。客户和节点管理器以轮询（round-robin）方式试图连接每一个资源管理器，直到找到主资源管理器。如果主资源管理器故障，他们将再次尝试直到备份资源管理器变成主机。