HDFS Federation联合 Namenodes/Namespaces 配置

1.为什么需要联合Namenode

对于hdfs架构，datanode已经有完善的容错机制，我们的担忧始终在namenode上，上面一节已经讲了namenode的容错机制，也就是两种备份namenode的方式。这一节绝不是要解决namenode容错的问题。

那联合nameNodes是要干什么？（我这里的联合HDFS 又被称作联邦HDFS）

问题：可不可以通过扩展datanode来无限增加文件容量。
答案：当然不可以
因为：namenode在内存中保存文件系统中每个文件和每个数据块的引用关系，这意味着对于一个拥有大量文件的超大集群来说，内存将成为限制系统横向扩展的瓶颈。
所以：我们需要联合namenodes来实现扩展

2.什么是联合Namenodes

在2.x发行版本系列中引入的联合HDFS 允许系统通过添加namenode实现扩展，其中每个namenode 管理文件系统命名空间中的一部分。例如，一个namenode可能管理/user目录下的所有文件，而另一个namenode可能管理/share目录下的所有文件。

2.1HDFS架构

HDFS 包括两层架构:

Namespace
- 包含目录文件和块.
- 支持所有与命名空间相关的文件系统操作，如创建、删除、修改和列出文件和目录.
Block Storage Service:
- Block Management (在namenode种)
  - 通过注册和周期性心跳来提供datanode群集成员资格。.
  - 处理块报告并维护块的位置.
  - 支持与块相关的操作，如创建、删除、修改和获取块位置.
  - 管理副本放置、未复制块的块复制，并删除过度复制的块.
- Storage - datanodes通过在本地文件系统上存储块并允许读/写访问.
以前的hdfs体系结构只允许整个集群使用一个名称空间。在该架构中，单个namenode管理命名空间。hdfs联合环境通过向hdfs添加对多个namenodes/namespace的支持来解决这个限制。

2.2联合HDFS环境

在联邦环境下，每个namenode 维护-一个命名空间卷(namespace volume)，由命名空间的元数据和一个数据块池(block pool)组成，数据块池包含该命名空间下文件的所有数据块。命名空间卷之间是相互独立的，两两之间并不相互通信，甚至其中一个namenode的失效也不会影响由其他namenode维护的命名空间的可用性。数据块池不再进行切分，因此集群中的datanode需要注册到每个namenode,并且存储着来自多个数据块池中的数据块。datanode向所有namenode发送心跳和块报告，并执行namenode的命令。
要想访问联邦HDFS集群，客户端需要使用客户端挂载数据表将文件路径映射到namenode。该功能可以通过ViewFileSystem 和viewfs: //URI 进行配置和管理。

3.联合namenode环境配置

联邦配置是向前兼容的，允许已经存在的单一Namenode继续工作而不需要任何修改。新的配置是这样设计的：所有集群中的节点需要同样的配置文件而不需要根据集群中节点类型的不同分发不同的配置文件。

联邦增加了一个新的抽象变量NameServiceID 。一个Namenode 以及它相关联的所有secondary/backup/checkpointer节点属于同一个NameServiceId。为了支持单一的配置文件，Namenode 、secondary/backup/checkpointer 节点的配置文件的参数都需要用NameServiceID来作为后缀。

3.1 联合namenodes配置

配置hdfs-site.xml：

Step 1: 在配置中增加 dfs.nameservices变量，并且指定一个以逗号分隔的NameServiceIDs列表。Datanodes 将以此来识别集群中的Namenodes 。

Step 2: 对每一个Namenode 、Secondary Namenode/BackupNode/Checkpointer 增加下面的以NameServiceID 为后缀的配置参数到配置文件。

守护进程	配置参数
Namenode	dfs.namenode.rpc-address dfs.namenode.servicerpc-address dfs.namenode.http-address dfs.namenode.https-address dfs.namenode.keytab.file dfs.namenode.name.dir dfs.namenode.edits.dir dfs .namenode.checkpoint.dir dfs.namenode.checkpoint.edits.dir
Secondary Namenode	dfs.namenode.secondary.http-address dfs.secondary.namenode.keytab.file
BackupNode	dfs.namenode.backup.address dfs.secondary.namenode.keytab.file

以下是具有两个Namenode的示例配置：

