图文详解HDFS的高可用和联邦到底是什么

写在前面

本文隶属于专栏《1000个问题搞定大数据技术体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！

本专栏目录结构和文献引用请见1000个问题搞定大数据技术体系

解答

HDFS HA是用来解决NameNode 单点故障问题的，
HDFS 联邦是用来解决 NameNode 内存瓶颈问题的。

补充

NameNode单点故障

在 HDFS 中 NameNode 所处的位置是非常重要的，绝对不允许出现故障。

因为整个HDFS文件系统的的元数据信息都是由 NameNode 来管理， NameNode 的可用性直接决定了整个 HDFS 的可用性。

在 Hadoop1.x时代， NameNode 存在单点故障， 且 NameNode 进程不能正常工作了，就会影响整个集群的正常使用，整个HDFS就无法使用，

Hive 或者HBase 等的数据都是存在HDFS之上的，所有 Hive 或者 HBase 等框架也就无法使用，这可能就会导致你的生产集群上很多框架都没办法正常使用。

如果通过重新启动 NameNode 来进行数据恢复的过程也会比较耗时。

HDFS NameNode HA体系架构

在 Hadoop2.x中， HDFS NameNode 的单点问题都得到了解决。
HDFS NameNode 高可用整体架构如图所示。

从上图中，我们可以看出 NameNode的高可用架构主要分为下面几个部分:

在典型的HA集群中，两个独立的机器作为 NameNode。

任何时刻，只有个 NameNode处于 Active状态，另一个处于 Standby 状态。
Active NameNode 负责所有的客户端操作，而 Standby NameNode 只是简单的充当 Slave，它负责维护状态信息以便在需要时能快速切换。

主备切换控制器 ZKFailoverController

ZKFailoverController 作为独立的进程运行，对 NameNode的主备切换进行总体控制。

ZKFailoverController 能及时检测到NameNode的健康状况，在主 NameNode故障时借助 Zookeeper实现自动的主备选举和切换，当然 NameNode目前也支持不依赖于 Zookeeper的手动主备切换。

Zookeeper 集群的目的是为主备切换控制器提供主备选举支持。

ZKFailoverController 的主要职责

健康监测

周期性的向它监控的 NameNode发送健康探测命令，从而来确定某个 NameNode是否处于健康状态，如果机器宕机，心跳失败，那么 ZKFailoverController 就会标记它处于一个不健康的状态

会话管理

如果 NameNode是健康的，ZKFailoverController 就会在 Zookeeper 中保持一个打开的会话.

如果 NameNode同时还是 Active状态的，那么kfc还会在Zookeeper中占有一个类型为短暂类型的 znode，当这个 Name Node挂掉时， 这个 znode将会被删除，然后备用的 NameNode将会得到这把锁，升级为主NN，同时标记状态为 Active。

当宕机的 NameNode新启动时，它会再次注册 Zookeeper ，发现已经有 znode 锁了，便会自动变为 Standby状态，如此往复循环，保证高可靠。

Hadoop2.x仅仅支持最多配置2个NameNode，Hadoop3.x支持多于2个的 NameNode。

master 选举

如上所述，通过在 Zookeeper中维持一个短暂类型的 znode，来实现抢占式的锁机制，从而判断哪个 NameNode 为 Active 状态

共享存储系统 Quorum Journal Node

为了让 Standby Node 与 Active Node 保持状态的同步，它们两个都要与称为"JournalNodes"（JNs）的一组独立的进程通信。

Active Node 所做的任何命名空间的修改，都将修改记录的日志发送给大多数的 JNs。

Standby Node 能够从 JNs 读取 edits ，并且时时监控它们对 EditLog 的修改。

Standby Node获取 edits 后，将它们应用到自己的命名空间。

故障切换时， Standby 将确保在提升它自己为 Active 状态前已经从 JNs 读完了所有的 edits ，这就确保了故障切换发生前（两个 NameNode）命名空间状态是完全同步的。

DataNode节点

除了通过共享存储系统共享HDFS的元数据信息之外，主 NameNode和备 NameNode 还需要共享 HDFS 的数据块和 DataNode之间的映射关系。

DataNode会同时向主 NameNode 和备 NameNode 上报数据块的位置信息。

联邦（Federation）

Federation产生背景

通过阅读专栏之前的内容我们知道 HDFS 集群的元数据信息是存放在 NameNode 的内存中的，

当集群扩大到一定的规模以后， NameNode 内存中存放的元数据信息可能会非常大，由于 HDFS 的所有的操作都会和 NameNode 进行交互， 当集群很大时， NameNode 会成为集群的瓶颈。

在 Hadoop2.x 诞生之前，HDFS 中只能有一个命名空间，对于 HDFS 中的文件没有办法完成隔离。

正因为如此，在 Hadoop2.x中引入了Federation的机制，可以解决如下场景的问题。

1. HDFS集群扩展性。多个 NameNode 分管一部分目录，使得一个集群可以扩展到更多节点，不再像 1.0 中由于内存的限制制约文件存储数目。
2. 性能更高效。多个 NameNode 管理不同的数据，且同时对外提供服务，将为用户提供更高的读写吞吐率。
3. 良好的隔离性。用户可根据需要将不同业务数据交由不同 NameNode 管理这样不同业务之间影响很小。

HDFS数据管理架构

数据存储采取分层的结构。也就是说，所有关于存储数据的信息和管理是放在 NameNode 这边，而真实的数据则是存储在各个 DataNode 下。

这些隶属于同一个 NameNode所管理的数据都在同一个命名空间 namespace 下，而一个 namespace 对应一个 block pool。

Block Pool 是同一个 namespace 下的 block 的集合，当然这是我们最常见的单个 namespace 的情况，

也就是一个 Name Node 管理集群中所有元数据信息的时候，如果我们遇到了前面提到的 NameNode 内存使用过高的问题，这时候怎么办?

元数据空间依然还是在不断增大，一味调高 NameNode 的jvm大小绝对不是一个持久的办法。这时候就诞生了 HDFS Federation 的机制。

Federation架构

NameNode 内存过高问题，我们完全可以将大的文件目录移到另外一个 NameNode 上做管理，更重要的一点在于，这些 NameNode 是共享集群中所有的 DataNode 的，

它们还是在同一个集群内的。 HDFS Federation 原理结构如图所示。

HDFS Federation 是解决 NameNode 单点问题的水平横向扩展方案。使得到多个独立的 NameNode 和命名空间。

从而使得 HDFS 的命名服务能够水平扩张 HDFS Federation 中的 NameNode 相互独立管理自己的命名空间。

这时候在 DataNode 上就不仅仅存储一个 Block Pool 下的数据，而是多个。

在 HDFS Federation 的情况下，只有元数据的管理与存放被分隔开，而真实数据的存储还是共用的。

文献参考

《Hadoop & Spark大数据开发实战》肖睿、雷刚跃主编