2 namenode、datanode
HDFS集群有两类节点，并以管理者-工作者模式运行，即一个namenode（管理者）和多个datanode（工作者）。namenode管理文件系统的命名空间，它维护着整个文件系统树以及树中所有文件及目录的元数据。这些信息在本地文件系统中以两种形式永久保存：namespace image（包括namespace中所有文件的inode和block列表）和editlog（记录了所有用户对HDFS所做的更改操作）。NameNode也保存着构成给定文件的blocks的位置，但这些信息并不是永久保存在磁盘中的，因为这些信息是在系统启动时根据datanode的反馈信息重建、并且是定时基于datanode的报考更新的，具有很强的动态性。
客户端（client）代表用户（user）通过与NameNode和DataNode交互来访问文件系统。client提供了一个类似POSIX（PortableOperating SystemInterface，可移植操作系统接口）的文件系统接口，所以用户在编程中并不需要namenode和datanode的具体实现。
datanode是文件系统的工作节点，它们根据需要存储并检索数据块（受客户端或namenode调度），并且定期向namenode发送它们所存储的块的列表。
namenode是整个分布式文件系统的一个单点故障（single point of failure），没有了namenode整个分布式文件系统就无法使用了，因为我们无法从blocks中重构出相应的文件了。所以确保namenode能从失败中及时恢复是很重要的一件事，我们可以从以下两方面入手：
1. 第一种方法就是备份namenode中保存的永久信息（也就是上文中所提到的namespaceimage和editlog），namenode可以经过额外配置把它的永久信息保存到多个文件系统上去（这些多写操作是同步和原子性的）。最常用的做法是把永久信息保存到本地文件系统和某个远程NFS（Network FileSystem）上去。
2.另一种可能的做法就是运行一个secondarynamenode，尽管它的名字跟namenode听起来差不多，但它的功能跟namenode却不一样。它最主要的工作就是把namespaceimage检查点文件与editlog相融合（以防止editlog过大）并把融合后的namespaceimage保存在自己的本地文件系统上，同时发送这个新的备份给namenode。因为需要大量CPU资源和跟namenode一样大小内存的缘故，secondary namenode通常运行在另一个单独的机器上。然后由于secondarynamenode上保存的状态信息总是要滞后于namenode上的状态信息的缘故（未融合的editlog记录了这一部分改变），如果namenode完全失败，数据肯定要丢失一部分。
3. 通常的做法是把上述两种方法结合起来，也即当namenode当机时，把远端NFS上的namespace image拷贝到secondarynamenode上，然后把secondarynamenode当做namenode来运行。
namenode在内存中保存着文件系统中每个文件和目录的引用，但集群规模扩大时，这便造成了一个瓶颈。于是在hadoop2.x发行版中引入了一个新的概念：Hadoop Fedoration。它允许集群拥有不止一个namenode，这样每个namenode只负责维护文件系统中的一部分，例如一个namenode维护/user目录，另一个namenode可以维护/share目录。
在fedoration中，每个namenode维护两部分信息：1）由namespace 元数据组成的namespace volume；2）包含其负责维护的某一部分文件系统中的的所有文件的block位置信息的block pool。namespace volume各自之间是独立的，这就意味着namenode之间不用交互，而且某个namenode当机并不影响其他namenode的正常使用。相对于namespace volume而言，Block pool并不是分区的，所以datanodes需要向集群中的每个namenode注册，并且可能要存储来自多个blockpool的数据。
要想使用带有fedoration特性的cluster，用户可以使用用户端的挂载表来映射文件路径到namenode。这个可以通过ViewFileSystem来配置，并使用view fs://URI.
以下为Fedoration实现方式图解：
注解：
1. 多个NN共用一个集群里DN上的存储资源，每个NN都可以单独对外提供服务
2. 每个NN都会定义一个存储池，有单独的id，每个DN都为所有存储池提供存储
3. DN会按照存储池id向其对应的NN汇报块信息，同时，DN会向所有NN汇报本地存储可用资源情况
4. 如果需要在客户端方便的访问若干个NN上的资源，可以使用客户端挂载表，把不同的目录映射到不同的NN，但NN上必须存在相应的目录
这样设计的好处大致有：
1. 改动最小，向前兼容 ：
1）现有的NN无需任何配置改动.
2）如果现有的客户端只连某台NN的话，代码和配置也无需改动。
2. 分离命名空间管理和块存储管理 ：
1）提供良好扩展性的同时允许其他文件系统或应用直接使用块存储池
2）统一的块存储管理保证了资源利用率
3）可以只通过防火墙配置达到一定的文件访问隔离，而无需使用复杂的Kerberos认证
3. 客户端挂载表：
1）通过路径自动对应NN
2）使Federation的配置改动对应用透明