Hadoop单节点故障改进方案对比

HDFS 单点改造方案对比

1背景

目前,HDFS集群的架构包括了单个Name Node和若干个DataNodeName Node负责两方面的事情:一方面是存储和管理整个命名空间,包括创建、修改、删除和列举文件目录等文件系统级别的操作;另一方面是管理Data Node和文件块。Data Node主要负责文件块的持久化存储和远程访问。

1.1命名空间管理

HDFS的命名空间包含目录、文件和块。命名空间管理:是指命名空间支持对HDFS中的目录、文件和块做类似文件系统的创建、修改、删除、列表文件和目录等基本操作

 

1.2 块管理

A) 处理Data Node向NameNode注册的请求,处理datanode的成员关系,处理来自DataNode周期性的心跳。

B) 处理来自块的报告信息,维护块的位置信息。

C) 处理与块相关的操作:块的创建、删除、修改及获取块信息。

D) 管理副本放置(replica placement)和块的复制及多余块的删除。

目前HDFS为单NameNode模式,Namenode运行时将元数据及其块映射关系加载到内存中,随着集群数据量的增大,Namenode的内存空间也会遇到瓶颈。据实际生产经验统计如下:

文件数

 

数据块数

 

内存空间占用

 

3千万

 

3千万

 

约12GB

块管理 ≈ 7.8G,包括全部块副本信息

目录树 ≈ 4.3G,目录层次结构,包含文件块列表信息

 

10亿

 

10亿

 

约380GB

块管理 ≈ 240GB

目录树 ≈ 140GB

 

注:淘宝与百度等均以支撑10亿的文件数为设计目标,京东文件系统的业务对象主要为图片,电子书等,10亿文件量可能只是时间问题。

2方案对比 2.1 Federation HDFS

HDFS Federation使用了多个独立的Namenode/namespace来使得HDFS的命名服务能够水平扩展。在HDFS Federation中的Namenode之间是联盟关系,他们之间相互独立且不需要相互协调。HDFS Federation中的Namenode提供了提供了命名空间和块管理功能。Federation中引入了block pool的概念,负责对该命名空间的数据块进行管理。命名空间和它所拥有的BlockPool统称为一个Namespace Volume。datanode被所有的Namenode用作公共存储块的地方。每一个datanode都会向所在集群中所有的Namenode注册,并且会周期性的发送心跳和块信息报告,同时处理来自Namenode的指令。

优点:namenode增加了集群存储数据容量与访问的并发处理,namenode中分为了2个部分:命名空间管理及其数据块管理;单个namenode down掉重启需要的时间比集中到一个namenode需要的时间变短;降低集群整体不可用的风险。

缺点:集群失去了统一的命名空间管理,单个namenode down掉对应该namenode的数据不可访问;多命名空间独立而不支持统一命名空间;

2.2 HDFS2

Hadoop单节点故障改进方案对比


百度从2007年开始使用Hadoop,我们相信从那时候开始,HDFS逐渐开始被改造。从百度HDFS2的架构图可以看出大致分为2层,上面一层为命名空间管理,类似Federation的多命名空间设计思路,提供了几种命名空间管理方式:层级命名空间管理;S3扁平化命名空间管理;用户定制化命名空间。3者是平级的。文件管理与块管理不再包括在namenode。在对象管理层,整合了文件管理与块管理功能,同时也负责了数据块存储。

优点:

1、大部分耗时操作都属于文件对象管理层,不用经过Namespace

2、最耗CPU资源的若干操作中,仍需经过Namespace的只占13.7%

3、命名空间管理不再维护块信息,大部分操作都不需要加全局锁,可以更充分利用CPU资源;

4、文件对象管理服务直接就是水平可扩展的;

5、文件对象管理做为单独服务存在,可挂载不同类型命名空间,如S3;

6、改造后,10亿文件量,文件 ≈66GB,目录 ≈ 1GB,单节点命名空间就可以管理;

缺点:

HDFS2现阶段版本没有实现高可用性;

HDFS2借鉴了Lustre,Ceph,S3等的设计思想,调研结果如下:

   

Lustre

 

Ceph

 

GFS2

 

分布式元数据组织策略

 

随机,轮询等;各节点平坦存放INODE信息

 

动态子树分割,元数据服务维护INODE到根目录的路径;子树修改可以同步到每一个节点上的子树副本;

     

独立块,对象管理层

 

 

是,独立的对象管理层RADOS,通过P2PW维护内部的数据一致性和副本安全

 

推测是

 

元数据存储策略

 

共享对象存储

 

共享对象存储

 

共享存储bigtable

 

元数据定位

 

路径查询和权限控制需要根据目录层级遍历多个元数据服务。解决性能问题采用了客户端缓存和分布式锁机制

 

无需跨多台

     

特色

     

RADOS,CRUSH

 

支持小文件存储;支持低延迟的交互式请求

 

由于这些资料都不是官方发布,我们通过公布的一些架构图大致可以推断一些设计:

1、 在命名空间部分,用到了静态子树,动态子树分割,及其hash算法,猜测其树状命名空间是跨越节点的;

2、 对象层有文件管理及其块管理,猜测可能先通过树状命名空间获得文件的inode,及其位置,然后客户端直接到相应节点读取文件元数据,通过文件对象找到其块映射,及其块与datenode的映射关系,然后客户端再直接与datenode通信,进行相关块的读写操作,在树状命名空间,后面的对象层均可以实现冗余及其修复机制。

3、 像亚马逊的S3,文件系统最大的问题就是扩展性,完全取决于他的树状结构,扩展起来相当困难。亚马逊解决存储服务的时候,抛弃了树状,采取了很平坦的结构,对象存储的概念。S3对象存储概念,使得亚马逊支撑对象数可以支撑上千亿,是现在最大的存储集群。实现了S3的平坦两层命名空间,可用于存储百度的图片,MP3,PPT。当然如网盘类的应用可采用树状结构的命名空间。

相关阅读

Ubuntu 13.04上搭建Hadoop环境

Ubuntu 12.10 +Hadoop 1.2.1版本集群配置

Ubuntu上搭建Hadoop环境(单机模式+伪分布模式)

Ubuntu下Hadoop环境的配置

单机版搭建Hadoop环境图文教程详解

搭建Hadoop环境(在Winodws环境下用虚拟机虚拟两个Ubuntu系统进行搭建)

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:http://www.heiqu.com/f38bc9beedec88fde5595c2f65b262b6.html