Hadoop YARN容错机制

朴灿烈づ我的快乐病毒、 2022-05-27 04:24 260阅读 0赞

在现实情况中，用户代码错误不断，进程崩溃，机器故障等情况均容易造成任务失败。hadoop最主要的好处之一就是它能处理此类故障并能够成功完成作业。

**1、任务失败**  
首先应考虑任务的失败，最常见的情况是map任务或reduce任务中代码运行异常。遇到此情况任务JVM会在退出之前向其父application master发送错误报告，并将此次任务尝试标记为failed（失败），然后释放容器以便资源可以为其他任务使用。

另一种失败模式是任务JVM突然退出，可能由于JVM软件缺陷而导致MapReduce用户代码由于某些特殊原因造成JVM退出。在这种情况下，节点管理器会通知application master将此次任务尝试标记为失败。在此之后，任务JVM进程将被自动杀死。任务被认为失败的时间默认为10分钟，可以以作业为基础（或以集群为基础进行设置：mapreduce.task.timeout）

处理办法：  
当application master被告知一个任务尝试失败后，将重新调度该任务的执行。application master会试图避免在以前失败过的节点管理器上重新调度该任务。此外如果一个任务失败过4次，将不会再重试运行任务的最多尝试次数：mapreduce.map.maxattempts设置)。在默认情况，如果任何任务失败次数大于4，整个作业都会失败。

对于一些应用程序，不希望一旦有少数几个任务失败就终止运行整个作业，因为即使有任务失败，作业的一些结果可能还是可用的。在这种情况下，可以为作业设置在不触发作业失败的情况下允许任务失败的最大百分比。针对map任务和reduce任务的设置可以通过mapreduce.map.failures.maxpercent设置。

**2、应用管理器失败**

YARN中的应用程序在运行失败的时候会有几次尝试机会，就像mapreduce任务在遇到硬件或网络故障时要进行几次尝试一样。  
运行 MapReduce application master的最多尝试次数默认为2。超过后边不会再进行尝试，作业将失败。  
运行 YARN application master的最多尝试次数加以限制默认为2。单个应用程序不可以超过这个限制

如果想增加MapReduce application master的尝试次数，也必须增加集群上YARN的设置。  
恢复过程：  
application master向资源观其发送周期性的心跳，当application master失败时，资源管理器将检测到该失败并在一个新的容器（由节点管理器管理）中开始一个新的master实例。对于MapReduce application master，它将使用作业历史来恢复失败的应用程序所运行任务的状态，使其不必重新运行。默认情况下恢复功能是开启的。

mapreduce客户端向application master轮询进度报告，但是如果它的application master运行失败，客户端就需要定位新的实例。在作业初始化期间，客户端向资源管理器询问并缓存application master的地址，使其每次需要向application master查询时不必重载资源管理器。但是，如果application master运行失败，客户端就会在发出状态更新时请求时经历超时，这时客户端会折回向资源管理器请求新的application master的地址。这个过程对于用户是透明的。

**3、节点管理器失败**

如果节点管理器由于崩溃或运行非常缓慢而失败，就会停止向资源管理器发送心跳信息（或发送频率很低）。如果10分钟内没有收到一条心跳信息，资源管理器将会通知停止发送心跳信息的节点管理器，并且将其从自己的节点池中移除以调度启用容器。

在失败的节点管理器上运行的所有任务或application master都用前两节描述的机制进行恢复。另外，对于那些曾经在失败的节点管理器上运行且成功完成的map任务，如果属于未完成的作业，那么application master会安排他们重新运行。这是由于这些任务的中间输出驻留在失败的节点管理器的本地文件系统中，可能无法被reduce任务访问的缘故。

如果应用程序的运行失败次数过高，那么节点管理器可能会被拉黑，即使节点管理自己并没有失败过。由application master管理黑名单，对于MapReduce，如果一个节点管理器上有超过三个任务失败，application master就会尽量将任务调度在不同的节点上。

**4、资源管理器失败**

资源管理器失败时非常严重的问题，没有资源管理器，作业和任务容器将无法启动。在默认的配置中，资源管理器是个单点故障，这是由于在机器失败的情况下，所有运行的作业都失败且不能被恢复。

为获得高可用性（HA),在双机热备配置下，运行一堆资源管理器是必要的。如果主资源管理器失败了，那么备份资源管理器能够接替，且客户端不会感到明显的中断。

关于所有运行中的应用程序的信息存储在一个高可用的状态存储区中（由zookeeper或HDFS备份），这样备机可以恢复出失败的主资源管理器的关键状态，节点管理器信息没有存储在状态存储区中，因为当节点管理器发送他们的第一个心跳时，这些信息能以相当快的速度被新的资源管理器重构。（因为任务是有application master管理的，因此任务不是资源管理器的状态的一部分。这样要存储的状态量比mapreduce 1 中jobTracker要存储的状态量要更好管理）

当新的资源管理器启动后，他从状态存储区中读取应用程序的信息，然后为集群中运行的所有应用程序重启application master。这个行为不被记为节失败的应用程序尝试。这是因为应用程序并不是因为程序代码错误而失败，而是被系统强制终止的。实际情况中，application master重启不是mapreduce应用程序的问题，因为他们是恢复已完成的任务的工作。

资源管理器从备机到主机的切换是由故障转移控制器（failover controller）处理的。  
默认的故障转移控制器是自动工作的，使用zookeeper的leader选举机制（leader election）以确保同一时刻只有一个主资源管理器。为应对资源管理器的故障转移，必须对客户和节点管理器进行配置，因为他们可能是在和两个资源管理器打交道。客户和节点管理器以轮询方式视图连接每一个资源管理器，直到找到主资源管理器。如果主资源管理器故障，他们将再次尝试直到备份资源管理器变成主机。