Hadoop3.2.0 HDFS HA ( Quorum Journal Manager )

古城微笑少年丶 2022-02-18 10:15 225阅读 0赞

*  目的
 *  注意：使用Quorum Journal Manager或常规共享存储
 *  背景
 *  架构
 *  硬件资源
 *  部署
    
     *  配置概述
     *  配置细节
     *  部署细节
     *  管理命令
     *  负载均衡器设置
 *  自动故障转移
    
     *  介绍
     *  组件
     *  部署ZooKeeper
     *  在你开始之前
     *  配置自动故障转移
     *  在ZooKeeper中初始化HA状态
     *  使用start-dfs.sh启动集群
     *  手动启动集群
     *  保护对ZooKeeper的访问
     *  验证自动故障转移
 *  自动故障转移常见问题
 *  启用HA的HDFS升级/终结/回滚

## 目的 ##

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

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

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

本指南讨论如何使用Quorum Journal Manager（QJM）配置和使用HDFS HA，以共享活动和备用NameNode之间的编辑日志。有关如何使用NFS为共享存储而不是QJM配置HDFS HA的信息，请参阅[此备用指南。][Link 1]

## 背景 ##

在Hadoop 2.0.0之前，NameNode是HDFS集群中的单点故障（SPOF）。每个群集都有一个NameNode，如果该机器或进程变得不可用，整个群集将无法使用，直到NameNode重新启动或在单独的计算机上启动。

这在两个主要方面影响了HDFS集群的总体可用性：

*  对于计划外事件（例如计算机崩溃），在操作员重新启动NameNode之前，群集将不可用。
 *  计划维护事件（如NameNode计算机上的软件或硬件升级）将导致群集停机时间窗口。

HDFS高可用性功能通过提供在具有热备用的主动/被动配置中的同一群集中运行两个（以及3.0.0多于两个）冗余NameNode的选项来解决上述问题。这允许在机器崩溃的情况下快速故障转移到新的NameNode，或者为了计划维护而优雅地管理员启动的故障转移。

## 架构 ##

在典型的HA群集中，两个或多个单独的计算机配置为NameNode。在任何时间点，其中一个NameNode处于*Active *状态，而其他NameNode 处于 *Standby *状态。Active NameNode负责集群中的所有客户端操作，而Standbys只是充当工作者，维持足够的状态以在必要时提供快速故障转移。

为了使备用节点保持其状态与Active节点同步，两个节点都与一组称为“JournalNodes”（JNs）的单独守护进程通信。当Active节点执行任何名称空间修改时，它会将修改记录持久地记录到大多数这些JNs中。待机节点能够从JNs读取编辑，并且不断观察它们对edit log的更改。当备用节点看到edit log 时，它会将它们应用到自己的命名空间。如果发生故障转移，Standby将确保在将自身升级为Active状态之前已从JournalNodes读取所有edit log 内容。这可确保在发生故障转移之前完全同步命名空间状态。

为了提供快速故障转移，备用节点还必须具有关于群集中块的位置的最新信息。为了实现这一点，DataNode配置了所有NameNode的位置，并向所有人发送块位置信息和心跳。

对于HA群集的正确操作而言，一次只有一个NameNode处于活动状态至关重要。否则，命名空间状态将在两者之间快速分歧，冒着数据丢失或其他不正确结果的风险。为了确保这个属性并防止所谓的“裂脑情景”，JournalNodes只允许一个NameNode一次成为一个作家。在故障转移期间，要激活的NameNode将简单地接管写入JournalNodes的角色，这将有效地阻止其他NameNode继续处于Active状态，从而允许新的Active安全地进行故障转移。

## 硬件资源 ##

要部署HA群集，您应准备以下内容：

