HDFS Federation机制

一 HDFS1.x逻辑结构

HDFS1.x使用一个NameNode来管理文件系统命名空间和数据块信息，使用DataNode来提供块的存储和访问。这种架构比较简单，但是缺点也大：

1、         受限制于NameNode的内存大小：NameNode在内存保存了整个文件系统的元数据，所以内存大小直接限制了文件系统的大小

2、         影响HDFS吞吐量：因为文件的读写都需要和NameNode交互，如果NameNode很繁忙了，那么势必降低文件系统吞吐量。

3、         无法做到数据或者资源的有效隔离

4、         命名空间和数据块管理高度耦合，难以让其他服务单独使用数据块存储功能

5、         只有一个NameNode存在单点故障问题

二 HDFS2.x 逻辑结构

为了能够水平扩展NameNode,HDFS2.x引入了联盟的机制，我们可以定义多个NameNode，每一个NameNode各自管理着自己的命名空间和BlockPool.HDFS集群中的DataNode负责提供数据块共享存储的功能，每一个DataNode都会向每一个NameNode注册，周期性发送心跳报告和数据块等，然后执行NameNode回传的响应指令

BlockPool: 管理当前命名空间中存储在集群中DataNode上所有的数据块信息，每一个BlockPool也是独立的，不同NameNode之间不会相互影响。当一个NameNode出现故障，并不会影响集群中其他的NameNode

 

NamespaceVolume: 一个NameNode的命名空间和BlockPool被称为命名空间卷，主要是作为一个统一的管理单元，方便NameNode管理。当NameNode/Namespace删除后，所对应的blockpool也会从其集群删除；集群升级的时候。每一个命名空间卷都会作为一个基本的升级单元。

 

注意：

一定要指定与原集群相同的clusterId来format新的NameNode,代表新的NameNode隶属于原集群

hdfsnamenode -format -clusterId <cluster_id>

在所有的DataNode节点同步以上修改过的hdfs-site.xml配置,逐个重启DataNode即可.注册成功后,在DataNode的datadir数据存储目录下将会多出一个blockpool的存储目录

 

一个blockpool对应一个namespace.DataNode通过建立多个blockpool目录的方式实现了DataNode的存储共享.如果重启DataNode的时候,你发现DataNode启动失败了,并出现如下所示的错误

这个时候再次确认新的NameNode是否是用原集群的clusterformat的.ClusterId不匹配就会导致DataNode启动出现上图所示的错误.但是有的时候我们并不想让所有的DataNode都添加到每个NameNode,比如对于用于冷数据存储的机器我只想把它加入到77所在的原NameNode上.这个时候HDFS能支持吗?答案是确定的.添加如下配置表明目标注册的nameservice.

 

对于HDFSFederation引入的多nameservice的问题,会让客户端程序维护多个nameservice,以及这些对应namespace所存储的具体文件目录,namespace多了,这个问题会显得比较麻烦,一个优化的做法是用viewFs来解决,在客户端配置上增加一个mounttable.让客户端访问的是一个逻辑意义上的filesystem,无须更改目标指向的filesystem.这样可以同时应用HDFSFederation和viewFs的优势,无疑是一个更好的选择.