Hadoop基础（四）：Hadoop容错机制

---

一、HDFS副本机制

HDFS对于读写的容错机制是基于HDFS的副本机制

对于文件上传

HDFS副本放置策略是默认三个备份，当前节点一份，同一机架不同节点一份，不同机架任任意节点一份。如果上传过程中某一副本上传失败，那么整个块的上传失败，需要重新启动这个副本的上传。

对于文件下载

下载失败可能因为备份丢失或节点坏掉，此时会优先调取同一机架另外一个节点的数据备份，以减少数据开销。如果该机架的机器集体宕机，则从另一个机架上获取数据备份。

二、YARN容错机制

YARN是如何配合副本机制的

ResourceManager通常运行在NameNode上，NodeManager运行在DataNode上。
ResourceManager管理所有DataNode上的NodeManager，NodeManager负责监控每一台设备上的系统资源状况，包括CPU、内存、当前节点上运行的任务、存储的文件块信息。通过心跳机制由NodeManager定时向ResourceManager汇报，以便于实时掌握整个HDFS上的资源状况。
心跳既是NodeManager向ResourceManager汇报的机制，也是ResourceManager向DataNode发布任务的机制。

YARN执行流程

• 客户端提交作业后，会向ResourceManager申请运行MRAppMaster（运行MapReduce应用程序的AppMaster）。
• ResourceManager为该应用程序分配第一个Container，并与对应的NodeManager建立通信。
• NodeManager创建Container容器，并启动MRAppMaster。
• AppMaster启动时，首先会注册到ResourceManager，启动成功后与ResourceManager保持心跳。
• AppMaster从HDFS上下载Job资源到本地，并根据切片信息创建MapTask和ReduceTask。
• AppMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取Container资源。
• ResourceManager返回AppMaster申请的Containers信息。申请成功的Container，由AppMaster进行初始化。
• Container的启动信息初始化后，AppMaster与对应的NodeManager通信，要求NodeManager启动Container。
• AppMaster与NodeManager保持心跳，从而对NodeManager上运行的任务进行监控和管理。
• Container通过RPC协议向AppMaster汇报自己的状态和进度等信息。以便AppMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。
• 应用程序运行过程中，客户端可以随时通过RPC与AppMaster通信获取应用程序的运行状态、进度更新等信息。
• 应用程序运行结束后，AppMaster向ResourceManager注销自己，并允许属于它的Container被收回。

Map/ReduceTask

AppMaster负责任务的容错

• MapReduce的计算过程中，有可能会启动多个MapTask和ReduceTask。如果某个MapTask失败，AppMaster通过心跳机制向ApplicationManager传递任务失败信息。然后ApplicationManager会重启这个MapTask任务，通过ResourceSchedule去找到另一个副本block所在的节点，并把节点信息反馈给AppMaster。AppMaster通过当前节点的NodeManager把任务传给目标DataNode，在目标DataNode上重建一个Container，并且调取当前节点上的副本block来启动MapTask。

PS：

• 当AppMaster被告知一个任务尝试失败后，将重新调度该任务的执行。AppMaster会试图避免在以前失败过的DataNode上重新调度该任务。默认情况下，如果一个任务失败超过4次，将不会再重试运行任务，即整个作业失败。最多尝试次数可通过mapreduce.map.maxattempts设置。
• 对于一些应用程序，不希望因为少数几个任务失败就终止运行整个作业，因为即使有任务失败，作业的一些结果可能还是可用的。在这种情况下，可以为作业设置在不触发作业失败的情况下允许任务失败的最大百分比。针对MapTask和ReduceTask可以通过mapreduce.map.failures.maxpercent设置。

ApplicationMaster

ResourceManager负责AppMaster的容错

• AppMaster与ResourceManager通过心跳机制保持定期通信，当检测到AppMaster运行失败时，ResourceManager会重新分配Container资源并启动AppMaster。MRAppMaster在作业运行过程中将状态信息动态记录到HDFS上，一旦出现故障重启后，它能够从HDFS读取并恢复之前的运行状态，以减少重新计算带来的开销。

PS：

• 在作业初始化期间，客户端向ResourceManager询问并缓存AppMaster的地址，使其每次需要向AppMaster查询时不必重载ResourceManager。但是如果AppMaster运行失败，客户端就会在发出状态更新时请求时经历超时，这时客户端会折回向ResourceManager请求新的AppMaster的地址。这个过程对于用户是透明的。

NodeManager

• 如果NodeManager由于崩溃或运行非常缓慢而失败，就会停止向ResourceManager发送心跳信息（或发送频率很低）。如果10分钟内没有收到一条心跳信息，ResourceManager将会通知该NodeManager并将其从节点池中移除以调度启用容器。
• 在失败的NodeManager上运行的所有任务或AppMaster都用前两节描述的机制进行恢复。对于那些曾经在失败的NodeManager上运行且成功完成的MapTask，如果属于未完成的作业，那么AppMaster会安排他们重新运行。因为这些MapTask的中间输出保存在失败的NodeManager的本地文件系统中，可能无法被ReduceTask访问。

PS：

• 如果应用程序的运行失败次数过高，那么NodeManager可能会被拉黑。对于MapReduce，如果一个NodeManager上有超过三个任务失败，AppMaster就会尽量将任务调度在不同的节点上。

三、高可用集群HA Cluster

NameNode

ZooKeeper负责NameNode的容错

• 以上的所有容错都是基于DataNode的故障问题进行考虑的，但是NameNode本身就存在单点故障，如果NameNode出现故障，则整个集群会直接宕机。因此HDFS提供了HA的架构，借助于ZooKeeper的机制来完成NameNode的管理。
• 在高可用集群状态下，NameNode会被配置在多台独立的机器上，但只有一个NameNode处于Active状态，其他都是Standby状态。Active状态的NameNode会响应集群中所有的客户端的请求，Standby状态的NameNode只是作为一个副本，保证在必要的时候提供一个快速的转移，使得上层对NameNode的切换无感知。
• 在任务执行期间，ZooKeeper一直在同步Standby NameNode与Active NameNode镜像数据。Active NameNode不断将信息写入共享存储系统，Standby NameNode则不断读取这些信息，使得Active NameNode和Standby NameNode内存中的HDFS元数据保持同步。
• 当ZooKeeper通过和NameNode之间的心跳机制检测到Active NameNode挂掉时，需先保证选中的Standby NameNode信息完全同步后，才会启动它并将状态切换至Active，同时对外启动Job。比如之前挂掉的NameNode上有个Job未执行完，当前Active NameNode刚接过来发现有个未完成的列表，则通过ApplicationManager把这个Job重启一遍。