HDFS 高可用性

配置概述

与联合配置类似，HA 配置向后兼容，并允许现有的单个 NameNode 配置在不进行更改的情况下工作。新配置的设计使得集群中的所有节点都可以具有相同的配置，而无需根据节点类型将不同的配置文件部署到不同的机器。

与 HDFS 联合一样，HA 集群重复使用 nameservice ID 来标识一个可能实际上由多个 HA NameNode 组成的单个 HDFS 实例。此外，HA 中添加了一个名为 NameNode ID 的新抽象。集群中的每个不同的 NameNode 都具有不同的 NameNode ID 来对其进行区分。为了支持所有 NameNode 的单个配置文件，相关配置参数后缀为 nameservice ID 以及 NameNode ID。

配置详细信息

要配置 HA NameNode，您必须向 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 将使用此列表确定集群中的所有 NameNode。例如，如果您之前使用“mycluster”作为名称服务 ID，并且您想使用“nn1”、“nn2”和“nn3”作为 NameNode 的各个 ID，则可以按如下方式进行配置

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

  注意：HA 的 NameNode 最小数量为两个，但您可以配置更多。建议不要超过 5 个（建议为 3 个 NameNode），因为这会产生通信开销。

• 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>
  <property>
    <name>dfs.namenode.rpc-address.mycluster.nn3</name>
    <value>machine3.example.com:8020</value>
  </property>
  

  注意：如果您愿意，还可以类似地配置“servicerpc-address”设置。

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

  与上面提到的 rpc-address 类似，设置两个 NameNode 的 HTTP 服务器监听的地址。例如

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

  注意：如果您启用了 Hadoop 的安全功能，则还应为每个 NameNode 以类似的方式设置 https-address。

• dfs.namenode.shared.edits.dir - 共享存储目录的位置

  这是配置备用 NameNode 用于随时了解活动 NameNode 所做的所有文件系统更改的远程共享编辑目录的路径的位置。您应该仅配置其中一个目录。此目录应在 NameNode 机器上以 r/w 方式挂载。此设置的值应是 NameNode 机器上此目录的绝对路径。例如

  <property>
    <name>dfs.namenode.shared.edits.dir</name>
    <value>file:///mnt/filer1/dfs/ha-name-dir-shared</value>
  </property>
  

• dfs.client.failover.proxy.provider.[名称服务 ID] - HDFS 客户端用来联系活动名称节点的 Java 类

  配置 DFS 客户端将用来确定哪个名称节点是当前活动名称节点的 Java 类的名称，因此哪个名称节点当前正在处理客户端请求。Hadoop 当前附带的两个实现是 ConfiguredFailoverProxyProvider 和 RequestHedgingProxyProvider（对于第一个调用，它同时调用所有名称节点以确定活动名称节点，对于后续请求，它调用活动名称节点，直到发生故障转移），因此除非您正在使用自定义代理提供程序，否则请使用其中一个。

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

• dfs.ha.fencing.methods - 在故障转移期间将用来隔离活动名称节点的脚本或 Java 类的列表

  对于系统的正确性来说，至关重要的是在任何给定时间只有一个名称节点处于活动状态。因此，在故障转移期间，我们首先确保活动名称节点处于备用状态，或者进程已终止，然后才能将另一个名称节点转换到活动状态。为了做到这一点，您必须配置至少一种隔离方法。它们被配置为一个换行符分隔的列表，该列表将按顺序尝试，直到一个指示隔离已成功。Hadoop 附带了两种方法：shell 和 sshfence。有关实现您自己的自定义隔离方法的信息，请参阅 org.apache.hadoop.ha.NodeFencer 类。

  ---

  sshfence - SSH 到活动名称节点并终止该进程

  sshfence 选项 SSH 到目标节点并使用 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 命令来隔离活动名称节点

  shell 隔离方法运行任意 shell 命令。它可以这样配置

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

  ‘(’ 和 ‘)’ 之间字符串直接传递到 bash shell，并且不能包含任何闭合括号。

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

  此外，以下变量也适用于要隔离的目标节点

  $target_host	要隔离的节点的主机名
  $target_port	要隔离的节点的 IPC 端口
  $target_address	以上两者，组合为 host:port
  $target_nameserviceid	要隔离的 NN 的名称服务 ID
  $target_namenodeid	要隔离的 NN 的名称节点 ID

  这些环境变量也可以用作 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.ha.nn.not-become-active-in-safemode - 如果防止安全模式名称节点变为活动

  是否允许 namenode 在安全模式下变为活动状态，当设置为 true 时，安全模式下的 namenode 将在自动故障转移开启时向 ZKFC 报告 SERVICE_UNHEALTHY，或将在自动故障转移关闭时抛出异常，从而导致无法转换到活动状态。例如

  <property>
    <name>dfs.ha.nn.not-become-active-in-safemode</name>
    <value>true</value>
  </property>
  

