hadoop-2.7.4-翻译文档-QJM高可用

HDFS高可用(QJM)

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

本文档假设读者对HDFS集群中的一般组件和节点类型有一般的了解。有关详细信息，请参阅分布式集群部署。

        本指南讨论如何使用Quorum Journal Manager（QJM）配置和使用HDFS HA，以共享Active和Standby NameNodes之间的编辑日志。有关如何使用NFS为共享存储而不是QJM配置HDFS HA的信息，(暂无)。

        在Hadoop 2.0.0之前，NameNode在HDFS集群中存在单点故障（SPOF）。每个集群只有一个NameNode，如果该机器或进程变得不可用，则整个集群将不可用，直到NameNode重新启动或在单独的计算机上启动。

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

• 在计算机事件（如机器崩溃）的情况下，集群将不可用，直到操作员重新启动NameNode。

• 对NameNode机器上的计划维护事件（如软件或硬件升级），将导致集群的宕机。

        HDFS高可用性功能，通过在一个集群中提供两个具有热备份功能的，主动/被动配置可选的NameNode，来解决上述问题。这允许在机器崩溃的情况下，快速将故障切换到新的NameNode，或者需要对集群进行维护时，允许管理员手动启动快速转换。

        在典型的HA群集中，两个单独的机器配置为NameNodes。在任何时间点，其中一个NameNodes处于Active状态，另一个处于Standby状态。Active NameNode负责群集中的所有客户端操作，而Standby只是作为从属节点，维护足够的状态以便必要时提供快速故障转移。

        为了使Standby节点保持其状态与Active节点同步，两个节点都与一组名为“JournalNodes”（JN）的单独守护程序进行通信。当Active节点执行任何命名空间的修改时，它可以将编辑日志持久化记录到这些JN集群当中。Standby节点能够读取JN中的编辑日志，并且不断监视编辑日志的更改。当Standby节点发现有新的编辑日志时，它将这些编辑日志应用于自己的namespace。当Active NameNode出现故障而需要进行状态切换时，Standby节点必须确保它已经从JounalNodes读取所有编辑日志，然后再将其自身切换到Active状态。这步操作保证namespace在进行故障转移前完全同步。

        为了提供快速故障切换，还需要Standby节点存储集群中文件块的位置的最新信息。为了实现这一点，每个DataNodes配置了两个NameNodes的位置，并同时向两者发送文件块信息和心跳信息。

        对于HA群集的正确操作至关重要，因为一次只能有一个NameNodes处于Active状态。否则，namespace的状态将在两者之间快速产生偏差，产生了数据丢失或其他非正常结果的风险。为了确保此属性并防止所谓的“脑裂”，JournalNodes将只允许一个NameNode对其进行写入操作。在故障切换期间，将要转换为Active的NameNode将直接接管写入JournalNodes的角色，这将有效地防止其他NameNode继续处于Active状态，从而允许新的Active节点可以安全地进行故障切换。

        为了部署HA群集，您应该准备以下内容：

• NameNode主机 - 运行Active和Standby状态NameNodes的计算机应采用性能相当的硬件，以及与非HA集群中使用的硬件相当的硬件。
• JournalNode主机 -JournalNode守护进程是相对轻量级的，所以这些守护进程可以合理地与其他Hadoop守护进程（例如NameNodes，JobTracker或YARN ResourceManager）并置在同一机器上。注意：必须至少有3个JournalNode守护进程，因为编辑日志修改必须写入大多数JN(大于1/2)。这将允许系统容忍单个JN的故障。您还可以运行超过3个JournalNodes，在实际中为了增加系统可以容忍的故障节点数，您应该运行奇数JN（即3，5，7等）。请注意，当使用N JournalNodes运行时，系统最多可以忍受（N-1）/ 2数量的JN故障，并继续正常工作。

        请注意，在HA群集中，Standby NameNode还执行命名空间状态的检查点任务，因此不需要在HA群集中运行Secondary NameNode，CheckpointNode或BackupNode。而且如果运行SNN,CN,BN还会产生错误。这一功能还支持在非HA的HDFS集群转化为HA集群时重用先前专用于Secondary NameNode的硬件。

集群部署

