MapReduce的容错机制

Failures

在现实世界中，难免遇到用户代码错误、进程崩溃、机器宕机等情况。使用Hadoop的一个好处是它有能力处理这些失败，使你的job能够成功完成。我们需要考虑以下实体的失败：task、application master、node manager 、resource manager。

Task Failure

考虑第一种情况task失败。最常见的task 失败是在map或reduce task中的用户代码抛出一个运行时异常。如果发生这种情况，JVM在退出之前将向父application master报告一个错误，错误最终会被写进用户的日志中。application master将task标记为失败，并且释放container，以便其资源可用于其它的task。

对于Streaming task，如果Streaming Process以非零代码退出（即非正常退出），它将被标记为失败。这种行为有stream.non.zero.exit.is.failure属性控制（默认为true）。

另一种失败的情况是JVM突然退出——也许有一个JVM bug导致JVM的退出。在这种情况下，node manager通知application master task进程已经退出，然后application master尝试标记task为失败状态。

对挂起task的处理有些不同，如果application master 感知到它已有一段时间没有接收到进度更新的通知，它会将task标记为failed，并且在一段时间后会自动杀掉JVM进程。任务视为失败的超时时间通常为10分钟，也可以通过设置mapreduce.task.timeout属性值（单位为毫秒）针对每个job进行配置。

设置mapreduce.task.timeout的属性值为0将禁用超时失败的约束，对于长时间运行的task来说，将永远不会被标记为failed，挂起的task将永远不会释放container，并且，随着时间的推移可能会导致集群变慢。这种情况是应该要避免的，并且确保任务定期报告进度就可以了。

当application master被告知一个task已经失败，那么它会重新调度执行task。application mastet会尽量避免在之前失败的同一个节点上重新调度task。此外，如果一个task失败4次，将不会被再次重试。这个次数是可以配置的。运行job的最大尝试次数是由map task的mapreduce.map.maxattempts属性和reduce task的mapreduce.reduce.maxattempts属性值控制的。默认，任何一个task失败了4次（或是配置的最大尝试次数），那么整个job都将是失败的。

对于一些应用，如果仅有少数的task失败，并不希望终止job，因为尽管有些失败，但是结果也许还是可以用的。在这种情况下，可以为job设置允许task失败而不会触发job失败的最大百分比。Map task和Reduce task是使用mapreduce.map.failures.maxpercent 和mapreduce.reduce.failures.maxpercent属性来单独控制的。

一个task被杀死，和它失败是不同的。一个task被杀死可能是因为它投机性的重复，或是node manager运行故障、或是application master要杀死所有运行在其上的task。被杀死的task不会再被尝试重新调度，因为这不是task的错误，而是被杀死的。

用户也可以通过Web UI或命令行来杀死或失败task，同样，Job也是可以被杀死的。

Application Master Failure

就像MapReduce的task，对于失败的task会尝试几次重新调度，同样在YARN中的应用如果失败了也会重新尝试运行。尝试运行MapReduce application master的最大次数是由mapreduce.am.max-attempts属性控制的，默认值为2。所以如果一个MapReduce application master失败了两次，那么它将不会被再次尝试，MapReduce Job将失败。

YARN规定了MapReduce application master在集群中的最大尝试次数，独立的应用不能超过这个限制。这个限制通过yarn.resourcemanager.am.max-attempts属性设置，默认为2，所以，如果你想增加MapReduce application master的尝试次数，还必须要在集群中增加YARN的设置。

恢复方式如下：application master 定期发送心跳到resource manager，包括application master失败的事件，如果resource manager 检测到失败的事件，会在一个新的container重新启动一个application master的实例（由node manager管理）。对于新的MapReduce application master来说，它会根据已失败的application运行的job的历史记录来恢复task的状态，所以不需要重新运行它们。恢复默认是启用的，但可以通过设置yarn.app.mapreduce.am.job.recovery.enable属性值为false禁用它。

MapReduce客户端会向application master轮询进度报告，但是如果application master失败了，客户端需要重新查找一个新的实例。在job初始化期间，客户端会向resource manager询问application master的地址，然后缓存它，所以它每次轮询application master的请求不会使resource manager超载。但是，如果application master失败了，客户端的轮询请求将会超时，此时客户端会向resource manager请求一个新的application master的地址。这个过程对用户是透明的。

Node Manager Failure

如果一个node manage节点因中断或运行缓慢而失败，那么它将不会发送心跳到resource manager（或者发送次数较少）。如果resource manage在10分钟内（这个配置可以通过yarn.resourcemanager.nm.liveness-monitor.expiry-interval-ms属性设置，以毫秒为单位）没有接收到一个心跳，它会感知到node manager已经停了，并把它冲节点集群中移除。

在出现故障的node manager节点上运行的任何task或application master将会按上两节描述的机制来恢复。另外，对于出现故障的node manager节点，application master分配在其上已经成功运行完成的map task，如果这些map task属于未完成的Job，它们将会被重新运行，因为它们的中间输出存放在故障node manager节点的本地文件系统中，reduce task可能不能访问。

对于一个应用来说，如果node manage出现故障的机率比较高，它可能会被列入黑名单（blacklisted），即使node manager自身没有出现故障。黑名单是由application master管理的，如果一个node manager有3个以上的task失败，application master将会在其它的节点上重新调度这些task。用户可以使用job的mapreduce.job.maxtaskfailures.per.tracker属性设置一个阈值。

需要注意的是：resource manager 并不管理黑名单，所以，对于新的job的task，在一个即使被之前job正在运行的application master加入黑名单的node manager节点上也是可以被调度。

Resource Manager Failure

Resource manager出现故障是比较严重的，因为没有它，job 和 task都不能被启动。默认配置，resource manager是一个单点故障，因为在机器出现故障时，所有的job都会失败，并且不能被恢复。

为了实现高可用（HA），有必要以一种active-standby（活动-备用）配置模式运行一对resource manager。如果活动的resource manager出现故障，备用的resource manager可以很开的接管，并且对客户端来说没有明显的中断现象。

有关所有运行的应用信息都会被存储在一个具有高可用的状态存储中（比如Zookeeper或HDFS），所以，备用的resource manager可以恢复到出现故障的活动的resource manager的核心状态。node manager的信息并没有存储在状态存储中，因为在node manager向新的resource manager 发送第一个心跳时，它可以从新的resource manager中快速重建。（要注意的是task不是resource manager状态的一部分，因为task是由application master管理的。因此，和MapReduce 1中的jobtracker相比，要更容易管理）。

当新的resource manager启动，它从状态存储中读取应用信息，然后为集群中正在运行的所有应用重启application master。这不会被计入失败应用的尝试次数（即不计入yarn.resourcemanager.am.max-attempts），因为application并没有因错误的代码而失败，而是被系统强制杀死的。实际上，application master的重启并不影响MapReduce application，因为它们会通过已完成的task来恢复工作。

resource manager从standby转为active，是由故障控制器处理的。故障控制器默认是自动的，它使用ZooKeeper的选举领导者的方式，确保在同一时间只有一个active resource manager。

不像HDFS的高可用（见http://blog.csdn.net/qiruiduni/article/details/48010745这篇文章的“HDFS High Availability”部分），故障控制器不必是一个独立的进程，而是默认嵌入到resource manager中的，当然也是可以手动配置的，但不推荐这样做。

客户端和node manager必须被配置来处理resource manager的故障切换，因为存在两种可能与resource manager通信。它们会以循环的方式尝试连接每一个resource manager，直到找到一个active manager。如果active resource manager出现故障，它们将重试直到standby resource manager变为active resource manager。