概述
Hadoop分布式文件系统（ Hadoop Distributed File System）能提供高吞吐量的数据访问，适合大规模数据集方面的应用，为海量数据提供存储服务，提供类POSIX接口。
HDFS包含主、备NameNode和多个DataNode，如下图所示。
图 2‑1
HDFS是一个Master/Slave的架构，在Master上运行NameNode，而在每一个Slave上
运行DataNode， ZKFC需要和NameNode一起运行。
NameNode和DataNode之间的通信都是建立在TCP/IP的基础之上的。 NameNode、DataNode、 ZKFC和JournalNode能部署在运行Linux的服务器上。
图2-1中各模块的功能说明如表2-1所示。
表 2‑1
|
名称 |
描述 |
|
Name Node |
用于管理文件系统的命名空间、目录结构、元数据信息以及提供备份机制等，分为： ● Active NameNode：管理文件系统的命名空间、维护文件系统的目录结构树以及元数据信息；记录写入的每个“数据块”与其归属文件的对应关系。 ● Standby NameNode：与Active NameNode中的数据保持同步；随时准备在Active NameNode出现异常时接管其服务。 ● Observer NameNode：与Active NameNode中的数据保持同步，处理来自客户端的读请求。 |
|
Data Node |
用于存储每个文件的“数据块”数据，并且会周期性地向NameNode报告该DataNode的数据存放情况。 |
|
Journal Node |
HA集群下，用于同步主备NameNode之间的元数据信息。 |
|
ZKFC |
ZKFC是需要和NameNode一一对应的服务，即每个NameNode都需要部署ZKFC。它负责监控NameNode的状态，并及时把状态写入Zookeeper。 ZKFC也有选择谁作为Active NameNode的权利。 |
|
ZK Cluster |
ZooKeeper是一个协调服务，帮助ZKFC执行主NameNode的选举。 |
|
HttpFS gateway |
HttpFS是个单独无状态的gateway进程，对外提供webHDFS接口，对HDFS使用FileSystem接口对接。可用于不同Hadoop版本间的数据传输，及用于访问在防火墙后的HDFS(HttpFS用作gateway)。 |
1.2 基本原理
1.2.1 HDFS原理
表 2‑2
在HDFS内部，一个文件分成一个或多个“数据块”，这些“数据块”存储在DataNode集合里， NameNode负责保存和管理所有的HDFS元数据。客户端连接到NameNode，执行文件系统的“命名空间”操作，例如打开、关闭、重命名文件和目录，同时决定“数据块”到具体DataNode节点的映射。 DataNode在NameNode的指挥下进行“数据块”的创建、删除和复制。客户端连接到DataNode，执行读写数据块操作。
1.2.2 HDFS HA架构
HA即为High Availability，用于解决NameNode单点故障问题，该特性通过主备的方式为主NameNode提供一个备用者，一旦主NameNode出现故障，可以迅速切换至备NameNode，从而不间断对外提供服务。
在一个典型HDFS HA场景中，通常由两个NameNode组成，一个处于Active状态，另一个处于Standby状态。为了能实现Active和Standby两个NameNode的元数据信息同步，需提供一个共享存储系统。本版本提供基于QJM（ Quorum Journal Manager）的HA解决方案，如图2-2所示。主备NameNode之间通过一组JournalNode同步元数据信息。
图 2‑2
通常配置奇数个（ 2N+1个） JournalNode，且最少要运行3个JournalNode。这样，一条元数据更新消息只要有N+1个JournalNode写入成功就认为数据写入成功，此时最多容忍N个JournalNode写入失败。比如， 3个JournalNode时，最多允许1个JournalNode写入失败， 5个JournalNode时，最多允许2个JournalNode写入失败。
由于JournalNode是一个轻量级的守护进程，可以与Hadoop其它服务共用机器。建议将JournalNode部署在控制节点上，以避免数据节点在进行大数据量传输时引起JournalNode写入失败。
1.3 HA方案介绍
在Hadoop2.0.0之前， HDFS集群中存在单点故障问题。由于每个集群只有一NameNode，如果NameNode所在机器发生故障，将导致HDFS集群无法使用，除非NameNode重启或者在另一台机器上启动。这在两个方面影响了HDFS的整体可用性：
- 当异常情况发生时，如机器崩溃，集群将不可用，除非重新启动NameNode。
- 计划性的维护工作，如软硬件升级等，将导致集群停止工作。
针对以上问题， HDFS高可用性方案通过自动或手动（可配置）的方式，在一个集群中为NameNode启动一个热替换的NameNode备份。当一台机器崩溃时，可以迅速地自动进行NameNode主备切换。或者当主NameNode节点需要进行维护时，通过管理员控制，可以手动进行NameNode主备切换，从而保证集群在维护期间的可用性。
图 2‑3
在一个典型的HA集群中（如图2-3），需要把两个NameNodes配置在两台独立的机器上。在任何一个时间点，只有一个NameNode处于Active状态，另一个处于Standby状态。 Active节点负责处理所有客户端操作， Standby节点时刻保持与Active节点同步的状态以便在必要时进行快速主备切换。
为保持Active和Standby节点的数据一致性，两个节点都要与一组称为JournalNode的节点通信。当Active对文件系统元数据进行修改时，会将其修改日志保存到大多数的JournalNode节点中，例如有3个JournalNode，则日志会保存在至少2个节点中。
Standby节点监控JournalNodes的变化，并同步来自Active节点的修改。根据修改日志， Standby节点将变动应用到本地文件系统元数据中。一旦发生故障转移， Standby节点能够确保与Active节点的状态是一致的。这保证了文件系统元数据在故障转移时在Active和Standby之间是完全同步的。
为保证故障转移快速进行， Standby需要时刻保持最新的块信息，为此DataNodes同时向两个NameNodes发送块信息和心跳。
对一个HA集群，保证任何时刻只有一个NameNode是Active状态至关重要。否则，命名空间会分为两部分，有数据丢失和产生其他错误的风险。为保证这个属性，防止“ split-brain”问题的产生， JournalNodes在任何时刻都只允许一个NameNode写入。在故障转移时，将变为Active状态的NameNode获得写入JournalNodes的权限，这会有效防止其他NameNode的Active状态，使得切换安全进行。
关于HDFS高可用性方案的更多信息，可参考如下链接：
http://hadoop.apache.org/docs/r3.1.1/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html
