cdh-启用hdfs ha
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 yarnfs.defaultFS
hdfs://mycluster
- for mrv1fs.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/jn s u d o m k d i r − p / d a t a / 1 / d f s / j n 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，因此除非您使用自定义配置，否则请使用它。例如：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命令来隔离活动的NameNode
shell 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= targetnameserviceid t 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−cp j 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.启动备用namenodesudo−uhdfshdfsnamenode−bootstrapStandby s 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 y sudo service hadoop-hdfs-namenode start
注意：如果启用了Kerberos，请不要使用sudo -u <user> <command> 形式的命令;他们会因安全错误而失败。相反，使用以下命令： $ kinit <user>（如果您使用的是密码）或$ kinit -kt <keytab> <principal>（如果您使用的是密钥表），然后对于此用户执行的每个命令 $ <command>
使用-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：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守护进程的日志以进一步诊断问题。
手机扫一扫
移动阅读更方便
你可能感兴趣的文章