YARN - Task, Node manager, AppMaster, Resource manager 失败时所做的处理

本文为《 Hadoop 权威指南第四版 》(英文原版) 读书笔记，仅限交流使用，转载请注明出处，多谢。

YARN - 失败时所做的处理

Henvealf/文

YARN 的失败总共包含四种实体的失败：task，application master，node manager 和 resource manager。

Task 失败

task 的运行也都会称为 尝试(attempt) task。可以理解为 task 的运行被认为是试试看看，不能保证一定会成功。

task 失败的第一种情况就是用户的 map task 或者 reduce task 代码在执行的之后抛出了运行时异常。如果发生了，就做以下操作:

• task JVM 会在退出之前报告失败给他的 AppMaster。
• 错误会立刻写进用户的日志中。
• AppMaster 将 task 标记为 fail。
• 释放 task 的容器，以留给其他的 task 使用。

对于 Streaming task，如果程序执行的退出码是 0，就将其标记为 fail。这个行为是使用 stream.non.zero.exit.is.failure 属性来设置的。

task 失败的另一种情况就是 JVM 意外的退出 – 可能是因为 MapReduce 用户配置的环境导致了 JVM 出现了 bug。 在这种情况下，

• node manager 注意到处理已经退出，就报告给 AppMaster。
• AppMaster 就会将 task 标记为 failed。

挂起的 task 使用不同的方式处理。

• AppMaster 注意到 task 有一段时间没有发来执行状态的更新,就将其标记为 filed。
• JVM 进程会在当前周期后自动的被杀掉。

超时周期是考虑经过多长时间将 task 考虑为失败的规则，一般为 10 分钟，通过 mapreduce.task.timeout 属性来设置，值的单位为毫秒。

设置超时时间为 0 意味着关闭超时，所以长时运行的 task 永远不会被标记为 failed 。在挂起的例子中，task 的容器将永远不会被释放，随着时间的流逝，集群会逐渐被托慢。最好不要这样设置。

如果 AppMaster 被告知 task 的尝试失败了，他将会重新调度来执行该 task。 AppMaster 会努力不将 task 重新调度到先前失败的 node manager 之下。幸运的是，当 task 失败了四次，就不再重新运行他。 尝试次数是可以设置的，通过 mapreduce.map.maxattempt 属性设置 map 尝试次数。通过 mapreduce.reduce.maxattempt 设置 reduce 尝试次数。默认为4.

在一些应用中，不希望因为少数的 task 失败而造成 job 中途夭折。这时，可以设置失败 task 的比例，失败的 task 在此比例内，就不会触发 job 的失败。同样通过配置来设置:
mapreduce.map.failures.maxpercents 和 mapreduce.map.failures.maxpercents

一个尝试的 task 可能会被杀死，但是和失败是有所不同的。task 可能因为他是一个 speculative duplicate(推测复制品)，或者是因为 node manager 运行失败才被杀死的。 AppMaster 会将他们标记为 killed。标记为 killed 的 tas 重新运行时不会记录尝试次数。

用户也可以使用命令行(mapred job)或者web页面来手动杀死或者让task 失败。

Application Master 失败

和 MapReduce 的 task 一样， AppMaster 失败了，也会试着重新运行几次。次数配置项为: mapreduce.am.max-attempts ， 默认为2。

YARN 会在高水平上限制任何 AppMaster 的尝试次数，任何应用程序都不能超过这个限制。配置项为: yarn.resourcemanager.am.max-attempt ,默认为2。所以你要增加 AppMaster 的尝试次数，别忘了设置该属性。

恢复 AppMaster 的工作如下:

• AppMaster 会周期性的发送心跳给 resource manager， 如果 AppMaster 失败了， resource manager 收不到心跳消息，就认为 AppMaster 失败了，就实例化一个新的 AppMaster 让其运行在一个新的容器里。然后 AppMaster 将会使用 job 历史来恢复该应用程序的 task 的状态，所以没必要重新运行他们。 恢复 task 是默认激活的，设置 yarn.app.mapreduce.am.job.recovery.enable 为 false 来关闭。

