Hadoop2.5.1 HDFS High Availability With QJM（Quorum Journal Manager）

关注

翻译最新推荐文章于 2026-07-05 11:02:07 发布 2k 阅读 AI 写同款· GEO 优化 ›

HDFS High Availability 高可用(HA) with QJM 什么是高可用： 1.持续服务的能力。 2.避免single point of failure 单点故障 SPOF Fail Over 容灾 fault tolerent 容错 hadoop实现HA的两种方式 1.Using the Quorum Journal Manager (QJM) 2.NFS net FileSystem 3.QJM架构... 阅读详情

（部分太简单一看就懂的，或看不懂的不翻译）

http://hadoop.apache.org/docs/r2.5.1/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html

一、目的

1. 介绍HDFS HA特性概况

2. 介绍如何使用QJM配置和管理高可用HDFS集群

二、背景

Hadoop2.0之前，HDFS集群的NN有单点故障问题。每个集群只有一个单独的NN，如果NN所在集群宕机或者进程不可用，整个集群也将不可用，直到NN被重启或者指定到别的主机。

影响HDFS集群高可用性的主要原因有以下两个：

1. 如机器宕机等非计划内事件，在NN的重启操作前，集群将处于不可用状态。

2. 如软硬件更新升级等计划性维护，将导致一个小阶段的不可用。

HDFS HA特性通过提供选项，允许在同一个集群以主动/被动方式，在线运行两个冗余的NN，解决了上面的问题。这将允许在如机器宕机等情况下，快速恢复到一个新的NN；或在计划性维护时，管理员以优雅的方式执行故障恢复。

三、架构

在一个普通的高可用集群里，有两台独立机器被配置为NN。在任何时间里，只有一个是处于活动状态，而另一个则处于备用状态。活动NN负责所有客户端通信，同时，备用NN只是一个简单的从节点，维护一个为了在需要时能快速故障恢复的状态。

为了备用NN能通过活动NN通过状态，两个节点通过一组独立进程JN进行通信。任何执行在活动NN的edits，将持久地记录到大多数JN里。备用NN能够在这些JN里读取到edits，并且不断的监控记录的改变。当备用NN读取到这些edits时，就把它们执行一遍。发现故障恢复时，备份NN在确保从JN中读取到所有edits后，就将自己提升为活动NN。这就确保了再发生故障恢复前命名空间已完全同步。

为了提供快速的故障恢复，备用NN拥有最新的块地址信息也是非常重要的。为了实现这个要求，DN同时配置有两个NN的地址，并且同时向两者发送块地址信息和心跳。

在同一时间里，保证高可用集群中只有一个活动NN是至关重要的。否则，两个NN的状态将很快出现不一致，数据有丢失的风险，或者其他错误的结果。为了确保这种属性、防止所谓的脑裂场景（split-brain scenario），在同一时间里，JN只允许一个NN写edits。故障恢复期间，将成为活动节点的NN简单的获取写edits的角色，这将有效的阻止其他NN继续处于活动状态，允许新活动节点安全的进行故障恢复。

四、硬件资源

为了部署高可用集群，需要做如下准备：

NameNode 机器：运行活动NN和备用NN的硬件配置应该是一致的。这和非高可用集群的配置一样。

l JournalNode 机器：JN进程相对轻量级，所以这些进程可以合理的配置在Hadoop集群的其他机器里，如NN，JT、RM。注意：必须至少有3个JN进程，因为edits需要写入到大多数的JN里。这就允许系统单台机器的错误。你也可以运行3个以上JN，但为了实际提高系统对错误的容忍度，最好运行奇数个JN。执行N个JN的集群上，系统可以容忍(N-1)/2台机器错误的同时保持正常工作。

注意：在高可用集群里，备用NN也扮演checkpoint，所以没必要再运行一个Secondary NN，CheckpointNode，或BackupNode。事实上，这样做（运行上述几个节点）是一种错误。这也就允许复用原来指定为Secondary Namenode 的硬件，将一个非高可用的HDFS集群重新配置为高可用的。