部署详细信息

设置所有必需的配置选项后，必须先同步两个 HA NameNode 的磁盘元数据。

• 如果要设置新的 HDFS 集群，应首先在其中一个 NameNode 上运行格式化命令 (hdfs namenode -format)。

• 如果您已格式化 NameNode，或正在将非 HA 启用的集群转换为 HA 启用，现在应通过在未格式化的 NameNode 上运行命令“hdfs namenode -bootstrapStandby”将 NameNode 元数据目录的内容复制到另一个未格式化的 NameNode。运行此命令还将确保共享编辑目录（由 dfs.namenode.shared.edits.dir 配置）包含足够编辑事务，以便能够启动两个 NameNode。

• 如果您正在将非 HA NameNode 转换为 HA，应运行命令“hdfs -initializeSharedEdits”，这将使用本地 NameNode 编辑目录中的编辑数据初始化共享编辑目录。

此时，您可以像通常启动 NameNode 一样启动所有 HA NameNode。

您可以通过浏览其配置的 HTTP 地址分别访问每个 NameNode 的网页。您会注意到，在配置的地址旁边将显示 NameNode 的 HA 状态（“备用”或“活动”）。每当 HA NameNode 启动时，它最初都处于备用状态。

管理命令

现在，您的 HA NameNode 已配置并启动，您将可以访问一些其他命令来管理 HA HDFS 集群。具体来说，您应熟悉“hdfs haadmin”命令的所有子命令。在没有任何其他参数的情况下运行此命令将显示以下使用信息

Usage: DFSHAAdmin [-ns <nameserviceId>]
    [-transitionToActive <serviceId>]
    [-transitionToStandby <serviceId>]
    [-failover [--forcefence] [--forceactive] <serviceId> <serviceId>]
    [-getServiceState <serviceId>]
    [-getAllServiceState]
    [-checkHealth <serviceId>]
    [-help <command>]

本指南描述了每个子命令的高级用法。有关每个子命令的具体用法信息，应运行“hdfs haadmin -help <command>”。

• transitionToActive 和 transitionToStandby - 将给定 NameNode 的状态转换为活动或备用

  这些子命令分别导致给定的 NameNode 过渡到活动或备用状态。这些命令不会尝试执行任何隔离，因此很少使用。相反，几乎总是应该优先使用“hdfs haadmin -failover”子命令。

• failover - 在两个 NameNode 之间发起故障转移

  此子命令导致从第一个提供的 NameNode 故障转移到第二个。如果第一个 NameNode 处于备用状态，此命令会简单地将第二个 NameNode 过渡到活动状态，而不会出错。如果第一个 NameNode 处于活动状态，将尝试将其优雅地过渡到备用状态。如果失败，将按顺序尝试隔离方法（由 dfs.ha.fencing.methods 配置），直到其中一个成功。只有在此过程之后，第二个 NameNode 才会过渡到活动状态。如果没有隔离方法成功，第二个 NameNode 不会过渡到活动状态，并且会返回错误。

• getServiceState - 确定给定的 NameNode 是活动还是备用

  连接到提供的 NameNode 以确定其当前状态，将“standby”或“active”打印到 STDOUT 中。此子命令可由 cron 作业或监视脚本使用，这些脚本需要根据 NameNode 当前是活动还是备用而表现出不同的行为。

• getAllServiceState - 返回所有 NameNode 的状态

  连接到配置的 NameNode 以确定当前状态，将“standby”或“active”打印到 STDOUT 中。

• checkHealth - 检查给定 NameNode 的运行状况

  连接到提供的 NameNode 以检查其运行状况。NameNode 能够对自身执行一些诊断，包括检查内部服务是否按预期运行。如果 NameNode 运行状况良好，此命令将返回 0，否则返回非零值。可以将此命令用于监视目的。

  注意：这尚未实现，目前将始终返回成功，除非给定的 NameNode 完全关闭。

