(11)HDFS高可用性使用Quorum Journal Manager

HDFS高可用性使用Quorum日记管理器

• HDFS高可用性使用Quorum日记管理器
  • 目的
  • 注意：使用Quorum Journal Manager或常规共享存储
  • 背景
  • 建筑
  • 硬件资源
  • 部署
    • 配置概述
    • 配置详细信息
    • 部署详细信息
    • 管理命令
  • 自动故障转移
    • 介绍
    • 组件
    • 部署ZooKeeper
    • 在你开始之前
    • 配置自动故障转移
    • 在ZooKeeper中初始化HA状态
    • 使用start-dfs.sh启动集群
    • 手动启动集群
    • 保护对ZooKeeper的访问
    • 验证自动故障切换
  • 自动故障转移常见问题
  • HDFS升级/完成/回滚，并启用HA

目的

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

本文假设读者对HDFS集群中的一般组件和节点类型有一般的了解。有关详细信息，请参阅HDFS架构指南。

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

本指南讨论如何配置和使用HDFS HA，使用Quorum Journal Manager（QJM）在活动和备用NameNode之间共享编辑日志。有关如何配置HDFS HA使用NFS共享存储，而不是QJM的信息，请参阅此替代指南。

背景

在Hadoop 2.0.0之前，NameNode是HDFS集群中的单点故障（SPOF）。每个集群都有一个NameNode，如果该机器或进程不可用，则作为整体的集群将不可用，直到NameNode被重新启动或在单独的机器上启动。

这会以两种主要方式影响HDFS集群的总可用性：

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

• 计划的维护事件（如NameNode计算机上的软件或硬件升级）将导致集群停机时间的窗口。

HDFS高可用性功能通过在具有热备份的主动/被动配置中提供在同一群集中运行两个冗余NameNode的选项来解决上述问题。这允许在机器崩溃的情况下快速故障切换到新的NameNode，或者出于计划维护的目的，由管理员发起的优雅故障切换。

建筑

在典型的HA群集中，两个单独的计算机配置为NameNode。在任何时间点，只有一个NameNode处于活动状态，另一个处于待机状态。Active NameNode负责集群中的所有客户端操作，而Standby仅仅充当从属，保持足够的状态，以在必要时提供快速故障转移。

为了使备用节点保持其与活动节点同步的状态，两个节点都与一组称为“日志节点”（JN）的独立守护进程通信。当活动节点执行任何命名空间修改时，它持久地将修改的记录记录到这些JN中的大多数。备用节点能够从JN读取编辑，并且不断地监视它们对编辑日志的更改。当备用节点看到编辑时，它将它们应用于其自己的命名空间。在故障切换的情况下，备用将确保它已经从JounalNodes读取所有编辑，然后将其自身升级到活动状态。这可确保在发生故障转移之前，命名空间状态完全同步。

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

对于HA群集的正确操作，每次只有一个NameNode活动是至关重要的。否则，命名空间状态将在两者之间快速分歧，冒着数据丢失或其他不正确的结果的风险。为了确保这个属性并防止所谓的“裂脑情况”，JournalNode只允许一个NameNode成为一个作者。在故障切换期间，要变为活动的NameNode将仅接管写入JournalNode的角色，这将有效地防止其他NameNode继续处于活动状态，从而允许新的Active安全地继续故障转移。

硬件资源

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

• NameNode计算机 - 运行活动和备用NameNode的计算机应具有彼此等效的硬件，以及与非HA群集中使用的硬件等效的硬件。

• JournalNode计算机 - 您在其上运行JournalNode的计算机。JournalNode守护进程相对轻量级，所以这些守护进程可以合理地在具有其他Hadoop守护进程的机器上并置，例如NameNodes，JobTracker或YARN ResourceManager。注意：必须至少有3个JournalNode守护程序，因为编辑日志修改必须写入大多数JN。这将允许系统容忍单个机器的故障。您也可以运行超过3个JournalNodes，但为了实际增加系统可以容忍的故障数，您应该运行奇数个JN（即3,5,7等）。请注意，当使用N个JournalNode运行时，系统最多可容忍（N-1）/ 2个故障，并继续正常工作。

注意，在HA群集中，备用NameNode还执行命名空间状态的检查点，因此不需要在HA群集中运行辅助NameNode，CheckpointNode或BackupNode。事实上，这样做将是一个错误。这还允许将重新配置非HA启用的HDFS集群的人员启用HA以重新使用他们先前专用于辅助NameNode的硬件。

部署

配置概述

与联合配置类似，HA配置向后兼容，并允许现有的单个NameNode配置无变化地工作。新配置被设计为使得集群中的所有节点可以具有相同的配置，而不需要基于节点的类型将不同的配置文件部署到不同的机器。

