HDFS概述（5）————HDFS HA

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。

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

$target_host	hostname of the node to be fenced
$target_port	IPC port of the node to be fenced
$target_address	the above two, combined as host:port
$target_nameserviceid	the nameservice ID of the NN to be fenced
$target_namenodeid	the namenode ID of the NN to be fenced

　　　　这些环境变量也能够用做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的硬件。