简介

以上部分描述了如何配置手动故障转移。在此模式下，即使活动节点已发生故障，系统也不会自动触发从活动 NameNode 到备用 NameNode 的故障转移。本节介绍如何配置和部署自动故障转移。

组件

自动故障转移向 HDFS 部署添加了两个新组件：ZooKeeper 仲裁和 ZKFailoverController 进程（缩写为 ZKFC）。

Apache ZooKeeper 是一种高可用服务，用于维护少量协调数据，通知客户端该数据中的更改，并监控客户端以查找故障。自动 HDFS 故障转移的实现依赖于 ZooKeeper 来执行以下操作

• 故障检测 - 集群中的每台 NameNode 机器都在 ZooKeeper 中维护一个持久会话。如果机器崩溃，ZooKeeper 会话将过期，通知其他 NameNode 应触发故障转移。

• 活动 NameNode 选举 - ZooKeeper 提供了一种简单的机制，可独占地将一个节点选为活动节点。如果当前活动 NameNode 崩溃，另一个节点可以在 ZooKeeper 中获取一个特殊的独占锁，表示它应成为下一个活动节点。

ZKFailoverController (ZKFC) 是一个新组件，它是一个 ZooKeeper 客户端，还监控和管理 NameNode 的状态。运行 NameNode 的每台机器还运行一个 ZKFC，该 ZKFC 负责

• 运行状况监控 - ZKFC 定期使用运行状况检查命令 ping 其本地 NameNode。只要 NameNode 及时响应并处于运行状况良好状态，ZKFC 就会认为该节点运行状况良好。如果节点已崩溃、冻结或进入其他运行状况不佳的状态，运行状况监控器会将其标记为运行状况不佳。

• ZooKeeper 会话管理 - 当本地 NameNode 运行状况良好时，ZKFC 会在 ZooKeeper 中保持会话处于打开状态。如果本地 NameNode 处于活动状态，它还将持有特殊的“锁”znode。此锁使用 ZooKeeper 对“临时”节点的支持；如果会话过期，锁节点将自动删除。

• 基于 ZooKeeper 的选举 - 如果本地 NameNode 运行状况良好，并且 ZKFC 看到当前没有其他节点持有锁 znode，它本身将尝试获取锁。如果成功，则它已“赢得选举”，并负责运行故障转移以使其本地 NameNode 处于活动状态。故障转移过程类似于上面描述的手动故障转移：首先，如果需要，将隔离以前的活动节点，然后本地 NameNode 转换到活动状态。

有关自动故障转移设计的更多详细信息，请参阅附加到 Apache HDFS JIRA 上的 HDFS-2185 的设计文档。

部署 ZooKeeper

在典型部署中，ZooKeeper 守护进程配置为在三个或五个节点上运行。由于 ZooKeeper 本身对资源要求较低，因此可以将 ZooKeeper 节点与 HDFS NameNode 和 Standby Node 部署在同一硬件上。许多操作员选择将第三个 ZooKeeper 进程部署在与 YARN ResourceManager 相同的节点上。建议将 ZooKeeper 节点配置为将数据存储在与 HDFS 元数据分开的磁盘驱动器上，以获得最佳性能和隔离性。

ZooKeeper 的设置不在本文档的讨论范围内。我们将假设您已设置了一个在三个或更多节点上运行的 ZooKeeper 集群，并通过使用 ZK CLI 连接验证了其正确操作。

开始之前

在开始配置自动故障转移之前，您应该关闭集群。在集群运行时，目前无法从手动故障转移设置过渡到自动故障转移设置。

配置自动故障转移

自动故障转移的配置需要在配置中添加两个新参数。在您的 hdfs-site.xml 文件中，添加

 <property>
   <name>dfs.ha.automatic-failover.enabled</name>
   <value>true</value>
 </property>

这指定了集群应设置为自动故障转移。在您的 core-site.xml 文件中，添加

 <property>
   <name>ha.zookeeper.quorum</name>
   <value>zk1.example.com:2181,zk2.example.com:2181,zk3.example.com:2181</value>
 </property>

这列出了运行 ZooKeeper 服务的主机端口对。

