HDFS- High Availability

NameNode High Availability

Background

Hadoop2.0.0以前，NameNode存在单点失败（single point of failure） (SPOF) 问题。

出现单点失败的缘由：

（1）NameNode所在的机器挂了；

（2）NameNode所在的机器须要硬件或者软件上的更新维护。

新的NameNode须要

（1）将FS Image加载到内存

（2）Replay edit log

（3）从DataNodes接收到足够的Block报告从而离开安全模式；

才能从新开始服务。

在包含大量文件和Blocks的大的集群中，namenode的冷启动可能须要30min或更久。

NameNode会按期将文件系统的命名空间（文件目录树、文件/目录元信息）保存到FS Image中，从而在NameNode由于掉电或者崩溃而宕机时，NameNode重启动以后能够从磁盘加载出FS Image文件从新构造命名空间。可是若是实时地将命名空间同步到FS Image中，将会消耗大量的系统资源，形成NameNode运行缓慢。所以，NameNode会先将命名空间的修改操做保存着在Edit Log中，而后按期合并FS Image和Edit Log。Hadoop 2.X以前，由Secondary NameNode进行FS Image和Edit Log的合并。Hadoop 2.X以后，由Standby NameNode进行合并，合并完再发送给Active NameNode。

Architecture

NameNode HA包含两个NameNode，在任意一个时刻，只有一个NameNode是的状态是Active，另外一个是NameNode的状态是Standby，此外还包含ZooKeeper Failover Controller（ZKFC）、ZooKeeper以及共享编辑日志（share edit log）。 Active NameNode负责全部客户端对集群的操做， Standby NameNode做为slave，维护状态信息以便在提供快速的故障转移。以下图所示。

实现HA的流程

（1）集群启动后，一个NameNode处于Active的状态，提供服务，处理客户端和DataNodes的请求，并把修改写到edit log，而后将edit log写到本地和共享编辑日志（NFS、QJM等）。

共享编辑日志分两种：

1：若是是NFS，那么主、从NameNode访问NFS的一个目录或者共享存储设备，Active Node对namespace的修改记录到edit log中，而后将edit log存储到共享目录中。Standby NameNode将共享目录中的edit log 写到本身的namespace

2：若是是QJM，那么主、从NameNode与一组单独的称为Journal Nodes（JNs）的守护线程进行通讯，Active Node将修改记录到大多数（> (N / 2) + 1，N是Journal Nodes的数量），Standby NameNode可以从JNs读到修改并写到本身的namespace中

（2）另一个NameNode处于Standby状态，它启动时加载FS Image文件，Standby NameNode会不断将读入的edit log文件与当前的命名空间合并，从而始终保持着一个最新版本的命名空间，因此Standby NameNode秩序按期将本身的命名空间写入一个新的FS Image文件，并经过HTTP协议将这个FS Image文件传回Active NameNode便可。

在发生故障转移时，Standby节点须要确保本身已经从共享编辑日志读到了全部的edit log以后，才会变成Active节点。这保证了namespace状态的彻底同步。

（3）为了实现Standby NameNode在Active NameNode失败以后可以快速提供服务，每一个DataNode须要同时向两个NameNode发送块的位置信息和心跳【块报告（block report）】，由于NameNode启动最费时的工做就是处理全部DataNodes的块报告。为了实现热备，增长ZKFC和ZooKeeper，经过ZK选择主节点，Failover Controller经过RPC让NameNode转换为主或从。

（4）当Active NameNode失败时，Standby NameNode能够很快地接管，由于在Standby NameNode的内存中有最新的状态信息（1）最新的edit log（2）最新的block mapping

高可用的共享存储的两种选择：NFS和QJM

quorum journal manager(QJM)是HDFS专门的实现，惟一的目的就是提供高可用的edit log，是大多数HDFS的推荐选择。

QJM的工做过程：QJM运行一组journal nodes，每一个edit必须被写入到majority的journal nodes中。一般，journal nodes的数量是3（至少是3个），所以每一个edit必须被写入到至少两个journal nodes，容许一个journal nodes失败。【与ZooKeeper类似，可是QJM不是依赖ZooKeeper实现的】

使用 Fencing（隔离）来防止"split-brain"（脑裂）

Why Fencing？

slow network or a network partition能够触发故障转移，即便以前的Active NameNode仍然在正常运转而且认为它本身仍然是Active NameNode，这时HA就须要确保阻止这样的NameNode继续运行。

两种隔离

（1）经过隔离保证在同一时刻主NameNoel和从NameNode只有一个可以写 共享编辑日志

（2）DataNode隔离：对客户端进行隔离，要确保只有一个NameNode可以响应客户端的请求

对于HA集群来讲，同一时刻只能有一个Active NameNode，不然namespace的状态很快就会发散成两个，形成数据丢失以及其余不正确的结果，即"split-brain"。为了防止这种状况发生，对于共享存储必须配置隔离（fencing）方法。在故障转移期间，若是不能断定以前的Active 节点放弃了他的Active状态，隔离处理负责切断切断以前的Active节点对共享编辑存储的访问，这就防止了以前Active节点对namespace的进一步编辑，从而使得新的Active节点可以安全地进行故障转移。（即一旦主NameNode失败，那么共享存储须要当即进行隔离，确保只有一个NameNode可以命令DataNodes。这样作以后，还须要对客户端进行隔离，要确保只有一个NameNode可以响应客户端的请求。让访问从节点的客户端直接失败，而后经过若干次的失败后尝试链接新的NameNode，对客户端的影响是增长一些重试时间，但对应用来讲基本感受不到。）

Why QJM recommended?

QJM在同一个时刻只容许一个NameNode写edit log；然而，以前的Active NameNode仍有可能为客户端的旧的读请求服务，此时能够设置SSH fencing命令来杀死NameNode的进程。

因为NFS不可能在同一个时刻只容许一个NameNode向它写数据，所以NFS须要更强的fencing方法，包括：

一、revoking the namenode’s access to the shared storage directory (typically by using a vendor-specific NFS command)；

二、disabling its network port via a remote management command；

三、STONITH, or “shoot the other node in the head,” which uses a specialized power distribution unit to forcibly power down the host machine.

Failover Controller

从Active NameNode到Standby NameNode的转换经过Failover Controller实现。Hadoop的FC的默认实现是基于ZooKeeper的，从而确保只有一个Active NameNode。Failover Controller的做用是监控NameNode、操做系统、硬件的健康状态，若是出现NameNode的失败，则进行故障转移。

 NOTE：HA集群中的Standby NameNode同时为namespace的状态执行检查点（HA上运行Secondary NameNode, CheckpointNode, or BackupNode是错误的） 

参考：

（1）《Hadoop The Definitive Guide 4th》

（2）http://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-hdfs/HdfsUserGuide.html