CDH HDFS High Availability（CDH启用HDFS高可用）5.11.x

电玩女神 2022-03-16 16:56 327阅读 0赞

**Table of Contents**

HDFS高可用性介绍

背景

HA实现

Quorum-based存储

自动故障转移

关于HDFS HA的一般问题

“Operation category READ/WRITE is not supported in state standby”是什么意思?

为HDFS HA配置硬件

开启HDFS HA

使用 Cloudera 管理器启用 HDFS HA

启用高可用性和自动故障转移

Fencing Methods

使用命令行启用HDFS HA

为HDFS HA配置软件

部署HDFS高可用性

--------------------

本节概述HDFS高可用性(HA)特性以及如何配置和管理HA HDFS集群。

# HDFS高可用性介绍 #

## 背景 ##

在标准配置中，NameNode 是 HDFS 集群中的单点故障(SPOF)。每个集群都有一个 NameNode，如果该主机或进程变得不可用，则整个集群都不可用，直到 NameNode 重新启动或在新主机上启动。Secondary NameNode 不提供故障转移功能。

标准配置通过两种主要方式减少 了HDFS 集群的总可用性：

*  在发生意外事件(如主机崩溃)的情况下，在操作员重新启动 NameNode 之前，集群是不可用的。
 *  计划的维护事件(如NameNode机器上的软件或硬件升级)会导致集群停机。

HDFS HA 通过提供在同一集群中以主动/被动配置运行两个 namenode 的选项来解决上述问题。这些被称为活动 NameNode 和备用 NameNode。与备用的 NameNode 不同，备用的 NameNode 是热备用的，它允许在主机崩溃的情况下快速自动转移到一个新的 NameNode，或者允许运维发起的用于计划维护的故障转移。不能拥有两个以上的 namenode。

## HA实现 ##

Cloudera Manager 5 和 cdh5 支持 Quorum-based 存储来实现 HA。

### Quorum-based存储 ###

Quorum-based Storage 是指使用 Quorum Journal Manager (QJM) 的 HA 实现。

为了使备用 NameNode 的状态与此实现中的活动 NameNode 保持同步，两个节点都与一组称为 JournalNodes 的独立守护进程通信。当活动的 NameNode 执行任何名称空间修改时，它会将修改的记录持久地记录到大多数日志节点上。备用的 NameNode 能够从 JournalNodes 读取编辑，并不断监视它们对编辑日志的更改。当备用节点看到编辑时，它将它们应用到自己的名称空间。在发生故障转移时，备用服务器将确保它正常工作。

为了提供快速的故障转移，备用 NameNode 还必须具有关于集群中数据块的位置的最新信息。为此，datanode 配置了两个 namenode 的位置，并将块位置信息和心跳发送给两个 namenode。

对于 HA 集群的正确操作来说，一次只激活一个 namenode 是非常重要的。否则，名称空间状态将很快在两者之间产生分歧，可能导致数据丢失或其他不正确的结果。为了确保这个属性并防止所谓的“分裂大脑场景”，JournalNodes 一次只允许一个 NameNode 作为写入器。在故障转移期间，将被激活的 NameNode 简单地接管了向 JournalNodes 写入的角色，这有效地阻止了其他 NameNode 继续处于活动状态，从而允许新的活动 NameNode 安全的进行故障转移。

### 自动故障转移 ###

自动故障转移依赖于 HDFS 中的两个附加组件：ZooKeeper quorum 和 ZKFailoverController 进程(缩写为ZKFC)。在 Cloudera Manager 中，ZKFC 进程映射到 HDFS 故障转移控制器角色。

Apache ZooKeeper是一种高可用性的服务，用于维护少量的协调数据、通知客户端数据的更改以及监控客户端故障。HDFS自动故障转移的实现依赖于ZooKeeper实现以下功能：

