本文为《 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!!!

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

当图片加载失败时，做处理(onerror)(vue)
问题:在写项目时,使用的img标签总会遇到一些奇奇怪怪的图片,不是加载慢就是加载不出来,所以我们做相应的处理,就能使得用户体验更好了解决: 给img标签一个onerror失败事件,在图片加载失败时做 ...
YARN/MRv2 Resource Manager深入剖析—RM总体架构
在YARN中,ResourceManager负责集群中所有资源的统一管理和分配,它接收来自各个节点(NodeManager)的资源汇报信息,并把这些信息按照一定的策略分配给各个应用程序(实际上是App ...
详解yarn的resource manager组件
详解yarn的resource manager组件
System.Transactions:实现你自己的Resource Manager
By Sahil Malik[http://www.developer.com/net/net/article.php/11087_3565196_1] .net 2.0所带来最大的变化之一也许就是S ...
Oracle Resource Manager 概述
官网的链接说明 About Oracle Database Resource Manager http://docs.oracle.com/cd/E11882_01/server.112/e25494 ...
彻底禁用resource manager
禁用resource manager 由于发现系统的一个等待事件:resmgr:cpu quantum.这是由于resource manager的原因.看来resource manager 的bug还 ...
在 Azure Resource Manager 中为虚拟机设置密钥保管库
Note Azure 具有两种不同的部署模型,用于创建和处理资源:Resource Manager 模型和经典模型.本文介绍使用 Resource Manager 部署模型.Azure 建议对大多数新 ...
使用 Azure CLI 将 IaaS 资源从经典部署模型迁移到 Azure Resource Manager 部署模型
以下步骤演示如何使用 Azure 命令行接口 (CLI) 命令将基础结构即服务 (IaaS) 资源从经典部署模型迁移到 Azure Resource Manager 部署模型. 本文中的操作需要 Az ...
Linux/Ubuntu: 命令行任务（To-Do List）管理 task - A command line todo manager
安装: sudo apt-get install task $ task add some very important task $ task You can also install vit if ...

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