五、部署

1．配置预览

HA配置是向后兼容的，允许现有的单个NN节点的配置不做任何改变。新的配置被设计成集群里的所有节点都有相同的配置，而不需要根据节点的类型在不同的机器上部署不同的配置文件。

类似于HDFS Federation，HA集群复用nameservice ID 来标识一个单一实例是否可能是包含在多个HA NN中。另外，增加一个新的抽象名词NameNode ID。集群中，每一个不同的NN使用不同的NameNode ID区分。为了支持所有节点使用单个配置文件，所有相关的配置参数都以nameservice ID 为后缀，类似于NameNode ID。

2．配置详情

在hdfs-site.xml中增加几个配置：

Ø dfs.nameservices - NS的逻辑名词

指定一个逻辑名词，后续的配置选项中将使用到；可以任意指定一个名称，后续将作为HDFS绝对路径的一个权威组件。

注意：如果集群中有使用HDFS Federation，此配置项须同时包含其他NS名称、HA，使用逗号分隔。

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

Ø dfs.ha.namenodes.[nameservice ID] - NS 里每个 NN 的唯一标识

使用逗号分隔配置所有NN。DN通过此配置确定集群中的NN。

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

注意：目前每个NS最多只能配置两个NN。

Ø dfs.namenode.rpc-address.[nameservice ID].[name node ID] - 为每个NN指定完全限定的RPC地址

为前面指定的NN，设置完整地址、端口。

<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]

<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>

Ø dfs.namenode.shared.edits.dir - 指定JN里可读写edits的NN注意：如果你打开了Hadoop 的安全特性，也可以使用https地址。

这是配置JN地址的唯一一个配置。JN提供共享编辑存储，活动NN写入、备用NN读取以保证更新到活动节点对文件系统做出的所有修改。虽然必须指定几个JN地址，但只能配置一次。格式为：

qjournal://host1:port1;host2:port2;host3:port3/journalId

每个NS中，JournalId是唯一的标识，这允许一个单独的JN集合为多个命名系统提供存储。

虽然不是必须的，journalId 复用NS id 是个好主意。

<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客户端连接活动NN的Java类

配置DFS客户端决定当前活动NN的Java类名。目前只有以下一个实现。

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

Ø dfs.ha.fencing.methods - 发生故障时，用来隔离活动NN的一些脚本或Java类

在任何给定时间只有一个节点处于活动状态，这对系统的正确性是理想的。更重要的是，当是用QJM时，只有一个NN被允许写入到JNs，所以不存在脑裂的场景使元数据文件系统被损坏的潜在危险。

然而，当发生故障恢复时，仍然有可能出现上一个活动NN接受客户端读请求，在NN关闭前、尝试写入JNs的时候，这可能已经过期了。出于这个原因，即使使用QJM，配置一些隔离方法也是可取的。

然而，为了提高在隔离方法失效时系统的可用性，最好是保证列表最后一个隔离方法返回成功结果。

注意：如果你选择不使用实际的隔离方法，你仍然必须做一些设置，如"shell(/bin/true)"。

故障恢复时的隔离方法配置为以换行分隔的列表，按顺序尝试表达式知道有一个指明了隔离成功。Hadoop有两种方法： shell 和 sshfence 。如果想实现自己的隔离方法，可以参考org.apache.hadoop.ha.NodeFencer 类。

sshfence - SSH到活动节点并且杀掉进程

SSH到目标节点，使用fuser杀掉监听服务的进程。为了此隔离方法能正常工作，必须指定一个能够SSH到目标节点的秘钥。因此，必须配置dfs.ha.fencing.ssh.private-key-files选项：

<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命令以隔离活动NN

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

这个shell命令将运行在以“_”代替“.”的所有当前hadoop配置变量组成的环境变量中。这些配置已经被一些NN指定的格式提升为通用形式——例如，dfs_namenode_rpc-address可能包含目标节点的RPC，尽管配置的是dfs.namenode.rpc-address.ns1.nn1。“(”和“)”之间的字符串是直接传递给一个bash shell，不得包含任何关闭括号。