<configuration>
  <property>
    <name>dfs.nameservices</name>
    <value>ns1,ns2</value>
  </property>
  <property>
    <name>dfs.namenode.rpc-address.ns1</name>
    <value>nn-host1:rpc-port</value>
  </property>
  <property>
    <name>dfs.namenode.http-address.ns1</name>
    <value>nn-host1:http-port</value>
  </property>
  <property>
    <name>dfs.namenode.secondary.http-address.ns1</name>
    <value>snn-host1:http-port</value>
  </property>
  <property>
    <name>dfs.namenode.rpc-address.ns2</name>
    <value>nn-host2:rpc-port</value>
  </property>
  <property>
    <name>dfs.namenode.http-address.ns2</name>
    <value>nn-host2:http-port</value>
  </property>
  <property>
    <name>dfs.namenode.secondary.http-address.ns2</name>
    <value>snn-host2:http-port</value>
  </property>

  .... Other common configuration ...
</configuration>

先启动新的 Namenode and Secondary/Backup.

然后通过对集群中的所有datanodes运行以下命令，刷新datanodes以获取新添加的namenode:

[hdfs]$ $HADOOP_HOME/bin/hdfs dfsadmin -refreshNamenodes <datanode_host_name>:<datanode_rpc_port>

3.2HDFS viewfs访问配置

HDFS Federation，当你启用该功能时，会同时存在多个可用的namenode，为了便于配置“fs.default.name”，你可以规划这些namenode的使用方式，比如图片组使用namenode1，爬虫组使用namenode2等等，这样，爬虫组员工使用的HDFS client端的core-site.xml文件可进行如下配置：

<property>
    <name>fs.default.name</name>
    <value>hdfs://namenode1:9000</value>
 </property>

图片组员工使用的HDFS client端的core-site.xml文件可进行如下配置：

<property>
    <name>fs.default.name</name>
    <value>hdfs://namenode2:9000</value>
 </property>

从HDFS和HBase使用者角度看，当仅仅使用单NameNode上管理的数据时，是没有问题的。但是，当考虑HDFS之上的计算类应用，比如YARN/MapReduce应用程序，则可能出现问题。因为这类应用可能涉及到跨NameNode数据读写，这样必须显式的指定全URI，即输入输出目录中必须显式的提供类似“hdfs://namenode2:9000”的前缀，以注明目录管理者NameNode的访问地址。

为了解决这种麻烦，为用户提供统一的全局HDFS访问入口，HDFS Federation借鉴Linux提供了client-side mount table，这是通过一层新的文件系统viewfs实现的，它实际上提供了一种映射关系，将一个全局（逻辑）目录映射到某个具体的namenode（物理）目录上，采用这种方式后，core-site.xml配置如下：

<configuration xmlns:xi="http://www.w3.org/2001/XInclude">
  <xi:include href="mountTable.xml"/>
    <property>
      <name>fs.default.name</name>
      <value>viewfs://ClusterName/</value>
    </property>
</configuration>

经过以上配置后，你可以像1.0那样，访问HDFS上的文件，比如：其中，“ClusterName”是HDFS整个集群的名称，你可以自己定义一个。mountTable.xml配置了全局（逻辑）目录与具体namenode（物理）目录的映射关系，你可以类比linux挂载点来理解。
假设你的集群中有三个namenode，分别是namenode1，namenode2和namenode3，其中，namenode1管理/usr和/tmp两个目录，namenode2管理/projects/foo目录，namenode3管理/projects/bar目录，则可以创建一个名为“ClusterName”的client-side mount table，并在mountTable.xml中进行如下配置：

<configuration>
  <property>
    <name>fs.viewfs.mounttable.ClusterName.link./user</name>
    <value> hdfs://namenode1:9000/user </value>
  </property>
  <property>
    <name>fs.viewfs.mounttable.ClusterName.link./tmp</name>
    <value> hdfs:/ namenode1:9000/tmp </value>
  </property>
  <property>
    <name>fs.viewfs.mounttable.ClusterName.link./projects/foo</name>
    <value> hdfs://namenode2:9000/projects/foo </value>
  </property>
  <property>
    <name>fs.viewfs.mounttable.ClusterName.link./projects/bar</name>
    <value> hdfs://namenode3:9000/projects/bar</value>
  </property>
</configuration>

上面使用了include href="mountTable.xml",将外部配置导入，当然也可以直接配置在原来的一个配置文件中也是可以的。

中的“/usr/”将被映射成“hdfs://namenode1:9000/user/”。

Client-side mount table的引入为用户使用HDFS带来极大的方便，尤其是跨namenode的数据访问。

参考hadoop官方Federation文档：https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/Federation.html