背景
在Hadoop 2.0.0之前，NameNode是HDFS集群中的单点故障（SPOF）问题所在。 每个群集都有一个NameNode，如果该机器或进程不可用，整个群集将不可用，直到NameNode重新启动或在单独的机器上启动。
这在两个主要方面影响了HDFS集群的总体可用性：
- 在计划外事件（例如机器崩溃）的情况下，集群将不可用，直到操作人员重新启动NameNode。
- 计划的维护事件（如NameNode计算机上的软件或硬件升级）将导致群集停机。
HDFS高可用性功能通过提供在具有热备份的主动（或被动）配置中，在同一群集运行两个冗余NameNode的方法来解决上述问题。 这允许在机器崩溃的情况下快速故障转移到新的NameNode，或者为了计划维护的目的而进行正常故障转移。
架构
在典型的HA（高可用）集群中，两台独立的机器被配置为NameNode。 在任何时候，只有一个NameNode处于Active状态，另一个处于Standby状态。 主动NameNode负责群集中的所有客户端操作，而备用服务器仅充当从服务器，保持足够的状态以在必要时提供快速故障转移。
为了使备用节点保持其与主动节点的状态同步，两个节点都与称为“日志节点”（JN）的一组单独的守护进程进行通信。 当活动节点执行任何名称空间修改时，它会将修改记录持久地记录到大多数这些JN中。备用节点能够读取来自JN的编辑日志，并不断监视编辑日志的变化。 当待机节点看到编辑日志时，它将它们应用到它自己的命名空间。 如果发生故障转移，备用服务器将确保在将自己提升为活动状态之前，已经从JounalNodes中读取所有编辑日志。这确保了在故障转移发生之前命名空间状态已经完全同步。
为了提供快速故障切换，备用节点还需要有关于集群中块的位置的最新信息。 为了实现这一点，DataNode通过配置得知两个NameNode的位置，并发送块位置信息和心跳给两者。
HA群集的正确操作对于一次只有一个NameNode处于活动状态至关重要。 否则，命名空间状态将很快在两者之间发生分歧，从而可能导致数据丢失或其他不正确的结果。为了确保这个属性并防止所谓的“裂脑场景”，JournalNodes一次只允许一个NameNode作为一个主节点进行编辑。 在故障转移期间，要成为活动状态的NameNode将简单地接管写入JournalNodes的日志，这将有效地防止另一个NameNode继续处于活动状态，从而允许新的活动安全地进行故障转移。
硬件资源
为了部署HA群集，您应该准备以下内容：
- NameNode机器 - 运行Active和Standby NameNode的机器应该具有彼此相同的硬件，以及等同于非HA群集中使用的硬件的硬件。
- JournalNode机器 - 运行JournalNodes的机器。 JournalNode守护进程是相对轻量级的，所以这些守护进程可以合理地与其他Hadoop守护进程（例如NameNodes，JobTracker或YARN ResourceManager）同时配置在机器上。 注意：必须至少有3个JournalNode守护进程，因为编辑日志修改必须写入大多数JN。 这将允许系统容忍单台机器的故障。 您也可以运行3个以上的JournalNodes，但为了增加系统可以容忍的故障次数，应该运行奇数个JN（即3,5,7等）。 请注意，在运行N个JournalNodes时，系统最多可以承受（N-1）/ 2次故障，并继续正常工作。
请注意，在HA群集中，备用NameNode也会检查名称空间状态的检查点，因此不需要在HA群集中运行Secondary NameNode，CheckpointNode或BackupNode。事实上，这样做会是一个错误。这也允许正在重新配置未启用HA的HDFS群集启用HA之前专用于Secondary NameNode的服务器。
文章评论