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，则可以将其配置为：

<property><name>dfs.ha.namenodes.mycluster</name><value>nn1,nn2</value>
</property>

注意：目前，每个名称服务器最多只能配置两个NameNodes。

dfs.namenode.rpc-address.[nameservice ID].[name node ID]  每个NameNode要收听的完全限定的RPC地址

对于以前配置的两个NameNode ID，请设置NameNode进程的完整地址和IPC端口。请注意，这将导致两个单独的配置选项。例如：

<property><name>dfs.namenode.rpc-address.mycluster.nn1</name><value>machine1.example.com:8020</value>
</property>
<property><name>dfs.namenode.rpc-address.mycluster.nn2</name><value>machine2.example.com:8020</value>
</property>

注意：如果您愿意，也可以配置“servicerpc-address”设置。

dfs.namenode.http-address.[nameservice ID].[name node ID]   每个NameNode要监听的完全限定的HTTP地址

类似于上面的rpc-address，设置两个NameNodes的HTTP服务器进行监听的地址。例如：

<property><name>dfs.namenode.http-address.mycluster.nn1</name><value>machine1.example.com:50070</value>
</property>
<property><name>dfs.namenode.http-address.mycluster.nn2</name><value>machine2.example.com:50070</value>
</property>

注意：如果您启用了Hadoop的安全功能，您还应该为每个NameNode设置类似的https地址

dfs.namenode.shared.edits.dir  　　标识NameNodes  JN组进程将写/读EditLog的URI

这是一个配置提供共享编辑存储的JournalNodes的地址，由Active nameNode写入并由Standby NameNode读取，以保持Active NameNode所做的所有文件系统更改的最新。虽然您必须指定几个JournalNode地址，但您只能配置其中一个URI。URI的格式应为：“qjournal：// host1：port1; host2：port2; host3：port3 / journalId”。日记帐ID是此名称服务的唯一标识符，允许单个JournalNodes集合为多个联合名称系统提供存储。虽然不是一个要求，但是重新使用日志标识符的名称服务ID是个好主意。

例如，如果此群集的JournalNodes在机器“node1.example.com”，“node2.example.com”和“node3.example.com”上运行，并且名称服务ID为“mycluster”，则将使用以下作为此设置的值（JournalNode的默认端口为8485）：

<property><name>dfs.namenode.shared.edits.dir</name><value>qjournal://node1.example.com:8485;node2.example.com:8485;node3.example.com:8485/mycluster</value>
</property>

dfs.client.failover.proxy.provider.[nameservice ID]  HDFS客户端用于联系Active NameNode的Java类

配置将由DFS客户端使用的Java类的名称来确定哪个NameNode是当前的Active，并且因此NameNode当前正在为客户端请求提供服务。目前与Hadoop一起提供的唯一实现是ConfiguredFailoverProxyProvider，因此除非您使用自定义的。例如：

<property><name>dfs.client.failover.proxy.provider.mycluster</name><value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>

dfs.ha.fencing.methods 在故障切换期间将用于隔离Active NameNode的脚本或Java类的列表

对于系统的正确性，期望在任何给定时间只有一个NameNode处于活动状态。重要的是，当使用Quorum Journal Manager时，只有一个NameNode将被允许写入JournalNodes，所以不存在从裂脑场景中破坏文件系统元数据的可能性。但是，当发生故障切换时，以前的Active NameNode可能会向客户端提供读取请求，这可能是过期的，直到该NameNode在尝试写入JournalNodes时关闭。因此，即使使用Quorum Journal Manager，仍然需要配置一些防护方法。但是，为了提高系统在防护机制发生故障时的可用性，建议配置防护方法，保证将其作为列表中最后的防护方法返回成功。请注意，如果您选择不使用实际的防护方法，您仍然必须为此设置配置一些东西，例如“shell（/ bin / true）”。

在故障切换期间使用的防护方法被配置为回车分隔列表，将按顺序尝试，直到一个指示击剑成功。Hadoop有两种方法：shell和sshfence。有关实现自己的定制防护方法的信息，请参阅org.apache.hadoop.ha.NodeFencer类。

　　sshfence   SSH到Active NameNode并终止进程

　　　sshfence选项SSHes到目标节点，并使用fuser来杀死监听服务的TCP端口的进程。为了使这个防护选项工作，它必须能够SSH到目标节点而不提供密码。因此，还必须配置dfs.ha.fencing.ssh.private-key-files选项，该选项是以逗号分隔的SSH私钥文件列表。例如：

　　　　<property><name>dfs.ha.fencing.methods</name><value>sshfence</value></property><property><name>dfs.ha.fencing.ssh.private-key-files</name><value>/home/exampleuser/.ssh/id_rsa</value></property>

　　　　或者，可以配置非标准用户名或端口来执行SSH。也可以为SSH配置超时时间（以毫秒为单位），之后该防护方法将被认为失败。它可以像这样配置：　　

　　　　<property><name>dfs.ha.fencing.methods</name><value>sshfence([[username][:port]])</value></property><property><name>dfs.ha.fencing.ssh.connect-timeout</name><value>30000</value></property>

　　shell 运行一个任意的shell命令来终止Active NameNode　　
　　　　shell防护方法运行任意shell命令。它可以像这样配置：

<property><name>dfs.ha.fencing.methods</name><value>shell(/path/to/my/script.sh arg1 arg2 ...)</value>
</property>

　　　　'（'and'）'之间的字符串直接传递给bash shell，可能不包括任何关闭括号。

　　　　shell命令将运行，环境设置为包含所有当前的Hadoop配置变量，'_'字符替换任何'。'。配置键中的字符。所使用的配置已经具有提升为其通用形式的任何特定于Namenode的配置 - 例如，dfs_namenode_rpc-address将包含目标节点的RPC地址，即使配置可以将该变量指定为dfs.namenode.rpc-address。ns1.nn1。

　　　　另外，还可以使用下列变量来指定要围栏的目标节点：

　　　　这些环境变量也可以用作shell命令本身的替代。例如：

<property><name>dfs.ha.fencing.methods</name><value>shell(/path/to/my/script.sh --nameservice=$target_nameserviceid $target_host:$target_port)</value>
</property>

如果shell命令返回0的退出代码，则确定击剑是成功的。如果返回任何其他退出代码，则击剑不成功，并且将尝试列表中的下一个击剑方法。注意：此防护方法不会执行任何超时。如果超时是必要的，它们应该在shell脚本本身中实现（例如，通过在几秒钟内分割子shell来杀死其父进程）。

fs.defaultFS　　当没有给出Hadoop FS客户端时使用的默认路径前缀

或者，您现在可以配置Hadoop客户端的默认路径以使用新的启用HA的逻辑URI。如果您以前使用“mycluster”作为名称服务ID，则这将是所有HDFS路径的权限部分的值。在core-site.xml文件中可以这样配置：

<property><name>fs.defaultFS</name><value>hdfs://mycluster</value>
</property>

dfs.journalnode.edits.dir JournalNode守护程序将存储其本地状态的路径

这是日志节点计算机上绝对路径，其中JN将使用编辑和其他本地状态。您只能使用单一路径进行此配置。通过运行多个独立的JournalNodes或通过在本地连接的RAID阵列上配置此目录来提供此数据的冗余。例如：

<property><name>dfs.journalnode.edits.dir</name><value>/path/to/journal/node/local/data</value>
</property>

部署细节

//TODO：

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的硬件。