配置概览

        与联邦HDFS配置类似，HA集群配置向后兼容，允许现有的单节点NameNode配置而无需对集群做更改。新的配置设计使集群中所有的节点可以使用相同的配置文件，而不需要根据节点、机器的不同而采用不同配置。

       与联邦HDFS一样，HA集群使用新的名称服务来标识可能实际上由多个HA NameNode组成的单个HDFS实例。另外，一个称为NameNode ID的新抽象概念与HA同步引入。集群中的每个不同的NameNode具有不同的NameNode ID来区分。为了支持所有NameNodes配置写入同一个配置文件，相关配置参数加入NameNode ID的后缀。

配置细节

        要配置HA NameNodes，必须在[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列表进行配置。DataNodes将使用它来确定集群中的所有NameNodes。例如，如果以前使用“mycluster”作为nameervice ID，并且想要使用“nn1”和“nn2”作为NameNodes的各个ID，则可以将其配置为：

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

  注意：目前，每个名称服务最多只能配置两个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>

  注意：如果您愿意，也可以配置“ 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: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 - 定义一个包括JN节点的URI对象，用来标识NameNodes将写/读编辑日志的位置。

  这是个配置提供了共享编辑存储的JournalNodes地址，由Active NameNode写入并由Standby NameNode读取，以存储Active NameNode所做的所有文件系统更改的最新信息。虽然您必须指定多个JournalNode地址，但只能配置一个URI。URI应具有以下格式：qjournal：// * host1：port1 *; * host2：port2 *; * host3：port3 * / * journalId *。Journal 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，除非您使用自行定义的java类，否则应采用如下配置:

  <property>  <name>dfs.client.failover.proxy.provider.mycluster</name>  <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value></property>

• dfs.ha.fencing.methods - 在故障转移期间将用于隔离Active NameNode的脚本或Java类的列表。

  它将被用于保证系统的正确性，及在任何时间仅存在一个Active Namenode。重要的是，当使用Quorum Journal Manager时，只有一个NameNode将被允许写入JournalNodes，所以不会导致文件系统元数据的破坏，及裂脑现象。但是，发生故障转移时，以前的Active NameNode可能会向客户端提供读取请求，这可能是过期的，直到该NameNode在尝试写入JournalNodes时关闭。因此，即使使用Quorum Journal Manager，仍然需要配置一些防护方法。但是，为了提高系统在防护机制发生故障时的可用性，建议配置防护方法，保证将其作为列表中最后的防护方法返回true。注意，如果您选择不使用实际的防护方法，您仍然必须为此设置配置一些内容，例如“ shell（/ bin / true） ”。

  在故障切换期间使用的防护方法被配置为使用回车符分隔的列表，它将按顺序尝试，直到一个指示隔离成功。Hadoop有两种方法：shell和sshfence。有关实现自己的定制隔离方法的信息，请参阅org.apache.hadoop.ha.NodeFencer类。

  ---

  sshfence - SSH到Active 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命令来隔离Active 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配置变量，将会使用 '_' 替换hadoop配置变量中所有的 '.' 字符。所使用的配置文件已经从指定的NameNode通用配置中提取出了所有配置信息 - 例如，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的编辑日志和其他本地状态。您只能使用单一路径进行此配置。通过运行多个单独的JournalNodes或通过在本地连接的RAID阵列上配置此目录来提供此数据的冗余。例如：

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

部署细节

完成所有必要的配置选项后，必须在对应的的机器上启动JournalNode守护程序。这可以通过运行命令“ hadoop-daemons.sh start journalnode ”并等待守护进程在每个相关的机器上启动，或者ssh登录到指定机器启动单一的journalnode进程“ssh exp hadooop-daemon.sh start journalnode”。

一旦JournalNodes启动，必须​​首先同步两个HA NameNodes的磁盘元数据。

• 如果要启用新的HDFS群集，则应首先在其中一个NameNode上运行format命令（hdfs namenode -format）(之后启动该NameNode)。

• 如果您已经格式化了NameNode，或者将非HA集群转换为HA集群，则现在应该在未格式化的NameNode节点通过运行命令“ hdfs namenode -bootstrapStandby ”命令将已启动NameNode元数据目录的内容复制到该未格式化的NameNode当中。运行此命令还将确保JournalNodes（由dfs.namenode.shared.edits.dir配置）包含足够的编辑事务以能够启动两个NameNodes。

• 如果将非HA NameNode转换为HA NameNode，则应运行命令“ hdfs namenode -initializeSharedEdits ”，该命令将使用本地NameNode编辑目录中的编辑日志初始化JournalNodes。

此时，您可以像正常启动NameNode一样启动两个HA NameNodes。

您可以通过浏览其配置的HTTP地址分别访问每个NameNodes的web-ui。您应该注意，配置的地址旁边将是NameNode的HA状态（“standby”或“active”）。每当HA NameNode启动时，它的初始状态都是standby。

管理命令

现在，您的HA名称节点已配置并启动，您将可以访问一些其他命令来管理HA HDFS集群。具体来说，您应该熟悉“ hdfs haadmin ”命令的所有子命令。运行此命令而没有任何其他参数将显示以下使用信息：

用法：haadmin    [-transitionToActive <serviceId>]    [-transitionToStandby <serviceId>]    [-failover [--forcefence] [--forceactive] <serviceId> <serviceId>]    [-getServiceState <serviceId>]    [-checkHealth <serviceId>]    [-help <command>]

本指南介绍了每个子命令的高级使用。对于每个子命令的具体使用信息，应运行“ hdfs haadmin -help <command >”。

• transitionToActive / transitionToStandby - 将给定NameNode的状态转换为Active或Standby

  这些子命令会使给定的NameNode转换到Active或Standby状态。这些命令不会尝试执行任何隔离方法，因此很少使用。我们通常偏向于使用“ hdfs haadmin -failover ”子命令来控制NameNode的状态转换而非前者。

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

  此子命令启动故障转移，从第一个NameNode切换到第二个NameNode。如果第一个NameNode处于standby状态，则该命令只会将第二个状态转换为active状态，而不会出现错误。如果第一个NameNode处于活动状态，则会尝试将其正常地转换到standby状态。如果转换失败，将按顺序尝试隔离方法（由dfs.ha.fencing.methods配置），直到转换成功。只有在此过程之后，第二个NameNode才会转换到活动状态。如果没有隔离方法成功，则第二个NameNode将不会转换到活动状态，并返回错误。

• getServiceState - 确定给定的NameNode的运行状态，active或者standby

  连接到提供的NameNode以确定其当前状态，将“standby”或“active”适当地打印到标准输出。计划任务或监视脚本可能会使用此子命令，这些脚本需要基于NameNode当前处于活动状态或待机状态而执行不同的操作。

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

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

  注意：checkhealth命令还没有实现，目前总是会返回成功，除非给定的NameNode完全关闭。

自动故障转移

介绍

以上部分介绍如何配置手动故障切换。在该模式下，即使主动节点出现故障，系统也不会自动触发从active NameNode到standby NameNode的故障转移。本节介绍如何配置和部署自动故障切换。

组件

自动故障切换为HDFS部署添加了两个新组件：ZooKeeper仲裁和ZKFailoverController进程（简写为ZKFC）。

Apache ZooKeeper是一种高度可用的服务，用于维护少量协调数据，通知客户该数据的更改，以及监控客户端的故障。自动HDFS故障切换的实现依赖于ZooKeeper，具体如下：

• 故障检测 - 群集中的每个NameNode机器在ZooKeeper中维护一个持久会话。如果机器崩溃，ZooKeeper会话将过期，通知另一个NameNode应该触发故障切换。

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

ZKFailoverController（ZKFC）是一个新的组件，它是一个ZooKeeper客户端，还监视和管理NameNode的状态。运行NameNode的每台机器也运行一个ZKFC，ZKFC负责：

• 健康监控 - ZKFC定期使用健康检查命令对其本地NameNode进行ping操作。只要NameNode以健康状态作出响应，ZKFC认为节点健康。如果节点崩溃，宕机或以其他方式进入不健康状态，健康状况监视器会将其标记为不健康。

• ZooKeeper会话管理 - 当本地NameNode健康时，ZKFC在ZooKeeper中持有一个会话。如果本地NameNode处于活动状态，它也会保存一个特殊的znode“锁”。这个锁由ZooKeeper“短暂”的节点提供支持; 如果会话过期，znode锁将被自动删除。

• 基于ZooKeeper的选举 - 如果本地NameNode是健康的，并且ZKFC看到没有其他节点当前持有znode锁，则它本身将尝试获取该锁。如果成功，则该zkfc“赢得选举”，并负责运行故障切换，使其本地NameNode处于活动状态。故障转移过程类似于上述手动故障转移：首先，如果需要的话会先前的active NameNode隔离，然后将本地NameNode转换到活动状态。

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

部署ZooKeeper

在典型的部署中，ZooKeeper守护进程配置为在三个或五个节点上运行。由于ZooKeeper本身具有轻量资源要求，因此可以将ZooKeeper节点与HDFS NameNode和Standby Node在同一硬件上并置。许多程序(员)猿选择在与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作为后缀关键字来对每个nameservice进行配置。例如，在启用联邦的集群中，您可以通过设置dfs.ha.automatic-failover.enabled.my-nameservice-id来显式启用仅一个名称服务器的自动故障转移。

还有其他几个配置参数可以设置为控制自动故障切换的行为; 然而，它们对大多数安装没有必要。有关详细信息，请参阅配置关键字具体文档。

在ZooKeeper中初始化HA状态

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

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

这将在ZooKeeper中创建一个znode来为自动故障切换系统存储其数据。

使用start-dfs.sh启动群集

由于配置中启用了自动故障转移功能，所以start-dfs.sh脚本现在将自动在运行NameNode的任何计算机上启动ZKFC守护程序。当ZKFC启动时，它们将自动选举一个NameNodes以使其成为活动状态。

手动启动集群

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

[hdfs] $ $ HADOOP_PREFIX / sbin / hadoop-daemon.sh --script $ HADOOP_PREFIX / bin / hdfs 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>

请注意这些值中的“@”字符 - 这表示配置不是内联的，而是指向磁盘上的文件。

第一个配置的文件指定了一个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:mypasswordoutput: 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-UI面来查看哪个节点处于活动状态 - 每个节点在页面顶部显示了其HA状态。

找到活动的NameNode后，可以在该节点制造一些故障。例如，可以使用kill -9 <NN/ZKFC pid>来模拟JVM崩溃。或者，您可以重新启动机器或拔掉其网络接口(可以使用 ifdown eth0 命令)以模拟不同类型的中断。触发您想要测试的中断后，其他NameNode将在几秒钟内自动变为活动状态。检测故障并触发故障切换所需的时间取决于ha.zookeeper.session-timeout.ms的配置，但默认为5秒。

如果测试不成功，您可能存在配置错误。检查zkfc守护程序以及NameNode守护程序的日志，以进一步诊断问题。

自动故障转移常见问题

• 我以任何特定的顺序启动ZKFC和NameNode守护进程很重要吗？

  否。在任何给定的节点上，您可以在其对应的NameNode之前或之后启动ZKFC。

• 我应该进行什么额外的监测吗？

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

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

• 如果ZooKeeper停机，会发生什么？

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

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

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

• 配置自动故障切换时，如何启动手动故障切换？

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

HDFS升级/完成/回滚与HA启用

在HDFS版本之间进行更改时，有时可以简单地安装较新的版本，并重新启动集群。然而，有时升级您正在运行的HDFS版本可能需要更改磁盘上的数据。在这种情况下，在安装新软件之后，必须使用HDFS升级/完成/回滚工具。这个过程在HA环境中变得更加复杂，因为NN所依赖的磁盘元数据是被定义为分部核实存储的：在成对的HA NN上，在JournalNodes上，以及在QJM被用于共享的编辑日志。本部分介绍在HA设置中使用HDFS升级/完成/回滚工具的步骤。

要执行HA升级，操作员必须执行以下操作：

1. 正常关闭所有NN，并安装较新的版本。

2. 启动所有JN。请注意，执行升级、回滚或完成操作时，所有JN都正在运行至关重要。如果任何JN在运行任何这些操作时关闭，操作都将失败。

3. 使用'-upgrade'参数启动其中一个NN。

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

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

请注意，如果您在完成、升级或回滚操作之前的任何时候之前重新启动NameNodes，那么您应该正常启动NN，即没有任何特殊的启动参数。

要完成HA升级，操作员可以在两个NN同时运行并且有且只有其中一个处于active态时使用“hdfs dfsadmin -finalizeUpgrade”命令。此时发生的活动NN将执行共享日志的最终化，并且本地目录中包含其先前FS状态的NN将对其状态进行删除。

要执行升级的回滚，应首先关闭两个NN。运营商应该在启动升级过程的NN上运行回滚命令，该命令将对本地目录进行回滚，以及NFS或JN上的共享日志。之后，应该启动这个NN，并且操作员应该在另一个NN上运行`-bootstrapStandby'，使两个NN以回滚后的文件系统状态保持同步。