你的位置:首页 > 数据库

[数据库]hadoop(二):hdfs HA原理及安装


     早期的hadoop版本,NN是HDFS集群的单点故障点,每一个集群只有一个NN,如果这个机器或进程不可用,整个集群就无法使用。为了解决这个问题,出现了一堆针对HDFS HA的解决方案(如:Linux HA, VMware FT, shared NAS+NFS, BookKeeper, QJM/Quorum Journal Manager, BackupNode等); 在HA具体实现方法不同的情况下,HA框架的流程是一致的, 不一致的就是如何存储和管理日志。在Active NN和Standby NN之间要有个共享的存储日志的地方,Active NN把EditLog写到这个共享的存储日志的地方,Standby NN去读取日志然后执行,这样Active和Standby NN内存中的HDFS元数据保持着同步。一旦发生主从切换Standby NN可以尽快接管Active NN的工作; 在 HDP2.4安装(五):集群及组件安装 章节使用ambari创建cluster时,默认并未启用 hdfs ha, 可以通过 ambari 管理界面进行安装

目录:

  • SPOF(single point of failure)方案回顾
  • hadoop2.x ha 原理
  • hadoop2.x ha 详述
  • hadoop2.x Federation
  • ha 安装配置

SPOF方案回顾:


  1. Secondary NameNode:它不是HA,它只是阶段性的合并edits和fsimage,以缩短集群启动的时间。当NN失效的时候,Secondary NN并无法立刻提供服务,Secondary NN甚至无法保证数据完整性:如果NN数据丢失的话,在上一次合并后的文件系统的改动会丢失
  2. Backup NameNode (HADOOP-4539):它在内存中复制了NN的当前状态,算是Warm Standby,可也就仅限于此,并没有failover等。它同样是阶段性的做checkpoint,也无法保证数据完整性
  3. 手动把name.dir指向NFS(Network File System),这是安全的Cold Standby,可以保证元数据不丢失,但集群的恢复则完全靠手动
  4. Facebook AvatarNode:Facebook有强大的运维做后盾,所以Avatarnode只是Hot Standby,并没有自动切换,当主NN失效的时候,需要管理员确认,然后手动把对外提供服务的虚拟IP映射到Standby NN,这样做的好处是确保不会发生脑裂的场景。其某些设计思想和Hadoop 2.0里的HA非常相似,从时间上来看,Hadoop 2.0应该是借鉴了Facebook的做法
    • Facebook AvatarNode 原理示例图
    • PrimaryNN与StandbyNN之间通过NFS来共享FsEdits、FsImage文件,这样主备NN之间就拥有了一致的目录树和block信息;而block的位置信息,可以根据DN向两个NN上报的信息过程中构建起来。这样再辅以虚IP,可以较好达到主备NN快速热切的目的。但是显然,这里的NFS又引入了新的SPOF
    • 在主备NN共享元数据的过程中,也有方案通过主NN将FsEdits的内容通过与备NN建立的网络IO流,实时写入备NN,并且保证整个过程的原子性。这种方案,解决了NFS共享元数据引入的SPOF,但是主备NN之间的网络连接又会成为新的问题

hadoop2.X ha 原理:


  • hadoop2.x之后,Clouera提出了QJM/Qurom Journal Manager,这是一个基于Paxos算法实现的HDFS HA方案,它给出了一种较好的解决思路和方案,示意图如下:
  • 基本原理就是用2N+1台 JN 存储EditLog,每次写数据操作有大多数(>=N+1)返回成功时即认为该次写成功,数据不会丢失了。当然这个算法所能容忍的是最多有N台机器挂掉,如果多于N台挂掉,这个算法就失效了。这个原理是基于Paxos算法
  • 在HA架构里面SecondaryNameNode这个冷备角色已经不存在了,为了保持standby NN时时的与主Active NN的元数据保持一致,他们之间交互通过一系列守护的轻量级进程JournalNode
  • 任何修改操作在 Active NN上执行时,JN进程同时也会记录修改log到至少半数以上的JN中,这时 Standby NN 监测到JN 里面的同步log发生变化了会读取 JN 里面的修改log,然后同步到自己的的目录镜像树里面,如下图:
  • 当发生故障时,Active的 NN 挂掉后,Standby NN 会在它成为Active NN 前,读取所有的JN里面的修改日志,这样就能高可靠的保证与挂掉的NN的目录镜像树一致,然后无缝的接替它的职责,维护来自客户端请求,从而达到一个高可用的目的
  • QJM方式来实现HA的主要优势:
    1. 不需要配置额外的高共享存储,降低了复杂度和维护成本
    2. 消除spof
    3. 系统鲁棒性(Robust:健壮)的程度是可配置
    4. JN不会因为其中一台的延迟而影响整体的延迟,而且也不会因为JN的数量增多而影响性能(因为NN向JN发送日志是并行的)

