Hadoop-HA节点介绍

设计思想

1. hadoop2.x启用了主备节点切换模式（1主1备）
2. 当主节点出现异常的时候，集群直接将备用节点切换成主节点
   1. 要求备用节点马上就要工作
   2. 主备节点内存几乎同步
3. 有独立的线程对主备节点进行监控健康状态
4. 需要有一定的选举机制，帮助我们确定主从关系
5. 我们需要实时存储日志的中间件

ActiveNameNode（ANN）

1. Active NameNode 的功能和原理的NN的功能是一样的
2. 接受客户端请求，查询数据块DN信息
3. 存储数据的元数据信息
   1. 数据文件：Block：DN的映射关系
4. 工作
   1. 启动时：接受DN的block汇报
   2. 运行时：和DN保持心跳(3s,10m30s)
5. 存储介质
   1. 完全基于内存
   2. 优点：数据处理效率高
   3. 缺点：数据的持久化(日志edits+快照fsimage)

StandbyNameNode（SNN）

1. Standby NameNode：NN的备用节点
2. 他和主节点做同样的工作，但是它不会发出任何指令
3. 存储：数据的元数据信息
   1. 数据文件：Block：DN的映射关系
   2. 它的内存数据和主节点内存数据几乎是一致的
4. 工作：
   1. 启动时：接受DN的block汇报
   2. 运行时：和DN保持心跳(3s,10m30s)
5. 存储介质
   1. 完全基于内存
   2. 优点：数据处理效率高
   3. 缺点：数据的持久化
6. 合并日志文件和镜像
   1. 当搭建好集群的时候，格式化主备节点的时候，ANN和SNN都会会默认创建
      • fsimage_000000000000000
   2. 当我们操作HDFS的时候ANN会产生日志信息
      • edits_inprogress_0000000000001
   3. 主节点会将日志文件中新增的数据同步到JournalNode集群上
   4. 所以只需要snn有操作的日志信息，就可以合并fsImage与edits信息,理论上是一直在合并数据
      • fsimage -->初始化创建
      • edits-->从JournalNode集群上定时同步
      • 只要同步到edits文件，就开始于fsimage合并
      • 当达到阈值的时候，直接拍摄快照即可
   5. SNN将合并好的Fsimage发送给ANN,ANN验证无误后，存放到自己的目录中

DataNode (DN)

1. 存储
   • 文件的Block数据
2. 介质
   • 硬盘
3. 启动时：同时向两个NN汇报Block信息
4. 运行中同时和两个NN节点保持心跳机制

Quorum JournalNode Manager （QJM）

1. Quorum JournalNode Manager 共享存储系统，NameNode通过共享存储系统实现日志数据同
   步。
2. JournalNode是一个独立的小集群，它的实现原理和Zookeeper的一致( Paxos)
3. ANN产生日志文件的时候，就会同时发送到 JournalNode的集群中每个节点上
4. JournalNode不要求所有的jn节点都接收到日志，只要有半数以上的（n/2+1）节点接受收到日
   志，那么本条日志就生效
5. SNN每间隔一段时间就去QJM上面取回最新的日志
   1. SNN上的日志有可能不是最新的
6. HA集群的状态正确至关重要，一次只能有一个NameNode处于活动状态。
7. JournalNode只允许单个NameNode成为作者。在故障转移期间，将变为活动状态的NameNode
   将承担写入JournalNodes的角色，这将有效地防止另一个NameNode继续处于活动状态，从而使 新的Active节点可以安全地进行故障转移。

Zookeeper Failover Controler（ZFKC）

1. Failover Controller(故障转移控制器)
2. 对 NameNode 的主备切换进行总体控制，能及时检测到 NameNode 的健康状况
   1. 在主 NameNode 故障时借助 Zookeeper 实现自动的主备选举和切换
   2. 为了防止因为NN的GC失败导致心跳受影响，ZKFC作为一个deamon进程从NN分离出来

1. 启动时：
   1. 当集群启动时，主备节点的概念是很模糊的
   2. 当ZKFC只检查到一个节点是健康状态，直接将其设置为主节点
   3. 当zkfc检查到两个NN节点是的健康状态，发起投票机制
   4. 选出一个主节点，一个备用节点，并修改主备节点的状态
2. 运行时：
   1. 由 ZKFailoverController、HealthMonitor 和 ActiveStandbyElector 这 3 个组件来协同实现主备切换
      1. ZKFailoverController启动的时候会创建 HealthMonitor 和 ActiveStandbyElector 这两
         个主要的内部组件
      2. HealthMonitor 主要负责检测 NameNode 的健康状态
      3. ActiveStandbyElector 主要负责完成自动的主备选举，内部封装了 Zookeeper 的处理逻
         辑

