本篇博客，博主主要为大家介绍的是什么是NamenodeHA 和 Yarn HA。并在下一篇博客中为大家带来关于搭建HadoopHA集群的详细步骤！
码字不易,先赞后看!
Hadoop High Availability
HA(High Available), 高可用，是保证业务连续性的有效解决方案，一般有两个或两个以上的节点，分为活动节点（Active）及备用节点（Standby）。通常把正在执行业务的称为活动节点，而作为活动节点的一个备份的则称为备用节点。当活动节点出现问题，导致正在运行的业务（任务）不能正常运行时，备用节点此时就会侦测到，并立即接续活动节点来执行业务。从而实现业务的不中断或短暂中断。
Hadoop1.X版本，NN是HDFS集群的单点故障点，每一个集群只有一个NN,如果这个机器或进程不可用，整个集群就无法使用。为了解决这个问题，出现了一堆针对HDFS HA的解决方案（如：Linux HA, VMware FT, shared NAS NFS, BookKeeper, QJM/Quorum Journal Manager, BackupNode等）。
在HA具体实现方法不同情况下，HA框架的流程是一致的, 不一致的就是如何存储、管理、同步edits编辑日志文件。
在Active NN和Standby NN之间要有个共享的存储日志的地方，Active NN把edit Log写到这个共享的存储日志的地方，Standby NN去读取日志然后执行，这样Active和Standby NN内存中的HDFS元数据保持着同步。一旦发生主从切换Standby NN可以尽快接管Active NN的工作。
小结:
高可用方案中NN有两个，一个是Active状态，表示正在对外提供服务的，活跃的NN。StandBy状态，不是对外提供服务的，随时准备替换ActiveNN. ZKFC:监控NN所在节点的硬件设备、软件（NN）、操作系统。同时维护与ZK的通信。HA方案中只有两个NN，每个NN都有一个ZKFC. NN Active 状态和StandBy状态的确认： 两个NN到ZK集群注册一个临时的ZNode,哪个先注册成功，哪个就是Active,另外一个就是StandBy. 当ActiveNN节点故障 ActiveZKFC通知ZK删除临时ZNode StandBy状态的ZKFC订阅这个临时ZNode的变换，若ZNode消失，立刻同时StandBy NN StandBy NN 远程登录NN，执行Kill -9 ActiveNN StandBy NN通知StandBy ZKFC去ZK上注册临时ZNode。 两个元数据信息如何实现快速同步？ JournalNode（JN） :高效的存储系统，能够实现数据的超快速写入与读取。JN是一个小集群（小的文件系统）。节点数需要是奇数台（1、3、5） ActiveNN实时将FSimage和日志接入JN。StandByNN实时获取JN内部的数据，实现两个节点的实时元数据同步。
1. Namenode HA
1.1 Namenode HA详解
hadoop2.x之后，Clouera提出了QJM/Qurom Journal Manager，这是一个基于Paxos算法（分布式一致性算法）实现的HDFS HA方案，它给出了一种较好的解决思路和方案,QJM主要优势如下：
- 不需要配置额外的高共享存储，降低了复杂度和维护成本。
- 消除spof(单点故障)。
基本原理就是用2N 1台 JournalNode 存储EditLog，每次写数据操作有>=N 1返回成功时即认为该次写成功，数据不会丢失了。当然这个算法所能容忍的是最多有N台机器挂掉，如果多于N台挂掉，这个算法就失效了。这个原理是基于Paxos算法。
在HA架构里面SecondaryNameNode已经不存在了，为了保持standby NN时时的与Active NN的元数据保持一致，他们之间交互通过JournalNode进行操作同步。
任何修改操作在 Active NN上执行时，JournalNode进程同时也会记录修改log到至少半数以上的JN中，这时 Standby NN 监测到JN 里面的同步log发生变化了会读取 JN 里面的修改log，然后同步到自己的目录镜像树里面，如下图：
当发生故障时，Active的 NN 挂掉后，Standby NN 会在它成为Active NN 前，读取所有的JN里面的修改日志，这样就能高可靠的保证与挂掉的NN的目录镜像树一致，然后无缝的接替它的职责，维护来自客户端请求，从而达到一个高可用的目的。
在HA模式下，datanode需要确保同一时间有且只有一个NN能命令DN。为此：
每个NN改变状态的时候，向DN发送自己的状态和一个序列号。
DN在运行过程中维护此序列号，当failover时，新的NN在返回DN心跳时会返回自己的active状态和一个更大的序列号。DN接收到这个返回则认为该NN为新的active。
如果这时原来的active NN恢复，返回给DN的心跳信息包含active状态和原来的序列号，这时DN就会拒绝这个NN的命令。
1.2 Failover Controller
HA模式下，会将FailoverController部署在每个NameNode的节点上，作为一个单独的进程用来监视NN的健康状态。FailoverController主要包括三个组件:
HealthMonitor: 监控NameNode是否处于unavailable(不可用的)或unhealthy(不健康的)状态。当前通过RPC调用NN相应的方法完成。
ActiveStandbyElector: 监控NN在ZK中的状态。
ZKFailoverController: 订阅HealthMonitor 和ActiveStandbyElector 的事件，并管理NN的状态,另外zkfc还负责解决fencing（也就是脑裂问题）。
上述三个组件都在跑在一个JVM中，这个JVM与NN的JVM在同一个机器上。但是两个独立的进程。一个典型的HA集群，有两个NN组成，每个NN都有自己的ZKFC进程。
ZKFailoverController主要职责：
- 健康监测：周期性的向它监控的NN发送健康探测命令，从而来确定某个NameNode是否处于健康状态，如果机器宕机，心跳失败，那么zkfc就会标记它处于一个不健康的状态
- 会话管理：如果NN是健康的，zkfc就会在zookeeper中保持一个打开的会话，如果NameNode同时还是Active状态的，那么zkfc还会在Zookeeper中占有一个类型为短暂类型的znode，当这个NN挂掉时，这个znode将会被删除，然后备用的NN将会得到这把锁，升级为主NN，同时标记状态为Active
- 当宕机的NN新启动时，它会再次注册zookeper，发现已经有znode锁了，便会自动变为Standby状态，如此往复循环，保证高可靠，需要注意，目前仅仅支持最多配置2个NN
- master选举：通过在zookeeper中维持一个短暂类型的znode，来实现抢占式的锁机制，从而判断那个NameNode为Active状态
2.Yarn HA
Yarn作为资源管理系统，是上层计算框架（如MapReduce,Spark）的基础。在Hadoop 2.4.0版本之前，Yarn存在单点故障（即ResourceManager存在单点故障），一旦发生故障，恢复时间较长，且会导致正在运行的Application丢失，影响范围较大。从Hadoop 2.4.0版本开始，Yarn实现了ResourceManager HA，在发生故障时自动failover，大大提高了服务的可靠性。
ResourceManager（简写为RM）作为Yarn系统中的主控节点，负责整个系统的资源管理和调度，内部维护了各个应用程序的ApplictionMaster信息、NodeManager（简写为NM）信息、资源使用等。由于资源使用情况和NodeManager信息都可以通过NodeManager的心跳机制重新构建出来，因此只需要对ApplicationMaster相关的信息进行持久化存储即可。
在一个典型的HA集群中，两台独立的机器被配置成ResourceManger。在任意时间，有且只允许一个活动的ResourceManger,另外一个备用。切换分为两种方式：
手动切换：在自动恢复不可用时，管理员可用手动切换状态，或是从Active到Standby,或是从Standby到Active。
自动切换：基于Zookeeper，但是区别于HDFS的HA，2个节点间无需配置额外的ZFKC守护进程来同步数据。
本篇分享的内容就到这里了，下一篇即将为大家带来搭建HA高可用集群的详细步骤，敬请期待!(感兴趣的朋友记得点个关注支持一下~)