与本文档前面描述的参数一样，这些设置可以通过在配置键后缀添加名称服务 ID 来按名称服务进行配置。例如，在启用了联合的集群中，您可以通过设置 dfs.ha.automatic-failover.enabled.my-nameservice-id 来显式地仅为其中一个名称服务启用自动故障转移。

还有几个其他配置参数可以设置来控制自动故障转移的行为；但是，大多数安装都不需要这些参数。有关详细信息，请参阅特定配置键文档。

在 ZooKeeper 中初始化 HA 状态

添加配置键后，下一步是在 ZooKeeper 中初始化所需状态。您可以从其中一个 NameNode 主机运行以下命令来执行此操作。

[hdfs]$ $HADOOP_HOME/bin/zkfc -formatZK

这将在 ZooKeeper 中创建一个 znode，自动故障转移系统在其内部存储数据。

使用 start-dfs.sh 启动集群

由于已在配置中启用了自动故障转移，因此 start-dfs.sh 脚本现在将在运行 NameNode 的任何机器上自动启动 ZKFC 守护进程。当 ZKFC 启动时，它们将自动选择一个 NameNode 成为活动 NameNode。

手动启动集群

如果您手动管理群集上的服务，则需要在运行 NameNode 的每台机器上手动启动 zkfc 守护程序。您可以通过运行以下命令来启动守护程序

[hdfs]$ $HADOOP_HOME/bin/hdfs --daemon start zkfc

保护对 ZooKeeper 的访问

如果您正在运行安全群集，则可能希望确保存储在 ZooKeeper 中的信息也受到保护。这可以防止恶意客户端修改 ZooKeeper 中的元数据或可能触发错误故障转移。

为了保护 ZooKeeper 中的信息，首先将以下内容添加到您的 core-site.xml 文件中

 <property>
   <name>ha.zookeeper.auth</name>
   <value>@/path/to/zk-auth.txt</value>
 </property>
 <property>
   <name>ha.zookeeper.acl</name>
   <value>@/path/to/zk-acl.txt</value>
 </property>

请注意这些值中的“@”字符 - 这指定配置不是内联的，而是指向磁盘上的文件。还可以通过 CredentialProvider 读取身份验证信息（请参阅 hadoop-common 项目中的 CredentialProviderAPI 指南）。

第一个配置的文件指定了 ZooKeeper 身份验证列表，其格式与 ZK CLI 使用的格式相同。例如，您可以指定类似以下内容

digest:hdfs-zkfcs:mypassword

…其中 hdfs-zkfcs 是 ZooKeeper 的唯一用户名，而 mypassword 是用作密码的某个唯一字符串。

接下来，使用以下命令生成与该身份验证相对应的 ZooKeeper ACL

[hdfs]$ java -cp $ZK_HOME/lib/*:$ZK_HOME/zookeeper-3.4.2.jar org.apache.zookeeper.server.auth.DigestAuthenticationProvider hdfs-zkfcs:mypassword
output: hdfs-zkfcs:mypassword->hdfs-zkfcs:P/OQvnYyU/nF/mGYvB/xurX8dYs=

将此输出中“->”字符串后面的部分复制并粘贴到文件 zk-acls.txt 中，并在前面加上字符串“digest:”。例如

digest:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=:rwcda

为了使这些 ACL 生效，您应该按上述描述重新运行 zkfc -formatZK 命令。

这样做之后，您可以从 ZK CLI 验证 ACL，如下所示

[zk: localhost:2181(CONNECTED) 1] getAcl /hadoop-ha
'digest,'hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=
: cdrwa

验证自动故障转移

设置自动故障转移后，您应该测试其操作。为此，首先找到活动 NameNode。您可以通过访问 NameNode Web 界面来判断哪个节点处于活动状态 - 每个节点都会在其页面顶部报告其 HA 状态。

找到活动 NameNode 后，您可以在该节点上引发故障。例如，您可以使用 kill -9 <pid of NN> 来模拟 JVM 崩溃。或者，您可以对机器进行电源循环或拔下其网络接口来模拟不同类型的故障。触发您希望测试的故障后，其他 NameNode 应在几秒钟内自动变为活动状态。检测故障并触发故障转移所需的时间取决于 ha.zookeeper.session-timeout.ms 的配置，但默认为 5 秒。

如果测试不成功，则您可能配置错误。检查 zkfc 守护程序和 NameNode 守护程序的日志，以便进一步诊断问题。