使用Quorum Journal Manager的HDFS高可用

作者: 嘟嘟碰碰叮叮当当 | 来源:发表于2020-04-02 20:40 被阅读0次

官网翻译而已。

目的

本指南概述了HDFS高可用性（HA）功能以及如何使用Quorum Journal Manager（QJM）功能配置和管理HA HDFS群集。

本文档假定读者对HDFS群集中的常规组件和节点类型有一般的了解。有关详细信息，请参阅HDFS体系结构指南。

注意：使用Quorum Journal Manager或常规共享存储

本指南讨论如何使用Quorum Journal Manager（QJM）配置和使用HDFS HA，以在活动和备用NameNode之间共享编辑日志。

有关如何使用NFS而非QJM将NFS用于共享存储来配置HDFS HA的信息，请参阅此替代指南。

背景

在Hadoop 2.0.0之前，NameNode是HDFS集群中的单点故障（SPOF）。每个群集只有一个NameNode，如果该计算机或进程不可用，则整个群集将不可用，直到NameNode重新启动或在单独的计算机上启动。
这从两个方面影响了HDFS群集的总可用性：

在意外事件（例如机器崩溃）的情况下，除非操作员重新启动NameNode，否则群集将不可用。
计划的维护事件，例如NameNode计算机上的软件或硬件升级，将导致群集停机时间的延长。

HDFS高可用性功能通过提供在具有热备用的主动/被动配置中在同一群集中运行两个冗余NameNode的选项来解决上述问题。

这样可以在机器崩溃的情况下快速故障转移到新的NameNode，或者出于计划维护的目的由管理员发起的正常故障转移。

结构

在典型的HA群集中，将两个单独的计算机配置为NameNode。在任何时间点，一个NameNode都恰好处于活动状态，而另一个则处于Standby状态。 Active NameNode负责集群中的所有客户端操作，而Standby则仅充当从属，并保持足够的状态以在必要时提供快速故障转移。

为了使备用节点保持其状态与活动节点同步，两个节点都与一组称为“ JournalNodes”（JN）。当活动节点执行任何名称空间修改时，它会持久地将修改记录记录到这些JN的大多数中。 Standby节点能够从JN中读取编辑内容，并不断监视它们是否有编辑日志的更改。当“备用节点”看到编辑内容时，会将其应用到自己的名称空间。发生故障转移时，备用服务器将确保在将自身升级为活动状态之前，已从JounalNodes读取所有编辑内容。这样可以确保在发生故障转移之前，名称空间状态已完全同步。

为了提供快速的故障转移，备用节点还必须具有有关集群中块位置的最新信息。为了实现这一点，DataNodes被配置了两个NameNodes的位置，并向两者发送块位置信息和心跳信号。

对于HA群集的正确操作至关重要，一次只能有一个NameNode处于活动状态。否则，名称空间状态将在两者之间迅速分散，从而有数据丢失或其他不正确结果的风险。为了确保此属性并防止所谓的“裂脑情况”，JournalNode将仅一次允许单个NameNode成为作者。在故障转移期间，将变为活动状态的NameNode将仅承担写入JournalNodes的角色，这将有效地防止其他NameNode继续处于活动状态，从而使新的Active可以安全地进行故障转移。

硬件资源

为了部署高可用性群集，您应该准备以下内容：
NameNode机器-运行主节点和备用名称节点的计算机应具有彼此等效的硬件，并且应具有与非HA群集中使用的硬件相同的硬件。

JournalNode机器-运行JournalNodes的计算机。 JournalNode守护程序相对较轻，因此可以合理地将这些守护程序与其他Hadoop守护程序（例如NameNode，JobTracker或YARN ResourceManager）并置在计算机上。注意：必须至少有3个JournalNode守护程序，因为必须将编辑日志修改写入大多数JN中。这将允许系统容忍单个计算机的故障。您可能还会运行3个以上的JournalNode，但是为了实际增加系统可以容忍的故障数量，您应该运行奇数个JN（即3、5、7等）。请注意，当与N个JournalNode一起运行时，系统最多可以容忍（N-1）/ 2个故障，并继续正常运行。

请注意，在HA群集中，备用NameNode也执行名称空间状态的检查点，因此不必在HA群集中运行Secondary NameNode，CheckpointNode或BackupNode。实际上，这样做将是一个错误。这还允许正在重新配置未启用HA的HDFS群集的用户启用HA，以重用他们先前专用于Secondary NameNode的硬件。

部署方式

配置概述

与联合身份验证配置类似，高可用性配置向后兼容，并允许现有的单个NameNode配置无需更改即可工作。设计新配置后，群集中的所有节点都可以具有相同的配置，而无需根据节点的类型将不同的配置文件部署到不同的机器上。
像HDFS联合身份验证一样，HA群集重用名称服务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 Federation，则此配置设置还应包括其他名称服务（HA或其他）的列表，以逗号分隔的列表。

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

