早期的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.xml和hdfs-site.xml
  • 关于ResourceManager高可靠需要配置的文件有yarn-site.xml    (参数配置及说明见第四章)
  • 操作的过程可通过 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 面板
  •  

最新文章

  1. ffmpeg-20160831-bin.7z
  2. WKWebView
  3. ios 自定义键盘
  4. [转]MYSQL远程登录权限设置
  5. MVC学习中遇到问题
  6. 使用commons-codec包加密字符串(MD5,SHA1,BASE64)
  7. js javascript:void(0) 真正含义
  8. mySQL、mariaDB、noSQL、SQL server、redis之间是什么关系？
  9. 最全Pycharm教程（32）——依据FHS在Linux上安装Pycharm
  10. RAC集群数据库连库代码示例(jdbc thin方式，非oci)
  11. Java开发需掌握的常用Linux命令(持续更新)
  12. 在DOM加载之前insertScript
  13. 【Linux基础】crontab定时命令详解
  14. vuejs中使用echarts
  15. dataTransfer对象
  16. attr VS prop 区别
  17. JDK自带jvisualvm监控工具
  18. mysql 字符编码设置
  19. Go 语言机制之逃逸分析
  20. Nginx + uWSGI 部署Django 项目,并实现负载均衡

热门文章

  1. [转]Raft [Why Not Paxos]
  2. [转Go-简洁的并发 ]
  3. andorid中Html.fromHtml方法
  4. js foreach比for多出两个undefined
  5. ajax 异步调用把返回值赋给一个全局变量的用法，最主要的就是把async属性改为 false,
  6. TextView中的图文混排
  7. html5表单新特性
  8. 课堂所讲整理：HTML--7JavaScript的DOM操作
  9. Javascript高性能动画与页面渲染
  10. java linux book