HDFS HA

翻译: http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html
版本: 2.9.0

目的

本指南介绍基于Quorum Journal Manager (QJM)的 高可用性(HA)以及如何配置和管理HA HDFS群集。

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

注意:使用仲裁日记管理器QJM或常规共享存储

本指南讨论如何使用仲裁日志管理器(QJM)配置HDFS HA。有关如何使用NFS配置HDFS HA而不是QJM的信息,请参阅此替代指南。

背景

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

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

  • 在计划外事件(例如机器崩溃)的情况下,直到操作员重新启动NameNode后,群集才可用。

  • 计划的维护事件(如NameNode计算机上的软件或硬件升级),集群在维护时间内都不可用。

HDFS高可用性功能通过在同一集群中运行两个NameNode来实现,冗余NameNode具有热备功能。这允许在计算机崩溃的情况下快速故障转移到新的NameNode,或者为计划维护目的而进行正常的管理员启动的故障转移。

架构

在典型的HA群集中,将两台独立的机器配置为NameNode。在任何时候,只有一个NameNodes处于Active状态,另一个处于Standby状态。活动NameNode负责群集中的所有客户端操作,而Standby仅充当从服务器,并保持同步状态时刻准备在必要时提供快速故障转移。

为了使备用节点保持其与主动节点的状态同步,两个节点都与一组称为“日志节点”(JN)的独立守护进程进行通信。当活动节点执行任何名称空间修改时,它会将修改记录持久记录到大多数的JN中。备用节点能够读取来自JN的编辑日志,并不断监视更改编辑日志。当备用节点看到编辑时,它将它们应用到自己的名称空间。如果发生故障转移,备用服务器将确保它在将自己提升为活动状态之前已经从JounalNodes中读取所有编辑。这确保了在故障转移发生之前命名空间状态已完全同步。

为了提供快速故障切换,备用节点还需要有关于集群中块的位置的最新信息。为了实现这一点,DataNode配置了两个NameNode的位置,并将块位置信息和心跳发送到两者。

一次只有一个NameNode处于活动状态对HA集群至关重要。否则,命名空间状态将很快在两者之间发生分歧,从而可能导致数据丢失或其他不正确的结果。为了防止所谓的“裂脑场景”,JournalNodes将永远只允许一个NameNode成为一个writer。在故障转移期间,要成为活动状态的NameNode将简单地接管写入JournalNodes的角色,这将有效地防止其他NameNode继续处于活动状态,从而允许新的活动安全地进行故障转移。

硬件资源

为了部署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。事实上,运行这些服务会出现错误。因此允许将原来准备专用于Secondary NameNode的硬件用于部署其他服务。

部署

配置概述

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

和HDFS联合一样,HA集群重用 nameservice ID 来标识实际上可能由多个HA NameNode组成的单个HDFS实例。另外,HA中添加了名为 NameNode ID 的新抽象。群集中每个不同的NameNode都有一个不同的NameNode ID来区分它。为了支持在单个配置文件配置所有NameNode,请在相关配置参数使用后缀nameservice ID以及NameNode ID

配置细节

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

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

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

    为此名称服务选择一个逻辑名称,例如“mycluster”,并使用此逻辑名称作为此配置选项的值。你选择的名字是任意的。它将用于配置,当日也可直接使用HDFS的绝对路径。

    注意:如果您在使用HDFS联合(有多个实例),则此配置还应该包括其他名称服务(HA或其他)的列表(作为逗号分隔列表)。

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

    配置一个由逗号分隔的NameNode ID列表。这将由DataNode用于确定群集中的所有NameNode。例如,如果您使用“mycluster”作为名称服务标识,并且您希望使用“nn1”和“nn2”作为NameNodes的单个标识,则可以这样配置它:

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

注意:目前,每个名称服务最多只能配置两个NameNode。

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

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

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

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

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

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

  • dfs.namenode.shared.edits.dir - 标识NameNode将写入/读取编辑的JN组的URI

