浅析分布式文件系统HDFS的高可用架构的实现

随着大数据时代的来临，数据量呈现几何级的爆炸增长，数据结构类型也多种多样，除了有结构化数据，还有半结构化数据、非结构化数据等。传统的关系型数据库已经不满足当前的存储、查询需求，而HDFS则因其卓越的存储能力、简单一致的模型、高容错性等优点被广泛应用起来。本文主要介绍基于Hadoop2.0下的HDFS的高可用架构设计，以及关于HDFS的一些常规操作技巧。
实际上，Hadoop已经发展到了3.0，这里之所以截取Hadoop2.0下的HDFS来介绍，是因为从1.0到2.0基本解决了HDFS高可用性的问题。
在Hadoop1.0的HDFS中，主体设计遵从主从结构，如图1：Hadoop1.0的HDFS架构图例。由于分布式存储的性质，一般认为主节点是NameNode，管理文件系统的命名空间和来自客户端的访问；从节点是若干个DataNode，用于管理存储的数据。SecondryNode是NameNode的助手节点，起到备份、元数据恢复（存在一定的滞后性）的作用，作为一个检查点协助NameNode更好的工作。

图1：Hadoop1.0的HDFS架构图例
无疑，这种设计架构是存在一定的风险性的，一旦NameNode因某种原因挂起，比如：服务器掉电、宕机等，导致单点故障，便会使得HDFS工作异常，甚至出现元数据丢失的现象。为了解决这个问题，Hadoop2.0中的HDFS的主体架构设计相较于1.0做了优化升级，如图2：Hadoop2.0的HDFS架构图例，具体变化如下。

图2：Hadoop2.0的HDFS架构图例
第一、支持同时启动两个NameNode，即Active NameNode和Standby NameNode，平时由Active NameNode对外提供服务，Standby NameNode中的元数据与Active NameNode保持一致。一旦Active NameNode发生故障，Standby NameNode可立即切换为Active状态，保证HDFS的正常运转。
第二、引入JournalNodes机制，用于NameNode之间的数据共享，当Active状态的NameNode的命名空间有任何修改时，会告知大部分的JournalNodes进程。Standby状态的NameNode有能力读取JournalNodes中的变更信息，把变化应用于自己的命名空间，从而保证两个NameNode节点的元数据的一致性。
第三、引入ZKFC（Zookeeper Failover Controller），即故障转移进程，用于监控NameNode状态，一般运行在NameNode的宿主机器上，与Zookeeper集群协作完成故障的自动转移，其原理是每个NameNode都会在Zookeeper中获取一个持久性Session，如果NameNode故障，则Session过期，使用Zookeeper的事件机制通知其他NameNode进行故障转移，即自动实现将Standby状态的NameNode切换为Active状态，对外提供服务。
Hadoop2.0下的HDFS解决了上一个版本的单点故障、单NameNode压力过大等问题，给用户更好的使用体验，有效提升了HDFS在使用过程中的稳定性。同时，笔者也有注意到，Hadoop3.0下的HDFS在架构上有一些轻微的优化，感兴趣的朋友不妨研究一下。