另外，下面提及目标节点的变量也是可用的：

$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 时，表示隔离成功。返回其他，表示隔离不成功，列表中的下一个隔离方法将被尝试执行。

Ø · fs.desfultFS - 当没有指定时，HDFS客户端使用的默认前缀

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

Ø · dfs.journalnode.edits.dir - JN进程保存本地状态的路径

只能配置为单独的一个路径。提供冗余的方式：1、运行多个独立JN；2、配置在本地连接到RAID矩阵的路径。

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

3．部署详情

配置完所有必须的选项后，启动要运行的JN。可以使用命令"hdfs-daemon.sh journalnode"（译注：实际操作时，发现是hdfs journalnode 或hadoop-daemon.sh start journalnode）。

当JN启动完成，要进行首次同步两个HA NN的磁盘元数据。

如果你是在设置一个新的HDFS集群，你需要先在任意一个NN执行命令(hdfs namenode -format)
如果已经格式化好NN，或者正在把非HA集群转化为HA集群，你可以拷贝原NN的元数据目录到新的NN，然后在新NN上执行"hdfs namenode -bootstrapStandby"，执行这个命令的同时会确保JN包含足够的edits事务以启动两个NN。
如果是在转化一个非HA集群为HA，你可以执行"hdfs -initializeSharedEdits"命令，这个命令将使用来自NN edits目录的edits数据初始化JN。

这时候你可以启动所有HANN节点，就像你平常启动一个NN一样。

你可以分别使用每个NN配置的Http地址访问各个NN网页。你可以看到在配置的地址后面紧跟着NN的HA状态（“standby”或“active”）。启动HANN的初始状态是standbby。

4．管理命令

现在你的HA NN都配置好并且启动了，你可以使用另外的命令管理你的HA HDFS。

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

· transitionToActive and transitionToStandby - transition the state of the given NameNode to Active or Standby This guide describes high-level uses of each of these subcommands. For specific usage information of each subcommand, you should run "hdfs haadmin -help <command>".

These subcommands cause a given NameNode to transition to the Active or Standby state, respectively. These commands do not attempt to perform any fencing, and thus should rarely be used. Instead, one should almost always prefer to use the "hdfs haadmin -failover" subcommand.

· failover - initiate a failover between two NameNodes

This subcommand causes a failover from the first provided NameNode to the second. If the first NameNode is in the Standby state, this command simply transitions the second to the Active state without error. If the first NameNode is in the Active state, an attempt will be made to gracefully transition it to the Standby state. If this fails, the fencing methods (as configured by dfs.ha.fencing.methods) will be attempted in order until one succeeds. Only after this process will the second NameNode be transitioned to the Active state. If no fencing method succeeds, the second NameNode will not be transitioned to the Active state, and an error will be returned.

· getServiceState - determine whether the given NameNode is Active or Standby

Connect to the provided NameNode to determine its current state, printing either "standby" or "active" to STDOUT appropriately. This subcommand might be used by cron jobs or monitoring scripts which need to behave differently based on whether the NameNode is currently Active or Standby.

· checkHealth - check the health of the given NameNode

Connect to the provided NameNode to check its health. The NameNode is capable of performing some diagnostics on itself, including checking if internal services are running as expected. This command will return 0 if the NameNode is healthy, non-zero otherwise. One might use this command for monitoring purposes.

Note: This is not yet implemented, and at present will always return success, unless the given NameNode is completely down.

六、自动故障恢复

1．介绍

上面介绍了如何配置人工故障恢复。这种方式下，系统不会自动触发负责恢复，即使活动NN挂掉了。下面描述如何配置和部署挨冻故障恢复。

2．组件

自动故障恢复增加了两个组件：Zookeeper quorum、ZKFailoverController（ZKFC）。

Apache Zookeeper是一个高可用的服务，它能维护少量的协调数据，通知客户数据的变化，监控客户端失败。HDFS故障自动恢复依赖ZK以下特性：

