目的

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

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

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

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

背景

在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或其他，以逗号分隔列表。

    <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，则可以这样配置：

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

    注意： HA的NameNode最小数量为2，但您可以配置更多。由于通信开销，建议不要超过5 - 推荐3个NameNodes。

  • 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>
<property>
  <name>dfs.namenode.rpc-address.mycluster.nn3</name>
  <value>machine3.example.com:8020</value>
</property>

    注意：如果您愿意，可以类似地配置“ servicerpc-address ”设置。

  • dfs.namenode.http-address。[nameservice ID]。[name node ID] - 要监听的每个NameNode的完全限定HTTP地址

    与上面的rpc-address类似，设置两个NameNodes的HTTP服务器的地址以进行侦听。例如：

    <property>
  <name>dfs.namenode.http-address.mycluster.nn1</name>
  <value>machine1.example.com:9870</value>
</property>
<property>
  <name>dfs.namenode.http-address.mycluster.nn2</name>
  <value>machine2.example.com:9870</value>
</property>
<property>
  <name>dfs.namenode.http-address.mycluster.nn3</name>
  <value>machine3.example.com:9870</value>
</property>

    注意：如果启用了Hadoop的安全功能，则还应为每个NameNode 设置https-address。

  • 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）：

    <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客户端将使用该名称来确定哪个NameNode是当前的Active，以及哪个NameNode当前正在为客户端请求提供服务。目前Hadoop附带的两个实现是ConfiguredFailoverProxyProvider和RequestHedgingProxyProvider（对于第一次调用，它同时调用所有名称节点以确定活动的名称，并在后续请求中调用活动的名称节点直到发生故障转移），所以除非您使用自定义代理提供程序，否则请使用其中一个。例如：

    <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类。

    sshfence - SSH到Active NameNode并终止进程

    该sshfence选项SSHes到目标节点，并使用定影杀死进程监听服务的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 fencing 方法运行的任意外壳命令。它可能配置如下：

        <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。

    此外，还提供了以下涉及要隔离的目标节点的变量：

      
    $ target_host要隔离的节点的主机名
    $ target_port要隔离的节点的IPC端口
    $ TARGET_ADDRESS以上两种，合并为主机：端口
    $ target_nameserviceid要隔离的NN的名称服务ID
    $ target_namenodeid要隔离的NN的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以在几秒钟内终止它的父节点）。

  • 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使用的edits 和其他本地状态。您只能使用单个路径进行此配置。通过运行多个单独的JournalNode或在本地连接的RAID阵列上配置此目录，可以提供此数据的冗余。例如：

    <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 ”子命令。

  • 故障转移 - 在两个NameNode之间启动故障转移

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

  • getServiceState - 确定给定的NameNode是Active还是Standby

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

  • getAllServiceState - 返回所有NameNode的状态

    连接到已配置的NameNodes以确定当前状态，适当地将“待机”或“活动”打印到STDOUT。

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

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

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

负载均衡器设置

如果在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。

  • 我应该采取哪些额外的监测措施？

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

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

  • 如果ZooKeeper出现故障会怎样？

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

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

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

  • 如何配置自动故障转移时启动手动故障转移？

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

启用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/

Logo
向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

avatar 云原生

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

avatar 云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...

avatar 云原生