HA With QJM

目标

本指南概述了HDFS高可用性（HA）功能以及如何使用Quorum Journal Manager（QJM）功能配置和管理HA HDFS集群。

本文档假设读者对HDFS集群中的一般组件和节点类型有一般的了解。有关详细信息，请参阅HDFS架构指南。

本指南讨论如何使用Quorum Journal Manager（QJM）配置和使用HDFS HA，以在Active和Standby NameNodes之间共享编辑日志

背景

在Hadoop 2.0.0之前，NameNode是HDFS集群中的单点故障（SPOF）。每个集群都有一个NameNode，如果该机器或进程变得不可用，则整个集群将不可用，直到NameNode重新启动或在单独的计算机上启动。

这两个方面影响了HDFS集群的总体可用性：

　　在计算机事件（例如机器崩溃）的情况下，集群将不可用，直到操作员重新启动NameNode。

　　NameNode机器上的计划维护事件（如软件或硬件升级）将导致集群停机时间的窗口。

HDFS高可用性功能通过提供在具有热备用的主动/被动配置中的同一集群中运行两个冗余名称节点来解决上述问题。这允许在机器崩溃的情况下快速故障切换到新的NameNode，或者为了计划维护而对管理员启动的优化优雅转换。

架构

在典型的HA集群中，将两台独立的计算机配置为NameNodes。在任何时间点，其中一个NameNodes处于活动状态，另一个处于待机状态。Active NameNode负责集群中的所有客户端操作，而Standby仅作为从站，维护足够的状态以在必要时提供快速故障转移。

为了使备用节点保持与Active节点同步的状态，两个节点都与一组名为“JournalNodes”（JN）的独立守护程序进行通信。当Active节点执行任何命名空间修改时，它可以将修改的记录持久记录到大多数这些JN。备用节点能够读取JN的编辑，并且不断地观察它们对编辑日志的更改。当待机节点看到编辑时，它将它们应用于自己的命名空间。在故障切换的情况下，待机将确保它已经读取了JounalNodes的所有编辑，然后再将其自身升级到Active状态。这将确保名称空间状态在发生故障转移之前完全同步。

为了提供快速故障切换，还需要备用节点具有有关集群中块的位置的最新信息。为了实现这一点，DataNodes配置有两个NameNodes的位置，并向两者发送块位置信息和心跳。

对于HA群集的正确操作至关重要，因此一次只能有一个NameNodes处于活动状态。否则，命名空间状态将在两者之间快速分离，冒着数据丢失或其他不正确的结果。为了确保这种属性并防止所谓的“脑裂”，JournalNodes将只允许一个NameNode作为一个作者。在故障切换期间，要变为活动状态的NameNode将简单地接管写入JournalNodes的角色，这将有效地防止其他NameNode继续处于活动状态，允许新的Active安全地进行故障转移。

硬件资源

为了部署HA群集，您应该准备以下内容：

　　NameNode机器 - 运行Active和Standby NameNodes的机器应具有彼此的等效硬件，以及与非HA集群中使用的硬件相同的硬件。

　　JournalNode机器 - 运行JournalNodes的机器。JournalNode守护进程是相对轻量级的，因此这些守护进程可能会合理地与其他Hadoop守护程序（例如NameNodes，JobTracker或YARN ResourceManager）并置在机器上。注意：必须至少有3个JournalNode守护程序，因为编辑日志修改必须写入大多数JN。这将允许系统容忍单个机器的故障。您也可以运行超过3个JournalNodes，但为了实际增加系统可以忍受的故障次数，您应该运行奇数JN（即3，5，7等）。请注意，当使用N JournalNodes运行时，系统最多可以忍受（N-1）/ 2故障，并继续正常工作

请注意，在HA群集中，Standby NameNode还执行命名空间状态的检查点，因此不需要在HA群集中运行Secondary NameNode，CheckpointNode或BackupNode。其实这样做会是一个错误。这还允许正在重新配置不支持HA的HDFS集群的HA被启用以重新使用先前专用于Secondary NameNode的硬件。

部署

配置概述

与联邦配置类似，HA配置向后兼容，并允许现有的单个NameNode配置工作，无需更改。新配置被设计为使得集群中的所有节点可以具有相同的配置，而不需要基于节点的类型将不同的配置文件部署到不同的机器。

