cdh|cdh-启用hdfs ha manager|cloudera

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

重要提示：启用和禁用HA会导致HDFS服务和依赖于HDFS的所有服务中断服务。在启用或禁用HA之前，请确保集群上没有运行作业。```####使用Cloudera Manager启用HDFS HA 最低要求的角色：群集管理员（也由完全管理员提供）您可以使用Cloudera Manager为CDH 5群集配置HDFS HA并自动进行故障转移。在Cloudera Manager 5中，HA使用基于Quorum的存储实施。基于法定存储的存储依赖于一组JournalNodes，每个JournalNode都维护一个本地编辑目录，将修改记录到名称空间元数据中。启用高可用性启用自动故障转移作为同一命令的一部分。

重要提示：
- 启用或禁用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.选择操作> High Availability。显示有资格运行备用NameNode和JournalNodes的主机的屏幕。 a.为nameservice指定一个名称或接受默认名称nameservice1，然后单击Continue。 b.在NameNode主机字段中，单击选择主机。显示主机选择对话框。 c.选中要设置备用NameNode的主机旁边的复选框，然后单击OK。备用NameNode不能与活动NameNode位于同一主机上，并且所选主机应具有与活动NameNode相同的硬件配置（RAM，磁盘空间，内核数量等）。 d.在JournalNode主机字段中，单击选择主机。显示主机选择对话框。 e.选中奇数个主机旁边的复选框（至少三个）作为JournalNodes，然后单击确定。 JournalNodes应托管在与NameNodes具有相似硬件规格的主机上。 Cloudera建议您将JournalNode分别放置在与主动和备用NameNode相同的主机上，以及类似硬件上的第三个JournalNode，例如JobTracker。 f.点击继续。 g.在JournalNode编辑目录属性中，将JournalNode编辑目录的目录位置输入到每个JournalNode主机的字段中。 - 每个JournalNode只能输入一个目录。每个JournalNode上的路径不需要相同。 - 您指定的目录应该是空的。 - 目录所有者应该是hdfs：hadoop，并且必须具有读，写和执行权限（drwx ------）。 h.额外选项：决定Cloudera Manager是否应清除ZooKeeper，备用NameNode和JournalNodes中的现有数据。如果目录不为空（例如，您重新启用先前的HA配置），则Cloudera Manager不会自动删除内容 - 您可以通过保留默认复选框选择来选择删除内容。建议的默认值是清除目录。如果您选择不这样做，数据应该在JournalNodes的编辑目录中同步，并且应该具有与NameNodes相同的版本数据。 i.点击继续。 Cloudera Manager执行一组命令来停止相关服务，根据需要删除，创建和配置角色和目录，创建名称服务和故障转移控制器，重新启动相关服务以及部署新的客户端配置。

重要：如果操作已完成，某些步骤（如格式化NameNode）可能会报告失败。但是，配置步骤在报告非严重失败步骤后继续执行。

如果要在配置了HA的群集中使用其他服务，请按照配置其他CDH组件中的步骤使用HDFS HA。

重要提示：如果在启用自动故障转移的情况下更改NameNode Service RPC端口（dfs.namenode.servicerpc-address），则会导致保存在ZooKeeper / hadoop-ha znode中的NameNode地址与故障转移的NameNode地址不匹配控制器配置有。这将阻止故障切换控制器重新启动。如果您需要在启用自动故障切换后更改NameNode Service RPC端口，则必须执行以下操作重新初始化znode：
1.停止HDFS服务。
2.配置服务RPC端口：
a.转到HDFS服务。
b.单击配置选项卡。
c.选择Scope> NameNode。
d.选择类别>端口和地址。
e.找到NameNode Service RPC端口属性或通过在搜索框中输入名称来搜索它。
f.根据需要更改端口值。
如果多个角色组适用于此配置，请编辑相应角色组的值。请参阅使用Cloudera Manager修改配置属性。
3.在ZooKeeper服务器主机上，运行zookeeper-client。
a. 执行以下操作删除配置的名称服务。这个例子假设nameservice的名字是nameservice1。您可以在HDFS实例选项卡上的联合身份验证和高可用性部分标识名称服务：
rmr /hadoop-ha/nameservice1

4.单击实例选项卡。 5.选择操作>在ZooKeeper中初始化高可用性状态。 6.启动HDFS服务。

####Fencing Methods 为确保一次只有一个NameNode处于活动状态，共享编辑目录需要使用防护方法。在故障转移期间，fencing方法负责确保先前活动的NameNode不再有权访问共享编辑目录，以便新的活动NameNode可以安全地继续写入。默认情况下，Cloudera Manager将HDFS配置为使用shell fencing方法（shell（true））。防护参数位于HDFS服务配置属性下的“服务范围”>“高可用性”类别中。有关CDH 5提供的防护方法以及如何配置防护的详细信息，请参阅防护配置。 ####使用命令行启用HDFS HA

重要：
在不使用Cloudera Manager的系统上遵循这些命令行指示信息。
此信息特别适用于CDH 5.11.x.有关其他版本的信息，请参阅Cloudera文档。

本节介绍CDH 5中HDFS HA所需的软件配置，并介绍如何设置配置属性并使用命令行来部署HDFS HA。 ####为HDFS HA配置软件配置概述与HDFS联合配置一样，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客户端在未给出默认路径前缀时使用的默认路径前缀。（对于YARN实现，已弃用fs.default.name，但仍可使用。）或者，您可以将Hadoop客户端的默认路径配置为使用启用HA的逻辑URI。例如，如果您使用mycluster作为Nameservice ID，如下所示，这将是所有HDFS路径的权威部分的值。您可以在core-site.xml文件中配置默认??路径： - for yarn

fs.defaultFS
hdfs://mycluster

- for mrv1

fs.default.name
hdfs://mycluster

新的配置参数要配置HA NameNode，您必须将多个配置选项添加到您的hdfs-site.xml配置文件。设置这些配置的顺序并不重要，但是您为dfs.nameservices和dfs.ha.namenodes。[Nameservice ID]选择的值将决定后面的那些键。这意味着您应该在设置其余配置选项之前决定这些值。 **Configure dfs.nameservices** dfs.nameservices - 这个新名称服务的逻辑名称为此名称服务选择一个逻辑名称，例如mycluster，并使用此逻辑名称作为此配置选项的值。你选择的名字是任意的。它将用于配置，也可用作群集中绝对HDFS路径的权威组件。注意：如果您还在使用HDFS联合身份验证，则此配置设置还应该包含其他名称服务（HA或其他）的列表，作为逗号分隔列表。

dfs.nameservices
mycluster

**Configure dfs.ha.namenodes.[nameservice ID]** dfs.ha.namenodes。[nameservice ID] - 名称服务中每个NameNode的唯一标识符配置逗号分隔的NameNode ID列表。这将由DataNode用于确定群集中的所有NameNode。例如，如果您先前使用mycluster作为NameService ID，并且您想将nn1和nn2用作NameNodes的单个ID，则可以按如下方式进行配置：

dfs.ha.namenodes.mycluster
nn1,nn2

注意：在此版本中，您可以为每个名称服务配置最多两个NameNode。 **Configure dfs.namenode.rpc-address.[nameservice ID]** dfs.namenode.rpc-address。[nameservice ID]。[name node ID] - 每个NameNode监听的完全限定的RPC地址对于以前配置的两个NameNode ID，请设置NameNode进程的完整地址和RPC端口。请注意，这会导致两个单独的配置选项。例如：

dfs.namenode.rpc-address.mycluster.nn1
machine1.example.com:8020

dfs.namenode.rpc-address.mycluster.nn2
machine2.example.com:8020

注意：如有必要，您可以类似地配置servicerpc-address设置。 **Configure dfs.namenode.http-address.[nameservice ID]** dfs.namenode.http-address。[nameservice ID]。[name node ID] - 每个NameNode监听的全限定HTTP地址与上面的rpc-address类似，为两个NameNode的HTTP服务器设置侦听地址。例如：

dfs.namenode.http-address.mycluster.nn1
machine1.example.com:50070

dfs.namenode.http-address.mycluster.nn2
machine2.example.com:50070

注意：如果启用了Hadoop Kerberos安全功能，并且您打算使用HSFTP，则还应该为每个NameNode设置类似的https地址。 **Configure dfs.namenode.shared.edits.dir** dfs.namenode.shared.edits.dir - 共享存储目录的位置配置提供共享编辑存储的JournalNodes的地址，由Active NameNode编写并由Standby NameNode读取，以保持Active NameNode所做的所有文件系统更改的最新状态。尽管您必须指定多个JournalNode地址，但您应该只配置其中一个URI。该URI应该采用以下格式：

qjournal://; ; /

日志ID是此名称服务的唯一标识符，它允许一组JournalNodes为多个联邦名称系统提供存储。尽管这不是要求，但重用日志标识符的名称服务标识是个好主意。例如，如果此群集的JournalNodes在机器node1.example.com，node2.example.com和node3.example.com上运行，并且名称服务ID是mycluster，则可以使用以下值作为此值设置（JournalNode的默认端口是8485）：

dfs.namenode.shared.edits.dir
qjournal://node1.example.com:8485; node2.example.com:8485; node3.example.com:8485/mycluster

**Configure dfs.journalnode.edits.dir** dfs.journalnode.edits.dir - JournalNode守护进程将存储其本地状态的路径在每个JournalNode机器上，配置JournalNodes使用的编辑和其他本地状态信息的绝对路径; 每个JournalNode只使用一个路径。（其他JournalNodes提供冗余; 您也可以在本地连接的RAID-1或RAID-10阵列上配置此目录。）例如：

dfs.journalnode.edits.dir
/data/1/dfs/jn

现在创建目录（如果它不存在），并确保它的所有者是hdfs，例如：

sudomkdir?p/data/1/dfs/jns u d o m k d i r ? p / d a t a / 1 / d f s / j nsudo chown -R hdfs:hdfs /data/1/dfs/jn

####客户端故障转移配置 dfs.client.failover.proxy.provider。[nameservice ID] - HDFS客户端用于联系Active NameNode的Java类配置DFS客户端将用于确定哪个NameNode是当前活动的Java类的名称，以及哪个NameNode当前正在为客户端请求提供服务。目前与Hadoop一起提供的唯一实现是ConfiguredFailoverProxyProvider，因此除非您使用自定义配置，否则请使用它。例如：

dfs.client.failover.proxy.provider.mycluster
org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider

####Fencing 配置 dfs.ha.fencing.methods - 将用于在故障转移期间隔离活动NameNode的脚本或Java类的列表系统的正确性是理想的，在任何给定的时间只有一个NameNode处于活动状态。当您使用基于Quorum的存储时，只有一个NameNode将被允许写入JournalNodes，因此在“裂脑”情况下不会破坏文件系统元数据。这反映在dfs.ha.fencing.methods的shell（true）的默认值中，该值并未显式尝试遏制备用NameNode。在没有明确屏蔽的情况下，有一个狭窄的时间窗口，以前活动的NameNode可能会提供对来自客户端的读取的过时响应。当以前活动的NameNode试图写入JournalNodes时，此窗口结束，此时NameNode关闭。由于没有裂脑腐败的危险，这种陈旧的阅读反应窗口很少成为应用程序的问题。在需要强读取一致性的罕见或特殊情况下，请使用显式的防护方法，例如基于代理的fencing.注意：如果您选择使用基于代理的防护方法，则应该仍将shell（true）配置为回退防护选项，因为如果其他NameNode没有响应，基于代理的防护失败。故障切换期间使用的防护方法将配置为以回车分隔的列表，并且会按顺序尝试这些方法，直到其中一个表明防护已成功为止。有关实现自己的自定义fencing方法的信息，请参阅org.apache.hadoop.ha.NodeFencer类。**Configuring the shell fencing method** shell - 运行一个任意的shell命令来隔离活动的NameNodeshell fencing方法运行一个任意的shell命令，你可以像下面这样配置它：

dfs.ha.fencing.methods
shell(/path/to/my/script.sh arg1 arg2 …)

'（'和'）'之间的字符串直接传递给bash shell，不能包含任何关闭的括号。执行时，配置脚本的第一个参数将是要被隔离的NameNode的地址，后面是在配置中指定的所有参数。shell命令将在设置为包含所有当前Hadoop配置变量的环境中运行，'_'字符替换任何'。'。配置键中的字符。所使用的配置已将任何NameNode特定的配置升级为其通用形式 - 例如，dfs_namenode_rpc-address将包含目标节点的RPC地址，即使配置可能将该变量指定为dfs.namenode.rpc-address.ns1 .nn1。引用要防护的目标节点的以下变量也可用：| Variable | Description | | - | :-: | | $target_host | 要隔离的节点的主机名| | $target_port | 围绕节点的IPC端口 | | $target_address | 以上两个变量组合为host：port | | $target_nameserviceid | 要被隔离的NameNode的名称服务ID | | $target_namenodeid | 要被隔离的NameNode的NameNode ID | 您也可以使用这些环境变量作为shell命令本身的替代。例如：

dfs.ha.fencing.methods
shell(/path/to/my/script.sh –nameservice= targetnameserviceidt a r g e t n a m e s e r v i c e i d target_host:$target_port)

如果shell命令返回0的退出码，则确定防护成功。如果它返回任何其他退出代码，则防护未成功，并尝试列表中的下一个防护方法。注意：此防护方法不会实现任何超时。如果超时是必要的，它们应该在shell脚本中实现（例如，通过分支子shell在几秒钟内杀死它的父代） **自动故障转移配置** 以上各节介绍如何配置手动故障转移。在该模式下，即使主动节点发生故障，系统也不会自动触发从活动节点到备用节点的故障转移。本节介绍如何配置和部署自动故障转移。有关如何实现自动故障转移的概述，请参阅自动故障转移。 Deploying ZooKeeper 在典型的部署中，ZooKeeper守护进程被配置为在三个或五个节点上运行。由于ZooKeeper本身具有轻量资源需求，因此可以在与HDFS NameNode和Standby节点相同的硬件上配置ZooKeeper节点。使用MapReduce v2（MRv2）的操作员经常选择在与YARN ResourceManager相同的节点上部署第三个ZooKeeper进程。建议将ZooKeeper节点配置为将其数据存储在HDFS元数据的单独磁盘驱动器上，以获得最佳性能和隔离。有关如何设置ZooKeeper集成的说明，请参阅ZooKeeper文档。在下面的章节中，我们假设您已经建立了一个在三个或更多节点上运行的ZooKeeper集群，并通过使用ZooKeeper命令行界面（CLI）进行连接来验证其正确的操作。**配置自动故障转移** 注意：在开始配置自动故障转移之前，您必须关闭群集。当集群正在运行时，目前无法从手动故障转移设置转换为自动故障转移设置。配置自动故障转移需要两个额外的配置参数。在您的hdfs-site.xml文件中，添加：

dfs.ha.automatic-failover.enabled
true

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

ha.zookeeper.quorum
zk1.example.com:2181,zk2.example.com:2181,zk3.example.com:2181

这列出了运行ZooKeeper服务的主机端口对。与本文档前面介绍的参数一样，这些设置可以通过在名称服务的基础上配置名称服务ID后缀来配置。例如，在启用了联合的群集中，您可以通过设置dfs.ha.automatic-failover.enabled.my-nameservice-id为其中一个名称服务显式启用自动故障转移。您可以设置几个其他配置参数来控制自动故障转移的行为，但在大多数安装中这些参数不是必需的。有关详细信息，请参阅Hadoop文档的配置部分。**初始化ZooKeeper中的HA状态** 添加配置密钥后，下一步是在ZooKeeper中初始化所需的状态。您可以通过从其中一个NameNode主机运行以下命令来完成此操作。注意：使用此命令时，ZooKeeper集合必须正在运行; 否则将无法正常工作。

$ hdfs zkfc -formatZK

这将在ZooKeeper中创建一个自动故障转移系统存储其数据的znode。**确保访问ZooKeeper** 如果您运行的是安全群集，则可能需要确保存储在ZooKeeper中的信息也是安全的。这可以防止恶意客户修改ZooKeeper中的元数据或者可能触发错误的故障转移。要保护ZooKeeper中的信息，请首先将以下内容添加到core-site.xml文件中：

ha.zookeeper.auth
@/path/to/zk-auth.txt

ha.zookeeper.acl
@/path/to/zk-acl.txt

请注意这些值中的'@'字符 - 它指定配置不是内联的，而是指向磁盘上的文件。第一个配置的文件指定ZooKeeper认证列表，其格式与ZooKeeper CLI使用的相同。例如，您可以指定类似摘要的内容：hdfs-zkfcs：mypassword其中，hdfs-zkfcs是ZooKeeper的唯一用户名，mypassword是用作密码的一些唯一字符串。接下来，使用如下命令生成与此验证对应的ZooKeeper访问控制列表（ACL）：

java?cpj a v a ? c p 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命令，如上所述。这样做后，您可以按如下方式验证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守护程序安装在它们将运行的每台机器上。要在Red Hat兼容系统上安装JournalNode：

$ sudo yum install hadoop-hdfs-journalnode

在Ubuntu和Debian系统上安装JournalNode：

$ sudo apt-get install hadoop-hdfs-journalnode

在SLES系统上安装JournalNode：

$ sudo zypper install hadoop-hdfs-journalnode

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

sudo service hadoop-hdfs-journalnode start

在格式化主NameNode（在新集群中）之前和启动NameNodes（在所有情况下）之前，请等待守护进程启动。 **格式化NameNode（如果是新集群）** 如果您正在设置新的HDFS群集，请格式化您将用作主NameNode的NameNode; 请参阅格式化NameNode。重要提示：确保JournalNodes已启动。如果您已将NameNode配置为与JournalNodes通信，但尚未启动JournalNodes，则格式化将失败。 **初始化共享编辑目录（如果转换现有的非HA集群）** 如果要将非HA NameNode转换为HA，请使用本地NameNode编辑目录中的编辑数据初始化共享编辑目录：

hdfs namenode -initializeSharedEdits

**启动namenodes** 1.启动主（格式）的NameNode：

$ sudo service hadoop-hdfs-namenode start

2.启动备用namenode

sudo?uhdfshdfsnamenode?bootstrapStandbys u d o ? u h d f s h d f s n a m e n o d e ? b o o t s t r a p S t a n d b ysudo service hadoop-hdfs-namenode start

注意：如果启用了Kerberos，请不要使用sudo -u 形式的命令; 他们会因安全错误而失败。相反，使用以下命令： $ kinit （如果您使用的是密码）或$ kinit -kt （如果您使用的是密钥表），然后对于此用户执行的每个命令 $ 使用-bootstrapStandby选项启动备用NameNode会将主NameNode的元数据目录（包括名称空间信息和最新检查点）的内容复制到备用NameNode。（包含NameNode元数据的目录的位置使用配置选项dfs.namenode.name.dir和dfs.namenode.edits.dir进行配置。）您可以通过浏览到其配置的HTTP地址来访问每个NameNode的网页。请注意，在配置的地址旁边是NameNode的HA状态（“Standby”或“Active”）。只要HA NameNode启动并且未启用自动故障转移，它最初处于Standby状态。如果启用自动故障转移，则启动的第一个NameNode将变为活动状态。 **重新启动服务（如果转换现有的非HA集群）** 如果要从非HA转换为HA配置，则需要重新启动JobTracker和TaskTracker（对于MRv1，如果使用的话），或者ResourceManager，NodeManager和JobHistory Server（对于YARN）以及DataNodes：在每个DataNode上：

sudo service hadoop-hdfs-datanode start

在每个TaskTracker系统（MRv1）上：

sudo service hadoop-0.20-mapreduce-tasktracker start

在JobTracker系统（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 FailoverController（ZKFC）配置了自动故障转移，则必须在运行NameNode的每台机器上安装并启动zkfc守护进程。继续如下。在红帽兼容系统上安装ZKFC：

sudo yum install hadoop-hdfs-zkfc

在Ubuntu和Debian系统上安装ZKFC：

sudo apt-get install hadoop-hdfs-zkfc

在SLES系统上安装ZKFC：

【cdh|cdh-启用hdfs ha】sudo zypper install hadoop-hdfs-zkfc

要启动zkfc守护进程：

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 来模拟JVM崩溃。或者，您可以重新启动机器或其网络接口以模拟不同类型的停机。触发您要测试的中断后，另一个NameNode应在几秒钟内自动激活。检测故障并触发故障转移所需的时间取决于ha.zookeeper.session-timeout.ms的配置，但默认为5秒。
如果测试不成功，则可能是配置错误。检查zkfc守护进程以及NameNode守护进程的日志以进一步诊断问题。