频道栏目
首页 > 数据库 > 其他综合 > 正文
大数据学习10:HDFS-HA原理和理解
2017-09-06 09:28:50      个评论    来源:ggwxk1990的博客  
收藏   我要投稿

核心思路:

在Active NN和Standby NN之间要有个共享的存储日志的地方,Active NN把EditLog写到这个共享的存储日志的地方,Standby NN去读取日志然后执行,这样Active和Standby NN内存中的HDFS元数据保持着同步。一旦发生主从切换Standby NN可以尽快接管Active NN的工作

目录:

一、SPOF(single point offailure)方案回顾

二、hadoop2.x ha 原理

三、hadoop2.x ha 详述

四、hadoop2.xFederation

=============================================

一、SPOF(single point offailure)方案回顾

(1)Secondary NameNode:它不是HA,它只是阶段性的合并edits和fsimage,以缩短集群启动的时间。默认为1小时进行一次整合。当NN失效的时候,SecondaryNN并无法立刻提供服务,Secondary NN甚至无法保证数据完整性:如果NN数据丢失的话,在上一次合并后的文件系统的改动会丢失。

(2)Backup NameNode (HADOOP-4539):它在内存中复制了NN的当前状态,算是Warm Standby,可也就仅限于此,并没有failover等。它同样是阶段性的做checkpoint,也无法保证数据完整性。

(3)手动把name.dir指向NFS(NetworkFile System),这是安全的Cold Standby,可以保证元数据不丢失,但集群的恢复则完全靠手动。

 

二、hadoop2.x ha 原理

hadoop2.x之后,Clouera提出了QJM/QuromJournal Manager,这是一个基于Paxos算法实现的HDFS HA方案,它给出了一种较好的解决思路和方案,示意图如下:

\

 

(1)基本原理就是用2N+1台 JN 存储EditLog,每次写数据操作有大多数(>=N+1)返回成功时即认为该次写成功,数据不会丢失了。当然这个算法所能容忍的是最多有N台机器挂掉,如果多于N台挂掉,这个算法就失效了。这个原理是基于Paxos算法

(2)在HA架构里面SecondaryNameNode这个冷备角色已经不存在了,为了保持standby NN时时的与主Active NN的元数据保持一致,他们之间交互通过一系列守护的轻量级进程JournalNode。

(3)任何修改操作在 Active NN上执行时,JN进程同时也会记录修改log到至少半数以上的JN中,这时 Standby NN 监测到JN 里面的同步log发生变化了会读取 JN 里面的修改log,然后同步到自己的的目录镜像树里面,如下图:

\

 

(4)当发生故障时,Active的 NN 挂掉后,Standby NN 会在它成为Active NN 前,读取所有的JN里面的修改日志,这样就能高可靠的保证与挂掉的NN的目录镜像树一致,然后无缝的接替它的职责,维护来自客户端请求,从而达到一个高可用的目的。

(5)QJM方式来实现HA的主要优势:

1、不需要配置额外的高共享存储,降低了复杂度和维护成本

2、消除spof

3、系统鲁棒性(Robust:健壮)的程度是可配置

4、JN不会因为其中一台的延迟而影响整体的延迟,而且也不会因为JN的数量增多而影响性能(因为NN向JN发送日志是并行的)

 

三、hadoop2.x ha 详述

(1)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的命令

(2)客户端fencing:确保只有一个NN能响应客户端请求,让访问standby nn的客户端直接失败。在RPC层封装了一层,通过FailoverProxyProvider以重试的方式连接NN。通过若干次连接一个NN失败后尝试连接新的NN,对客户端的影响是重试的时候增加一定的延迟。客户端可以设置重试此时和时间。

(3)Hadoop提供了ZKFailoverController角色,部署在每个NameNode的节点上,作为一个deamon进程, 简称zkfc,示例图如下:

\

 

(4)FailoverController主要包括三个组件:

1、HealthMonitor: 监控NameNode是否处于unavailable或unhealthy状态。当前通过RPC调用NN相应的方法完成

2、ActiveStandbyElector: 管理和监控自己在ZK中的状态

3、ZKFailoverController 它订阅HealthMonitor 和ActiveStandbyElector 的事件,并管理NameNode的状态

(5)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.xFederation

单Active NN的架构使得HDFS在集群扩展性和性能上都有潜在的问题,当集群大到一定程度后,NN进程使用的内存可能会达到上百G,NN成为了性能的瓶颈

常用的估算公式为1G对应1百万个块,按缺省块大小计算的话,大概是64T (这个估算比例是有比较大的富裕的,其实,即使是每个文件只有一个块,所有元数据信息也不会有1KB/block)

为了解决这个问题,Hadoop 2.x提供了HDFS Federation, 示意图如下:

\

 

(1)多个NN共用一个集群里的存储资源,每个NN都可以单独对外提供服务

(2)每个NN都会定义一个存储池,有单独的id,每个DN都为所有存储池提供存储

(3)DN会按照存储池id向其对应的NN汇报块信息,同时,DN会向所有NN汇报本地存储可用资源情况

(4)如果需要在客户端方便的访问若干个NN上的资源,可以使用客户端挂载表,把不同的目录映射到不同的NN,但NN上必须存在相应的目录

 

设计优势:

1、改动最小,向前兼容;现有的NN无需任何配置改动;如果现有的客户端只连某台NN的话,代码和配置也无需改动

2、分离命名空间管理和块存储管理

3、客户端挂载表:通过路径自动对应NN、使Federation的配置改动对应用透明

点击复制链接 与好友分享!回本站首页
上一篇:数据库连接池
下一篇:sed的用法
相关文章
图文推荐
点击排行

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站