文档章节

Hadoop HA现有解决方案

行走在路上
 行走在路上
发布于 2014/07/02 15:49
字数 2658
阅读 113
收藏 0

现有HDFS HA解决方案

HDFS的HA的解决方案,主要是从使用者的角度出发,提高元数据的可靠性,减少NameNode服务恢复时间。提高元数据的可靠性措施主要是对元数据进行备份,HDFS自身就具有多种机制来确保元数据的可靠性。

减少NameNode服务恢复时间的措施有两种思路:

第1种基于NameNode重启恢复服务的方式,对NameNode自身的启动过程进行分析,优化加载过程,减少启动时间;

第2种则是启动一个NameNode的热备(Warm standby)节点,当主节点不能正常服务时,由热备节点进行接替,此时主备切换时间成为服务恢复时间。

从效率上分析,第1种思路尽管进行了优化,但NameNode的启动时间仍受文件系统规模的限制,第2种则突破了这种限制。

现有比较成熟的HA解决方案有:

Hadoop的元数据备份方案

Hadoop的Secondary NameNode方案[3]

Hadoop的Checkpoint Node方案[4]

Hadoop的Backup Node方案[5]

DRDB方案[6]

Facebook的Avatarnode方案[7]

下面将依次介绍。

Hadoop的元数据备份方案

该方案利用Hadoop自身的Failover措施(通过配置dfs.name.dir),NameNode可以将元数据信息保存到多个目录。通常的做法,选择一个本地目录、一个远程目录(通过NFS进行共享),当NameNode发生故障时,可以启动备用机器的NameNode,加载远程目录中的元数据信息,提供服务。

优点

Hadoop自带机制,成熟可靠,使用简单方便,无需开发,配置即可。

元数据有多个备份,可有效保证元数据的可靠性,并且内容保持最新状态。

元数据需要同步写入多个备份目录,效率低于单个NameNode。

缺点

该方案主要是解决元数据保存的可靠性问题,但没有做到热备,HDFS恢复服务时,需要重新启动NameNode,恢复时间与文件系统规模成正比。

NFS共享的可靠性问题,如果配置的多个目录中有任何一个目录的保存因为异常而阻塞,将会导致整个HDFS的操作阻塞,无法对外提供正常服务。

Hadoop的Secondary NameNode方案

该方案启动一个Secondary NameNode节点,该节点定期从NameNode节点上下载元数据信息(元数据镜像fsimage 和元数据库操作日志edits),然后将fsimage和edits进行合并,生成新的fsimage(该fsimage就是Secondary NameNode下载时刻的元数据的Checkpoint),在本地保存,并将其推送到NameNode,同时重置NameNode上的edits。

优点

Hadoop自带机制,成熟可靠,使用简单方便,无需开发,配置即可。

Secondaryary NameNode定期做Checkpoint,可保证各个Checkpoint阶段的元数据的可靠性,同时,进行fsimage与edits的合并,可以有效限制edits的大小,防止其无限制增长。

缺点

没有做到热备,当NameNode无法提供服务时,需要重启NameNode,服务恢复时间与文件系统规模大小成正比。

Secondary NameNode保存的只是Checkpoint时刻的元数据,因此,一旦NameNode上的元数据损坏,通过Checkpoint恢复的元数据并不是HDFS此刻的最新数据,存在一致性问题。

Hadoop的Checkpoint Node方案

Checkpoint Node方案与Secondary NameNode的原理基本相同,只是实现方式不同。该方案利用Hadoop的Checkpoint机制进行备份,配置一个Checkpoint Node。该节点会定期从Primary NameNode中下载元数据信息(fsimage+edits),将edits与fsimage进行合并,在本地形成最新的Checkpoint,并上传到Primary NameNode进行更新。

当NameNode发生故障时,极端情况下(NameNode彻底无法恢复),可以在备用节点上启动一个NameNode,读取Checkpoint信息,提供服务。

优点

使用简单方便、无需开发、配置即可。

元数据有多个备份。

缺点

没有做到热备、备份节点切换时间长。

Checkpoint Node所做的备份,只是最后一次Check时的元数据信息,并不是发生故障时最新的元数据信息,有可能造成数据的不一致。

 Hadoop的Backup Node方案

利用新版本Hadoop自身的Failover措施,配置一个Backup Node,Backup Node在内存和本地磁盘均保存了HDFS系统最新的名字空间元数据信息。如果NameNode发生故障,可用使用Backup Node中最新的元数据信息。