*  **NameNode计算机** - 运行Active和Standby NameNode的计算机应具有彼此相同的硬件，以及与非HA集群中使用的硬件等效的硬件。
 *  **JournalNode计算机** - 运行JournalNodes的计算机。JournalNode守护程序相对轻量级，因此这些守护程序可以合理地与其他Hadoop守护程序并置在机器上，例如NameNodes，JobTracker或YARN ResourceManager。**注意：**必须至少有3个JournalNode守护进程，因为编辑日志修改必须写入大多数JN。这将允许系统容忍单个机器的故障。您也可以运行3个以上的JournalNodes，但为了实际增加系统可以容忍的失败次数，您应该运行奇数个JN（即3,5,7等）。请注意，当使用N JournalNodes运行时，系统最多可以容忍（N-1）/ 2个故障并继续正常运行。

请注意，在HA群集中，备用NameNode还会执行命名空间状态的检查点，因此无需在HA群集中运行Secondary NameNode，CheckpointNode或BackupNode。事实上，这样做会是一个错误。这还允许正在重新配置启用HA的HDFS群集的人员启用HA，以重用他们之前专用于Secondary NameNode的硬件。

## 部署 ##

### **配置概述** ###

与联邦配置类似，HA配置是向后兼容的，允许现有的单个NameNode配置无需更改即可运行。新配置的设计使得集群中的所有节点可以具有相同的配置，而无需根据节点的类型将不同的配置文件部署到不同的计算机。

与HDFS Federation一样，HA集群重用名称服务ID来标识单个HDFS实例，该实例实际上可能包含多个HA NameNode。此外，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”，并使用此逻辑名称作为此config选项的值。您选择的名称是任意的。它既可用于配置，也可用作群集中绝对HDFS路径的权限组件。
 
 注意：如果您还在使用HDFS Federation，则此配置设置还应包括其他名称服务列表，HA或其他，以逗号分隔列表。
 
 <pre class="has" style="margin-left:7px;" name="code"><code class="language-source"><property>

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