*  **故障检测 ——** 集群中的每个 NameNode 机器都在 ZooKeeper 中维护一个持久会话。如果机器崩溃，ZooKeeper 会话将到期，通知另一个 NameNode 应该触发故障转移。
 *  **活跃的NameNode选举 —— **ZooKeeper 提供了一个简单的机制来专门选择一个活动节点。如果当前活动的 NameNode 崩溃，则另一个节点可以在 ZooKeeper 中获取一个特殊的独占锁，表明它应该成为下一个活动的 NameNode。

ZKFailoverController (ZKFC)是一个 ZooKeeper 客户机，它还监视和管理 NameNode 的状态。运行 NameNode 的每个主机也运行 ZKFC。ZKFC 负责：

*  **健康监控 —— **ZKFC 定期通过健康检查命令与本机的 NameNode 联系。只要 NameNode 以健康状态迅速响应，ZKFC 就认为 NameNode 是健康的。如果 NameNode 崩溃、冻结或以其他方式进入不健康状态，则健康监视器将其标记为不健康。
 *  **Zookeeper会话管理 —— **当本机的 NameNode 是健康的，ZKFC 会在 ZooKeeper 中打开一个会话。如果本机 NameNode 是活动的，它还持有一个特殊的锁 znode。此锁使用 ZooKeeper 对“临时”节点的支持；如果会话过期，锁节点将被自动删除。
 *  **ZooKeeper-based选举 —— **如果本机的 NameNode 是健康的，并且 ZKFC 发现当前没有其他的 NameNode 持有锁 znode，它将自己尝试获取锁。如果它成功了，那么它就“赢得了选举”，并负责运行故障转移来激活本机 NameNode。故障转移过程类似于上面描述的手动故障转移：首先，前一个活动被隔离(如果需要)，然后本地 NameNode 转换为活动状态。

## 关于HDFS HA的一般问题 ##

### “Operation category READ/WRITE is not supported in state standby”是什么意思? ###

以下信息来自Apache Hadoop wiki：

在启用了 ha 的集群中，DFS 客户机不能预先知道在给定时间内哪个 NameNode 是活动的。因此，当客户端连接到 NameNode 并且它恰好是备用服务器时，读或写操作将被拒绝，并记录此消息。然后客户端将自动联系另一个 NameNode 并再次尝试操作。只要集群中有一个活动 NameNode 和一个备用 NameNode，就可以安全地忽略该消息。

如果将应用程序配置为始终只联系一个NameNode，则此消息表明应用程序未能执行任何读/写操作。在这种情况下，需要修改应用程序以使用集群的HA配置。

# 为HDFS HA配置硬件 #

要使用 Quorum-based 存储部署 HA 集群，您应该准备以下内容：

*  **NameNode 主机**——这是运行活动和备用 NameNode 的主机。它们应该具有彼此等价的硬件，以及与非 ha 集群中使用的硬件等价。
 *  **JournalNod e主机**——这些是运行 JournalNodes 的主机。Cloudera 建议在“master”主机( NameNode、备用 NameNode、JobTracke r等)上部署 JournalNode 守护进程，这样，JournalNode 的本地目录就可以在这些机器上使用可靠的本地存储。
 *  如果位于同一主机上，则每个 JournalNode 进程和每个 NameNode 进程都应该有自己的专用磁盘。不应该对这些目录使用 SAN 或 NAS 存储。
 *  必须至少有三个 JournalNode 守护进程，因为编辑日志修改必须写入到大多数 JournalNode。这将允许系统容忍单个主机的故障。您还可以运行三个以上的 JournalNodes，但是要实际增加系统能够容忍的故障数量，您应该运行奇数个 JournalNodes( 3、5、7，等等)。**注意，当使用 N 个 JournalNodes 运行时，系统最多可以容忍 (N - 1) / 2 个故障，并继续正常运行。**如果所需的 quorum 不可用，NameNode 将不会格式化或启动，您将看到类似这样的错误：

12/10/01 17:34:18 WARN namenode.FSEditLog: Unable to determine input streams from QJM to [10.0.1.10:8485, 10.0.1.10:8486, 10.0.1.10:8487]. Skipping.
    java.io.IOException: Timed out waiting 20000ms for a quorum of nodes to respond.