优点

简单方便、无需开发、配置即可使用。

Backup Node的内存中对当前最新元数据信息进行了备份(Namespace),避免了通过NFS挂载进行备份所带来的风险。

Backup Node可以直接利用内存中的元数据信息进行Checkpoint,保存到本地,与从NameNode下载元数据进行Checkpoint的方式相比效率更高。

NameNode 会将元数据操作的日志记录同步到Backup Node,Backup Node会将收到的日志记录在内存中更新元数据状态,同时更新磁盘上的edits,只有当两者操作成功,整个操作才成功。这样即便NameNode上的元数据发生损坏,Backup Node的磁盘上也保存了HDFS最新的元数据,从而保证了一致性。

缺点

高版本(0.21以上)才支持。

许多特性还处于开发之中,例如:当NameNode无法工作时,Backup Node目前还无法直接接替NameNode提供服务,因此当前版本的Backup Node还不具有热备功能,也就是说,当NameNode发生故障,目前还只能通过重启NameNode的方式来恢复服务。

Backup Node的内存中未保存Block的位置信息,仍然需要等待下面的DataNode进行上报,因此,即便在后续的版本中实现了热备,仍然需要一定的切换时间。

当前版本只允许1个Backup Node连接到NameNode。

 DRDB方案

利用DRDB机制进行元数据备份。

当NameNode发生故障时,可以启动备用机器的NameNode,读取DRDB备份的元数据信息,提供服务。

优点

DRDB是一种较为成熟的备份机制。

元数据有多个备份、并且保持最新状态。

由于备份的工作交由DRDB完成,对于一条新的日志记录,NameNode无需同步写入多个备份目录,因而NameNode在效率上优于Hadoop的元数据备份方案。

缺点

没有做到热备、备份节点切换时间长。

需要引入新的机制、由此带来一定的可靠性问题。

FaceBook的AvatarNode方案

利用FaceBook提出的Avatar Node机制。

Active Node作为Primary NameNode对外提供服务。Standby Node处于Safe mode模式,在内存中保存Primary NameNode最新的元数据信息。Active Node和Standby Node通过NFS共享存储进行交互。DataNode同时向Active Node和Standby Node发送Block location信息。当管理员确定Primary NameNode发生故障后,将Standby Node切换为Primary NameNode。由于Standby Node内存中保存了所有元数据的最新信息,因此可直接对外提供服务,大大缩短了切换时间。

优点

提供热备、切换时间大大缩短。

FaceBook已将其集成到自己维护的Hadoop代码中,并部署到了自己的集群使用。

缺点

修改了部分源码、增加了一定的复杂性,并在软件的维护性上带来一定问题。

参考资料较少。

只提供一个备份节点。

方案优缺点比较

综上所述,HDFS HA方案比较如表1.1所示。

表1.1  HDFS HA方案比较

方案名称

切换时间

元数据

一致性

是否做

checkpoint

使用

复杂度

成熟度

相关

资料

元数据备份

一致

较多

Secondary

NameNode

不一定

较多

Checkpoint Node

不一定

较少

Backup Node

一致

较少

DRDB

一致

AvatarNode

一致

其中"元数据备份方案"不能单独使用,因为在系统运行期间,没有相应的Checkpoint机制,会造成日志的无限制增长,因此需要和Secondary NameNode、Checkpoint Node或Backup Node配合使用。

"DRDB方案"同样如此。

而对于Secondary NameNode、Checkpoint Node机制,它们只有Checkpoint的功能,而不能保存实时的元数据,因此需要在Namenode上配置元数据备份路径来保存实时元数据。

对于Backup Node,虽然它可以实时保存元数据,但为防止Backup Node成为一个单点,也需要在NameNode上配置元数据备份路径,保存在本地进行备份。

总结

元数据备份方案使用简单方便,在功能上可替代DRDB;

Backup Node是 Checkpoint Node的升级版,效率更高;

Secondary NameNode在低版本的Hadoop中就已存在。

因此用户实际上可选择的HA组合方案为:

(1)元数据备份+ Secondary NameNode

这种方案适用于目前Hadoop 的所有版本,属于冷备,切换时间长。由于Secondary NameNode自身并不实时保存元数据,一旦NameNode上的元数据损坏,将无法恢复到最新的元数据,因此采用元数据备份机制,在NameNode上需要配置多个目录进行备份,常见的做法是再配置一个NFS节点,共享一个目录进行备份。

