本指南概述了HDFS高可用性&＃xff08;HA&＃xff09;功能以及如何使用Quorum Journal Manager&＃xff08;QJM&＃xff09;功能配置和管理HA HDFS群集。
本文档假定读者对HDFS集群中的一般组件和节点类型有一般性的了解。有关详细信息&＃xff0c;请参阅HDFS体系结构指南。
本指南讨论如何使用Quorum Journal Manager&＃xff08;QJM&＃xff09;配置和使用HDFS HA&＃xff0c;以共享活动和备用NameNode之间的编辑日志。有关如何使用NFS为共享存储而不是QJM配置HDFS HA的信息&＃xff0c;请参阅此备用指南。
在Hadoop 2.0.0之前&＃xff0c;NameNode是HDFS集群中的单点故障&＃xff08;SPOF&＃xff09;。每个群集都有一个NameNode&＃xff0c;如果该机器或进程变得不可用&＃xff0c;整个群集将无法使用&＃xff0c;直到NameNode重新启动或在单独的计算机上启动。
这在两个主要方面影响了HDFS集群的总体可用性&＃xff1a;
对于计划外事件&＃xff08;例如计算机崩溃&＃xff09;&＃xff0c;在操作员重新启动NameNode之前&＃xff0c;群集将不可用。
计划维护事件&＃xff08;如NameNode计算机上的软件或硬件升级&＃xff09;将导致群集停机时间窗口。
HDFS高可用性功能通过提供在具有热备用的主动/被动配置中的同一群集中运行两个&＃xff08;以及3.0.0多于两个&＃xff09;冗余NameNode的选项来解决上述问题。这允许在机器崩溃的情况下快速故障转移到新的NameNode&＃xff0c;或者为了计划维护而优雅地管理员启动的故障转移。
在典型的HA群集中&＃xff0c;两个或多个单独的计算机配置为NameNode。在任何时间点&＃xff0c;其中一个NameNode处于Active 状态&＃xff0c;而其他NameNode 处于 Standby 状态。Active NameNode负责集群中的所有客户端操作&＃xff0c;而Standbys只是充当工作者&＃xff0c;维持足够的状态以在必要时提供快速故障转移。
为了使备用节点保持其状态与Active节点同步&＃xff0c;两个节点都与一组称为“JournalNodes”&＃xff08;JNs&＃xff09;的单独守护进程通信。当Active节点执行任何名称空间修改时&＃xff0c;它会将修改记录持久地记录到大多数这些JNs中。待机节点能够从JNs读取编辑&＃xff0c;并且不断观察它们对edit log的更改。当备用节点看到edit log 时&＃xff0c;它会将它们应用到自己的命名空间。如果发生故障转移&＃xff0c;Standby将确保在将自身升级为Active状态之前已从JournalNodes读取所有edit log 内容。这可确保在发生故障转移之前完全同步命名空间状态。
为了提供快速故障转移&＃xff0c;备用节点还必须具有关于群集中块的位置的最新信息。为了实现这一点&＃xff0c;DataNode配置了所有NameNode的位置&＃xff0c;并向所有人发送块位置信息和心跳。
对于HA群集的正确操作而言&＃xff0c;一次只有一个NameNode处于活动状态至关重要。否则&＃xff0c;命名空间状态将在两者之间快速分歧&＃xff0c;冒着数据丢失或其他不正确结果的风险。为了确保这个属性并防止所谓的“裂脑情景”&＃xff0c;JournalNodes只允许一个NameNode一次成为一个作家。在故障转移期间&＃xff0c;要激活的NameNode将简单地接管写入JournalNodes的角色&＃xff0c;这将有效地阻止其他NameNode继续处于Active状态&＃xff0c;从而允许新的Active安全地进行故障转移。
要部署HA群集&＃xff0c;您应准备以下内容&＃xff1a;
NameNode计算机 - 运行Active和Standby NameNode的计算机应具有彼此相同的硬件&＃xff0c;以及与非HA集群中使用的硬件等效的硬件。
JournalNode计算机 - 运行JournalNodes的计算机。JournalNode守护程序相对轻量级&＃xff0c;因此这些守护程序可以合理地与其他Hadoop守护程序并置在机器上&＃xff0c;例如NameNodes&＃xff0c;JobTracker或YARN ResourceManager。注意&＃xff1a;必须至少有3个JournalNode守护进程&＃xff0c;因为编辑日志修改必须写入大多数JN。这将允许系统容忍单个机器的故障。您也可以运行3个以上的JournalNodes&＃xff0c;但为了实际增加系统可以容忍的失败次数&＃xff0c;您应该运行奇数个JN&＃xff08;即3,5,7等&＃xff09;。请注意&＃xff0c;当使用N JournalNodes运行时&＃xff0c;系统最多可以容忍&＃xff08;N-1&＃xff09;/ 2个故障并继续正常运行。
请注意&＃xff0c;在HA群集中&＃xff0c;备用NameNode还会执行命名空间状态的检查点&＃xff0c;因此无需在HA群集中运行Secondary NameNode&＃xff0c;CheckpointNode或BackupNode。事实上&＃xff0c;这样做会是一个错误。这还允许正在重新配置启用HA的HDFS群集的人员启用HA&＃xff0c;以重用他们之前专用于Secondary NameNode的硬件。
与联邦配置类似&＃xff0c;HA配置是向后兼容的&＃xff0c;允许现有的单个NameNode配置无需更改即可运行。新配置的设计使得集群中的所有节点可以具有相同的配置&＃xff0c;而无需根据节点的类型将不同的配置文件部署到不同的计算机。
与HDFS Federation一样&＃xff0c;HA集群重用名称服务ID来标识单个HDFS实例&＃xff0c;该实例实际上可能包含多个HA NameNode。此外&＃xff0c;HA添加了一个名为NameNode ID的新抽象。群集中的每个不同的NameNode都有一个不同的NameNode ID来区分它。要支持所有NameNode的单个配置文件&＃xff0c;相关配置参数后缀为nameservice ID和NameNode ID。
要配置HA NameNode&＃xff0c;必须向hdfs-site.xml配置文件添加多个配置选项。
您设置这些配置的顺序并不重要&＃xff0c;但您为dfs.nameservices和dfs.ha.namenodes。[nameservice ID]选择的值将确定后面的那些键。因此&＃xff0c;在设置其余配置选项之前&＃xff0c;您应该决定这些值。
dfs.nameservices - 此新名称服务的逻辑名称
为此名称服务选择一个逻辑名称&＃xff0c;例如“mycluster”&＃xff0c;并使用此逻辑名称作为此config选项的值。您选择的名称是任意的。它既可用于配置&＃xff0c;也可用作群集中绝对HDFS路径的权限组件。 注意&＃xff1a;如果您还在使用HDFS Federation&＃xff0c;则此配置设置还应包括其他名称服务列表&＃xff0c;HA或其他&＃xff0c;以逗号分隔列表。
dfs.ha.namenodes。[nameservice ID] - nameservice中每个NameNode的唯一标识符
配置逗号分隔的NameNode ID列表。DataNodes将使用它来确定集群中的所有NameNode。例如&＃xff0c;如果您之前使用“mycluster”作为名称服务ID&＃xff0c;并且您希望使用“nn1”&＃xff0c;“nn2”和“nn3”作为NameNodes的各个ID&＃xff0c;则可以这样配置&＃xff1a; 注意&＃xff1a; HA的NameNode最小数量为2&＃xff0c;但您可以配置更多。由于通信开销&＃xff0c;建议不要超过5 - 推荐3个NameNodes。
dfs.namenode.rpc-address。[nameservice ID]。[name node ID] - 要监听的每个NameNode的完全限定的RPC地址
对于两个先前配置的NameNode ID&＃xff0c;请设置NameNode进程的完整地址和IPC端口。请注意&＃xff0c;这会产生两个单独的配置选项。例如&＃xff1a;
注意&＃xff1a;如果您愿意&＃xff0c;可以类似地配置“ servicerpc-address ”设置。
dfs.namenode.http-address。[nameservice ID]。[name node ID] - 要监听的每个NameNode的完全限定HTTP地址
与上面的rpc-address类似&＃xff0c;设置两个NameNodes的HTTP服务器的地址以进行侦听。例如&＃xff1a;
注意&＃xff1a;如果启用了Hadoop的安全功能&＃xff0c;则还应为每个NameNode 设置https-address。
dfs.namenode.shared.edits.dir - 标识NameNodes将写入/读取 edits 的JNs 组的URI
这是一个配置JournalNodes的地址的地方&＃xff0c;它提供共享 edits 存储&＃xff0c;由Active nameNode写入并由Standby NameNode读取&＃xff0c;以保持Active NameNode所做的所有文件系统更改的最新状态。虽然您必须指定多个JournalNode地址&＃xff0c;但您应该只配置其中一个URI。URI应该是以下形式&＃xff1a; qjournal://*host1:port1*;*host2:port2*;*host3:port3*/*journalId*. 。Journal ID是此nameservice的唯一标识符&＃xff0c;它允许一组JournalNodes为多个联合名称系统提供存储。虽然不是必需的&＃xff0c;但最好重用日志标识符的名称服务ID。
例如&＃xff0c;如果此群集的JournalNodes在计算机“node1.example.com”&＃xff0c;“node2.example.com”和“node3.example.com”上运行&＃xff0c;并且名称服务ID是“mycluster”&＃xff0c;则您将使用以下为此设置的值&＃xff08;JournalNode的默认端口为8485&＃xff09;&＃xff1a;
dfs.client.failover.proxy.provider。[nameservice ID] - HDFS客户端用于联系Active NameNode的Java类
配置Java类的名称&＃xff0c;DFS客户端将使用该名称来确定哪个NameNode是当前的Active&＃xff0c;以及哪个NameNode当前正在为客户端请求提供服务。目前Hadoop附带的两个实现是ConfiguredFailoverProxyProvider和RequestHedgingProxyProvider&＃xff08;对于第一次调用&＃xff0c;它同时调用所有名称节点以确定活动的名称&＃xff0c;并在后续请求中调用活动的名称节点直到发生故障转移&＃xff09;&＃xff0c;所以除非您使用自定义代理提供程序&＃xff0c;否则请使用其中一个。例如&＃xff1a;
dfs.ha.fencing.methods - 脚本或Java类的列表&＃xff0c;用于在故障转移期间屏蔽 Active NameNode
对于系统的正确性&＃xff0c;期望在任何给定时间只有一个NameNode处于活动状态。重要的是&＃xff0c;在使用Quorum Journal Manager时&＃xff0c;只允许一个NameNode写入JournalNodes&＃xff0c;因此不存在从裂脑情况中破坏文件系统元数据的可能性。但是&＃xff0c;当发生故障转移时&＃xff0c;以前的Active NameNode仍可能向客户端提供读取请求&＃xff0c;这可能已过期&＃xff0c;直到NameNode在尝试写入JournalNode时关闭。因此&＃xff0c;即使使用Quorum Journal Manager&＃xff0c;仍然需要配置一些防护方法。但是&＃xff0c;为了在防护机制失败的情况下提高系统的可用性&＃xff0c;建议配置防护方法&＃xff0c;该方法可保证作为列表中的最后一个防护方法返回成功。请注意&＃xff0c;如果您选择不使用实际的防护方法&＃xff0c;则仍必须为此设置配置某些内容&＃xff0c;例如“ shell(/bin/true) ”。 故障转移期间使用的防护方法配置为回车分隔列表&＃xff0c;将按顺序尝试&＃xff0c;直到指示防护成功为止。Hadoop有两种方法&＃xff1a;shell和sshfence。有关实现自定义防护方法的信息&＃xff0c;请参阅org.apache.hadoop.ha.NodeFencer类。 sshfence - SSH到Active NameNode并终止进程 该sshfence选项SSHes到目标节点&＃xff0c;并使用定影杀死进程监听服务的TCP端口上。为了使此防护选项起作用&＃xff0c;它必须能够在不提供密码的情况下SSH到目标节点。因此&＃xff0c;还必须配置dfs.ha.fencing.ssh.private-key-files选项&＃xff0c;该选项是以逗号分隔的SSH私钥文件列表。例如&＃xff1a; 可选地&＃xff0c;可以配置非标准用户名或端口以执行SSH。还可以为SSH配置超时&＃xff08;以毫秒为单位&＃xff09;&＃xff0c;之后将认为此防护方法已失败。它可能配置如下&＃xff1a; shell - 运行任意shell命令以阻止Active NameNode 所述 shell fencing 方法运行的任意外壳命令。它可能配置如下&＃xff1a; &＃39;&＃xff08;&＃39;和&＃39;&＃xff09;&＃39;之间的字符串直接传递给bash shell&＃xff0c;可能不包含任何右括号。 shell命令将在环境设置为包含所有当前Hadoop配置变量的情况下运行&＃xff0c;其中&＃39;_&＃39;字符替换任何&＃39;.&＃39;。配置键中的字符。使用的配置已经将任何特定于名称节点的配置提升为其通用格式 - 例如&＃xff0c;dfs_namenode_rpc-address将包含目标节点的RPC地址&＃xff0c;即使配置可能将该变量指定为dfs.namenode.rpc-address.ns1.nn1。 此外&＃xff0c;还提供了以下涉及要隔离的目标节点的变量&＃xff1a; 这些环境变量也可以用作shell命令本身的替换。例如&＃xff1a; 如果shell命令返回退出代码0&＃xff0c;则确定防护成功。如果它返回任何其他退出代码&＃xff0c;则防护不成功&＃xff0c;将尝试列表中的下一个防护方法。 注意&＃xff1a;此防护方法不会实现任何超时。如果需要超时&＃xff0c;则应该在shell脚本本身中实现它们&＃xff08;例如&＃xff0c;通过分配子shell以在几秒钟内终止它的父节点&＃xff09;。 $ target_host 要隔离的节点的主机名 $ target_port 要隔离的节点的IPC端口 $ TARGET_ADDRESS 以上两种&＃xff0c;合并为主机&＃xff1a;端口 $ target_nameserviceid 要隔离的NN的名称服务ID $ target_namenodeid 要隔离的NN的namenode ID
fs.defaultFS - Hadoop FS客户端在没有给出时使用的默认路径前缀
&＃xff08;可选&＃xff09;您现在可以配置Hadoop客户端的默认路径以使用新的启用HA的逻辑URI。如果您之前使用“mycluster”作为名称服务ID&＃xff0c;那么这将是所有HDFS路径的权限部分的值。这可以在您的core-site.xml文件中进行如下配置&＃xff1a;
dfs.journalnode.edits.dir - JournalNode守护程序将存储其本地状态的路径
这是JournalNode计算机上的绝对路径&＃xff0c;其中将存储JN使用的edits 和其他本地状态。您只能使用单个路径进行此配置。通过运行多个单独的JournalNode或在本地连接的RAID阵列上配置此目录&＃xff0c;可以提供此数据的冗余。例如&＃xff1a; 在设置了所有必需的配置选项后&＃xff0c;必须在将运行它们的一组计算机上启动JournalNode守护程序。这可以通过运行命令“ hdfs --daemon start journalnode ”并等待守护进程在每个相关机器上启动来完成。 一旦启动了JournalNodes&＃xff0c;就必须首先同步两个HA NameNodes的磁盘元数据。 如果要设置新的HDFS集群&＃xff0c;则应首先在其中一个NameNode上运行format命令&＃xff08;hdfs namenode -format&＃xff09;。 如果您已经格式化了NameNode&＃xff0c;或者正在将启用了HA的群集转换为启用HA&＃xff0c;则现在应该通过运行命令将NameNode元数据目录的内容复制到其他未格式化的NameNode上。hdfs namenode -bootstrapStandby“在未格式化的NameNode上。运行此命令还将确保JournalNodes&＃xff08;由dfs.namenode.shared.edits.dir配置&＃xff09;包含足够的编辑事务&＃xff0c;以便能够启动两个NameNode。 如果要将非HA NameNode转换为HA&＃xff0c;则应运行命令“ hdfs namenode -initializeSharedEdits ”&＃xff0c;该命令将使用本地NameNode编辑目录中的编辑数据初始化JournalNodes。 此时&＃xff0c;您可以像通常启动NameNode一样启动所有HA NameNode。 您可以通过浏览到配置的HTTP地址&＃xff0c;分别访问每个NameNodes的网页。您应该注意到&＃xff0c;配置的地址旁边将是NameNode的HA状态&＃xff08;“standby”或“active”&＃xff09;。每当HA NameNode启动时&＃xff0c;它最初处于 Standby 状态。 现在您的HA NameNode已配置并启动&＃xff0c;您将可以访问一些其他命令来管理HA HDFS集群。具体来说&＃xff0c;您应该熟悉“ hdfs haadmin ”命令的所有子命令。在没有任何其他参数的情况下运行此命令将显示以下用法信息&＃xff1a; 本指南介绍了每个子命令的高级用法。有关每个子命令的特定用法信息&＃xff0c;您应该运行“ hdfs haadmin -help transitionToActive和transitionToStandby - 将给定NameNode的状态转换为Active或Standby 这些子命令使给定的NameNode分别转换为Active或Standby状态。这些命令不会尝试执行任何防护&＃xff0c;因此很少使用。相反&＃xff0c;人们几乎总是喜欢使用“ hdfs haadmin -failover ”子命令。 故障转移 - 在两个NameNode之间启动故障转移 此子命令导致从第一个提供的NameNode到第二个NameNode的故障转移。如果第一个NameNode处于Standby状态&＃xff0c;则此命令只是将第二个NameNode转换为Active状态而不会出现错误。如果第一个NameNode处于活动状态&＃xff0c;将尝试将其正常转换为待机状态。如果失败&＃xff0c;将按顺序尝试防护方法&＃xff08;由dfs.ha.fencing.methods配置&＃xff09;&＃xff0c;直到成功为止。只有在此过程之后&＃xff0c;第二个NameNode才会转换为Active状态。如果没有防护方法成功&＃xff0c;则第二个NameNode将不会转换为活动状态&＃xff0c;并且将返回错误。 getServiceState - 确定给定的NameNode是Active还是Standby 连接到提供的NameNode以确定其当前状态&＃xff0c;适当地将“standby”或“active”打印到STDOUT。此子命令可能由cron作业或监视脚本使用&＃xff0c;这些脚本需要根据NameNode当前是活动还是待机而表现不同。 getAllServiceState - 返回所有NameNode的状态 连接到已配置的NameNodes以确定当前状态&＃xff0c;适当地将“待机”或“活动”打印到STDOUT。 checkHealth - 检查给定NameNode的运行状况 连接到提供的NameNode以检查其运行状况。NameNode能够对自身执行某些诊断&＃xff0c;包括检查内部服务是否按预期运行。如果NameNode是健康的&＃xff0c;则此命令将返回0&＃xff0c;否则返回非零。可以使用此命令进行监视。 注意&＃xff1a;这尚未实现&＃xff0c;并且除非给定的NameNode完全关闭&＃xff0c;否则目前将始终返回成功。
部署细节
管理命令
Usage: haadmin[-transitionToActive
如果在Load Balancer&＃xff08;例如Azure或AWS&＃xff09;后面运行一组NameNode 并希望Load Balancer指向活动NN&＃xff0c;则可以使用/ isActive HTTP端点作为运行状况探测。如果NN处于活动HA状态&＃xff0c;则 http://NN_HOSTNAME/isActive 将返回200状态代码响应&＃xff0c;否则返回405。
以上部分介绍了如何配置手动故障转移。在该模式下&＃xff0c;即使活动节点发生故障&＃xff0c;系统也不会自动触发从活动状态到备用NameNode的故障转移。本节介绍如何配置和部署自动故障转移。
自动故障转移为HDFS部署添加了两个新组件&＃xff1a;ZooKeeper quorum 和ZKFailoverController进程&＃xff08;缩写为ZKFC&＃xff09;。
Apache ZooKeeper是一种高可用性服务&＃xff0c;用于维护少量协调数据&＃xff0c;通知客户端该数据的更改以及监视客户端是否存在故障。自动HDFS故障转移的实现依赖于ZooKeeper来实现以下功能&＃xff1a;
故障检测 - 集群中的每个NameNode计算机都在ZooKeeper中维护一个持久会话。如果计算机崩溃&＃xff0c;ZooKeeper会话将过期&＃xff0c;通知其他NameNode应该触发故障转移。
Active NameNode选举 - ZooKeeper提供了一种简单的机制&＃xff0c;可以将节点专门选为活动节点。如果当前活动的NameNode崩溃&＃xff0c;则另一个节点可能在ZooKeeper中采用特殊的独占锁&＃xff0c;指示它应该成为下一个活动的。
ZKFailoverController&＃xff08;ZKFC&＃xff09;是一个新组件&＃xff0c;它是一个ZooKeeper客户端&＃xff0c;它还监视和管理NameNode的状态。运行NameNode的每台机器也运行ZKFC&＃xff0c;ZKFC负责&＃xff1a;
运行状况监视 - ZKFC定期使用运行状况检查命令对其本地NameNode进行ping操作。只要NameNode及时响应健康状态&＃xff0c;ZKFC就认为该节点是健康的。如果节点已崩溃&＃xff0c;冻结或以其他方式进入不健康状态&＃xff0c;则运行状况监视器会将其标记为运行状况不佳。
ZooKeeper会话管理 - 当本地NameNode运行正常时&＃xff0c;ZKFC在ZooKeeper中保持会话打开。如果本地NameNode处于活动状态&＃xff0c;它还拥有一个特殊的“锁定”znode。此锁使用ZooKeeper对“短暂”节点的支持; 如果会话过期&＃xff0c;将自动删除锁定节点。
基于ZooKeeper的选举 - 如果本地NameNode是健康的&＃xff0c;并且ZKFC发现没有其他节点当前持有锁znode&＃xff0c;它将自己尝试获取锁。如果成功&＃xff0c;那么它“赢得了选举”&＃xff0c;并负责运行故障转移以使其本地NameNode处于活动状态。故障转移过程类似于上述手动故障转移&＃xff1a;首先&＃xff0c;必要时对先前的活动进行隔离&＃xff0c;然后本地NameNode转换为活动状态。
有关自动故障转移设计的更多详细信息&＃xff0c;请参阅Apache HDFS JIRA上附加到HDFS-2185的设计文档。
在典型部署中&＃xff0c;ZooKeeper守护程序配置为在三个或五个节点上运行。由于ZooKeeper本身具有轻量级资源要求&＃xff0c;因此可以在与HDFS NameNode和备用节点相同的硬件上并置ZooKeeper节点。许多运营商选择在与YARN ResourceManager相同的节点上部署第三个ZooKeeper进程。建议将ZooKeeper节点配置为将数据存储在与HDFS元数据不同的磁盘驱动器上&＃xff0c;以获得最佳性能和隔离。
ZooKeeper的设置超出了本文档的范围。我们假设您已经设置了在三个或更多节点上运行的ZooKeeper集群&＃xff0c;并通过使用ZK CLI进行连接来验证其正确的操作。
在开始配置自动故障转移之前&＃xff0c;应关闭群集。当群集运行时&＃xff0c;目前无法从手动故障转移设置转换为自动故障转移设置。
自动故障转移的配置需要在配置中添加两个新参数。在hdfs-site.xml文件中&＃xff0c;添加&＃xff1a;
这指定应设置群集以进行自动故障转移。在您的core-site.xml文件中&＃xff0c;添加&＃xff1a;
这列出了运行ZooKeeper服务的主机端口对。
与本文档前面所述的参数一样&＃xff0c;这些设置可以通过使用名称服务ID后缀配置密钥来基于每个名称进行配置。例如&＃xff0c;在启用了联合的群集中&＃xff0c;您可以通过设置dfs.ha.automatic-failover.enabled.my-nameservice-id&＃xff0c;仅为其中一个名称服务显式启用自动故障转移。
还可以设置其他几个配置参数来控制自动故障转移的行为; 但是&＃xff0c;大多数安装都不需要它们。有关详细信息&＃xff0c;请参阅配置密钥特定文档。
添加配置密钥后&＃xff0c;下一步是在ZooKeeper中初始化所需的状态。您可以通过从其中一个NameNode主机运行以下命令来执行此操作。
[hdfs]$ $HADOOP_HOME/bin/hdfs zkfc -formatZK
这将在ZooKeeper中创建一个znode&＃xff0c;其中自动故障转移系统存储其数据。
由于配置中已启用自动故障转移&＃xff0c;因此start-dfs.sh脚本现在将在运行NameNode的任何计算机上自动启动ZKFC守护程序。当ZKFC启动时&＃xff0c;它们将自动选择其中一个NameNode变为活动状态。
如果手动管理群集上的服务&＃xff0c;则需要在运行NameNode的每台计算机上手动启动zkfc守护程序。您可以通过运行以下命令来启动守护程序&＃xff1a;
[hdfs]$ $HADOOP_HOME/bin/hdfs --daemon start zkfc
如果您正在运行安全群集&＃xff0c;则可能需要确保ZooKeeper中存储的信息也是安全的。这可以防止恶意客户端修改ZooKeeper中的元数据或可能触发错误的故障转移。
为了保护ZooKeeper中的信息&＃xff0c;首先将以下内容添加到core-site.xml文件中&＃xff1a;
请注意这些值中的“&＃64;”字符 - 这指定配置不是内联的&＃xff0c;而是指向磁盘上的文件。身份验证信息也可以通过CredentialProvider读取&＃xff08;请参阅hadoop-common项目中的CredentialProviderAPI指南&＃xff09;。
第一个配置的文件指定ZooKeeper身份验证列表&＃xff0c;格式与ZK CLI使用的格式相同。例如&＃xff0c;您可以指定以下内容&＃xff1a;
digest:hdfs-zkfcs:mypassword
...其中hdfs-zkfcs是ZooKeeper的唯一用户名&＃xff0c;mypassword是一些用作密码的唯一字符串。
接下来&＃xff0c;使用如下命令生成与此身份验证对应的ZooKeeper ACL&＃xff1a;
[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&＃61;
将此输出的部分复制并粘贴到“ - >”字符串后面的zk-acls.txt文件中&＃xff0c;前缀为字符串“ digest&＃xff1a; ”。例如&＃xff1a;
digest:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM&＃61;:rwcda
为了使这些ACL生效&＃xff0c;您应该重新运行zkfc -formatZK命令&＃xff0c;如上所述。
执行此操作后&＃xff0c;您可以从ZK CLI验证ACL&＃xff0c;如下所示&＃xff1a;
[zk: localhost:2181(CONNECTED) 1] getAcl /hadoop-ha
&＃39;digest,&＃39;hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM&＃61;
: cdrwa
设置自动故障转移后&＃xff0c;应测试其操作。为此&＃xff0c;请首先找到活动的NameNode。您可以通过访问NameNode Web界面来确定哪个节点处于活动状态 - 每个节点在页面顶部报告其HA状态。
找到活动的NameNode后&＃xff0c;可能会导致该节点出现故障。例如&＃xff0c;您可以使用 kill -9
如果测试不成功&＃xff0c;则可能是配置错误。检查日志以查找zkfc守护程序以及NameNode守护程序&＃xff0c;以便进一步诊断问题。
以任何特定顺序启动ZKFC和NameNode守护进程是否重要&＃xff1f;
在任何给定节点上&＃xff0c;您可以在其对应的NameNode之前或之后启动ZKFC。
我应该采取哪些额外的监测措施&＃xff1f;
您应该在运行NameNode的每个主机上添加监视&＃xff0c;以确保ZKFC仍在运行。例如&＃xff0c;在某些类型的ZooKeeper故障中&＃xff0c;ZKFC可能会意外退出&＃xff0c;应重新启动以确保系统已准备好进行自动故障转移。
此外&＃xff0c;您应该监视ZooKeeper仲裁中的每个服务器。如果ZooKeeper崩溃&＃xff0c;则自动故障转移将不起作用。
如果ZooKeeper出现故障会怎样&＃xff1f;
如果ZooKeeper集群崩溃&＃xff0c;则不会触发自动故障转移。但是&＃xff0c;HDFS将继续运行而不会产生任何影响。重新启动ZooKeeper时&＃xff0c;HDFS将重新连接&＃xff0c;没有任何问题。
我可以将我的一个NameNode指定为主要/首选吗&＃xff1f;
不。目前&＃xff0c;这不受支持。无论哪个NameNode首先启动都将变为活动状态。您可以选择以特定顺序启动集群&＃xff0c;以便首选节点启动。
如何配置自动故障转移时启动手动故障转移&＃xff1f;
即使配置了自动故障转移&＃xff0c;您也可以使用相同的hdfs haadmin命令启动手动故障转移。它将执行协调的故障转移。
在HDFS版本之间移动时&＃xff0c;有时可以简单地安装较新的软件并重新启动集群。但是&＃xff0c;有时升级正在运行的HDFS版本可能需要更改磁盘数据。在这种情况下&＃xff0c;必须在安装新软件后使用HDFS Upgrade / Finalize / Rollback工具。此过程在HA环境中变得更加复杂&＃xff0c;因为NN依赖的磁盘上元数据按定义分布&＃xff0c;在该对中的两个HA NN上&＃xff0c;以及在使用QJM的情况下的JournalNodes上。共享编辑存储。本文档部分介绍了在HA设置中使用HDFS Upgrade/Finalize/Rollback 功能的过程。
要执行HA升级&＃xff0c;操作员必须执行以下操作&＃xff1a;
正常关闭所有NN&＃xff0c;并安装较新的软件。
启动所有JN。请注意&＃xff0c;这是至关重要的&＃xff0c;所有的JNS执行升级&＃xff0c;回滚或完成操作时运行。如果在运行任何这些操作时任何JN出现故障&＃xff0c;操作将失败。
使用&＃39;-upgrade&＃39;标志启动其中一个NN。
一开始&＃xff0c;此NN将不会像HA设置中那样正常进入待机状态。相反&＃xff0c;此NN将立即进入活动状态&＃xff0c;执行其本地存储目录的升级&＃xff0c;并执行共享编辑日志的升级。
此时&＃xff0c;HA对中的其他NN将与升级的NN不同步。为了使其恢复同步并再次具有高可用性设置&＃xff0c;您应该通过使用&＃39;-bootstrapStandby&＃39;标志运行NN来重新引导此NameNode 。使用&＃39;-upgrade&＃39;标志启动第二个NN是错误的。
请注意&＃xff0c;如果您想在最终确定或回滚升级之前重新启动NameNode&＃xff0c;则应该正常启动NN&＃xff0c;即没有任何特殊的启动标志。
要查询升级状态&＃xff0c;操作员将使用&＃96;hdfs dfsadmin -upgrade query&＃39;命令&＃xff0c;而至少有一个NN正在运行。对于每个NN&＃xff0c;该命令将返回NN升级过程是否已完成。
要完成HA升级&＃xff0c;操作员将在NN运行且其中一个处于活动状态时使用&＃96;hdfs dfsadmin -finalizeUpgrade&＃39;命令。发生这种情况时的活动NN将执行共享日志的最终确定&＃xff0c;并且其本地存储目录包含先前FS状态的NN将删除其本地状态。
要执行升级回滚&＃xff0c;应首先关闭两个NN。操作员应在NN上执行回滚命令&＃xff0c;在NN上启动升级过程&＃xff0c;该过程将在那里的本地目录以及共享日志&＃xff08;NFS或JN&＃xff09;上执行回滚。之后&＃xff0c;应启动此NN&＃xff0c;操作员应在另一个NN上运行&＃96;-bootstrapStandby&＃39;&＃xff0c;以使两个NN与此回滚文件系统状态同步。
原文链接: https://hadoop.apache.org/docs/r3.2.0/
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有