目的

本指南概述了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全生命周期开发者社区

更多推荐

沃云统一开发平台介绍

沃云集成平台研发平台介绍1.平台优势2.平台原理3.研发平台使用方法4.遇到的问题5.现阶段实现的功能6.后续需要补充的功能和优化内容研发平台介绍1.平台优势解决孤岛式应用，实现能力共享；现有系统框架过于复杂，跨系统业务处理成本居高不下，协同服务共享，降低运维成本；提高项目应用资源监控能力，改善资源利用率；业务微服务化，快速发布、快速部署，快速响应业务需求变化；沃云平台不仅提供了自动化的、可快速部

avatar 云原生

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

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

avatar 云原生

基于docker的test-containers环境百宝箱

笔者语录： 我开了个公众号【Java你我他】，欢迎大家关注。  在很多时候，程序猿们更关注代码本身，而不愿意把时间花费在环境搭建上，这也是Docker变得越来越受欢迎的原因之一。test-containe是Docker生态圈中的一颗新星，其 主要针对测试领域、背靠Docker实现环境百宝箱功能。  test-containers： 你要的环境，我都有~  假设我们现在需要一个redis-clust

avatar 云原生