像HDFS联盟一样，HA集群重新使用名称服务ID来标识单个HDFS实例，其实际上可能由多个HA名称节点组成。另外，一个称为NameNode ID的新抽象与HA一起添加。群集中的每个不同的NameNode具有不同的NameNode ID来区分它。为了支持所有NameNodes的单个配置文件，相关配置参数后缀名称服务ID以及NameNode ID。

配置细节

要配置HA NameNodes，必须在hdfs-site.xml配置文件中添加多个配置选项。

您设置这些配置的顺序不重要，但是您为dfs.nameservices和dfs.ha.namenodes.[nameservice ID]选择的值将决定随后的键。因此，在设置其余的配置选项之前，您应该决定这些值。

dfs.nameservices  新服务的逻辑名称

　　　为此名称服务器选择一个逻辑名称，例如“mycluster”，并使用此逻辑名称作为此配置选项的值。你选择的名字是任意的。它将用于配置和集群中绝对HDFS路径的权限组件。

　　　注意：如果您还使用HDFS联合，则此配置设置还应包含其他名称服务（HA或其他）的列表，以逗号分隔列表。

<property>
  <name>dfs.nameservices</name>
  <value>mycluster</value>
</property>

dfs.ha.namenodes.[nameservice ID]   名称服务中每个NameNode的唯一标识符

使用以逗号分隔的NameNode ID的列表进行配置。DataNodes将使用它来确定集群中的所有NameNodes。例如，如果以前使用“mycluster”作为nameervice ID，并且想要使用“nn1”和“nn2”作为NameNodes的个别ID，则可以将其配置为：

HA With NFS

目标

本指南概述了HDFS高可用性（HA）功能，以及如何配置和管理HA HDFS集群，使用NFS作为NameNodes所需的共享存储。

本文档假设读者对HDFS集群中的一般组件和节点类型有一般的了解。有关详细信息，请参阅HDFS架构指南。

架构

在典型的HA集群中，将两台独立的计算机配置为NameNodes。在任何时间点，其中一个NameNodes处于活动状态，另一个处于待机状态。Active NameNode负责集群中的所有客户端操作，而Standby仅作为从站，维护足够的状态以在必要时提供快速故障转移。

为了使备用节点将其状态与Active节点保持同步，当前实现要求两个节点都可以访问共享存储设备上的目录（例如，从NAS安装NFS）。这种限制在将来的版本中可能会放宽。

当Active节点执行任何命名空间修改时，它可以将修改的记录持久记录到共享目录中存储的编辑日志文件中。待机节点一直在观看此目录以进行编辑，并且当它看到编辑时，它将其应用于其自己的命名空间。在故障切换的情况下，待机将确保已经从共享存储中读取所有编辑，然后再将其自身升级到活动状态。这将确保名称空间状态在发生故障转移之前完全同步。

为了提供快速故障切换，还需要备用节点具有有关集群中块的位置的最新信息。为了实现这一点，DataNodes配置有两个NameNodes的位置，并向两者发送块位置信息和心跳

对于HA群集的正确操作至关重要，因此一次只能有一个NameNodes处于活动状态。否则，命名空间状态将在两者之间快速分离，冒着数据丢失或其他不正确的结果。为了确保这种属性并防止所谓的“脑裂”，JournalNodes将只允许一个NameNode作为一个作者。在故障切换期间，要变为活动状态的NameNode将简单地接管写入JournalNodes的角色，这将有效地防止其他NameNode继续处于活动状态，允许新的Active安全地进行故障转移。

硬件资源

为了部署HA群集，您应该准备以下内容：

　　NameNode机器 - 运行Active和Standby NameNodes的机器应具有彼此的等效硬件，以及与非HA集群中使用的硬件相同的硬件。

　　共享存储 - 您将需要一个共享目录，这两个NameNode机器可以具有读/写访问权限。通常这是一个远程文件管理器，它支持NFS并安装在每个NameNode机器上。目前只支持单个共享编辑目录。因此，系统的可用性受到该共享编辑目录的可用性的限制，因此为了删除共享编辑目录需要冗余的所有单个故障点。具体来说，存储的多个网络路径，以及存储本身的冗余（磁盘，网络和电源）。扼杀这一点，建议共享存储服务器是高品质的专用NAS设备，而不是一个简单的Linux服务器。

请注意，在HA群集中，Standby NameNode还执行命名空间状态的检查点，因此不需要在HA群集中运行Secondary NameNode，CheckpointNode或BackupNode。其实这样做会是一个错误。这还允许正在重新配置不支持HA的HDFS集群的HA被启用以重新使用先前专用于Secondary NameNode的硬件。