故障检测（Failure detection） - 集群里的每个NN与ZK保持一个持久会话。如果机器宕机，ZK会话将过期，然后提醒其他NN从而触发一个故障恢复。
活动NN选举（Active NameNode election） - ZK提供一个简单的机制专门用来选举活动节点。如果当前的活动NN宕机，另外一个节点会拿到一个在ZK里的特殊的独占锁，这表示这个节点将会成为下一个活动节点。

ZKFC 是一个新的组件，它是一个 ZK 客户端，同时监听和管理 NN 的状态。运行 NN 的机器上须同时运行 ZKFC ，它的责任是：

健康监控（Health monitoring） - ZKFC使用“health-check”命令定期ping本地的NN。只要NN及时的响应一个健康状态，则认为这个节点是健康的。如果节点宕机，无响应或者进入了其他不健康状态，健康监控器认为它是不健康的。
ZK会话管理（ZooKeeper session management） - 当本地NN是健康的，ZKFC持有ZK的一个打开的会话。如果本地NN是活动状态，ZKFC同时持有一个特殊的锁节点（a special "lock" znode）。这个锁使用了ZK的临时节点。如果会话过期，这个锁节点将被自动删除。
基于ZK的选举（ZooKeeper-based election） - 如果本地节点是健康的并且ZKFC发现当前没有节点持有锁，它就尝试获取这个锁。如果成功，它就赢得了选举，执行一次故障恢复以使自己成为活动NN。这个故障恢复过程和前面介绍的人工故障恢复是相似的：1、隔离前活动节点（如果需要）；2、本地NN转换成活动节点

了解更详细的自动恢复的设计，查看HDFS-2185。

3．部署Zookeeper

标准的部署，ZK守护进程一般配置3或5个节点。由于ZK本身对资源的要求很低，所以它可以部署在HDFS的NN上。许多操作者配置第三个ZK节点在ResourceManager上。 It is advisable to configure the ZooKeeper nodes to store their data on separate disk drives from the HDFS metadata for best performance and isolation.

4．开始之前

在开始配置自动故障恢复前，关闭你的集群。。目前还不支持在集群运行时将人工故障恢复转换为自动故障恢复。

5．配置自动故障恢复

增加两个配置：

# 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>

如果集群开启了 federation ，则配置为 dfs.ha.automatic-failover.enabled.my-nameservice-id 。

6．初始化HA在ZK中的状态

在其中一个NN上执行：

hdfs zkfc -formatZK

hdfs zkfc -formatZK这将在ZK里创建一个保存自动故障恢复系统数据的znode节点。

7．使用start-dfs.sh启动集群

这个脚本现在将在NN所在的机器上自动启动ZKFC进程。当ZKFC启动，他们将自动选择一个NN作为活动节点。

8．手动启动集群

如果你是手动管理你集群的服务的，你也可以在NN所在机器上，手动启动zkfc：

$ hadoop-daemon.sh start zkfc

9．安全访问ZK

If you are running a secure cluster, you will likely want to ensure that the information stored in ZooKeeper is also secured. This prevents malicious clients from modifying the metadata in ZooKeeper or potentially triggering a false failover.

In order to secure the information in ZooKeeper, first add the following to your core-site.xml file:

<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>

Please note the '@' character in these values -- this specifies that the configurations are not inline, but rather point to a file on disk.

The first configured file specifies a list of ZooKeeper authentications, in the same format as used by the ZK CLI. For example, you may specify something like:

digest:hdfs-zkfcs:mypassword

...where hdfs-zkfcs is a unique username for ZooKeeper, and mypassword is some unique string used as a password.

Next, generate a ZooKeeper ACL that corresponds to this authentication, using a command like the following:

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

Copy and paste the section of this output after the '->' string into the file zk-acls.txt, prefixed by the string "digest:". For example:

digest:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=:rwcda

In order for these ACLs to take effect, you should then rerun the zkfc -formatZK command as described above.

After doing so, you may verify the ACLs from the ZK CLI as follows:

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

10．验证自动故障恢复