dfs.ha.namenodes.[nameservice ID] -名称服务中每个NameNode的唯一标识符

使用逗号分隔的NameNode ID列表进行配置。 DataNode将使用它来确定集群中的所有NameNode。例如，如果您以前使用“ mycluster”作为名称服务ID，并且想要使用“ nn1”和“ nn2”作为NameNode的各个ID，则可以这样配置：

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

注意：当前，每个名称服务最多只能配置两个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>

注意：如果需要，可以类似地配置“ 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: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- URI，它标识NameNode将在其中写入/读取编辑内容的JN组

在这里，可以配置提供共享编辑存储的JournalNode的地址，该地址由Active nameNode写入并由Standby NameNode读取，以与Active NameNode所做的所有文件系统更改保持最新。尽管您必须指定多个JournalNode地址，但是您仅应配置这些URI之一。 URI的格式应为："qjournal://host1:port1;host2:port2;host3:port3/journalId"。日记ID是此名称服务的唯一标识符，它允许单个JournalNode集为多个联合名称系统提供存储。尽管不是必需的，但最好将名称服务ID用作日记标识符。

例如，如果此群集的JournalNode在计算机"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类
配置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处于Active状态。重要的是，使用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选项SSH到目标节点，并使用熔凝器杀死监听该服务的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>

'（'和'）'之间的字符串直接传递给bash shell，并且不得包含任何右括号。

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

此外，还提供以下变量，这些变量引用要隔离的目标节点：
[图片上传失败...(image-4b62b8-1585831234393)]

这些环境变量也可以在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脚本本身中实现超时（例如，通过分叉subshell在几秒钟内杀死其父级）。

**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守护程序将存储其本地状态的路径

这是JournalNode机器上将存储JN使用的编辑和其他本地状态的绝对路径。您只能为此配置使用一条路径。通过运行多个单独的JournalNode或在本地连接的RAID阵列上配置此目录，可以提供此数据的冗余。例如：

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

部署细节

设置完所有必需的配置选项后，必须在将要运行它们的机器集上启动JournalNode守护程序。这可以通过运行命令“ hadoop-daemon.sh start journalnode”并等待守护程序在每台相关计算机上启动来完成。

一旦启动JournalNode，便必须首先同步两个HA NameNode的磁盘元数据。

如果要设置新的HDFS群集，则应首先在其中一个NameNode上运行format命令（hdfs namenode -format）。
如果您已经格式化了NameNode，或者正在将未启用HA的群集转换为启用HA，则现在未格式化的NameNode上应该通过运行命令 "hdfs namenode -bootstrapStandby" -将NameNode元数据目录的内容复制到其他未格式化的NameNode。运行此命令还将确保JournalNode（由dfs.namenode.shared.edits.dir配置）包含足够的编辑事务以能够启动两个NameNode。
如果要将非HA NameNode转换为HA，则应运行命令“ hdfs -initializeSharedEdits”，该命令将使用本地NameNode edits目录中的edits数据初始化JournalNode。

此时，您可以像平常启动NameNode一样启动两个HA NameNode。

您可以通过浏览到它们的已配置HTTP地址来分别访问每个NameNode的网页。您应该注意，配置的地址旁边将是NameNode的HA状态（“待机”或“活动”）。每当HA NameNode启动时，它最初都处于Standby状态。

行政命令

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

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

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

transitionToActive和transitionToStandby-将给定NameNode的状态转换为Active或Standby
这些子命令使给定的NameNode分别转换为Active或Standby状态。这些命令不会尝试执行任何防护，因此应很少使用。相反，几乎应该总是喜欢使用hdfs haadmin -failover子命令。

failover -启动两个NameNode之间的故障转移

此子命令导致从第一个提供的NameNode到第二个的NameNode故障转移。如果第一个NameNode处于Standby状态，则此命令仅将第二个NameNode转换为Active状态而不会出现错误。如果第一个NameNode处于活动状态，则将尝试将其优雅地转换为Standby状态。如果失败，将按顺序尝试防护方法（由dfs.ha.fencing.methods配置），直到成功为止。仅在此过程之后，第二个NameNode才会转换为Active状态。如果没有成功的防护方法，则第二个NameNode将不会转换为Active状态，并且将返回错误。

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

连接到提供的NameNode以确定其当前状态，并在STDOUT上适当地打印“待机”或“活动”。 cron作业或监视脚本可能会使用此子命令，这些脚本或监视脚本需要根据NameNode当前处于活动状态还是待机状态而表现不同。

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

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

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

自动故障转移

介绍

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

组件

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

Apache ZooKeeper是一项高可用性服务，用于维护少量协调数据，将数据中的更改通知客户端并监视客户端的故障。 HDFS自动故障转移的实现依赖ZooKeeper进行以下操作：