> 在HA集群中，备用的NameNode也执行名称空间状态的检查点，因此不需要在HA集群中运行备用的NameNode、CheckpointNode或BackupNode。事实上，这样做是错误的。如果将不支持ha的HDFS集群重新配置为支持ha，则可以重用以前专用于辅助NameNode的硬件。

# 开启HDFS HA #

HDFS 高可用性(HA)集群使用两个 NameNode —— 一个活动的 NameNode 和一个备用的 NameNode。在任何时间点，只有一个 NameNode 可以被激活。HDFS HA 依赖于在一个对两个 NameNode 都可用的位置上维护所有名称空间修改的日志，以便在发生故障时，备用 NameNode 具有关于集群中块的编辑和位置的最新信息。

> **重要：**启用和禁用HA会导致HDFS服务和所有依赖于HDFS的服务中断。在启用或禁用HA之前，请确保集群上没有运行作业。

## 使用 Cloudera 管理器启用 HDFS HA ##

您可以使用 Cloudera Manager 为 HDFS HA 和自动故障转移配置 cdh5 集群。在 Cloudera Manager 5 中，HA 是使用 Quorum-based 的存储来实现的。Quorum-based 的存储依赖于一组 JournalNodes，每个 JournalNodes 维护一个本地编辑目录，该目录记录对名称空间元数据的修改。启用 HA 使自动故障转移成为同一命令的一部分。

> 重要：
> 
>  *  启用或禁用 HA 将导致先前的监控历史记录不可用。
>  *  一旦启用了JobTracker HA，一些参数将自动设置如下。如果希望更改这些参数的默认值，请使用高级配置片段。
> 
>     mapred.jobtracker.restart.recover: true
>             mapred.job.tracker.persist.jobstatus.active: true
>             mapred.ha.automatic-failover.enabled: true
>             mapred.ha.fencing.methods: shell(true)
> 
>

## 启用高可用性和自动故障转移 ##

启用高可用性工作流引导您添加第二个(备用) NameNode 并配置 JournalNodes。

1.  执行在为HDFS HA配置硬件中描述的所有配置和设置任务。
2.  确保你有一个 ZooKeeper 服务。
3.  转到 HDFS 服务。
4.  Select Actions > Enable High Availability。显示有资格运行备用 NameNode 的主机的屏幕，并显示 JournalNodes。a.为 nameservice 指定一个名称，或者接受默认名称 nameservice1 并单击 Continue。b.在NameNode Hosts 字段中，单击 Select a host。将显示“主机选择”对话框。c.选中您希望设置备用NameNode的主机旁边的复选框，然后单击OK。备用的NameNode不能与活动的NameNode在同一主机上，所选的主机应该与活动的NameNode具有相同的硬件配置(RAM、磁盘空间、内核数量等)。d.在J ournalNode Hosts 字段中，单击 Select Hosts。将显示“主机选择”对话框。e.选中奇数台主机(至少3台)旁边的复选框，作为 JournalNodes 并单击 OK。JournalNodes 应该驻留在具有与 namenode 类似的硬件规范的主机上。Cloudera 建议将一个 JournalNode 分别放在与活动和备用 namenode 相同的主机上，而将第三个 JournalNode 放在类似的硬件上，比如 JobTracker。f.单击 Continue。g.在 JournalNode 编辑目录属性中，为每个 JournalNode 主机的字段输入 JournalNode 编辑目录的目录位置。对于每个 JournalNode 只能输入一个目录。在每个 JournalNode 上，路径不必相同。指定的目录应该是空的。目录所有者应该是hdfs:hadoop，并且必须具有读、写和执行权限(drwx——)。h.额外选项：决定 Cloudera manager 是否应该清除 ZooKeeper、standby NameNode 和 JournalNodes 中的现有数据。如果目录不是空的(例如，您正在重新启用以前的 HA 配置)，Cloudera manager 将不会自动删除内容—您可以通过保留默认的复选框选择来选择删除内容。推荐的默认设置是清除目录。如果您选择不这样做，那么数据应该在 JournalNodes 的编辑目录中保持同步，并且应该具有与 NameNodes 相同的版本数据。i.单击 Continue。  
    Cloudera Manager 执行一组命令，这些命令停止依赖的服务，根据需要删除、创建和配置角色和目录，创建名称服务和故障转移控制器，重新启动依赖的服务，并部署新的客户端配置。**注意：**如果操作已经完成，则格式化NameNode等一些步骤可能会报告失败。但是，在报告了非关键的失败步骤之后，配置步骤将继续执行。
