Hadoop 文档

General

Common

HDFS

MapReduce

MapReduce REST APIs

YARN

YARN REST APIs

YARN Service

Submarine

Hadoop Compatible File Systems

Auth

Tools

Reference

Configuration

目的

本指南概述了HDFS高可用性(HA)功能以及如何使用NFS为NameNodes所需的共享存储设备配置和管理HA HDFS群集。

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

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

本指南讨论如何使用共享的NFS目录配置和使用HDFS HA,以在活动和备用NameNode之间共享编辑日志。有关如何使用Quorum Journal Manager(而不是NFS)配置HDFS HA的信息,请参阅此替代指南。

背景

在Hadoop 2.0.0之前,NameNode是HDFS集群中的单点故障(SPOF)。每个群集只有一个NameNode,并且如果该计算机或进程不可用,则整个群集将不可用,直到NameNode重新启动或在单独的计算机上启动。

这从两个方面影响了HDFS群集的总可用性:

  • 如果发生意外事件(例如机器崩溃),则在操作员重新启动NameNode之前,群集将不可用。

  • 计划内的维护事件,例如NameNode计算机上的软件或硬件升级,将导致群集停机时间的延长。

HDFS高可用性功能通过提供以下选项来解决上述问题:在具有热备用的主动/被动配置中,可以在同一集群中运行两个(或更多,从Hadoop 3.0.0起)冗余NameNode。这可以在计算机崩溃的情况下快速故障转移到新的NameNode,或出于计划维护的目的由管理员发起的正常故障转移。

建筑

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

为了使备用节点保持其状态与活动节点同步,当前的实现要求这些节点有权访问共享存储设备上的目录(例如,来自NAS的NFS挂载)。在将来的版本中,可能会放宽此限制。

当活动节点执行任何名称空间修改时,它会持久地将修改记录记录到存储在共享目录中的编辑日志文件中。备用节点一直在监视此目录中的编辑,并且在看到编辑时,会将它们应用于自己的名称空间。发生故障转移时,备用服务器将确保在将其自身升级为活动状态之前,已从共享存储中读取了所有编辑内容。这样可确保在发生故障转移之前,名称空间状态已完全同步。

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

对于HA群集的正确操作至关重要,一次只能有一个NameNode处于活动状态。否则,名称空间状态将在两者之间迅速分散,从而有数据丢失或其他不正确结果的风险。为了确保此属性并防止所谓的“裂脑方案”,管理员必须为共享存储配置至少一种防护方法。在故障转移期间,如果无法验证先前的活动节点已放弃其活动状态,则隔离过程负责切断先前的活动节点对共享编辑存储的访问。这样可以防止对名称空间进行任何进一步的编辑,从而使新的Active可以安全地进行故障转移。

硬件资源

为了部署高可用性群集,您应该准备以下内容:

  • NameNode计算机 -在其上运行“活动”和“备用” NameNode的计算机应具有彼此等效的硬件,以及与在非HA群集中使用的硬件相同的硬件。

  • 共享存储 -您将需要具有NameNode机器具有读/写访问权限的共享目录。通常,这是一个支持NFS的远程文件管理器,并安装在每个NameNode计算机上。当前仅支持一个共享的edits目录。因此,系统的可用性受到此共享编辑目录的可用性的限制,因此,为了消除所有单点故障,共享编辑目录需要冗余。具体来说,有到存储的多个网络路径,以及存储本身的冗余(磁盘,网络和电源)。因此,建议共享存储服务器是高质量的专用NAS设备,而不是简单的Linux服务器。

请注意,在高可用性群集中,备用名称节点也执行名称空间状态的检查点,因此不必在高可用性群集中运行辅助名称节点,检查点节点或备份节点。实际上,这样做将是一个错误。这还允许重新配置未启用HA的HDFS群集的用户启用HA,以重用他们先前专用于次要NameNode的硬件。

部署方式

配置概述

与联合身份验证配置类似,高可用性配置向后兼容,并允许现有的单个NameNode配置无需更改即可工作。设计新的配置,以便群集中的所有节点都可以具有相同的配置,而无需根据节点的类型将不同的配置文件部署到不同的计算机。

像HDFS联合身份验证一样,HA群集重用名称服务ID来标识实际上可能由多个HA NameNode组成的单个HDFS实例。此外,HA还添加了一个名为NameNode ID的新抽象。群集中的每个不同的NameNode都有一个不同的NameNode ID来区分它。为了支持所有NameNode的单个配置文件,相关的配置参数后缀有nameservice IDNameNode ID

配置细节

要配置HA NameNode,必须将多个配置选项添加到hdfs-site.xml配置文件中。