该配置提供JournalNode的地址,由Active NameNode编写并由Standby NameNode读取,使用Standby保持与Active NameNode所做的所有文件系统更改的一致最新状态。尽管您必须指定多个JournalNode地址,但您应该只配置其中一个URI。URI的格式应为:qjournal://host1:port1;host2:port2;host3:port3/journalId 。日志ID是此名称服务的唯一标识符,它允许一组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类

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

<property>
  <name>dfs.client.failover.proxy.provider.mycluster</name>
  <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>
  • dfs.ha.fencing.methods - 在故障转移期间将用于遏制活动NameNode的脚本或Java类的列表

    系统的正确性是基于如下期望的,即在任何给定时间只有一个NameNode处于活动状态。重要的是,在使用仲裁日志管理器时,只有一个NameNode将被允许写入JournalNodes,因此不会破坏裂脑场景中的文件系统元数据。但是,当发生故障转移时,前面的Active NameNode仍可能向客户端提供读取请求,这可能会过时,直到NameNode在尝试写入JournalNodes时关闭。由于这个原因,即使在使用仲裁日志管理器时,仍然需要配置一些屏蔽方法。但是,为了在防护机制发生故障的情况下提高系统的可用性,建议配置一种防护方法,该防护方法可保证作为列表中的最后一个防护方法返回成功。请注意,如果您选择不使用实际的防护方法,则仍必须为此设置配置一些内容,例如 “shell(/bin/true)” 。

    故障切换期间使用的防护方法将配置为一个以回车分隔的列表,该列表将按顺序尝试,直到指示防护成功为止。Hadoop提供了两种方法:shellsshfence。有关实现自己的自定义fencing方法的信息,请参阅org.apache.hadoop.ha.NodeFencer类。


    sshfence - SSH到活动NameNode并杀死进程

    sshfence选项SSHes到目标节点,并使用fuser杀死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命令来隔离活动NameNode

shell 隔离方法运行的任意shell命令。它可以像这样配置:

    <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

此外,还提供了以下指向要防护的目标节点的变量:


图片.png

这些环境变量也可以用作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”作为名称服务标识,则这将是所有HDFS路径的权限部分的值。这可能是这样配置的,在你的core-site.xml文件中:

<property>
  <name>fs.defaultFS</name>
  <value>hdfs://mycluster</value>
</property>
  • dfs.journalnode.edits.dir - JournalNode守护进程用于存储其本地状态的路径

    这是JournalNode计算机上绝对路径,JN将使用编辑和其他本地状态进行存储。您只能为此配置使用单个路径。通过运行多个单独的JournalNode或通过在本地连接的RAID阵列上配置此目录来提供此数据的冗余。例如:

<property>
  <name>dfs.journalnode.edits.dir</name>
  <value>/path/to/journal/node/local/data</value>
</property>

部署详情

在设置了所有必要的配置选项之后,您必须启动JournalNode守护进程。这可以通过运行命令“ hadoop-daemon.sh start journalnode ”并等待守护进程在每台相关机器上启动来完成。

JournalNodes启动后,必须首先同步两个HA NameNodes的磁盘元数据。

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

  • 如果您已经格式化了NameNode,或者将未启用HA的群集转换为启用HA,那么现在拷贝NameNode上的元数据目录到另一台,然后在未格式化的NameNode上执行 “hdfs namenode -bootstrapStandby” 。运行此命令还将确保JournalNodes(由dfs.namenode.shared.edits.dir配置)包含足够多的编辑事务以便能够启动两个NameNode。

  • 如果要将非HA NameNode转换为HA,则应运行命令“ hdfs namenode -initializeSharedEdits ”,该命令将使用NameNode的编辑目录的编辑数据初始化JournalNodes。

此时,您可以像平时启动NameNode一样启动两个HA NameNode。

