翻译: http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html
版本: 2.9.0
- Purpose
- Note: Using the Quorum Journal Manager or Conventional Shared Storage
- Background
- Architecture
- Hardware resources
- Deployment
- Automatic Failover
- Automatic Failover FAQ
- HDFS Upgrade/Finalization/Rollback with HA Enabled
目的
本指南介绍基于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。
此外,还提供了以下指向要防护的目标节点的变量:
这些环境变量也可以用作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升级,操作员必须执行以下操作:
照常关闭所有NN,然后安装较新的软件。
启动所有的JN。请注意,这是至关重要的,所有的JNS执行升级,回滚或完成操作时运行。如果任何JN在运行这些操作时都处于关闭状态,则操作将失败。
用<tt>'-upgrade'</tt>标志启动一个<tt>NN</tt>。
在开始时,这个NN不会像往常一样在HA设置中进入待机状态。相反,此NN将立即进入活动状态,执行其本地存储目录的升级,并执行共享编辑日志的升级。
此时,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与这个回退的文件系统状态同步。