翻译： https://www.cloudera.com/documentation/enterprise/latest/topics/cdh_hag_hdfs_ha_enabling.html
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-based的存储实施。Quorum-based的存储依赖于一组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。
- 执行HDFS HA硬件配置下描述的所有配置和设置任务。
- 确保你有一个ZooKeeper服务。
- 转到HDFS服务。
- 选择Actions > Enable High Availability。显示有资格运行备用NameNode和JournalNodes的主机的页面。
a. 为名称服务指定一个名称，然后单击继续。注意：为名称服务使用唯一名称。
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服务RPC端口（dfs.namenode.servicerpc-address），同时启用自动故障转移，这会导致保存在ZooKeeper中的NameNode地址不匹配/hadoop-ha znode和故障切换控制器配置的NameNode地址。这将阻止故障切换控制器重新启动。如果您需要在启用自动故障切换后更改NameNode Service RPC端口，则必须执行以下操作重新初始化znode：
停止HDFS服务。
配置服务RPC端口：
a. 转到HDFS服务。
b. 单击Configuration 选项卡。
c. 选择Scope > NameNode。
d. 选择 Category > Ports and Addresses.。
e. 找到NameNode Service RPC端口属性或通过在搜索框中输入名称来搜索它。
f. 根据需要更改端口值。
要根据需要将此配置属性应用于其他角色组，请编辑相应角色组的值。请参阅使用Cloudera Manager修改配置属性。在ZooKeeper服务器主机上运行zookeeper-client.。
a. 执行以下操作删除配置的名称服务。这个例子假设nameservice的名字是nameservice1。您可以在HDFS Instances 选项卡上的 Federation and High Availability 标识名称服务：rmr /hadoop-ha/nameservice1单击Instances 选项卡。
选择 Actions > Initialize High Availability State in ZooKeeper.
启动HDFS服务。
隔离方法Fencing Methods
为确保一次只有一个NameNode处于活动状态，共享编辑目录需要使用fencing methods 。在故障转移期间，fencing methods负责确保先前活动的NameNode不再有权访问共享编辑目录，以便新的活动NameNode可以安全地继续写入。
默认情况下，Cloudera Manager将HDFS配置为使用 fencing method (shell(true))）。
fencing 参数位于 HDFS服务配置属性下的 Service-Wide > High Availability 类别中。
有关CDH 5提供的fencing方法以及如何配置fencing的详细信息，请参阅fencing配置。
使用命令行启用HDFS HA
重要：
- 在不使用Cloudera Manager配置时，遵循这些命令行指示信息。
- 此信息特别适用于CDH 5.14.x。有关其他版本的信息，请参阅Cloudera文档。
本节介绍CDH 5中HDFS HA所需的软件配置，并介绍如何设置配置属性并使用命令行来部署HDFS HA。
为HDFS HA配置文件
配置概述
HA配置向后兼容，并允许现有的单一NameNode配置在无需更改情况下即可工作。新配置的设计使群集中的所有节点都可以具有相同的配置，而无需根据节点的类型将不同的配置文件部署到不同的机器。
HA群集重用Nameservice ID来标识由多个HA NameNode组成的单个HDFS实例。另外，还有一个名为NameNode ID的新抽象。群集中每个不同的NameNode都有一个不同的NameNode ID。配置文件的参数需要包括Nameservice ID和NameNode ID以支持所有NameNode使用同一个配置文件。
对现有配置参数的更改
对于YARN实现，以下配置参数已更改：
fs.defaultFS - 以前为 fs.default.name ，这是Hadoop FS客户端在未给出任何前缀时使用的默认路径前缀。（fs.default.name 参数已经被YARN弃用，但仍然有效。）
或者，您可以将Hadoop客户端的默认路径配置为使用启用HA的逻辑URI。例如，如果你使用myCluster 作为Nameservice ID，如下所示，这将是所有HDFS路径的权威部分的值。你可以在你的core-site.xml配置文件中设置默认路径：
- 对于YARN：
<property>
<name>fs.defaultFS</name>
<value>hdfs://mycluster</value>
</property>
- 对于MRv1：
<property>
<name>fs.default.name</name>
<value>hdfs://mycluster</value>
</property>
新的配置参数
要配置HA NameNodes，您必须在hdfs-site.xml中添加多个配置选项。
您设置这些配置的顺序不重要，但是dfs.nameservices and dfs.ha.namenodes.[Nameservice ID]的值非常关键。这意味着您应该在设置其余配置选项之前决定这些值。
配置dfs.nameservices
dfs.nameservices - 这个名字服务的逻辑名称
例如，为此名称服务选择一个逻辑名称 myCluster，并使用此逻辑名称作为此配置选项的值。你选择的名字是任意的。它将用于配置，也将作为群集中HDFS的绝对路径。
配置dfs.ha.namenodes.[nameservice ID]
dfs.ha.namenodes.[nameservice ID] - 名称服务中每个NameNode的唯一标识符
配置逗号分隔的NameNode ID列表。这将由DataNode用于确定群集中的所有NameNode。例如，如果你使用myCluster 作为NameService ID，并且您想使用NN1 和 NN2 作为NameNodes的个体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类似，为两个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 Kerberos安全功能，并且您打算使用HSFTP，则还应该设置 https-address 。
配置dfs.namenode.shared.edits.dir
dfs.namenode.shared.edits.dir - 共享存储目录的位置
配置供JournalNodes使用的共享编辑存储地址，由Active NameNode写入并由Standby NameNode读取，以保持两个 NameNode所做的所有文件系统更改一致。尽管您必须指定多个JournalNode地址，但您应该只配置其中一个URI。该URI应该采用以下格式：
qjournal://<host1:port1>;<host2:port2>;<host3:port3>/<journalId>
日志ID是此名称服务的唯一标识符，它允许一组JournalNodes为多个联邦名称系统提供存储。尽管这不是要求，但重用名称服务标识是个好主意。
例如，如果该群集的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机器上，配置JournalNodes使用的用于编辑和存储其他本地状态信息的绝对路径; 每个JournalNode只使用一个路径。（其他JournalNodes提供冗余;您也可以在本地连接的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客户端用于联系Active NameNode的Java类
配置DFS客户端将用于确定哪个NameNode是当前活动的Java类的名称，以及哪个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 - 一个脚本或Java类的列表，它们将用于在故障转移期间对活动NameNode进行篱笆划分
系统理想是，在任何给定的时间只有一个NameNode处于活动状态。
当您使用Quorum-based的存储时，只有一个NameNode将被允许写入JournalNodes，因此在“裂脑”场景中不会破坏文件系统元数据。为dfs.ha.fencing.methods 属性配置的默认值 shell(true) ，它并没有明确地尝试隔离备用NameNode。
在没有明确屏蔽的情况下，有一个狭窄的时间窗口，以前活动的NameNode可能会提供对来自客户端的读取的过时响应。当以前活动的NameNode试图写入JournalNodes时，此窗口结束，此时NameNode关闭。
由于没有裂脑的危险，这种时间窗口很少成为应用程序的问题。在需要强读取一致性的罕见或特殊情况下，请使用明确的屏蔽方法，如agent-based fencer。
注意：如果您选择使用agent-based fencer ，则仍应配置shell(true) ，因为如果agent-based fencer失败时其他NameNode没有响应。
故障切换期间使用的防护方法将配置为以回车分隔的列表，并且会按顺序尝试这些方法，直到其中一个表明防护已成功为止。
有关实现自己的自定义fencing 的信息，请参阅 org.apache.hadoop.ha.NodeFencer class.。
配置外壳防护方法
shell - 运行任意的shell命令来隔离活动的NameNode
shell fencing方法运行一个任意的shell命令，你可以像下面这样配置它：
<property>
<name>dfs.ha.fencing.methods</name>
<value>shell(/path/to/my/script.sh arg1 arg2 ...)</value>
</property>
'（'和'）'之间的字符串直接传递给bash shell ，不能包括任何结束括号。
执行时，配置脚本的第一个参数将是要被隔离的NameNode的地址，后面是在配置中指定的所有参数。
shell命令将在启动时包含hadoop环境中所有的配置遍历，将配置项中的_替换为. 。例如， dfs_namenode_rpc-address 将包含目标节点的RPC地址，即使配置可能将该变量指定为 dfs.namenode.rpc-address.ns1.nn1。
| 变量 | 描述 |
|---|---|
| $ target_host | 要隔离的节点的主机名 |
| $ target_port | 围绕节点的IPC端口 |
| $ TARGET_ADDRESS | 以上两个变量组合为port |
| $ target_nameserviceid | 要被隔离的NameNode的名称服务ID |
| $ target_namenodeid | 要被隔离的NameNode的NameNode ID |
要fencing的目标节点的以下变量也可用：
| 变量 | 描述 |
|---|---|
| $ target_host | 要隔离的节点的主机名 |
| $ target_port | 围绕节点的IPC端口 |
| $ TARGET_ADDRESS | 以上两个变量组合为port |
| $ target_nameserviceid | 要被隔离的NameNode的名称服务ID |
| $ target_namenodeid | 要被隔离的NameNode的NameNode 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在几秒钟内杀死它的父代）。
自动故障转移配置
以上各节介绍如何配置手动故障转移。在该模式下，即使主动节点发生故障，系统也不会自动触发从活动节点到备用节点的故障转移。本节介绍如何配置和部署自动故障转移。有关如何实现自动故障转移的概述，请参阅自动故障转移。
部署ZooKeeper
在典型的部署中，ZooKeeper守护进程被配置为在三个或五个节点上运行。由于ZooKeeper本身具有轻量资源需求，因此可以在与HDFS NameNode和Standby节点上配置ZooKeeper节点。使用MapReduce v2（MRv2）的操作员经常选择在与YARN ResourceManager相同的节点上部署第三个ZooKeeper进程。建议将ZooKeeper节点的数据存储与HDFS元数据的存储分开，以获得最佳性能和隔离。
有关如何设置ZooKeeper集成的说明，请参阅ZooKeeper文档。在下面的章节中，我们假设您已经建立了一个在三个或更多节点上运行的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 ID后缀来配置。例如，在启用了联合的群集中，您可以通过设置仅显式启用其中一个名称服务的自动故障转移dfs.ha.automatic-failover.enabled.my-nameservice-id 。
还有其他几个配置参数可以用来控制自动故障转移的行为，但它们在大多数安装中不是必需的。有关详细信息，请参阅Hadoop文档的配置部分。
初始化ZooKeeper中的HA状态
添加配置密钥后，下一步是在ZooKeeper中初始化所需的状态。您可以通过从其中一个NameNode主机运行以下命令来完成此操作。
注意：使用此命令时，ZooKeeper集合必须正在运行; 否则将无法正常工作。
$ hdfs zkfc -formatZK
这将创建一个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-zkcs是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：”为前缀。例如：
digest:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=:rwcda
要使这些ACL生效，请重新运行 zkfc -formatZK 命令，如上所述。
这样做后，您可以按如下方式验证ZooKeeper CLI的ACL：
[zk: localhost:2181(CONNECTED) 1] getAcl /hadoop-ha
'digest,'hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=
: cdrwa
自动故障转移FAQ
- 是否需要以特定顺序启动ZKFC和NameNode守护进程？
不需要。在任何给定的节点上，您可以在其相应的NameNode之前或之后启动ZKFC。
- 我应该进行哪些额外的监测？
您应该在运行NameNode的每台主机上添加监控，以确保ZKFC保持运行。例如，在某些ZooKeeper故障中，ZKFC可能会意外退出，应该重新启动以确保系统已准备好进行自动故障转移。此外，您应该在ZooKeeper quorum 中监视每个服务器。如果ZooKeeper崩溃，自动故障转移将不起作用。
- 如果ZooKeeper出现故障会发生什么？
如果ZooKeeper群集崩溃，则不会触发自动故障转移。但是，HDFS将继续运行，没有任何影响。当ZooKeeper重新启动时，HDFS将会重新连接。 - 我可以将我的NameNode中的一个指定为主/首选吗？
目前，这不支持。首先启动的NameNode将变为活动状态。您可以选择以特定顺序启动群集，以便首选节点首先启动。 - 如何在配置自动故障转移时启动手动故障转移？
即使配置了自动故障转移，您也可以启动手动故障转移。它将执行相应的故障转移。
部署HDFS高可用性
在设置完所有必要的配置选项后，即可启动JournalNodes和两个HA NameNode。
重要提示： 在开始之前：请确保您已执行中所述的所有配置和设置任务 配置硬件的HDFS HA和配置软件HDFS HA，包括初始化的ZooKeeper HA状态，如果部署了自动故障转移。
安装并启动JournalNodes
-
将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
- 在他们将要运行的每台机器上启动JournalNode守护进程：
sudo service hadoop-hdfs-journalnode start
在格式化主NameNode（在新集群中）之前和启动NameNodes（在所有情况下）之前，请确保守护进程启动。
格式化NameNode（如果是新集群）
如果您正在设置新的HDFS群集，请格式化您将用作主NameNode的NameNode; 请参阅格式化NameNode。
重要提示：确保JournalNodes已启动。如果您已将NameNode配置为与JournalNodes进行通信，但尚未启动JournalNodes，则格式化将失败。
初始化共享编辑目录（如果转换现有的非HA集群）
如果要将非HA NameNode转换为HA，需要使用本地NameNode中的edits目录的数据初始化共享编辑目录：
hdfs namenode -initializeSharedEdits
启动NameNodes
- 启动主（已格式化）的NameNode：
$ sudo service hadoop-hdfs-namenode start
- 启动备用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>.
启动备用NameNode 带-bootstrapStandby选项会将主NameNode的元数据目录（包括名称空间信息和最新的检查点）的内容复制到备用NameNode。（保存NameNode元数据的目录位置使用配置选项 dfs.namenode.name.dir 和 dfs.namenode.edits.dir）进行配置。
您可以通过每个NameNode配置的HTTP地址来访问其网页。请注意，在配置的地址旁边是NameNode的HA状态（“Standby”或“Active”）。每当HA NameNode启动并且未启用自动故障转移时，它最初处于Standby状态。如果启用自动故障转移，则启动的第一个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
在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：
$ sudo zypper install hadoop-hdfs-zkfc
启动 zkfc ：
$ sudo service hadoop-hdfs-zkfc start
以特定顺序启动ZKFC和NameNode后台进程并不重要。在任何给定的节点上，您可以在相应的NameNode之前或之后启动ZKFC。
您应该在运行NameNode的每台主机上添加监控，以确保ZKFC保持运行。例如，在某些类型的ZooKeeper故障中，ZKFC可能会意外退出，应该重新启动以确保系统准备好进行自动故障转移。
此外，您应该在每个服务器监控ZooKeeper quorum 。如果ZooKeeper崩溃，则自动故障转移将不起作用。如果ZooKeeper群集崩溃，则不会触发自动故障转移。但是，HDFS将继续运行，没有任何影响。当ZooKeeper重新启动时，HDFS将会重新连接。
验证自动故障转移
在启用了自动故障转移的群集的初始部署之后，您应该测试其操作。为此，首先找到活动的NameNode。如上所述，您可以通过访问NameNode Web界面来确定哪个节点处于活动状态。
一旦找到活动的NameNode，就可以在该节点上引发故障。例如，你可以使用 kill -9 <pid of NN> 模拟JVM崩溃。或者，您可以重新启动机器或其网络接口以模拟不同类型的停机。触发中断后，另一个NameNode应在几秒钟内自动激活。检测故障并触发故障转移所需的时间取决于配置ha.zookeeper.session-timeout.ms，默认为5秒。
如果测试不成功，则可能是配置错误。检查zkfc 日志 以及NameNode守护进程来进一步诊断问题。