当自动故障恢复设置好，你可以测试他是否工作。首先定位到活动NN。你可以通过NN的Web界面得知哪个是活动NN——每个节点都在页面顶部报告了他的HA状态。

当你定位到活动NN，你可以使它失效。比如，使用kill -9 <pid of NN> 模仿JVM死机。或者，通过重启机器、拔掉网线模仿其他运行中断的情况。触发运行中断后，另一个NN应该在几秒内自动成为活动NN。所需的时间用来发现故障和触发一次故障恢复，依赖于配置ha.zookeeper.session-timeout.ms（默认5秒）。

如果测试不成功，那么你的配置应该有问题。检查zkfc进程的日志。

七、自动故障恢复 FAQ

使用特定的顺序启动ZKFC和NN很重要吗？

不，在任何一个节点上，你可以使用任何顺序启动zkfc和nn。

有没有其他监控器需要在适当的位置部署？

你可以在每个运行了NN的节点监控ZKFC确保它保持运行。在一些ZK宕机的情况下，如ZKFC意外退出，应该重启它，确保系统可以自动故障恢复。

另外，你可以监控ZK quorum。如果ZK宕机，故障自动恢复也不会生效。

ZK宕机后会发生什么？

如果ZK集群宕机，自动故障恢复将不会被触发。然而，HDFS还是可以不受影响地继续运行。当ZK重启了，HDFS将正常地重新连接。

我可以指定一个NN为主要的/优先的（primary/preferred）吗？

不。当前，不支持这种情况。那个NN先启动，它将成为活动节点。你可以选择用特定的顺序启动集群，如你可以先启动优先的节点。

当配置了自动故障恢复，怎样引发一次手动故障恢复

即使配置了故障自动恢复，你也可以使用hdfs haadmin命令引发一次故障自动恢复。它将完成一次协调的故障恢复。

八、HA HDFS 的升级、完成、回滚（Upgrade/Finalize/Rollback）

When moving between versions of HDFS, sometimes the newer software can simply be installed and the cluster restarted. Sometimes, however, upgrading the version of HDFS you're running may require changing on-disk data. In this case, one must use the HDFS Upgrade/Finalize/Rollback facility after installing the new software. This process is made more complex in an HA environment, since the on-disk metadata that the NN relies upon is by definition distributed, both on the two HA NNs in the pair, and on the JournalNodes in the case that QJM is being used for the shared edits storage. This documentation section describes the procedure to use the HDFS Upgrade/Finalize/Rollback facility in an HA setup.

To perform an HA upgrade, the operator must do the following:

1. Shut down all of the NNs as normal, and install the newer software.

2. Start up all of the JNs. Note that it is critical that all the JNs be running when performing the upgrade, rollback, or finalization operations. If any of the JNs are down at the time of running any of these operations, the operation will fail.

3. Start one of the NNs with the '-upgrade' flag.

4. On start, this NN will not enter the standby state as usual in an HA setup. Rather, this NN will immediately enter the active state, perform an upgrade of its local storage dirs, and also perform an upgrade of the shared edit log.

5. At this point the other NN in the HA pair will be out of sync with the upgraded NN. In order to bring it back in sync and once again have a highly available setup, you should re-bootstrap this NameNode by running the NN with the '-bootstrapStandby' flag. It is an error to start this second NN with the '-upgrade' flag.

Note that if at any time you want to restart the NameNodes before finalizing or rolling back the upgrade, you should start the NNs as normal, i.e. without any special startup flag.

To finalize an HA upgrade, the operator will use the `hdfs dfsadmin -finalizeUpgrade' command while the NNs are running and one of them is active. The active NN at the time this happens will perform the finalization of the shared log, and the NN whose local storage directories contain the previous FS state will delete its local state.

To perform a rollback of an upgrade, both NNs should first be shut down. The operator should run the roll back command on the NN where they initiated the upgrade procedure, which will perform the rollback on the local dirs there, as well as on the shared log, either NFS or on the JNs. Afterward, this NN should be started and the operator should run `-bootstrapStandby' on the other NN to bring the two NNs in sync with this rolled-back file system state.