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.nameservices和dfs.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附带的两个实现是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 - 在故障转移期间将用于遏制活动NameNode的脚本或Java类的列表

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

    故障切换期间使用的防护方法将配置为一个以回车分隔的列表，该列表将按顺序尝试，直到指示防护成功为止。Hadoop提供了两种方法：shell和sshfence。有关实现自己的自定义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 <命令 >”。

  • transitionToActive和transitionToStandby - 将给定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阅读 203,362评论 5赞 477
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 85,330评论 2赞 381
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 150,247评论 0赞 337
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,560评论 1赞 273
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,580评论 5赞 365
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,569评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,929评论 3赞 395
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,587评论 0赞 258
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,840评论 1赞 297
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,596评论 2赞 321
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,678评论 1赞 329
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,366评论 4赞 318
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,945评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,929评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,165评论 1赞 259
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 43,271评论 2赞 349
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,403评论 2赞 342

推荐阅读更多精彩内容

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