5.  如果希望在集群中使用配置了 HA 的其他服务，请遵循配置其他 CDH 组件以使用 HDFS HA 的过程。

> 注意：如果在启用自动故障转移时更改 NameNode 服务 RPC 端口(dfss . NameNode .servicerpc-address)，将导致ZooKeeper /hadoop-ha znode 中保存的 NameNode 地址与故障转移控制器配置的 NameNode 地址不匹配。这将防止故障转移控制器重新启动。如果在启用自动故障转移后需要更改 NameNode 服务 RPC 端口，则必须执行以下操作来重新初始化 znode：
> 
> 1.  停止HDFS服务。
> 2.  配置服务RPC端口：a.转到HDFS服务。b.单击Configuration选项卡。c.选择 Scope > NameNode。d.选择 Category > Ports and Addresses。e.找到NameNode服务RPC端口属性，或者通过在搜索框中键入它的名称来搜索它。f.根据需要更改端口值。如果有多个角色组应用于此配置，请编辑相应角色组的值。
> 3.  在Z ooKeeper 服务器主机上运行 ZooKeeper -client。执行以下步骤以删除已配置的名称服务。本例假设 nameservice 的名称是 nameservice1。你可以在 HDFS 实例标签页的 **Federation and High Availability **部分找到nameservice ：
>     
>         rmr /hadoop-ha/nameservice1
> 4.  单击Instances选项卡。
> 5.  选择 Actions > Initialize High Availability State in ZooKeeper。
> 6.  启动HDFS服务。

### Fencing Methods ###

为了确保一次只有一个 NameNode 是活动的，共享编辑目录需要一个隔离方法。在故障转移期间，隔离方法负责确保以前的活动 NameNode 不再具有对共享编辑目录的访问权限，以便新的活动 NameNode 能够安全地继续对其进行写入。

默认情况下，Cloudera Manager将HDFS配置为使用 a shell fencing method (shell(true))。

fencing 参数可以在 Service-Wide > High Availability 类别下的HDFS服务配置属性中找到。

## 使用命令行启用HDFS HA ##

> **重要：**在不使用 Cloudera 管理器的系统上遵循这些命令行说明。此信息特别适用于CDH 5.11.x。

本节描述 cdh5 中 HDFS HA 所需的软件配置，并解释如何设置配置属性和使用命令行部署 HDFS HA。

### 为HDFS HA配置软件 ###

**配置概述**

HA 配置是向后兼容的，允许现有的单个 NameNode 配置无需更改即可工作。新配置的设计使集群中的所有节点都可以拥有相同的配置，而不需要根据节点的类型将不同的配置文件部署到不同的机器上。

HA 集群重用 Nameservice ID 来标识一个可能包含多个 HA namenode 的 HDFS 实例。此外，还有一个名为 NameNode ID 的新抽象。集群中每个不同的 NameNode 都有一个不同的 NameNode ID。为了支持所有 NameNode 的单个配置文件，相关的配置参数包括 Nameservice ID 和 NameNode ID。

**更改现有的配置参数**

YARN 实现更改了以下配置参数：

fs.defaultFS - 原名 fs.default.name，当没有指定时，Hadoop FS 客户端使用的默认路径前缀。fs.default.name 不支持 YARN，但是仍会工作。

还可以为 Hadoop 客户机配置默认路径，以使用启用 ha 的逻辑 URI。例如，如果使用 mycluster 作为如下所示的 Nameservice  ID，这将是所有 HDFS 路径的权限部分的值。您可以在您的 core-site.xml 文件中配置默认路径：

For YARN:

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

For MRv1:

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

**新的配置参数**