• MapReduce 客户端会从 AppMaster 那里拉取执行报告，但是如果他的 AppMaster 失败了，客户端就需要去定位新的 AppMaster 的位置。在 job 初始化之前， 客户端会向 resource manager 询问 AppMaster 的地址，并将地址缓存起来，这样就不需要每次都重询问了。如果 AppMaster 失败了，客户端察觉到 AppMaster 出现问题，就去 resource manager 去询问新的 AppMaster 地址。

当然他们对用户来说是透明的。

Node Manager 失败

如果 node manager 突然失败了或者运行异常的慢，发送给 resource manager 的心跳信息就会停止，当 resource manager 发觉一个 node manager 过了10分钟都没有再发送心跳(该时间通过 yarn.resourcemanager.nm.liveness-monitor.expiry-interval-ms 属性来设置，单位为毫秒)，就将他从包含了调度容器的节点池中移除。

任何在失败 node manager 的 task 或者 AppMaster 会使用上两节提到的方式进行恢复。除此之外， 如果失败的 node manager 属于是未完成的 job，AppMaster 会安排在失败 node manager 之下的还正在运行或者已经完成的 map task 重新运行，这样是因为失败node manager 所在的本地上中间文件， reduce task 已经获取不到了。

如果一个 node manager 管理的节点发生的失败太多了，该 node manager 就会被列入黑名单，即使 node manager 自己并没有发生失败。黑名单由 AppMaster 管理，如果在 node manager 上失败了3次，MapReduce 的 task 会被 AppMaster 重新调度到其他节点上。该次数配置项目为: mapreduce.job.maxtaskfailures.per.tracker 。

注意程序之间的的黑名单并不会共享。所以其他引用程序也可能将 job task 调度到坏的节点上。(现在或许会有所改变)

Resource Manager 失败

Resource Manager 的失败是非常可怕的。因为没有他，job 和 task 都无法开启。在默认配置下，Resource Manager 失败了就无法恢复了，所有的 job 也都会失败。

为了实现高可用性(HA),所以运行一对 actice-standby(活跃-备用) 配置的 Resource Manager 是必要的。活跃的 Resource Manager 失败了， 备用的 Resource Manager 就能在客户端很难察觉的中断后马上接管过来。

正在运行的所有应用程序的信息就保存在高科用的存储介质(比如 ZooKeeper 或者 HDFS)上，以至于备用 Resource Manager 能够恢复失败的活跃 Resource Manager 的核心状态。而 node manager 的状态没有保存下来，这些状态会根据 node manager 发送来的第一次心跳消息来很快的重新构造。

当新的 Resource Manager 开启了，他从状态存储里读取应用程序信息，接着为运行在集群上的所有应用程序重启 AppMaster。且这次重启并不会计为尝试次数，因为原来的 AppMaster 是被系统给杀死的。且 AppMaster 的重启方式见上面 Application Master 失败中的内容。

Resource Manager 从活跃到备用的转换是使用一个失效备援(failover)控制器来掌握的.默认的失效备援控制器是自动的 ZooKeeper 大领导，他能保证一个时刻只会有一个 resource manager 处于活动之中。与 HDFS HA 不一样的是， 失效备援控制器 不是一个单机进程，并且为了配置简单，默认是嵌入在 resource manager 中的。也能手动的配置 失效备援控制器，但是不推荐。

客户端与 node manager 也必须配置去掌握 resource manager 的失效备援，因为这里一共有两个 resource manager 可以联系。 他们会试图使用轮询的方式去连接每一个 resource manager，知道他们发现了活跃的一个。如果活跃的失败了，他们又会重新尝试直至找到变成活跃的备用 resource manager。

---

End!!!