Hadoop之Hadoop高容错

Hadoop高容错性大概分为三大块

1：HDFS的副本容错机制
2：YARN的容错机制
3：ZOOKEEPER高可用集群容错性

首先了解一下HDFS的副本机制

##1:为什么要有副本机制##

HDFS视硬件错误为常态，硬件服务器随时有可能发生故障。
为了容错，文件的所有 block 都会有副本。每个文件的 block 大小和副本系数都是可配置
的。应用程序可以指定某个文件的副本数目。副本系数可以在文件创建的时候指定，也可以在之
后改变。
数据副本默认保存三个副本，我们可以更改副本数以提高数据的安全性
在hdfs-site.xml当中修改以下配置属性，即可更改文件的副本数
<property>
      <name>dfs.replication</name>
      <value>3</value>
</property>

##2:副本存放机制##
第一个副本在client所处的节点上即当前节点。如果客户端在集群外，随机选一个。
第二个副本和第一个副本位于相同机架，随机节点。
第三个副本位于不同机架，随机节点。

##3:hdfs容错性##
#对于文件上传#
由于HDFS副本存放机制是默认有三个备份，当前节点一份，同一机架不同任意节点一份，不同
机架任任意节点一份。如果上传过程中某一副本上传失败，那么整个块的上传失败，需要重新启
动这个副本的上传。保证了上传成功的block块有充分的副本，防止在后期文件损坏无副本可
用，提高了文件的安全性，可靠性。

#对于文件下载#
下载失败可能因为备份丢失或节点坏掉，此时会优先调取同一机架另外一个节点的数据备份，
(就近原则，减少网络传输)，如果该机架的机器集体宕机，则从另一个机架上获取数据备份。

YARN的容错机制

##1：yarn组件及原理##

组件一Container是Yarn框架的计算单元，是具体执行应用task（如map task、reduce task）的
基本单位。Container和集群节点的关系是：一个节点会运行多个Container，但一个Container不
会跨节点。
组件二NodeManager是进程运行在集群中的节点上，每个节点都会有自己的NodeManager。
组件三ResourceManager主要有两个组件：ResourceScheduler和ApplicationManager。
组件四ApplicationMaster的主要作用是向ResourceManager申请资源并和NodeManager协同工
作来运行应用的各个任务然后跟踪它们状态及监控各个任务的执行，遇到失败的任务还负责重
启它。
ResourceManager通常运行在NameNode上，NodeManager运行在DataNode上。
ResourceManager管理所有DataNode上的NodeManager，NodeManager负责监控每一台设备
上的系统资源状况，包括CPU、内存、当前节点上运行的任务、存储的文件块信息。通过心跳
机制由NodeManager定时向ResourceManager汇报，以便于实时掌握整个HDFS上的资源状
况。
心跳既是NodeManager向ResourceManager汇报的机制，也是ResourceManager向DataNode
发布任务的机制。

##2：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被
收回。

##3：YARN容错机制##
1：job失败
1.1：MapTask或者ReduceTask中代码异常，jvm在关闭之前，会通知mrAppMaster这个task任
务失败，在mrAppMaster中，错误报告被写入到用户日志并标记任务失败，后释放jvm资源，
供其他任务使用。对于streaming任务，如果streaming进程以非0退出代码退出，则被标记
为失败。这种行为由stream.non.zero.is.failure属性（默认值为true）控制
1.2：jvm突然退出，可能是由于jvm缺陷而导致mr用户代码由于某种特殊原因造成jvm退出。
nodeManage会将这消息通知到mrAppMaster，标记此次任务失败
1.3：任务挂起（可能是由于资源不足造成）：一旦mrAppMaster一段时间没有接收到进度的更
新，则将任务标记为失败，nodeManager会将该jvm进程杀死。任务失败时长可以由
mapreduce.task.timeout来设置。如果为0 ，则表示关闭。如果关闭这个属性，那么可能会造成
长时间运行的任务不会被标记为失败，被挂起的任务就会一直不被释放资源，长时间会造成集群
效率降低，因此尽量避免这个设置。同时充分保证每个任务定期更新进度。
##处理##：当mrAppMaster被告知，一个任务失败的时候，会重新调度该任务。mrAppMaster
会尝试避免在以前失败过的nodeManager重新调度该任务。此外，一个任务失败的次数超过4
次，将不会再重新调度。这个数值由mapreduce.map.maxattempts控制。如果一个任务失败次
数大于该
属性设置的，则整个作业都会失败。对于一些应用程序中，不希望少部分任务失败，而导致整个
作业失败，因为即使一些任务失败，作业的输出结果也是可用的，我们可用通过运行任务失败的
最大比例：maptask由mapreduce.map.failures.maxpercent，reducetask由
mapreduce.reduce.failures.maxpercent来设置。任务尝试也是可以用来中止（killed），因为它
是一个推测副本（如果一个任务执行时间比预期的慢的时候，会启动另外一个相同的任务作为备
份，这个任务为推测执行）或者它所在的nodeManager失败，导致该nodeManager所执行的任
务被标记为killed，被中止的任务是不会被记录到任务运行尝试次数。