要配置 HA namenode，必须将几个配置选项添加到 hdfs-site.xml 配置文件中。

您设置这些配置的顺序并不重要，但是您为 dfs. namespace 服务和 dfs.ha.namenodes.\[Nameservice ID\] 选择的值将决定后面那些配置的键。这意味着您应该在设置其他配置选项之前确定这些值。

**dfs.nameservices**

dfs.nameservices - 此新名称服务的逻辑名称

为这个 nameservice 选择一个逻辑名，例如mycluster，然后使用这个逻辑名作为这个配置选项的值。您选择的名称是任意的。它将用于配置和作为集群中绝对 HDFS 路径的权威组件。

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

**dfs.ha.namenodes.\[nameservice ID\]**

dfs.ha.namenodes.\[nameservice ID\] - nameservice 中每个 NameNode 的惟一标识符

配置逗号分隔的 NameNode id 列表。datanode 将使用它来确定集群中的所有 namenode。例如，如果您以前使用 mycluster 作为 NameService ID，并且希望使用 nn1 和 nn2 作为 namenode 的单独 ID，您可以这样配置：

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

**注意：**在这个版本中，每个名称服务最多可以配置两个 namenode。

**dfs.namenode.rpc-address.\[nameservice ID\]**

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

对于前面配置的两个 NameNode id，设置 NameNode 进程的完整地址和 RPC 端口。注意，这会导致两个单独的配置选项。例如：

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

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 Kerberos 安全特性，并且打算使用 HSFTP，那么还应该为每个 NameNode 设置类似的 https-address。

**dfs.namenode.shared.edits.dir**

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

配置提供共享编辑存储的 JournalNodes 的地址，这些地址由活动 NameNode 写入，由备用 NameNode 读取，以便与活动 NameNode 所做的所有文件系统更改保持最新。虽然必须指定几个 JournalNode 地址，但是应该只配置其中一个 uri。URI 的格式应该是：

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

Journal ID 是此名称服务的唯一标识符，它允许一组日志节点为多个联合名称系统提供存储。虽然这不是必需的，但是最好重用 Nameservice ID 作为日志标识符。

例如，如果这个集群的 JournalNodes 运行在机器 node1.example.com、node2.example.com和node3.example.com 上，而 nameservice 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.journalnode.edits.dir**

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

在每台 JournalNode 机器上，配置存储 JournalNode 使用的编辑和其他本地状态信息的绝对路径；每个 JournalNode 只使用一条路径。(其他的日志节点提供冗余；您还可以在本地附加的RAID-1或RAID-10数组上配置此目录。)

例如：

<property>
      <name>dfs.journalnode.edits.dir</name>
      <value>/data/1/dfs/jn</value>
    </property>

现在创建目录(如果它还不存在)，并确保其所有者是 hdfs，例如：

$ sudo mkdir -p /data/1/dfs/jn
    $ sudo chown -R hdfs:hdfs /data/1/dfs/jn

**客户端故障转移配置**

dfs.client.failover.proxy.provider.\[nameservice ID\] - HDFS客 户端用来联系活动 NameNode 的 Java 类

配置 Java 类的名称，DFS 客户机将使用它来确定哪个 NameNode 是当前活动的，因此哪个 NameNode 当前正在为客户机请求提供服务。目前与 Hadoop 一起提供的唯一实现是 ConfiguredFailoverProxyProvider，所以除非您使用自定义的，否则就使用它。例如：

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

**Fencing 配置**

dfs.ha.fencing.methods - 将用于在故障转移期间保护活动 NameNode 的脚本或 Java 类的列表

为了保证系统的正确性，在任何给定的时间只有一个 NameNode 处于活动状态。

当您使用 Quorum-based 的存储时，只允许一个 NameNode 写入到 JournalNodes，因此在“分裂大脑”场景中不会破坏文件系统元数据。这映射 dfs.ha.fencing.methods 的默认值 true，它不会显式地尝试保护备用 NameNode。