与HDFS联合一样，HA群集重用名称服务ID来标识可能实际上由多个HA名称节点组成的单个HDFS实例。此外，一个名为NameNode ID的新抽象与HA一起添加。集群中的每个不同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] - 名称服务中每个NameNode的唯一标识符

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

  <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 - 标识NameNodes将写入/读取编辑的JN组的URI

  这是在哪里配置提供共享编辑存储的JournalNode的地址，由活动名称节点写入并由备用NameNode读取以保持最新与活动NameNode做出的所有文件系统更改。虽然必须指定多个JournalNode地址，但您只应配置其中一个URI。URI应该是以下形式：qjournal：// * host1：port1 *; * host2：port2 *; * host3：port3 * / * journalId *。日志ID是此名称服务的唯一标识符，它允许单个集合的JournalNode为多个联合名称系统提供存储。尽管不是必需的，但是对于日志标识符重用名称服务ID是个好主意。

  例如，如果此集群的JournalNode在计算机“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客户端用于联系活动NameNode的Java类

  配置将由DFS客户端使用的Java类的名称，以确定哪个NameNode是当前活动的，以及因此哪个NameNode当前为客户端请求提供服务。目前Hadoop附带的唯一实现是ConfiguredFailoverProxyProvider，所以使用它，除非你使用自定义。例如：

  <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处于活动状态。重要的是，当使用Quorum Journal Manager时，只有一个NameNode允许写入JournalNode，因此没有可能破坏来自裂脑情况的文件系统元数据。但是，当发生故障切换时，以前的Active NameNode仍然可能为客户端提供读请求，这可能已过期，直到NameNode在尝试写入JournalNode时关闭。因此，即使在使用Quorum Journal Manager时仍然需要配置一些防护方法。然而，为了在屏障机制失效的情况下提高系统的可用性，建议配置一个保证将返回成功作为列表中最后一个防护方法的防护方法。请注意，如果您选择不使用实际的防护方法，您仍然必须为此设置配置一些内容，例如“ shell（/ bin / true） ”。

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

  ---

  sshfence - SSH到活动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命令。它可以这样配置：

      <property>      <name> dfs.ha.fencing.methods </ name>      <value> shell（/path/to/my/script.sh arg1 arg2 ...）</ value>    </ property>

  '（'和'）'之间的字符串直接传递给bash shell，不能包含任何括号。

  shell命令将使用设置为包含所有当前Hadoop配置变量的环境运行，其中'_'字符替换任何'。'。字符。所使用的配置已经将任何特定于namenode的配置提升为其通用形式，例如dfs_namenode_rpc-address将包含目标节点的RPC地址，即使配置可能将该变量指定为dfs.namenode.rpc-address.ns1 .nn1。

  此外，还可以使用以下指向要保护的目标节点的变量：

    $ target_host要防护的节点的主机名$ target_portIPC端口的节点$ target_address以上两个，合并为host：port$ target_nameserviceid要屏蔽的NN的名称服务标识$ 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使用的编辑和其他本地状态。您只能对此配置使用单个路径。此数据的冗余通过运行多个单独的JournalNode或在本地连接的RAID阵列上配置此目录来提供。例如：

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

部署详细信息

在设置了所有必需的配置选项后，必须在将要运行它们的计算机集上启动JournalNode守护程序。这可以通过运行命令“ hadoop-daemon.sh start journalnode ”并等待守护程序在每个相关计算机上启动来完成。

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

• 如果要设置一个新的HDFS集群，您应该首先在其中一个NameNode上运行format命令（hdfs namenode -format）。

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

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

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

您可以通过浏览到其配置的HTTP地址单独访问每个NameNodes的网页。您应该注意到，配置的地址旁边将是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的状态转换为活动或待机

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

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

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

• getServiceState - 确定给定的NameNode是活动还是待机

  连接到提供的NameNode以确定其当前状态，适当地打印“待机”或“活动”到STDOUT。此子命令可能由cron作业或监视脚本使用，这些脚本需要根据NameNode当前是活动还是待机来进行不同的操作。

• 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 Node相同的硬件上配置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_PREFIX / bin / hdfs zkfc -formatZK

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

使用start-dfs.sh启动集群

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

手动启动集群

如果手动管理集群上的服务，则需要在运行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：mypassword输出：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命令启动手动故障转移。它将执行协调故障转移。

HDFS升级/完成/回滚，并启用HA

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

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

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

2. 启动所有JN。需要注意的是它是临界所有JNS执行升级，回滚或完成操作时运行。如果任何JN在运行任何这些操作时都关闭，则操作将失败。

3. 使用'-upgrade'标志启动其中一个NN 。

4. 开始时，此NN不会像通常在HA设置中那样进入备用状态。相反，该NN将立即进入活动状态，执行其本地存储路径的升级，并且还执行共享编辑日志的升级。

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

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

要完成HA升级，操作员将使用`hdfs dfsadmin -finalizeUpgrade'命令，而NN正在运行并且其中之一处于活动状态。在发生此时的活动NN将执行共享日志的最终化，并且其本地存储目录包含先前FS状态的NN将删除其本地状态。

要执行升级的回滚，应首先关闭两个NN。操作员应在NN上运行回滚命令，在那里它们发起升级过程，这将在本地dirs上以及在共享日志（NFS或JN上）上执行回滚。之后，应该启动此NN，并且操作员应在其他NN上运行`-bootstrapStandby'，以使两个NN与此回滚的文件系统状态同步。

原文https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html