hadoop中yarn容错机制

在现实情况中，用户代码错误不断，进程奔溃，机器故障等等。使用hadoop的好处之一就是可以它能处理这类故障并成功完成任务。需要考虑的实体失败任务为：任务（job），application master，nodemanager和resourcemanager。

任务失败

最常见的情况就是
1、mapTask或者reduceTask中由于代码原因抛出异常，jvm在关闭之前，会通知mrAppMaster这个task任务失败，在mrAppMaster中，错误报告被写入到用户日志并且任务标记为失败，并释放jvm资源，供其他任务使用。对于streaming任务，如果streaming进程以非0退出代码退出，则被标记为失败。这种行为由stream.non.zero.is.failure属性（默认值为true）控制。
2、jvm突然退出，可能是由于jvm缺陷而导致mr用户代码由于某种特殊原因造成jvm退出。nodeManage会将这消息通知到mrAppMaster，标记此次任务失败。
3、任务挂起（可能是由于资源不足造成）：一旦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，被中止的任务是不会被记录到任务运行尝试次数。

application master运行失败

在yarn中，application master有几次尝试次数，最多尝试次数由：mapreduce.am.max-attempts和yarn.resourcemanager.am.max-attempts。默认为2。mapreduce.am.max-attempts：表示mrAppMaster失败最大次数，yarn.resourcemanager.am.max-attempts表示：在yarn中运行的应用程序（还有很多其他可以应用程序可以在yarn运行）失败最大次数。所以如果要设置mrAppMaster最大失败次数，这两个都需要设置。
在application master向resourceManager定期发送心跳，当resourceManager检查到application master失败的时候，resourceManager会在新的nodeManager开启新的application master实例。如果是mrAppMaster，则会使用作业历史来恢复作业的运行状态，不必重新运行，由yarn.app.mapreduce.am.job.recovery.enable来控制该功能。
mr客户端向mrAppMaster来轮询进度报告，如果mrAppMaster失败了，则客户端通过询问resourceManager会定位新的mrAppMaster实例。在整个mr任务作业初始化的时候，客户端会向reourceManager询问并缓存mrAppMaster地址。

nodeManager运行失败

当nodemanager由于奔溃或者非常缓慢运行而失败，会停止向resourcemanager发送心跳信息。则如果10分钟内（由yarn.resourcemanager.nm.liveness-monitor.expiry-interval-ms来设置，以ms为单位），resourcemanager会停止通知发送的nodemanager，并将起从自己的节点池中移除。
在失败的nodemanager上的任务或者application master将由上面的机制恢复。对于曾经在失败的nodemanager运行并且成功的maptask，如果属于为完成的作业，则application master则会重新分配资源重新运行，因为输出结果在失败的nodemanager的本地文件系统中，reduce任务可能无法访问到。
如果在一个nodemanager中，任务失败次数过多，即使自己并没有失败过，则application master则会尽量将任务调度到其他的nodemanager上。失败次数由mapreduce.job.maxtaskfailures.per.tracker设置。

resourceManager运行失败

在yarn中，resourceManager失败是个致命的问题，如果失败，任何任务和作业都无法启动。在默认配置中，resourceManager是单点故障。为了获得高可用（HA），我们需要配置一对resourceManager，在主resourceManager失败后，备份resourceManager可以继续运行。
将所有的application master的运行信息保存到一个高可用的状态存储中（由zookeeper或者hdfs备份），这样备份resourceManager就可以恢复出失败的resourceManager状态。因为nodeManager在向他们发送的第一个心跳信息时，会用相当块的速度被新的resourceManager重构（也就是说，nodeManager会向所有的resourceManger发送心跳信息，汇报资源情况），又因为任务状态时又application master管理，所有，在搞可用存储区，只需要存储application master即可。
当新的resourceManager从存储区读取application master，然后在集群中重启所有application master。这个行为不会计入到application master尝试。
resourceManager在主备切换由故障转移器（failover controller）处理。默认情况，failover controller自动工作，由zookeeper的leader选举，保证同一时刻只有一个主resourceManager。不同于hdfs的ha，该failover controller不必是单独的进程，而是嵌入resourceManager中。