• 主备节点正常切换
  • NameNode 在选举成功后，ActiveStandbyElector会在 zk 上创建一个
    ActiveStandbyElectorLock 临时节点，而没有选举成功的备 NameNode 中的
    ActiveStandbyElector会监控这个节点
  • 如果 Active NameNode 对应的 HealthMonitor 检测到 NameNode 的状态异常时，
    ZKFailoverController 会主动删除当前在 Zookeeper 上建立的临时节点
    ActiveStandbyElectorLock
  • 如果是 Active 状态的 NameNode 所在的机器整个宕掉的话，那么跟zookeeper连接的客户
    端线程也挂了,会话结束,那么根据 Zookeepe的临时节点特性，ActiveStandbyElectorLock 节点会自动被删除，从而也会自动进行一次主备切换
  • 处于 Standby 状态的 NameNode 的 ActiveStandbyElector 注册的监听器就会收到这个节点
    的 NodeDeleted 事件，并创建 ActiveStandbyElectorLock 临时节点，本来处于 Standby 状
    态的 NameNode 就选举为Active NameNode 并随后开始切换为 Active 状态。

Zookeeper

1. 为主备切换控制器提供主备选举支持。
2. 辅助投票
3. 和ZKFC保持心跳机制，确定ZKFC的存活

脑裂 Brain-split

1. 定义
   1. 脑裂是Hadoop2.X版本后出现的全新问题，实际运行过程中很有可能出现两个namenode同
      时服务于整个集群的情况，这种情况称之为脑裂。
2. 原因
   1. 脑裂通常发生在主从namenode切换时，由于ActiveNameNode的网络延迟、设备故障等问
      题，另一个NameNode会认为活跃的NameNode成为失效状态，此时StandbyNameNode会
      转换成活跃状态，此时集群中将会出现两个活跃的namenode。因此，可能出现的因素有网
      络延迟、心跳故障、设备故障等。、
3. 脑裂场景
   1. NameNode 可能会出现这种情况，NameNode 在垃圾回收（GC）时，可能会在长时间内整 个系统无响应
   2. zkfc客户端也就无法向 zk 写入心跳信息，这样的话可能会导致临时节点掉线，备NameNode 会切换到 Active 状态
   3. 这种情况可能会导致整个集群会有同时有两个Active NameNode
4. 脑裂问题的解决方案是隔离（Fencing）
   1. 第三方共享存储：任一时刻，只有一个 NN 可以写入
   2. DataNode：需要保证只有一个 NN 发出与管理数据副本有关的命令
   3. Client需要保证同一时刻只有一个 NN 能够对 Client 的请求发出正确的响应。
      1. 每个NN改变状态的时候，向DN发送自己的状态和一个序列号。
      2. DN在运行过程中维护此序列号，当failover时，新的NN在返回DN心跳时会返回自己
         的active状态和一个更大的序列号。DN接收到这个返回是认为该NN为新的active。
      3. 如果这时原来的active（比如GC）恢复，返回给DN的心跳信息包含active状态和原来
         的序列号，这时DN就会拒绝这个NN的命令。
5. 解决方案
   1. ActiveStandbyElector为了实现 fencing，当NN成为ANN之后创建Zookeeper临时节点
      ActiveStandbyElectorLock，创建ActiveBreadCrumb 的持久节点，这个节点里面保存了这个Active NameNode的地址信息(node-01)
   2. Active NameNode的 ActiveStandbyElector在正常的状态下关闭 Zookeeper Session 的时
      候，会一起删除这个持久节点
   3. 但如果 ActiveStandbyElector在异常的状态下关闭，那么由于 /hadoop-
      ha/${dfs.nameservices}/ActiveBreadCrumb 是持久节点，会一直保留下来，后面当另一个
      NameNode 选主成功之后，会注意到上一个 Active NameNode 遗留下来的这个节点，从而
      会回调 ZKFailoverController的方法对旧的 Active NameNode 进行 fencing。
      1. 首先尝试调用这个旧 Active NameNode 的 HAServiceProtocol RPC 接口的
         transitionToStandby 方法，看能不能把它转换为 Standby 状态
      2. 如果 transitionToStandby 方法调用失败，那么就执行 Hadoop 配置文件之中预定义的
         隔离措施
         1. sshfence：通过 SSH 登录到目标机器上，执行命令 fuser 将对应的进程杀死
         2. shellfence：执行一个用户自定义的 shell 脚本来将对应的进程隔离
   4. 在成功地执行完成 fencing 之后，选主成功的 ActiveStandbyElector 才会回调
      ZKFailoverController 的 becomeActive 方法将对应的 NameNode 转换为 Active 状态，开始 对外提供服务