在现实情况中，用户代码错误不断，进程奔溃，机器故障等等。使用hadoop的好处之一就是可以它能处理这类故障并成功完成任务。需要考虑的实体失败任务为：任务（job），Application Master，NodeManager和ResourceManager。
任务失败
可能存在以下情况：
- MapTask或者ReduceTask中由于代码原因抛出异常，jvm在关闭之前，会通知mrAppMaster这个task任务失败，在mrAppMaster中，错误报告被写入到用户日志并且任务标记为失败，并释放jvm资源，供其他任务使用。对于streaming任务，如果streaming进程以非0退出代码退出，则被标记为失败。这种行为由stream.non.zero.is.failure属性（默认值为true）控制
- jvm突然退出，可能是由于jvm缺陷而导致mr用户代码由于某种特殊原因造成jvm退出。nodeManage会将这消息通知到mrAppMaster，标记此次任务失败
- 任务挂起（可能是由于资源不足造成）：一旦mrAppMaster一段时间没有接收到进度的更新，则将任务标记为失败，nodeManager会将该jvm进程杀死。任务失败时长可以由mapreduce.task.timeout来设置。如果为0 ，则表示关闭。如果关闭这个属性，那么可能会造成长时间运行的任务不会被标记为失败，被挂起的任务就会一直不被释放资源，长时间会造成集群效率降低，因此尽量避免这个设置。同时充分保证每个任务定期更新进度。
处理：当mrAppMaster被告知，一个任务失败的时候，会重新调度该任务。mrAppMaster会尝试避免在以前失败过的nodeManager重新调度该任务。此外，一个任务失败的次数超过4次，将不会再重新调度。这个数值由mapreduce.map.maxattempts控制。如果一个任务失败次数大于该属性设置的，则整个作业都会失败。对于一些应用程序中，不希望少部分任务失败，而导致整个作业失败，因为即使一些任务失败，作业的输出结果也是可用的，我们可用通过运行任务失败的最大比例：maptask由mapreduce.map.failures.maxpercent，reducetask由mapreduce.reduce.failures.maxpercent来设置。任务尝试也是可以用来中止（killed），因为它是一个推测副本（如果一个任务执行时间比预期的慢的时候，会启动另外一个相同的任务作为备份，这个任务为推测执行）或者它所在的nodeManager失败，导致该nodeManager所执行的任务被标记为killed，被中止的任务是不会被记录到任务运行尝试次数。
ApplicationMaster运行失败
在YARN中，ApplicationMaster有几次尝试次数，最多尝试次数由：mapreduce.am.max-attempts和yarn.resourcemanager.am.max-attempts确定，默认为2。mapreduce.am.max-attempts：表示mrAppMaster失败最大次数，yarn.resourcemanager.am.max-attempts表示：在YARN中运行的应用程序失败最大次数。所以如果要设置mrAppMaster最大失败次数，这两个都需要设置。
在ApplicationMaster向resourceManager定期发送心跳，当ResourceManager检查到ApplicationMaster失败的时候，ResourceManager会在新的NodeManager开启新的ApplicationMaster实例。如果是mrAppMaster，则会使用作业历史来恢复作业的运行状态，不必重新运行，由yarn.app.mapreduce.am.job.recovery.enable来控制该功能。
MapReduce客户端向mrAppMaster来轮询进度报告，如果mrAppMaster失败了，则客户端通过询问ResourceManager会定位新的mrAppMaster实例。在整个MapReduce任务作业初始化的时候，客户端会向ResourceManager询问并缓存mrAppMaster地址。
NodeManager运行失败
当NodeManager由于奔溃或者非常缓慢运行而失败，会停止向ResourceManager发送心跳信息。则如果10分钟内（由yarn.resourcemanager.nm.liveness-monitor.expiry-interval-ms来设置，以ms为单位），ResourceManager会停止通知发送的NodeManager，并将起从自己的节点池中移除。
在失败的NodeManager上的任务或者ApplicationMaster将由上面的机制恢复。对于曾经在失败的NodeManager运行并且成功的Map Task，如果属于为完成的作业，则ApplicationMaster则会重新分配资源重新运行，因为输出结果在失败的NodeManager的本地文件系统中，Reduce任务可能无法访问到。
如果在一个NodeManager中，任务失败次数过多，即使自己并没有失败过，则ApplicationMaster则会尽量将任务调度到其他的NodeManager上。失败次数由mapreduce.job.maxtaskfailures.per.tracker设置。
ResourceManager运行失败
在YARN中，ResourceManager失败是个致命的问题，如果失败，任何任务和作业都无法启动。在默认配置中，ResourceManager是单点故障。为了获得高可用（HA），我们需要配置一对ResourceManager，在主ResourceManager失败后，备份ResourceManager可以继续运行。
将所有的ApplicationMaster的运行信息保存到一个高可用的状态存储中（由ZooKeeper或者HDFS备份），这样备份ResourceManager就可以恢复出失败的ResourceManager状态。因为NodeManager在向他们发送的第一个心跳信息时，会用相当块的速度被新的ResourceManager重构（也就是说，nodeManager会向所有的ResourceManager发送心跳信息，汇报资源情况），又因为任务状态时又ApplicationMaster管理，所有，在搞可用存储区，只需要存储ApplicationMaster即可。
当新的ResourceManager从存储区读取ApplicationMaster，然后在集群中重启所有ApplicationMaster。这个行为不会计入到ApplicationMaster尝试。
ResourceManager在主备切换由故障转移器（failover controller）处理。默认情况，failover controller自动工作，由ZooKeeper的Leader选举，保证同一时刻只有一个主ResourceManager。不同于HDFS的HA，该failover controller不必是单独的进程，而是嵌入ResourceManager中。