hadoop2.x ha 详述:


  • datanode的fencing: 确保只有一个NN能命令DN。HDFS-1972中详细描述了DN如何实现fencing
    1. 每个NN改变状态的时候,向DN发送自己的状态和一个序列号
    2. DN在运行过程中维护此序列号,当failover时,新的NN在返回DN心跳时会返回自己的active状态和一个更大的序列号。DN接收到这个返回则认为该NN为新的active
    3. 如果这时原来的active NN恢复,返回给DN的心跳信息包含active状态和原来的序列号,这时DN就会拒绝这个NN的命令
  • 客户端fencing:确保只有一个NN能响应客户端请求,让访问standby nn的客户端直接失败。在RPC层封装了一层,通过FailoverProxyProvider以重试的方式连接NN。通过若干次连接一个NN失败后尝试连接新的NN,对客户端的影响是重试的时候增加一定的延迟。客户端可以设置重试此时和时间
  • Hadoop提供了ZKFailoverController角色,部署在每个NameNode的节点上,作为一个deamon进程, 简称zkfc,示例图如下:
  • FailoverController主要包括三个组件:
    1. HealthMonitor: 监控NameNode是否处于unavailable或unhealthy状态。当前通过RPC调用NN相应的方法完成
    2. ActiveStandbyElector: 管理和监控自己在ZK中的状态
    3. ZKFailoverController 它订阅HealthMonitor 和ActiveStandbyElector 的事件,并管理NameNode的状态
  • ZKFailoverController主要职责:
    1. 健康监测:周期性的向它监控的NN发送健康探测命令,从而来确定某个NameNode是否处于健康状态,如果机器宕机,心跳失败,那么zkfc就会标记它处于一个不健康的状态
    2. 会话管理:如果NN是健康的,zkfc就会在zookeeper中保持一个打开的会话,如果NameNode同时还是Active状态的,那么zkfc还会在Zookeeper中占有一个类型为短暂类型的znode,当这个NN挂掉时,这个znode将会被删除,然后备用的NN,将会得到这把锁,升级为主NN,同时标记状态为Active
    3. 当宕机的NN新启动时,它会再次注册zookeper,发现已经有znode锁了,便会自动变为Standby状态,如此往复循环,保证高可靠,需要注意,目前仅仅支持最多配置2个NN
    4. master选举:如上所述,通过在zookeeper中维持一个短暂类型的znode,来实现抢占式的锁机制,从而判断那个NameNode为Active状态

 

hadoop2.x Federation:


  • 单Active NN的架构使得HDFS在集群扩展性和性能上都有潜在的问题,当集群大到一定程度后,NN进程使用的内存可能会达到上百G,NN成为了性能的瓶颈
  • 常用的估算公式为1G对应1百万个块,按缺省块大小计算的话,大概是64T (这个估算比例是有比较大的富裕的,其实,即使是每个文件只有一个块,所有元数据信息也不会有1KB/block)
  • 为了解决这个问题,Hadoop 2.x提供了HDFS Federation, 示意图如下:
  • 多个NN共用一个集群里的存储资源,每个NN都可以单独对外提供服务
  • 每个NN都会定义一个存储池,有单独的id,每个DN都为所有存储池提供存储
  • DN会按照存储池id向其对应的NN汇报块信息,同时,DN会向所有NN汇报本地存储可用资源情况
  • 如果需要在客户端方便的访问若干个NN上的资源,可以使用客户端挂载表,把不同的目录映射到不同的NN,但NN上必须存在相应的目录
  • 设计优势:
    1. 改动最小,向前兼容;现有的NN无需任何配置改动;如果现有的客户端只连某台NN的话,代码和配置也无需改动
    2. 分离命名空间管理和块存储管理
    3. 客户端挂载表:通过路径自动对应NN、使Federation的配置改动对应用透明
  • 思考:与上面ha方案中介绍的最多2个NN冲突?

ha 安装配置:


  • 关于NameNode高可靠需要配置的文件有core-site.和hdfs-site.
  • 关于ResourceManager高可靠需要配置的文件有yarn-site. (参数配置及说明见第四章)
  • 操作的过程可通过 ambarir 的管理界面提供的 "enable NameNode HA" 完成,如下图:
  • 系统要求:至少3台以上zookeeper服务器,在原来基础上,将 hdp2\hdp3\R作为zookeeper
  • 停止HBase所有服务,设置JN安装在host,及standby NN 节点主机,如下图:
  • 按默认配置安装的 secondary NN将去被删除,同时安装 standby NN, 在 R、hdp1、hdp2上配置 JN服务,如下:
  • 登陆至 active NN (hdp4), 执行下面的命令
  • 命令: sudo su hdfs -l -c 'hdfs dfsadmin -safemode enter'    (进入安全模式)
  • 命令: sudo su hdfs -l -c 'hdfs dfsadmin -saveNamespace'    (create checkpoint)
  • ambari 检测到 NN进入安全模式并且checkpoint 后进入组件配置,如图:
  • 初始化JN节点,进入 hdp4,执行命令:sudo su hdfs -l -c 'hdfs namenode -initializeSharedEdits'
  • ambari检测到初始化成功后,进入下一步,如图 start component
  • 手工初始化 NN HA Metadata, 登陆hdp4主机,命令如下:
  • 命令: sudo su hdfs -l -c 'hdfs zkfc -formatZK'
  • 登陆到standy NN (R), 执行命令:
  • 命令: sudo su hdfs -l -c 'hdfs namenode -bootstrapStandby'
  • 成功执行上面命令后,点击“下一步”,开始HA安装,成功后如图:
  • 回到 ambari 面板
  •