HDFS- High Availability

Posted 2020-10-31 sodawoods

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方法，包括：

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

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

3、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