2：ApplicationMaster运行失败
在YARN中，ApplicationMaster有几次尝试次数，最多尝试次数由：mapreduce.am.max-
attempts和yarn.resourcemanager.am.max-attempts确定，默认为2。mapreduce.am.max-
attempts：表示mrAppMaster失败最大次数，yarn.resourcemanager.am.max-attempts表示：
在YARN中运行的应用程序失败最大次数。所以如果要设置mrAppMaster最大失败次数，这两
个都需要设置。
在ApplicationMaster向resourceManager定期发送心跳，当ResourceManager检查到
ApplicationMaster失败的时候，ResourceManager会在新的NodeManager开启新的
ApplicationMaster实例。如果是mrAppMaster，则会使用作业历史来恢复作业的运行状态，
不必重新运行，由yarn.app.mapreduce.am.job.recovery.enable来控制该功能。
MapReduce客户端向mrAppMaster来轮询进度报告，如果mrAppMaster失败了，
则客户端通过询问ResourceManager会定位新的mrAppMaster实例。在整个MapReduce
任务作业初始化的时候，客户端会向ResourceManager询问并缓存mrAppMaster地址。

3：NodeManager运行失败
当NodeManager由于奔溃或者非常缓慢运行而失败，会停止向ResourceManager发送心跳信
息。则如果10分钟内（由yarn.resourcemanager.nm.liveness-monitor.expiry-interval-ms来设
置，以ms为单位），ResourceManager会停止通知发送的NodeManager，并将起从自己的节
点池中移除。
在失败的NodeManager上的任务或者ApplicationMaster将由上面的机制恢复。对于曾经在失败
的NodeManager运行并且成功的Map Task，如果属于为完成的作业，则ApplicationMaster则会
重新分配资源重新运行，因为输出结果在失败的NodeManager的本地文件系统中，Reduce任务
可能无法访问到。
如果在一个NodeManager中，任务失败次数过多，即使自己并没有失败过，ApplicationMaster
则会尽量将任务调度到其他的NodeManager上。由mapreduce.job.maxtaskfailures.per.tracker
设置失败次数。

4：ResourceManager运行失败
在YARN中，ResourceManager失败是个致命的问题，如果失败，任何任务和作业都无法启动。
在默认配置中，ResourceManager是单点故障。为了获得高可用（HA），我们需要配置一对
ResourceManager，在主ResourceManager失败后，备份ResourceManager可以继续运行。
将所有的ApplicationMaster的运行信息保存到一个高可用的状态存储中（由ZooKeeper或者
HDFS备份），这样备份ResourceManager就可以恢复出失败的ResourceManager状态。因为
NodeManager在向他们发送的第一个心跳信息时，会用相当块的速度被新的ResourceManager
重构(也就是说，nodeManager会向所有的ResourceManager发送心跳信息，汇报资源情况)，
又因为任务状态时有ApplicationMaster管理，所以在搞可用存储区只需要存储ApplicationMaster
即可。
当新的ResourceManager从存储区读取ApplicationMaster，然后在集群中重启的所有
ApplicationMaster。这个行为不会计入到ApplicationMaster尝试。
ResourceManager在主备切换由故障转移器（failover controller）处理。默认情况，failover 
controller自动工作，由ZooKeeper的Leader选举，保证同一时刻只有一个主
ResourceManager。不同于HDFS的HA，该failover controller不必是单独的进程，而是嵌入
ResourceManager中。

小结：失败原因1：job失败（代码异常/jvm退出/job挂起）  2：ApplicationMaster运行失败  3：
NodeManager运行失败  4：ResourceManager运行失败

ZOOKEEPER容错

以上的所有容错都是基于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重启一遍。
zookeeper服务器判断集群是否可以正常运行，采用的是半数机制，即当可用服务器大于半数时
整个集群仍然可以继续运行，保证了，集群的容错率