(2)元数据备份+ Backup Node

这种方案只有在0.21.0以上版本才支持,目前的实现只支持冷备,切换时间长,自身实时保存元数据,不需要NFS节点。

(3)元数据备份+ AvatarNode

这种方案需要打Patch(补丁包),而且只支持特定的版本(0.20)或者使用FaceBook自身的Hadoop版本,切换时间短,需要一个NFS节点作为Active节点和Standby节点的数据交互节点。总之,如果当前Hadoop的版本较低,同时也不允许升级版本的话,可以选择第1种方案;如果版本较新(在0.21.0以上),第2种方案优于第1种;如果对HA切换时间有严格要求的话,则需要选择第3种方案。第1种方案比较简单,资料较多,本书将不再说明,后面着重讲述第2种和第3种方案。

本文转载自:http://book.51cto.com/art/201205/339036.htm

行走在路上
粉丝 11
博文 63
码字总数 33235
作品 0
项目经理
私信 提问
Hadoop 2.0中单点故障解决方案总结

项目构建 Hadoop 1.0内核主要由两个分支组成:MapReduce和HDFS,众所周知,这两个系统的设计缺陷是单点故障,即MR的JobTracker和HDFS的NameNode两个核心服务均存在单点问题,该问题在很长时间...

jackwxh
2018/06/29
0
0
Hadoop基础之HA(高可用)

1.Hadoop2.0产生背景 早期的hadoop版本,NN(namenode)是HDFS集群的单点故障点,每一个集群只有一个NN,如果这个机器或进程不可用,整个集群就无法 使用。为了解决这个问题,出现了一堆针对HDF...

landy8530
2017/11/25
0
0
Hadoop YARN单点故障解决方案(HA)介绍

在Apache Hadoop 2.0的第一个稳定版本2.2.0中,资源管理系统YARN存在单点故障,且尚未解决。YARN ResourceManage HA的相关jira为YARN-149,目前正在火热开发中,但尚未公布将来的发布版本。由...

蓝狐乐队
2014/05/12
391
0
Spring Hadoop Yarn HA问题调研

Spring Hadoop Yarn HA问题调研 OneCoder2017-03-2461 阅读 Hadoop Spring XD on Yarn在使用过程中发现不论是YarnClient还是AppMaster对Yarn HA的支持都不好。在Yarn的RM重启或切换的情况下,...

OneCoder
2017/03/24
0
0
轻量级分布式数据访问层--CobarClient

Cobar Client是一个轻量级分布式数据访问层(DAL)基于iBatis(已更名为MyBatis)和Spring框架实现。 主要特性: 可以支持垂直和水平数据切分数据库集群的访问; 支持双机热备的HA解决方案, 应用...

匿名
2011/04/27
1.2W
3

没有更多内容

加载失败,请刷新页面

加载更多

MBTI助你成功,让你更了解你自己

MBTI助你成功,让你更了解你自己 生活总是一个七日接着又一个七日,相信看过第七日的小伙伴,很熟悉这段开场白,人生是一个测试接着又一个测试,上学的时候测试,是为了证明你的智力,可谓从...

蛤蟆丸子
36分钟前
37
0
Android实现App版本自动更新

现在很多的App中都会有一个检查版本的功能。例如斗鱼TV App的设置界面下: 当我们点击检查更新的时候,就会向服务器发起版本检测的请求。一般的处理方式是:服务器返回的App版本与当前手机安...

shzwork
昨天
63
0
npm 发布webpack插件 webpack-html-cdn-plugin

初始化一个项目 npm init 切换到npm源 淘宝 npm config set registry https://registry.npm.taobao.org npm npm config set registry http://registry.npmjs.org 登录 npm login 登录状态......

阿豪boy
昨天
87
0
java基础(16)递归

一.说明 递归:方法内调用自己 public static void run1(){ //递归 run1(); } 二.入门: 三.执行流程: 四.无限循环:经常用 无限递归不要轻易使用,无限递归的终点是:栈内存溢出错误 五.递...

煌sir
昨天
63
0
REST接口设计规范总结

URI格式规范 URI中尽量使用连字符”-“代替下划线”_”的使用 URI中统一使用小写字母 URI中不要包含文件(脚本)的扩展名 URI命名规范 文档(Document)类型的资源用名词(短语)单数命名 集合(Co...

Treize
昨天
69
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部