设置这些配置的顺序并不重要,但是为dfs.nameservicesdfs.ha.namenodes。[nameservice ID]选择的值将确定后面的密钥。因此,您应该在设置其余配置选项之前决定这些值。

  • dfs.nameservices-此新名称服务的逻辑名称

    选择此名称服务的逻辑名称,例如“ mycluster”,然后将此逻辑名称用作此配置选项的值。您选择的名称是任意的。它既可以用于配置,也可以用作集群中绝对HDFS路径的权限组件。

    注意:如果您还使用HDFS Federation,则此配置设置还应包括其他名称服务(HA或其他)的列表,以逗号分隔的列表。

    <属性>
      <name> dfs.nameservices </ name>
      <value> mycluster </ value>
    </ property>
    
  • dfs.ha.namenodes。[nameservice ID] - 名称服务中每个NameNode的唯一标识符

    使用逗号分隔的NameNode ID列表进行配置。DataNode将使用它来确定集群中的所有NameNode。例如,如果您以前使用“ mycluster”作为名称服务ID,并且想要使用“ nn1”,“ nn2”和“ nn3”作为NameNode的各个ID,则可以这样配置:

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

    注意:用于HA的NameNode的最小数量为2,但是您可以配置更多。由于通信开销,建议不要超过5个(建议使用3个NameNode)。

  • dfs.namenode.rpc-address。[名称服务ID]。[名称节点ID] -每个NameNode监听的标准RPC地址

    对于两个先前配置的NameNode ID,请设置NameNode进程的完整地址和IPC端口。请注意,这将导致两个单独的配置选项。例如:

    <属性>
      <name> dfs.namenode.rpc-address.mycluster.nn1 </ name>
      <value> machine1.example.com:8020 </ value>
    </ property>
    <属性>
      <name> dfs.namenode.rpc-address.mycluster.nn2 </ name>
      <value> machine2.example.com:8020 </ value>
    </ property>
    <属性>
      <name> dfs.namenode.rpc-address.mycluster.nn3 </ name>
      <value> machine3.example.com:8020 </ value>
    </ property>
    

    注意:如果需要,您可以类似地配置“ servicerpc-address ”设置。

  • dfs.namenode.http-address。[名称服务ID]。[名称节点ID] -每个NameNode监听的标准HTTP地址

    与上面的rpc-address类似,为两个NameNode的HTTP服务器设置地址以进行侦听。例如:

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

    注意:如果启用了Hadoop的安全性功能,则还应该类似地为每个NameNode 设置https-地址

  • dfs.namenode.shared.edits.dir-共享存储目录的位置

    在这里,可以配置到远程共享编辑目录的路径,备用NameNode可以使用该目录来保持活动NameNode所做的所有文件系统的最新更新。您只应配置这些目录之一。该目录应在NameNode机器上左右安装。此设置的值应该是NameNode计算机上该目录的绝对路径。例如:

    <属性>
      <name> dfs.namenode.shared.edits.dir </ name>
      <value>文件:/// mnt / filer1 / dfs / ha-name-dir-shared </ value>
    </ property>
    
  • dfs.client.failover.proxy.provider。[名称服务ID]-HDFS客户端用于联系活动NameNode的Java类

    配置Java类的名称,DFS客户端将使用该Java类来确定哪个NameNode是当前的Active,从而确定哪个NameNode当前正在服务于客户端请求。Hadoop当前随附的两个实现是ConfiguredFailoverProxyProviderRequestHedgingProxyProvider(对于第一个调用,它们同时调用所有名称节点以确定活动的名称节点,并在后续请求时调用活动的名称节点,直到发生故障转移),因此除非使用自定义代理提供程序,否则请使用其中之一。

    <属性>
      <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处于Active状态。因此,在故障转移期间,在将另一个NameNode转换为Active状态之前,我们首先要确保Active NameNode处于Standby状态或进程已终止。为此,您必须配置至少一种防护方法。它们被配置为以回车符分隔的列表,将按顺序尝试该列表,直到指示防护成功为止。Hadoop附带两种方法:shellsshfence。有关实现自己的自定义防护方法的信息,请参见org.apache.hadoop.ha.NodeFencer类。


    sshfence -SSH到Active NameNode并终止进程

    sshfence选项SSHes到目标节点,然后通过定影杀该服务的TCP端口上侦听的过程。为了使该防护选项起作用,它必须能够在不提供密码的情况下SSH到目标节点。因此,还必须配置dfs.ha.fencing.ssh.private-key-files选项,这是一个用逗号分隔的SSH私钥文件列表。例如:

        <属性>
          <name> dfs.ha.fencing.methods </ name>
          <value> sshfence </ value>
        </ property>
    
        <属性>
          <name> dfs.ha.fencing.ssh.private-key-files </ name>
          <value> /home/exampleuser/.ssh/id_rsa </ value>
        </ property>
    

    (可选)可以配置非标准用户名或端口以执行SSH。您还可以为SSH配置一个以毫秒为单位的超时,此后该防护方法将被视为失败。可以这样配置:

    <属性>
      <name> dfs.ha.fencing.methods </ name>
      <value> sshfence([[[用户名] [:端口]])</ value>
    </ property>
    <属性>
      <name> dfs.ha.fencing.ssh.connect-timeout </ name>
      <value> 30000 </ value>
    </ property>
    

    shell-运行一个任意的shell命令来隔离Active NameNode

    所述击剑方法运行的任意外壳命令。可以这样配置:

    <属性>
      <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命令本身中用作替代。例如:

    <属性>
      <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脚本本身中实现超时(例如,通过分叉subshel​​l在几秒钟内杀死其父级)。


  • fs.defaultFS-当未指定任何路径时,Hadoop FS客户端使用的默认路径前缀

    (可选)您现在可以配置Hadoop客户端的默认路径,以使用新的启用HA的逻辑URI。如果您之前使用“ mycluster”作为名称服务ID,则它将是所有HDFS路径的授权部分的值。可以这样配置,在您的core-site.xml文件中:

    <属性>
      <名称> fs.defaultFS </名称>
      <value> hdfs:// mycluster </ value>
    </ property>
    

部署细节

设置完所有必需的配置选项后,必须首先同步两个HA NameNode的磁盘元数据。

  • 如果要设置新的HDFS群集,则应首先在其中一个NameNode上运行format命令(hdfs namenode -format)。

  • 如果您已经格式化了NameNode,或者正在将未启用HA的群集转换为启用HA,那么现在应该通过运行命令“ hdfs namenode-将NameNode元数据目录的内容复制到其他未格式化的NameNode。未经格式化的NameNode上的bootstrapStandby ”。运行此命令还将确保共享的edits目录(由dfs.namenode.shared.edits.dir配置)包含足以启动两个NameNode的编辑事务。

  • 如果要将非HA NameNode转换为HA,则应运行命令“ hdfs -initializeSharedEdits ”,该命令将使用本地NameNode edits目录中的edits数据初始化共享edits目录。

此时,您可以像通常启动NameNode一样启动所有HA NameNode。

您可以通过浏览到它们的已配置HTTP地址来分别访问每个NameNode的网页。您应该注意,配置的地址旁边将是NameNode的HA状态(“待机”或“活动”)。每当HA NameNode启动时,它最初都处于Standby状态。

行政命令

现在您的HA NameNodes已配置并启动,您将可以访问一些其他命令来管理HA HDFS群集。具体来说,您应该熟悉“ hdfs haadmin ”命令的所有子命令。在不使用任何其他参数的情况下运行此命令将显示以下用法信息:

用法:DFSHAAdmin [-ns <nameserviceId>]
    [-transitionToActive <serviceId>]
    [-transitionToStandby <serviceId>]
    [-故障转移[--forcefence] [--forceactive] <serviceId> <serviceId>]
    [-getServiceState <serviceId>]
    [-getAllServiceState]
    [-checkHealth <serviceId>]
    [-帮助<命令>]

本指南描述了每个子命令的高级用法。有关每个子命令的特定用法信息,应运行“ hdfs haadmin -help <命令 >”。

  • transitionToActivetransitionToStandby-将给定NameNode的状态转换为Active或Standby

    这些子命令使给定的NameNode分别转换为Active或Standby状态。这些命令不会尝试执行任何防护,因此应很少使用。相反,几乎应该总是喜欢使用“ hdfs haadmin -failover ”子命令。

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

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

  • getServiceState-确定给定的NameNode是活动的还是备用的

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

  • getAllServiceState-返回所有NameNode的状态

    连接到已配置的NameNode以确定当前状态,并在STDOUT上适当打印“待机”或“活动”。

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

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

    注意:这尚未实现,除非给定的NameNode完全关闭,否则当前将始终返回成功。

自动故障转移

介绍

以上各节描述了如何配置手动故障转移。在这种模式下,即使活动节点发生故障,系统也不会自动触发从活动NameNode到备用NameNode的故障转移。本节介绍如何配置和部署自动故障转移。

组件

自动故障转移为HDFS部署添加了两个新组件:ZooKeeper仲裁和ZKFailoverController进程(缩写为ZKFC)。

Apache ZooKeeper是一项高可用性服务,用于维护少量的协调数据,将数据中的更改通知客户端并监视客户端的故障。HDFS自动故障转移的实现依赖ZooKeeper进行以下操作:

  • 故障检测 -群集中的每个NameNode计算机都在ZooKeeper中维护一个持久性会话。如果计算机崩溃,则ZooKeeper会话将终止,通知另一个NameNode应触发故障转移。

  • 活动的NameNode选举 -ZooKeeper提供了一种简单的机制来专门选举一个节点为活动的节点。如果当前活动的NameNode崩溃,则另一个节点可能会在ZooKeeper中采取特殊的排他锁,指示它应成为下一个活动的NameNode。

ZKFailoverController(ZKFC)是一个新组件,它是一个ZooKeeper客户端,它还监视和管理NameNode的状态。运行NameNode的每台机器还运行ZKFC,该ZKFC负责:

  • 运行状况监视 -ZKFC使用运行状况检查命令定期ping其本地NameNode。只要NameNode以健康状态及时响应,ZKFC就会认为该节点是健康的。如果节点崩溃,冻结或以其他方式进入不正常状态,则运行状况监视器将其标记为不正常。

  • ZooKeeper会话管理 -当本地NameNode运行状况良好时,ZKFC会在ZooKeeper中保持打开的会话。如果本地NameNode处于活动状态,则它还将持有一个特殊的“锁定” znode。该锁使用ZooKeeper对“临时”节点的支持。如果会话到期,则锁定节点将被自动删除。

  • 基于ZooKeeper的选举 -如果本地NameNode运行状况良好,并且ZKFC看到当前没有其他节点持有锁znode,则它本身将尝试获取该锁。如果成功,则它“赢得了选举”,并负责运行故障转移以使其本地NameNode处于活动状态。故障转移过程类似于上述的手动故障转移:首先,如有必要,将先前的活动节点隔离,然后将本地NameNode转换为活动状态。

有关自动故障转移设计的更多详细信息,请参阅Apache HDFS JIRA上HDFS-2185附带的设计文档。

部署ZooKeeper

在典型的部署中,ZooKeeper守护程序被配置为在三个或五个节点上运行。由于ZooKeeper本身对光资源有要求,因此可以将ZooKeeper节点并置在与HDFS NameNode和Standby Node相同的硬件上。许多操作员选择将第三个ZooKeeper进程与YARN ResourceManager部署在同一节点上。建议将ZooKeeper节点配置为将其数据与HDFS元数据存储在单独的磁盘驱动器上,以实现最佳性能和隔离。

ZooKeeper的设置超出了本文档的范围。我们将假定您已经设置了在三个或更多节点上运行的ZooKeeper集群,并已通过使用ZK CLI进行连接来验证其正确的操作。

在你开始之前

在开始配置自动故障转移之前,应关闭集群。在群集运行时,当前无法从手动故障转移设置过渡到自动故障转移设置。

配置自动故障转移

自动故障转移的配置需要在配置中添加两个新参数。在您的hdfs-site.xml文件中,添加:

 <属性>
   <name> dfs.ha.automatic-failover.enabled </ name>
   <value> true </ value>
 </ property>

这指定应为自动故障转移设置群集。在您的core-site.xml文件中,添加:

 <属性>
   <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 / zkfc -formatZK

这将在ZooKeeper中创建一个znode,自动故障转移系统将在其中存储其数据。

使用start-dfs.sh启动集群

由于已在配置中启用了自动故障转移,因此start-dfs.sh脚本现在将在任何运行NameNode的计算机上自动启动ZKFC守护程序。ZKFC启动时,它们将自动选择一个NameNode激活。

手动启动集群

如果您手动管理集群上的服务,则需要在运行NameNode的每台计算机上手动启动zkfc守护程序。您可以通过运行以下命令启动守护程序:

[hdfs] $ $ HADOOP_HOME / bin / hdfs --daemon启动zkfc

确保对ZooKeeper的访问

如果运行的是安全群集,则可能需要确保ZooKeeper中存储的信息也受到保护。这可以防止恶意客户端修改ZooKeeper中的元数据或潜在地触发错误的故障转移。

为了保护ZooKeeper中的信息,首先将以下内容添加到您的core-site.xml文件中:

 <属性>
   <name> ha.zookeeper.auth </ name>
   <value> @ / path / to / zk-auth.txt </ value>
 </ property>
 <属性>
   <name> ha.zookeeper.acl </ name>
   <value> @ / path / to / zk-acl.txt </ value>
 </ property>

请注意这些值中的'@'字符-这表明配置不是内联的,而是指向磁盘上的文件。身份验证信息也可以通过CredentialProvider读取(请参阅hadoop-common项目中的CredentialProviderAPI指南)。

第一个配置的文件指定ZooKeeper身份验证的列表,格式与ZK CLI使用的格式相同。例如,您可以指定以下内容:

摘要: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
输出:hdfs-zkfcs:mypassword-> hdfs-zkfcs:P / OQvnYyU / nF / mGYvB / xurX8dYs =

将“->”字符串之后的输出部分复制并粘贴到文件zk-acls.txt中,该文件的前缀为“ 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 <NN的pid >模拟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命令启动手动故障转移。它将执行协调的故障转移。