Hadoop High Availability(HA高可用)

学习目标

    • 单词简写(必看!!!)
    • 简介
    • Hadoop HA(Hadoop高可用)
      • NameNode HA
      • Failover Controller
      • Hadoop 单点问题解决方案
    • Yarn HA(Yarn高可用)
      • Yarn单点问题解决方案

单词简写(必看!!!)

NameNode(NN)
SecondaryNameNode(SNN)
DataNode(DN)
Zookeeper(ZK)
Active ZKFailoverController(Active ZKFC)
StandBy ZKFailoverController(StandBy ZKFC)
NameNode Active状态(ActiveNN)
NameNode StandBy状态(StandByNN)
JournalNode(JN)
Active ResourceManager(ActiveRM)
Standby ResourceManager(StandbyRM)

简介

        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的工作。

Hadoop HA(Hadoop高可用)

NameNode HA

hadoop2.x之后,Clouera提出了QJM/Qurom Journal Manager,这是一个基于Paxos算法(分布式一致性算法)实现的HDFS HA方案,它给出了一种较好的解决思路和方案,QJM主要优势如下:

  • 不需要配置额外的高共享存储,降低了复杂度和维护成本。
  • 消除spof(单点故障)。
  • 系统鲁棒性(Robust)的程度可配置、可扩展。

        基本原理就是用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,然后同步到自己的目录镜像树里面,如下图:

Hadoop High Availability(HA高可用)_第1张图片
        当发生故障时,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的命令。

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进程。

Hadoop High Availability(HA高可用)_第2张图片
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状态

Hadoop 单点问题解决方案

  • 单点问题:当NameNode宕机时,SNN负责辅助NN工作,不能替换。恢复需要较长时间,这个阶段集群无法对外提供服务,该如何解决?
  • 答:HadoopHA方案解决(该方案中没有SNN,所以无法使用SNN解决)
  • 以下方案提供详解

Hadoop High Availability(HA高可用)_第3张图片
HA方案中有两个NN

  • 一个是Active状态,对外提供服务。
  • 一个是StandBy状态,随时准备替换Active的节点。
  • 注:对外提供服务的只有一个

两个NN如何决定哪个是Active?哪个是StandBy?

  • 两个 NN 到 ZK 注册临时节点(通过ZKFC注册),哪个先注册成功,哪个就是Active,另一个就是 StandBy,且StandBy状态的NN通过ZKFC向ZK订阅临时的Znode(Active状态的NN)的变化状态信息

ZKFC

  • ZKFC监控两种NN状态,以及NN所在节点的硬件、系统、软件(指NN)状态。同时与ZK保持心跳。ZKFC帮助NN在ZK上注册临时的Znode,每个NN都有一个ZKFC(即两种状态的ZKFC)

解决方案

ActiveNN节点发生故障 →
对应的ZKFC监控到故障通知ZK删除临时节点 →
StandByZKFC接收到ZK临时节点发生的变化(在抢占Active状态失败时向ZK订阅了其状态),通知给StandbyNN →
StandbyNN(补刀)远程登录ActiveNN 执行 kill -9 ActiveNN
StandbyNN通知ZKFC 到ZK注册临时Znode成功,StandbyNN切换成Active。

  • 此处解释一下为什么StandbyNN不需要询问ActiveNN是否出现故障就将其进程杀死?
  • ActiveNN和StandbyNN属于抢占关系,为了防止ActiveNN发出假信号给StandbyNN,所以只要StandbyNN通过订阅ZK得到ActiveNN发生故障的状态,不管是真是假直接将其杀死,之后StandbyNN状态上位成为ActiveNN状态,宕机的ActiveNN恢复后会变为StandbyNN。

JournalNode(共享文件系统)

通过JN使得两种状态的NN元数据信息共享

  • 创建一个小的文件系统JN,是一个读写效率极高的文件系统,节点数必须是奇数台(2n+1)
  • ActiveNN 实时将元数据信息写入到JN,StandbyNN实时读取JN元数据信息

在HA方案中不能有SNN,在安装部署的时候就不能安装,所以方案要么是NN+SNN,要么是NN+StandbyNN,只能二选一,该方案中只能有一个StandbyNN。

Yarn HA(Yarn高可用)

        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守护进程来同步数据。

Yarn单点问题解决方案

Hadoop High Availability(HA高可用)_第4张图片

        在YarnHA方案中,两个RM(ActiveRM、StandbyRM)直接到ZK上面注册临时Znode,哪个先创建,哪个就是Active,另一个是Standby。

        ActiveRM、StandbyRM两者之间的切换:StandbyRM订阅Znode,当ActiveRM状态的Znode删除后,StandByRM状态切换为ActiveRM。

你可能感兴趣的:(【大数据】High,Availability,HA,高可用,Hadoop,大数据,Yarn)