在没有明确的隔离的情况下，有一个很窄的时间窗口，以前活动的 NameNode 可能为来自客户机的读操作提供过时的响应。当先前活动的 NameNode 试图写入到 JournalNodes 时，此窗口将结束，此时 NameNode 将关闭。

对于应用程序来说，这种陈旧的读响应窗口很少成为问题，因为不存在分裂大脑损坏的危险。在需要强读一致性的罕见或特殊情况下，使用显式击剑方法，如 agent-based fencer。

> **注意：**如果您选择使用 agent-based fencing 方法，您仍然应该配置shell(true)作为备用击剑选项，因为如果另一个 NameNode 没有响应，那么 agent-based fencing 将失败。

故障转移期间使用的 fencing 方法被配置为一个以载物-返回-分隔的列表，这些方法将按顺序尝试，直到其中一个方法指示 fencing 成功为止。

有关实现自定义 fencing 方法的信息，请参阅 org.apache.hadoop.ha.NodeFencer 类。  
**the shell fencing method**

shell - 运行任意 shell 命令来保护活动的 NameNode

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

'('和')之间的字符串直接传递给 bash shell，不能包含任何右括号。

在执行时，配置脚本的第一个参数将是要保护的 NameNode 的地址，然后是配置中指定的所有参数。

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

下列变量引用的目标节点被隔离也可用：

<table> 
 <thead> 
  <tr> 
   <th>Variable</th> 
   <th>Description</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;">$target_host</td> 
   <td style="vertical-align:top;">Hostname of the node to be fenced</td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;">$target_port</td> 
   <td style="vertical-align:top;">IPC port of the node to be fenced</td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;">$target_address</td> 
   <td style="vertical-align:top;">The above two variables, combined as host:port</td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;">$target_nameserviceid</td> 
   <td style="vertical-align:top;">The nameservice ID of the NameNode to be fenced</td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;">$target_namenodeid</td> 
   <td style="vertical-align:top;">The NameNode ID of the NameNode to be fenced</td> 
  </tr> 
 </tbody> 
</table>

您还可以在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，则判断 fencing 成功。如果返回任何其他退出码，则说明 fencing 不成功，将尝试列表中的下一个 fencing 方法。

> **注意：**此隔离方法不实现任何超时。如果需要超时，则应该在 shell 脚本中实现超时(例如，通过分叉子 shell 在几秒钟内杀死其父 shell)。

**自动故障转移配置**

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

**部署ZooKeeper**

在典型的部署中，ZooKeeper 守护进程被配置为在三个或五个节点上运行。由于 ZooKeeper 本身需要较少的资源，所以可以将 ZooKeeper 节点配置在与 HDFS NameNode 和备用节点相同的硬件上。使用 MapReduce v2 (MRv2)的操作员通常选择将第三个 ZooKeeper 进程部署在与 YARN 资源管理器相同的节点上。建议将 ZooKeeper 节点配置为将数据从 HDFS 元数据存储到单独的磁盘驱动器上，以获得最佳性能和隔离性。