* 
 
 
 **dfs.ha.namenodes。\[nameservice ID\]** - **nameservice**中每个NameNode的唯一标识符
 * 配置逗号分隔的NameNode ID列表。DataNodes将使用它来确定集群中的所有NameNode。例如，如果您之前使用“mycluster”作为名称服务ID，并且您希望使用“nn1”，“nn2”和“nn3”作为NameNodes的各个ID，则可以这样配置：
 
 <pre class="has" style="margin-left:7px;" name="code"><code class="language-source"><property>
 
 <name>dfs.ha.namenodes.mycluster</name> 
 <value>nn1,nn2, nn3</value> 
 </property>
 
 注意： HA的NameNode最小数量为2，但您可以配置更多。由于通信开销，建议不要超过5 - 推荐3个NameNodes。
 </li>
 <li>
 dfs.namenode.rpc-address。[nameservice ID]。[name node ID] - 要监听的每个NameNode的完全限定的RPC地址
 
 对于两个先前配置的NameNode ID，请设置NameNode进程的完整地址和IPC端口。请注意，这会产生两个单独的配置选项。例如：
 
 <pre class="has" style="margin-left:7px;" name="code"><code class="language-source"><property>
 
 <name>dfs.namenode.rpc-address.mycluster.nn1</name> 
 <value>[machine1.example.com:8020][machine1.example.com_8020]</value> 
 </property> 
 <property> 
 <name>dfs.namenode.rpc-address.mycluster.nn2</name> 
 <value>[machine2.example.com:8020][machine2.example.com_8020]</value> 
 </property> 
 <property> 
 <name>dfs.namenode.rpc-address.mycluster.nn3</name> 
 <value>[machine3.example.com:8020][machine3.example.com_8020]</value> 
 </property>
 
 注意：如果您愿意，可以类似地配置“ servicerpc-address ”设置。
 </li>
 <li>
 dfs.namenode.http-address。[nameservice ID]。[name node ID] - 要监听的每个NameNode的完全限定HTTP地址
 
 与上面的rpc-address类似，设置两个NameNodes的HTTP服务器的地址以进行侦听。例如：
 
 <pre class="has" style="margin-left:7px;" name="code"><code class="language-source"><property>
 
 <name>dfs.namenode.http-address.mycluster.nn1</name> 
 <value>[machine1.example.com:9870][machine1.example.com_9870]</value> 
 </property> 
 <property> 
 <name>dfs.namenode.http-address.mycluster.nn2</name> 
 <value>[machine2.example.com:9870][machine2.example.com_9870]</value> 
 </property> 
 <property> 
 <name>dfs.namenode.http-address.mycluster.nn3</name> 
 <value>[machine3.example.com:9870][machine3.example.com_9870]</value> 
 </property>
 
 注意：如果启用了Hadoop的安全功能，则还应为每个NameNode 设置https-address。
 </li>
 <li>
 dfs.namenode.shared.edits.dir - 标识NameNodes将写入/读取 edits  的JNs 组的URI
 
 这是一个配置JournalNodes的地址的地方，它提供共享 edits 存储，由Active nameNode写入并由Standby NameNode读取，以保持Active NameNode所做的所有文件系统更改的最新状态。虽然您必须指定多个JournalNode地址，但您应该只配置其中一个URI。URI应该是以下形式： qjournal://*host1:port1*;*host2:port2*;*host3:port3*/*journalId*.   。Journal ID是此nameservice的唯一标识符，它允许一组JournalNodes为多个联合名称系统提供存储。虽然不是必需的，但最好重用日志标识符的名称服务ID。
 
 例如，如果此群集的JournalNodes在计算机“node1.example.com”，“node2.example.com”和“node3.example.com”上运行，并且名称服务ID是“mycluster”，则您将使用以下为此设置的值（JournalNode的默认端口为8485）：
 
 <pre class="has" style="margin-left:7px;" name="code"><code class="language-source"><property>
 
 <name>dfs.namenode.shared.edits.dir</name> 
 <value>qjournal://node1.example.com:8485;[node2.example.com:8485][node2.example.com_8485];[node3.example.com:8485/mycluster][node3.example.com_8485_mycluster]</value> 
 </property> 
 
 
 * 
 
 
 **dfs.client.failover.proxy.provider。\[nameservice ID\]** - HDFS客户端用于联系Active NameNode的Java类
 * 配置Java类的名称，DFS客户端将使用该名称来确定哪个NameNode是当前的Active，以及哪个NameNode当前正在为客户端请求提供服务。目前Hadoop附带的两个实现是ConfiguredFailoverProxyProvider和RequestHedgingProxyProvider（对于第一次调用，它同时调用所有名称节点以确定活动的名称，并在后续请求中调用活动的名称节点直到发生故障转移），所以除非您使用自定义代理提供程序，否则请使用其中一个。例如：
 
 <pre class="has" style="margin-left:7px;" name="code"><code class="language-source"><property>
 
 <name>dfs.client.failover.proxy.provider.mycluster</name> 
 <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value> 
 </property> 
 
 
 * 
 
 
 **dfs.ha.fencing.methods** - 脚本或Java类的列表，用于在故障转移期间**屏蔽** Active NameNode
 * 对于系统的正确性，期望在任何给定时间只有一个NameNode处于活动状态。重要的是，在使用Quorum Journal Manager时，只允许一个NameNode写入JournalNodes，因此不存在从裂脑情况中破坏文件系统元数据的可能性。但是，当发生故障转移时，以前的Active NameNode仍可能向客户端提供读取请求，这可能已过期，直到NameNode在尝试写入JournalNode时关闭。因此，即使使用Quorum Journal Manager，仍然需要配置一些防护方法。但是，为了在防护机制失败的情况下提高系统的可用性，建议配置防护方法，该方法可保证作为列表中的最后一个防护方法返回成功。请注意，如果您选择不使用实际的防护方法，则仍必须为此设置配置某些内容，例如“ shell(/bin/true) ”。
 
 故障转移期间使用的防护方法配置为回车分隔列表，将按顺序尝试，直到指示防护成功为止。Hadoop有两种方法：shell和sshfence。有关实现自定义防护方法的信息，请参阅org.apache.hadoop.ha.NodeFencer类。
 
 <hr>sshfence - SSH到Active NameNode并终止进程
 
 该sshfence选项SSHes到目标节点，并使用定影杀死进程监听服务的TCP端口上。为了使此防护选项起作用，它必须能够在不提供密码的情况下SSH到目标节点。因此，还必须配置dfs.ha.fencing.ssh.private-key-files选项，该选项是以逗号分隔的SSH私钥文件列表。例如：
 
 <pre class="has" style="margin-left:7px;" name="code"><code class="language-source"> <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></code></pre>
 
 可选地，可以配置非标准用户名或端口以执行SSH。还可以为SSH配置超时（以毫秒为单位），之后将认为此防护方法已失败。它可能配置如下：
 
 <pre class="has" style="margin-left:7px;" name="code"><code class="language-source"> <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></code></pre>
 
 <hr>shell - 运行任意shell命令以阻止Active NameNode
 
 所述 shell fencing 方法运行的任意外壳命令。它可能配置如下：
 
 <pre class="has" style="margin-left:7px;" name="code"><code class="language-source"> <property>
 <name>dfs.ha.fencing.methods</name>
 <value>shell(/path/to/my/script.sh arg1 arg2 ...)</value>
 </property></code></pre>
 
 '（'和'）'之间的字符串直接传递给bash shell，可能不包含任何右括号。
 
 shell命令将在环境设置为包含所有当前Hadoop配置变量的情况下运行，其中'_'字符替换任何'.'。配置键中的字符。使用的配置已经将任何特定于名称节点的配置提升为其通用格式 - 例如，dfs_namenode_rpc-address将包含目标节点的RPC地址，即使配置可能将该变量指定为dfs.namenode.rpc-address.ns1.nn1。
 
 此外，还提供了以下涉及要隔离的目标节点的变量：
 
 <div class="table-box"><table style="margin-left:-2px;"><thead><tr><th style="text-align:left;vertical-align:top;"> </th>
 			<th style="text-align:left;vertical-align:top;"> </th>
 		</tr></thead><tbody><tr><td style="vertical-align:top;">$ target_host</td>
 			<td style="vertical-align:top;">要隔离的节点的主机名</td>
 		</tr><tr><td style="vertical-align:top;">$ target_port</td>
 			<td style="vertical-align:top;">要隔离的节点的IPC端口</td>
 		</tr><tr><td style="vertical-align:top;">$ TARGET_ADDRESS</td>
 			<td style="vertical-align:top;">以上两种，合并为主机：端口</td>
 		</tr><tr><td style="vertical-align:top;">$ target_nameserviceid</td>
 			<td style="vertical-align:top;">要隔离的NN的名称服务ID</td>
 		</tr><tr><td style="vertical-align:top;">$ target_namenodeid</td>
 			<td style="vertical-align:top;">要隔离的NN的namenode ID</td>
 		</tr></tbody></table></div>这些环境变量也可以用作shell命令本身的替换。例如：
 
 <pre class="has" style="margin-left:7px;" name="code"><code class="language-source"> <property>
 <name>dfs.ha.fencing.methods</name>
 <value>shell(/path/to/my/script.sh --nameservice=$target_nameserviceid $target_host:$target_port)</value>
 </property></code></pre>
 
 如果shell命令返回退出代码0，则确定防护成功。如果它返回任何其他退出代码，则防护不成功，将尝试列表中的下一个防护方法。
 
 注意：此防护方法不会实现任何超时。如果需要超时，则应该在shell脚本本身中实现它们（例如，通过分配子shell以在几秒钟内终止它的父节点）。
 
 <hr></li>
 <li>
 fs.defaultFS - Hadoop FS客户端在没有给出时使用的默认路径前缀
 
 （可选）您现在可以配置Hadoop客户端的默认路径以使用新的启用HA的逻辑URI。如果您之前使用“mycluster”作为名称服务ID，那么这将是所有HDFS路径的权限部分的值。这可以在您的core-site.xml文件中进行如下配置：
 
 <pre class="has" style="margin-left:7px;" name="code"><code class="language-source"><property>
 
 <name>fs.defaultFS</name> 
 <value>hdfs://mycluster</value> 
 </property> 
 
 
 * 
 
 
 **dfs.journalnode.edits.dir** - JournalNode守护程序将存储其本地状态的路径
 * 这是JournalNode计算机上的绝对路径，其中将存储JN使用的edits 和其他本地状态。您只能使用单个路径进行此配置。通过运行多个单独的JournalNode或在本地连接的RAID阵列上配置此目录，可以提供此数据的冗余。例如：
 
 <pre class="has" style="margin-left:7px;" name="code"><code class="language-source"><property>
 
 <name>dfs.journalnode.edits.dir</name> 
 <value>/path/to/journal/node/local/data</value> 
 </property> 
 
 
 ### **部署细节** ###
 
 在设置了所有必需的配置选项后，必须在将运行它们的一组计算机上启动JournalNode守护程序。这可以通过运行命令“ *hdfs --daemon start journalnode* ”并等待守护进程在每个相关机器上启动来完成。
 
 一旦启动了JournalNodes，就必须首先同步两个HA NameNodes的磁盘元数据。
 
 * 如果要设置新的HDFS集群，则应首先在其中一个NameNode上运行format命令（*hdfs namenode -format*）。
 * 如果您已经格式化了NameNode，或者正在将启用了HA的群集转换为启用HA，则现在应该通过运行命令将NameNode元数据目录的内容复制到其他未格式化的NameNode上。*hdfs namenode -bootstrapStandby*“在未格式化的NameNode上。运行此命令还将确保JournalNodes（由**dfs.namenode.shared.edits.dir**配置）包含足够的编辑事务，以便能够启动两个NameNode。
 * 如果要将非HA NameNode转换为HA，则应运行命令“ *hdfs namenode -initializeSharedEdits* ”，该命令将使用本地NameNode编辑目录中的编辑数据初始化JournalNodes。
 
 此时，您可以像通常启动NameNode一样启动所有HA NameNode。
 
 您可以通过浏览到配置的HTTP地址，分别访问每个NameNodes的网页。您应该注意到，配置的地址旁边将是NameNode的HA状态（“standby”或“active”）。每当HA NameNode启动时，它最初处于 Standby 状态。
 
 ### **管理命令** ###
 
 现在您的HA NameNode已配置并启动，您将可以访问一些其他命令来管理HA HDFS集群。具体来说，您应该熟悉“ *hdfs haadmin* ”命令的所有子命令。在没有任何其他参数的情况下运行此命令将显示以下用法信息：
 
 Usage: haadmin
 [-transitionToActive <serviceId>]
 [-transitionToStandby <serviceId>]
 [-failover [--forcefence] [--forceactive] <serviceId> <serviceId>]
 [-getServiceState <serviceId>]
 [-getAllServiceState]
 [-checkHealth <serviceId>]
 [-help <command>]
 
 本指南介绍了每个子命令的高级用法。有关每个子命令的特定用法信息，您应该运行“ *hdfs haadmin -help <command* >”。
 
 * **transitionToActive**和**transitionToStandby** - 将给定NameNode的状态转换为Active或Standby
 
 这些子命令使给定的NameNode分别转换为Active或Standby状态。这些命令不会尝试执行任何防护，因此很少使用。相反，人们几乎总是喜欢使用“ hdfs haadmin -failover ”子命令。
 </li>
 <li>
 故障转移 - 在两个NameNode之间启动故障转移
 
 此子命令导致从第一个提供的NameNode到第二个NameNode的故障转移。如果第一个NameNode处于Standby状态，则此命令只是将第二个NameNode转换为Active状态而不会出现错误。如果第一个NameNode处于活动状态，将尝试将其正常转换为待机状态。如果失败，将按顺序尝试防护方法（由dfs.ha.fencing.methods配置），直到成功为止。只有在此过程之后，第二个NameNode才会转换为Active状态。如果没有防护方法成功，则第二个NameNode将不会转换为活动状态，并且将返回错误。
 </li>
 <li>
 getServiceState - 确定给定的NameNode是Active还是Standby
 
 连接到提供的NameNode以确定其当前状态，适当地将“standby”或“active”打印到STDOUT。此子命令可能由cron作业或监视脚本使用，这些脚本需要根据NameNode当前是活动还是待机而表现不同。
 </li>
 <li>
 getAllServiceState - 返回所有NameNode的状态
 
 连接到已配置的NameNodes以确定当前状态，适当地将“待机”或“活动”打印到STDOUT。
 </li>
 <li>
 checkHealth - 检查给定NameNode的运行状况
 
 连接到提供的NameNode以检查其运行状况。NameNode能够对自身执行某些诊断，包括检查内部服务是否按预期运行。如果NameNode是健康的，则此命令将返回0，否则返回非零。可以使用此命令进行监视。
 
 注意：这尚未实现，并且除非给定的NameNode完全关闭，否则目前将始终返回成功。
 </li>
 
 ### **负载均衡器设置** ###
 
 如果在Load Balancer（例如[Azure][]或[AWS][]）后面运行一组NameNode 并希望Load Balancer指向活动NN，则可以使用/ isActive HTTP端点作为运行状况探测。如果NN处于活动HA状态，则 http://NN\_HOSTNAME/isActive 将返回200状态代码响应，否则返回405。
 
 ## 自动故障转移 ##
 
 ### **介绍** ###
 
 以上部分介绍了如何配置手动故障转移。在该模式下，即使活动节点发生故障，系统也不会自动触发从活动状态到备用NameNode的故障转移。本节介绍如何配置和部署自动故障转移。
 
 ### **组件** ###
 
 自动故障转移为HDFS部署添加了两个新组件：ZooKeeper quorum 和ZKFailoverController进程（缩写为ZKFC）。
 
 Apache ZooKeeper是一种高可用性服务，用于维护少量协调数据，通知客户端该数据的更改以及监视客户端是否存在故障。自动HDFS故障转移的实现依赖于ZooKeeper来实现以下功能：
 
 * **故障检测** - 集群中的每个NameNode计算机都在ZooKeeper中维护一个持久会话。如果计算机崩溃，ZooKeeper会话将过期，通知其他NameNode应该触发故障转移。
 * **Active NameNode选举** - ZooKeeper提供了一种简单的机制，可以将节点专门选为活动节点。如果当前活动的NameNode崩溃，则另一个节点可能在ZooKeeper中采用特殊的独占锁，指示它应该成为下一个活动的。
 
 ZKFailoverController（ZKFC）是一个新组件，它是一个ZooKeeper客户端，它还监视和管理NameNode的状态。运行NameNode的每台机器也运行ZKFC，ZKFC负责：
 
 * **运行状况监视** - ZKFC定期使用运行状况检查命令对其本地NameNode进行ping操作。只要NameNode及时响应健康状态，ZKFC就认为该节点是健康的。如果节点已崩溃，冻结或以其他方式进入不健康状态，则运行状况监视器会将其标记为运行状况不佳。
 * **ZooKeeper会话管理** - 当本地NameNode运行正常时，ZKFC在ZooKeeper中保持会话打开。如果本地NameNode处于活动状态，它还拥有一个特殊的“锁定”znode。此锁使用ZooKeeper对“短暂”节点的支持; 如果会话过期，将自动删除锁定节点。
 * **基于ZooKeeper的选举** - 如果本地NameNode是健康的，并且ZKFC发现没有其他节点当前持有锁znode，它将自己尝试获取锁。如果成功，那么它“赢得了选举”，并负责运行故障转移以使其本地NameNode处于活动状态。故障转移过程类似于上述手动故障转移：首先，必要时对先前的活动进行隔离，然后本地NameNode转换为活动状态。
 
 有关自动故障转移设计的更多详细信息，请参阅Apache HDFS JIRA上附加到HDFS-2185的设计文档。
 
 ### **部署ZooKeeper** ###
 
 在典型部署中，ZooKeeper守护程序配置为在三个或五个节点上运行。由于ZooKeeper本身具有轻量级资源要求，因此可以在与HDFS NameNode和备用节点相同的硬件上并置ZooKeeper节点。许多运营商选择在与YARN ResourceManager相同的节点上部署第三个ZooKeeper进程。建议将ZooKeeper节点配置为将数据存储在与HDFS元数据不同的磁盘驱动器上，以获得最佳性能和隔离。
 
 ZooKeeper的设置超出了本文档的范围。我们假设您已经设置了在三个或更多节点上运行的ZooKeeper集群，并通过使用ZK 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服务的主机端口对。
 
 与本文档前面所述的参数一样，这些设置可以通过使用名称服务ID后缀配置密钥来基于每个名称进行配置。例如，在启用了联合的群集中，您可以通过设置dfs.ha.automatic-failover.enabled.my-nameservice-id，仅为其中一个名称服务显式启用自动故障转移。
 
 还可以设置其他几个配置参数来控制自动故障转移的行为; 但是，大多数安装都不需要它们。有关详细信息，请参阅配置密钥特定文档。
 
 ### **在ZooKeeper中初始化HA状态** ###
 
 添加配置密钥后，下一步是在ZooKeeper中初始化所需的状态。您可以通过从其中一个NameNode主机运行以下命令来执行此操作。
 
 [hdfs]$ $HADOOP_HOME/bin/hdfs zkfc -formatZK
 
 这将在ZooKeeper中创建一个znode，其中自动故障转移系统存储其数据。
 
 ### **使用start-dfs.sh启动集群** ###
 
 由于配置中已启用自动故障转移，因此start-dfs.sh脚本现在将在运行NameNode的任何计算机上自动启动ZKFC守护程序。当ZKFC启动时，它们将自动选择其中一个NameNode变为活动状态。
 
 ### **手动启动集群** ###
 
 如果手动管理群集上的服务，则需要在运行NameNode的每台计算机上手动启动zkfc守护程序。您可以通过运行以下命令来启动守护程序：
 
 [hdfs]$ $HADOOP_HOME/bin/hdfs --daemon 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>
 
 请注意这些值中的“@”字符 - 这指定配置不是内联的，而是指向磁盘上的文件。身份验证信息也可以通过CredentialProvider读取（请参阅hadoop-common项目中的CredentialProviderAPI指南）。
 
 第一个配置的文件指定ZooKeeper身份验证列表，格式与ZK CLI使用的格式相同。例如，您可以指定以下内容：
 
 digest:hdfs-zkfcs:mypassword
 
 ...其中hdfs-zkfcs是ZooKeeper的唯一用户名，mypassword是一些用作密码的唯一字符串。
 
 接下来，使用如下命令生成与此身份验证对应的ZooKeeper ACL：
 
 [hdfs]$ 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 <pid of NN> 来模拟JVM崩溃。或者，您可以重启机器或拔掉网络接口以模拟不同类型的停机。触发您希望测试的中断后，另一个NameNode应在几秒钟内自动激活。检测故障并触发故障转移所需的时间取决于ha.zookeeper.session-timeout.ms的配置，但默认为5秒。
 
 如果测试不成功，则可能是配置错误。检查日志以查找zkfc守护程序以及NameNode守护程序，以便进一步诊断问题。
 
 ## 自动故障转移常见问题 ##
 
 * **以任何特定顺序启动ZKFC和NameNode守护进程是否重要？**
 
 在任何给定节点上，您可以在其对应的NameNode之前或之后启动ZKFC。
 </li>
 <li>
 我应该采取哪些额外的监测措施？
 
 您应该在运行NameNode的每个主机上添加监视，以确保ZKFC仍在运行。例如，在某些类型的ZooKeeper故障中，ZKFC可能会意外退出，应重新启动以确保系统已准备好进行自动故障转移。
 
 此外，您应该监视ZooKeeper仲裁中的每个服务器。如果ZooKeeper崩溃，则自动故障转移将不起作用。
 </li>
 <li>
 如果ZooKeeper出现故障会怎样？
 
 如果ZooKeeper集群崩溃，则不会触发自动故障转移。但是，HDFS将继续运行而不会产生任何影响。重新启动ZooKeeper时，HDFS将重新连接，没有任何问题。
 </li>
 <li>
 我可以将我的一个NameNode指定为主要/首选吗？
 
 不。目前，这不受支持。无论哪个NameNode首先启动都将变为活动状态。您可以选择以特定顺序启动集群，以便首选节点启动。
 </li>
 <li>
 如何配置自动故障转移时启动手动故障转移？
 
 即使配置了自动故障转移，您也可以使用相同的hdfs haadmin命令启动手动故障转移。它将执行协调的故障转移。
 </li>
 
 ## 启用HA的HDFS升级/终结/回滚 ##
 
 在HDFS版本之间移动时，有时可以简单地安装较新的软件并重新启动集群。但是，有时升级正在运行的HDFS版本可能需要更改磁盘数据。在这种情况下，必须在安装新软件后使用HDFS Upgrade / Finalize / Rollback工具。此过程在HA环境中变得更加复杂，因为NN依赖的磁盘上元数据按定义分布，在该对中的两个HA NN上，以及在使用QJM的情况下的JournalNodes上。共享编辑存储。本文档部分介绍了在HA设置中使用HDFS   Upgrade/Finalize/Rollback  功能的过程。
 
 **要执行HA升级**，操作员必须执行以下操作：
 
 1. 正常关闭所有NN，并安装较新的软件。
 2. 启动所有JN。请注意，这是**至关重要的**，所有的JNS执行升级，回滚或完成操作时运行。如果在运行任何这些操作时任何JN出现故障，操作将失败。
 3. 使用'-upgrade'标志启动其中一个NN。
 4. 一开始，此NN将不会像HA设置中那样正常进入待机状态。相反，此NN将立即进入活动状态，执行其本地存储目录的升级，并执行共享编辑日志的升级。
 5. 此时，HA对中的其他NN将与升级的NN不同步。为了使其恢复同步并再次具有高可用性设置，您应该通过使用'-bootstrapStandby'标志运行NN来重新引导此NameNode 。使用'-upgrade'标志启动第二个NN是错误的。
 
 请注意，如果您想在最终确定或回滚升级之前重新启动NameNode，则应该正常启动NN，即没有任何特殊的启动标志。
 
 **要查询升级状态**，操作员将使用\`hdfs dfsadmin -upgrade query'命令，而至少有一个NN正在运行。对于每个NN，该命令将返回NN升级过程是否已完成。
 
 **要完成HA升级**，操作员将在NN运行且其中一个处于活动状态时使用\`hdfs dfsadmin -finalizeUpgrade'命令。发生这种情况时的活动NN将执行共享日志的最终确定，并且其本地存储目录包含先前FS状态的NN将删除其本地状态。
 
 **要执行**升级**回滚**，应首先关闭两个NN。操作员应在NN上执行回滚命令，在NN上启动升级过程，该过程将在那里的本地目录以及共享日志（NFS或JN）上执行回滚。之后，应启动此NN，操作员应在另一个NN上运行\`-bootstrapStandby'，以使两个NN与此回滚文件系统状态同步。
 
  
 
  
 
  
 
  
 
 原文链接: [https://hadoop.apache.org/docs/r3.2.0/][https_hadoop.apache.org_docs_r3.2.0]

[Link 1]: https://hadoop.apache.org/docs/r3.2.0/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithNFS.html
[machine1.example.com_8020]: http://machine1.example.com:8020
[machine2.example.com_8020]: http://machine2.example.com:8020
[machine3.example.com_8020]: http://machine3.example.com:8020
[machine1.example.com_9870]: http://machine1.example.com:9870
[machine2.example.com_9870]: http://machine2.example.com:9870
[machine3.example.com_9870]: http://machine3.example.com:9870
[node2.example.com_8485]: http://node2.example.com:8485
[node3.example.com_8485_mycluster]: http://node3.example.com:8485/mycluster
[Azure]: https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-custom-probe-overview
[AWS]: https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-healthchecks.html
[https_hadoop.apache.org_docs_r3.2.0]: https://hadoop.apache.org/docs/r3.2.0/