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的主要优势:
-
- 不需要配置额外的高共享存储,降低了复杂度和维护成本
- 消除spof
- 系统鲁棒性(Robust:健壮)的程度是可配置
- JN不会因为其中一台的延迟而影响整体的延迟,而且也不会因为JN的数量增多而影响性能(因为NN向JN发送日志是并行的)
hadoop2.x ha 详述:
- datanode的fencing: 确保只有一个NN能命令DN。HDFS-1972中详细描述了DN如何实现fencing
-
- 每个NN改变状态的时候,向DN发送自己的状态和一个序列号
- DN在运行过程中维护此序列号,当failover时,新的NN在返回DN心跳时会返回自己的active状态和一个更大的序列号。DN接收到这个返回则认为该NN为新的active
- 如果这时原来的active NN恢复,返回给DN的心跳信息包含active状态和原来的序列号,这时DN就会拒绝这个NN的命令
- 客户端fencing:确保只有一个NN能响应客户端请求,让访问standby nn的客户端直接失败。在RPC层封装了一层,通过FailoverProxyProvider以重试的方式连接NN。通过若干次连接一个NN失败后尝试连接新的NN,对客户端的影响是重试的时候增加一定的延迟。客户端可以设置重试此时和时间
- Hadoop提供了ZKFailoverController角色,部署在每个NameNode的节点上,作为一个deamon进程, 简称zkfc,示例图如下:
- FailoverController主要包括三个组件:
-
- HealthMonitor: 监控NameNode是否处于unavailable或unhealthy状态。当前通过RPC调用NN相应的方法完成
- ActiveStandbyElector: 管理和监控自己在ZK中的状态
- ZKFailoverController 它订阅HealthMonitor 和ActiveStandbyElector 的事件,并管理NameNode的状态
- 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状态
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上必须存在相应的目录
- 设计优势:
-
- 改动最小,向前兼容;现有的NN无需任何配置改动;如果现有的客户端只连某台NN的话,代码和配置也无需改动
- 分离命名空间管理和块存储管理
- 客户端挂载表:通过路径自动对应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 面板