故障检测Failure detection-群集中的每个NameNode计算机都在ZooKeeper中维护一个持久会话。如果计算机崩溃，则ZooKeeper会话将终止，通知另一个NameNode应触发故障转移。

Active NameNode election - ZooKeeper提供了一种简单的机制来专门选择一个节点为活动节点。如果当前活动的NameNode崩溃，则另一个节点可能会在ZooKeeper中采取特殊的排他锁，指示它应成为下一个活动的NameNode。

ZKFailoverController（ZKFC）是一个新组件，它是一个ZooKeeper客户端，还可以监视和管理NameNode的状态。运行NameNode的每台机器还运行ZKFC，该ZKFC负责：

运行状况监视Health monitoring-ZKFC使用运行状况检查命令定期ping通其本地NameNode。只要NameNode以健康状态及时响应，ZKFC就会认为该节点健康。如果该节点已崩溃，冻结或以其他方式进入不正常状态，则运行状况监视器将其标记为不正常。

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

基于ZooKeeper的选举ZooKeeper-based election-如果本地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进行连接来验证其正确的操作。

Before you begin

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

Configuring automatic failover

自动故障转移的配置需要在配置中添加两个新参数。在您的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 zkfc -formatZK

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

Starting the cluster with start-dfs.sh

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

手动启动集群

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

$ hadoop-daemon.sh 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>

请注意这些值中的'@'字符-这表明配置不是内联的，而是指向磁盘上的文件。
第一个配置的文件指定ZooKeeper身份验证列表，格式与ZK CLI使用的格式相同。例如，您可以指定以下内容：

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

接下来，使用类似于以下的命令生成与此身份验证相对应的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：”。例如：

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 <NN的pid>模拟JVM崩溃。或者，您可以重新启动计算机电源或拔出其网络接口以模拟另一种故障。触发您要测试的中断后，另一个NameNode应在几秒钟内自动变为活动状态。检测故障并触发故障转移所需的时间取决于ha.zookeeper.session-timeout.ms的配置，但默认值为5秒。

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

自动故障转移常见问题

以任何特定顺序启动ZKFC和NameNode守护程序是否重要？

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

我应该进行哪些其他监视？

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

此外，您应该监视ZooKeeper仲裁中的每个服务器。如果ZooKeeper崩溃，则自动故障转移将不起作用。

如果ZooKeeper崩溃了怎么办？

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

我可以将我的NameNode之一指定为主/首选吗？

否。目前不支持此功能。无论哪个NameNode首先启动，都将变为活动状态。您可以选择以特定顺序启动群集，以便您的首选节点首先启动。

配置自动故障转移后，如何启动手动故障转移？

即使配置了自动故障转移，也可以使用相同的hdfs haadmin命令启动手动故障转移。它将执行协调的故障转移。

启用HA的HDFS升级/最终确定/回滚

在不同版本的HDFS之间移动时，有时可以简单地安装较新的软件并重新启动群集。但是，有时，升级正在运行的HDFS版本可能需要更改磁盘上的数据。在这种情况下，安装新软件后必须使用HDFS升级/最终化/回滚功能。在HA环境中，此过程变得更加复杂，因为根据定义，NN所依赖的磁盘元数据既分布在该对中的两个HA NN上，又在使用QJM的情况下分布在JournalNode上共享编辑存储。本文档部分介绍在HA设置中使用HDFS升级/最终化/回滚功能的过程。

要执行HA升级，操作员必须执行以下操作：

正常关闭所有NN，然后安装更新的软件。
启动所有JN。请注意，执行升级，回滚或完成操作时，所有JN都必须运行是至关重要的。如果在运行任何这些操作时任何JN都已关闭，则该操作将失败。
用“ -upgrade”标志启动其中一个NN。
启动时，此NN将不会像通常在HA设置中那样进入待机状态。相反，此NN将立即进入活动状态，对其本地存储目录进行升级，还对共享编辑日志进行升级。
此时，HA对中的另一个NN将与升级的NN不同步。为了使其同步并再次具有高可用性设置，您应该通过使用'-bootstrapStandby'标志运行NN重新引导此NameNode。用“ -upgrade”标志启动第二个NN是错误的。
请注意，如果您要在完成或回滚升级之前随时重新启动NameNode，则应正常启动NN，即没有任何特殊的启动标志。

为了完成HA升级，操作员将在NN正在运行且其中一个处于活动状态时使用“ hdfs dfsadmin -finalizeUpgrade”命令。此时发生的活动NN将完成共享日志的终结，其本地存储目录包含先前FS状态的NN将删除其本地状态。

要执行升级的回滚，应先关闭两个NN。操作员应在启动升级过程的NN上运行rollback命令，这将在该本地目录以及共享日志（NFS或JN）上执行回滚。之后，应启动此NN，操作员应在另一个NN上运行“ -bootstrapStandby”，以使两个NN与此回滚文件系统状态同步。