您可以通过浏览到其配置的HTTP地址来分别访问每个NameNode的网页。您应该注意到,配置的地址旁边将是NameNode的HA状态(“待机”或“活动”)。每当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 <命令 >”。

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

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

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

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

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

    连接到提供的NameNode以确定其当前状态,打印“待机”或“激活”到STDOUT。此子命令可能由cron作业或监视脚本使用,这些脚本需要根据NameNode当前处于活动状态还是待机状态而具有不同的行为。

  • getAllServiceState - 返回所有NameNode的状态

    连接到已配置的NameNode以确定当前状态, 向STDOUT打印“待机”或“激活”。

  • checkHealth - 检查给定NameNode的健康状况

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

    注意:这还没有实现,并且目前将始终返回成功,除非给定的NameNode完全关闭。

自动故障转移

介绍

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

组件

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

Apache ZooKeeper是一种高度可用的服务,它使用少量的协调数据,通知客户端数据发生变化,并监视客户端的故障。自动HDFS故障转移的实现依赖ZooKeeper进行以下操作:

  • 失败检测 - 集群中的每个NameNode机器都在ZooKeeper中维护一个持久会话。如果机器崩溃,ZooKeeper会话将过期,并通知其他NameNode应该触发故障转移。

  • 活动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和Standby节点相同的硬件上配置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后缀来配置这些设置。例如,在启用了联合的群集中,您可以通过设置<tt>dfs.ha.automatic-failover.enabled.my-nameservice-id</tt>为其中一个名称服务显式启用自动故障转移。

还可以设置其他几个配置参数来控制自动故障转移的行为; 然而,对于大多数安装来说它们并不是必需的 有关详细信息,请参阅配置密钥特定文档。

在ZooKeeper中初始化HA状态

添加配置密钥后,下一步是在ZooKeeper中初始化所需的状态。您可以通过从其中一个NameNode主机运行以下命令来完成此操作。

[hdfs]$ $HADOOP_PREFIX/bin/hdfs zkfc -formatZK

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

用<tt>start-dfs.sh</tt>启动集群

由于配置中启用了自动故障转移功能,因此<tt>start-dfs.sh</tt>脚本将自动在任何运行NameNode的计算机上启动ZKFC守护程序。当ZKFC启动时,他们将自动选择一个NameNode变为活动状态。

手动启动集群

如果您手动管理群集上的服务,则需要在运行NameNode的每台机器上手动启动<tt>zkfc</tt>守护进程。您可以运行以下命令来启动守护进程:

[hdfs]$ $HADOOP_PREFIX/sbin/hadoop-daemon.sh --script $HADOOP_PREFIX/bin/hdfs start zkfc

安全访问ZooKeeper

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

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

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

请注意这些值中的'@'字符 - 它指定配置不是内联的,而是指向磁盘上的文件。

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

digest:hdfs-zkfcs:mypassword

...其中<tt>hdfs-zkfcs</tt>是ZooKeeper的唯一用户名,<tt>mypassword</tt>是用作密码的一些唯一字符串。

接下来,使用类似下面的命令生成与此验证对应的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=

将' - >'字符串后面的输出部分复制并粘贴到文件<tt>zk-acls.txt中</tt>,并以字符串“ digest: ” 作为前缀。例如:

digest:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=:rwcda

为了使这些ACL生效,您应该重新运行<tt>zkfc -formatZK</tt>命令,如上所述。

这样做后,您可以按如下方式验证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应在几秒钟内自动激活。检测故障并触发故障切换所需的时间取决于<tt>ha.zookeeper.session-timeout.ms</tt>的配置,但默认为5秒。

如果测试不成功,则可能是配置错误。检查<tt>zkfc</tt>守护进程以及NameNode守护进程的日志,以便进一步诊断问题。

自动故障转移常见问题

  • 我以任何特定顺序启动ZKFC和NameNode守护进程是否很重要?

    不需要。在任何给定节点上,您可以在其相应的NameNode之前或之后启动ZKFC。

  • 我应该进行哪些额外的监测?

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

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

  • 如果ZooKeeper出现故障会发生什么?

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

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

    目前,这不支持。NameNode首先启动的任何一个都将变为活动状态。您可以选择以特定顺序启动群集,以便首选节点首先启动。

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

    即使配置了自动故障切换,也可以使用相同的<tt>hdfs haadmin</tt>命令启动手动故障切换。它将执行协调的故障转移。