在下面的部分中，我们假设您已经设置了一个运行在三个或更多节点上的ZooKeeper集群，并通过使用ZooKeeper命令行接口(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服务的主机端口对。

与本文档前面描述的参数一样，可以在每个 nameservice 的基础上配置这些设置，方法是用 nameservice ID 作为配置键的后缀。例如，在启用了联合的集群中，您可以通过设置 dfs.ha.automatic-failover.enabled.my-nameservice-id 来显式地为其中一个 nameservices 启用自动故障转移。

您可以设置其他几个配置参数来控制自动故障转移的行为，但是对于大多数安装来说，这些参数不是必需的。

**在ZooKeeper中初始化HA状态**

添加配置键之后，下一步是在ZooKeeper中初始化所需的状态。可以通过在NameNode主机上运行以下命令来实现这一点。

> 使用此命令时，ZooKeeper 集合必须正在运行;否则它将不能正常工作。

$ hdfs zkfc -formatZK

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

**确保与 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>

注意这些值中的“@”字符—这指定配置不是内联的，而是指向磁盘上的文件。

第一个配置文件指定了 ZooKeeper 身份验证的列表，格式与 ZooKeeper CLI 使用的格式相同。例如，可以指定如下内容： digest:hdfs-zkfcs:mypassword，其中 hdfs-zkfcs 是 ZooKeeper 的惟一用户名，而 mypassword 是用作密码的惟一字符串。

接下来，使用以下命令生成与此身份验证对应的 ZooKeeper 访问控制列表(ACL)：

$ 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:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=:rwcda

要使这些 acl 生效，请如上所述重新运行 zkfc -formatZK 命令。

这样做之后，你可以验证来自 ZooKeeper CLI 的 acl 如下：

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

**自动故障转移常见问题解答**

*  我以特定的顺序启动 ZKFC 和 NameNode 守护进程重要吗?

不。在任何给定的节点上，您都可以在其相应的 NameNode 之前或之后启动 ZKFC。

*  我应该进行哪些额外的监视?

您应该在运行 NameNode 的每个主机上添加监控，以确保 ZKFC 保持运行。例如，在某些类型的 ZooKeeper 故障中，ZKFC 可能会意外退出，应该重新启动以确保系统准备好进行自动故障转移。另外，您应该监视 ZooKeeper 集群中的每个服务器。如果 ZooKeeper 崩溃，自动故障转移将不起作用。

*  如果 Zookeeper 宕了怎么办?

如果 ZooKeeper 集群崩溃，则不会触发自动故障转移。但是，HDFS 将继续运行，不会受到任何影响。当 ZooKeeper 重新启动时，HDFS 将重新连接，没有问题。

*  我可以指定一个 NameNode 作为首选吗？

不。目前，这是不支持的。首先启动的 NameNode 将成为活动的。您可以选择以特定的顺序启动集群，以便首选节点首先启动。

*  在配置自动故障转移时，如何启动手动故障转移?

即使配置了自动故障转移，也可以启动手动故障转移。它将执行协调的故障转移。

### 部署HDFS高可用性 ###

设置完所有必要的配置选项后，就可以启动 JournalNodes 和两个 HA namenode了 。

> **重要：**启动之前：确保您已经执行了为 HDFS HA 配置硬件和为 HDFS HA 配置软件中描述的所有配置和设置任务，包括在部署自动故障转移时在 ZooKeeper 中初始化 HA 状态。

**安装并启动JournalNodes**

1、在它们将要运行的每台机器上安装 JournalNode 守护进程。

**To install JournalNode on Red Hat-compatible systems:**

$ sudo yum install hadoop-hdfs-journalnode

**To install JournalNode on Ubuntu and Debian systems:**

$ sudo apt-get install hadoop-hdfs-journalnode

**To install JournalNode on SLES systems:**

$ sudo zypper install hadoop-hdfs-journalnode

2、在将要运行它们的每台机器上启动 JournalNode 守护进程：

sudo service hadoop-hdfs-journalnode start

在格式化主 NameNode (在新的集群中)和启动 NameNode (在所有情况下)之前，等待守护进程启动。

**格式化NameNode(如果是新的集群)**

如果要设置一个新的 HDFS 集群，请格式化将用作主 NameNode 的 NameNode

> **重要：**确保已经启动了 JournalNodes。如果您将 NameNode 配置为与 JournalNodes 通信，但尚未启动 JournalNodes，则格式化将失败。

**初始化共享编辑目录(如果转换现有的非ha集群)**

如果要将非 HA NameNode 转换为 HA，请使用本地 NameNode 编辑目录中的编辑数据初始化共享编辑目录：

hdfs namenode -initializeSharedEdits

**启动 namenode**

1、启动主(格式化)NameNode：

$ sudo service hadoop-hdfs-namenode start

2、启动备用NameNode：

$ sudo -u hdfs hdfs namenode -bootstrapStandby
    $ sudo service hadoop-hdfs-namenode start

> **注意：**如果启用了 Kerberos，不要使用 sudo -u <user> <command>；它们将由于安全错误而失败。相反，使用以下命令：$ kinit <user> （使用密码）或 $ kinit -kt <keytab> <principal> （使用keytab）然后，对于该用户执行的每个命令，$ <command>。

使用 -bootstrapStandby 选项启动备用 NameNode，将主 NameNode 的元数据目录(包括 namespace 信息和最近的检查点)的内容复制到备用 NameNode。(包含 NameNode 元数据的目录的位置是使用配置选项 dfs.namenode.name.dir 和 dfs. NameNode .edit .dir 来配置的。)

您可以通过浏览其配置的 HTTP 地址来访问每个 NameNode 的 web 页面。注意，在配置的地址旁边是 NameNode 的 HA 状态(“备用”或“活动”)。无论何时 HA NameNode 启动，且未启用自动故障转移，它最初都处于备用状态。如果启用了自动故障转移，则启动的第一个 NameNode 将成为活动的。

**重新启动服务(如果正在转换现有的非ha集群)**

如果您从非 HA 配置转换为 HA 配置，则需要重新启动 JobTracker 和 TaskTracker (对于 MRv1，如果使用)，或 ResourceManager、NodeManager 和 JobHistory Server (对于 YARN)，以及 DataNode：

每个 DataNode 上:

$ sudo service hadoop-hdfs-datanode start

在每个 TaskTracker 系统上(MRv1):

$ sudo service hadoop-0.20-mapreduce-tasktracker start

在每个 TaskTracker 系统上(MRv1):

$ sudo service hadoop-0.20-mapreduce-jobtracker start

确认 JobTracker 和 TaskTracker 启动正常:

sudo jps | grep Tracker

关于 ResourceManager 系统(YARN):

$ sudo service hadoop-yarn-resourcemanager start

在每个 NodeManager 系统上(YARN;通常与 DataNode 服务运行的地方相同):

$ sudo service hadoop-yarn-nodemanager start

关于 MapReduce JobHistory 服务器系统(YARN):

$ sudo service hadoop-mapreduce-historyserver start

**部署自动故障转移(如果已配置)**

如果您已经使用 ZooKeeper 故障转移控制器( ZKFC )配置了自动故障转移，则必须在运行 NameNode 的每台机器上安装并启动 ZKFC 守护进程。进行如下。

**To install ZKFC on Red Hat-compatible systems:**

$ sudo yum install hadoop-hdfs-zkfc

**To install ZKFC on Ubuntu and Debian systems:**

$ sudo apt-get install hadoop-hdfs-zkfc

**To install ZKFC on SLES systems:**

$ sudo zypper install hadoop-hdfs-zkfc

**To start the zkfc daemon:**

$ sudo service hadoop-hdfs-zkfc start

以特定的顺序启动 ZKFC 和 NameNode 守护进程并不重要。在任何给定的节点上，您都可以在其相应的 NameNode 之前或之后启动 ZKFC。

您应该在运行 NameNode 的每个主机上添加监控，以确保 ZKFC 保持运行。例如，在某些类型的 ZooKeeper 故障中，ZKFC 可能会意外退出，应该重新启动以确保系统准备好进行自动故障转移。

另外，您应该监视  ZooKeeper 集群中的每个服务器。如果 ZooKeeper 崩溃，那么自动故障转移将不起作用。如果 ZooKeeper 集群崩溃，则不会触发自动故障转移。但是，HDFS 将继续运行，不会受到任何影响。当 ZooKeeper 重新启动时，HDFS 将重新连接，没有问题。

**验证自动故障转移**

在启用了自动故障转移的集群的初始部署之后，您应该测试它的操作。为此，首先找到活动的 NameNode。如前所述，您可以通过访问 NameNode web 接口来判断哪个节点是活动的。

一旦定位了活动的 NameNode，就可能导致该节点出现故障。例如，您可以使用 kill -9 <pid of NN> 来模拟 JVM 崩溃。或者您可以对计算机或其网络接口进行电源循环，以模拟不同类型的停机。在触发要测试的停机之后，另一个 NameNode 应该在几秒钟内自动激活。检测故障和触发故障转移所需的时间取决于 ha.zookeeper.session-timeout 的配置。，但默认为5秒。

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