已启用HA的HDFS升级/终结/回滚

在HDFS版本之间移动时,有时可以简单地安装新软件并重新启动集群。然而,有时候,升级正在运行的HDFS版本可能需要更改磁盘上的数据。在这种情况下,安装新软件后必须使用HDFS升级/终结/回滚功能。在高可用性环境中,这个过程变得更加复杂,因为NN依赖的磁盘上元数据按照定义分布在对中的两个HA NN上,并且在使用QJM的情况下在JournalNodes上共享编辑存储。本文档部分描述在HA设置中使用HDFS升级/终结/回滚功能的过程。

要执行HA升级,操作员必须执行以下操作:

  1. 照常关闭所有NN,然后安装较新的软件。

  2. 启动所有的JN。请注意,这是至关重要的,所有的JNS执行升级,回滚或完成操作时运行。如果任何JN在运行这些操作时都处于关闭状态,则操作将失败。

  3. 用<tt>'-upgrade'</tt>标志启动一个<tt>NN</tt>。

  4. 在开始时,这个NN不会像往常一样在HA设置中进入待机状态。相反,此NN将立即进入活动状态,执行其本地存储目录的升级,并执行共享编辑日志的升级。

  5. 此时,HA对中的其他NN将与升级的NN不同步。为了使其恢复同步并且再次具有高度可用的设置,您应该通过使用<tt>'-bootstrapStandby'</tt>标志运行NN来重新引导此NameNode 。用<tt>'-upgrade'</tt>标志启动第二个NN是错误的。

请注意,如果您在任何时候想要在完成或回滚升级之前重新启动NameNodes,则应该照常启动NN,即不需要任何特殊的启动标志。

要完成高可用性升级,运营商将在神经网络运行时使用<tt>`hdfs dfsadmin -finalizeUpgrade'</tt>命令,并且其中一个是活动的。发生这种情况时的活动NN将执行共享日志的终结,而本地存储目录包含以前FS状态的NN将删除其本地状态。

要执行升级的回滚,应首先关闭两个NN。运营商应在NN发起升级程序的NN上运行回滚命令,该命令将在那里执行本地dir的回滚以及共享日志(NFS或JN)上的回滚。之后,这个NN应该启动,操作员应该在另一个NN上运行<tt>`-bootstrapStandby'</tt>,以使这两个NN与这个回退的文件系统状态同步。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,968评论 6 482
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,601评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 153,220评论 0 344
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,416评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,425评论 5 374
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,144评论 1 285
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,432评论 3 401
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,088评论 0 261
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,586评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,028评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,137评论 1 334
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,783评论 4 324
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,343评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,333评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,559评论 1 262
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,595评论 2 355
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,901评论 2 345

推荐阅读更多精彩内容

  • 翻译: https://www.cloudera.com/documentation/enterprise/lat...
    金刚_30bf阅读 2,612评论 1 1
  • 翻译: https://www.cloudera.com/documentation/enterprise/lat...
    金刚_30bf阅读 1,775评论 0 0
  • 根据HA架构图,规划HA的分布式集群服务器 HA集群规划 根据官方文档配置HA 部分说明 Architecture...
    明明德撩码阅读 2,262评论 0 0
  • HDFS HA 原理 标签:HDFS HA 概述 在 Hadoop 2.x 版本中,Hadoop 实现了 HDFS...
    神仙CGod阅读 2,079评论 1 4
  • "啊哈哈哈哈啊哈哈哈哈!终于舒爽啦!每年最喜欢就是这时候了,这城市的人都走光光了,城市终于又是我的世界啦!" 它肆...
    小生_490e阅读 103评论 0 0