做此广告的网站,做家纺的网站,长宁长沙网站建设,工作组赴平凉事故现场HA With QJM 目标 本指南概述了HDFS高可用性#xff08;HA#xff09;功能以及如何使用Quorum Journal Manager#xff08;QJM#xff09;功能配置和管理HA HDFS集群。 本文档假设读者对HDFS集群中的一般组件和节点类型有一般的了解。有关详细信息#xff0c;请参阅HDFS架…HA With QJM 目标 本指南概述了HDFS高可用性HA功能以及如何使用Quorum Journal ManagerQJM功能配置和管理HA HDFS集群。 本文档假设读者对HDFS集群中的一般组件和节点类型有一般的了解。有关详细信息请参阅HDFS架构指南。 本指南讨论如何使用Quorum Journal ManagerQJM配置和使用HDFS HA以在Active和Standby NameNodes之间共享编辑日志 背景 在Hadoop 2.0.0之前NameNode是HDFS集群中的单点故障SPOF。每个集群都有一个NameNode如果该机器或进程变得不可用则整个集群将不可用直到NameNode重新启动或在单独的计算机上启动。 这两个方面影响了HDFS集群的总体可用性 在计算机事件例如机器崩溃的情况下集群将不可用直到操作员重新启动NameNode。 NameNode机器上的计划维护事件如软件或硬件升级将导致集群停机时间的窗口。 HDFS高可用性功能通过提供在具有热备用的主动/被动配置中的同一集群中运行两个冗余名称节点来解决上述问题。这允许在机器崩溃的情况下快速故障切换到新的NameNode或者为了计划维护而对管理员启动的优化优雅转换。 架构 在典型的HA集群中将两台独立的计算机配置为NameNodes。在任何时间点其中一个NameNodes处于活动状态另一个处于待机状态。Active NameNode负责集群中的所有客户端操作而Standby仅作为从站维护足够的状态以在必要时提供快速故障转移。 为了使备用节点保持与Active节点同步的状态两个节点都与一组名为“JournalNodes”JN的独立守护程序进行通信。当Active节点执行任何命名空间修改时它可以将修改的记录持久记录到大多数这些JN。备用节点能够读取JN的编辑并且不断地观察它们对编辑日志的更改。当待机节点看到编辑时它将它们应用于自己的命名空间。在故障切换的情况下待机将确保它已经读取了JounalNodes的所有编辑然后再将其自身升级到Active状态。这将确保名称空间状态在发生故障转移之前完全同步。 为了提供快速故障切换还需要备用节点具有有关集群中块的位置的最新信息。为了实现这一点DataNodes配置有两个NameNodes的位置并向两者发送块位置信息和心跳。 对于HA群集的正确操作至关重要因此一次只能有一个NameNodes处于活动状态。否则命名空间状态将在两者之间快速分离冒着数据丢失或其他不正确的结果。为了确保这种属性并防止所谓的“脑裂”JournalNodes将只允许一个NameNode作为一个作者。在故障切换期间要变为活动状态的NameNode将简单地接管写入JournalNodes的角色这将有效地防止其他NameNode继续处于活动状态允许新的Active安全地进行故障转移。 硬件资源 为了部署HA群集您应该准备以下内容 NameNode机器 - 运行Active和Standby NameNodes的机器应具有彼此的等效硬件以及与非HA集群中使用的硬件相同的硬件。 JournalNode机器 - 运行JournalNodes的机器。JournalNode守护进程是相对轻量级的因此这些守护进程可能会合理地与其他Hadoop守护程序例如NameNodesJobTracker或YARN ResourceManager并置在机器上。注意必须至少有3个JournalNode守护程序因为编辑日志修改必须写入大多数JN。这将允许系统容忍单个机器的故障。您也可以运行超过3个JournalNodes但为了实际增加系统可以忍受的故障次数您应该运行奇数JN即357等。请注意当使用N JournalNodes运行时系统最多可以忍受N-1/ 2故障并继续正常工作 请注意在HA群集中Standby NameNode还执行命名空间状态的检查点因此不需要在HA群集中运行Secondary NameNodeCheckpointNode或BackupNode。其实这样做会是一个错误。这还允许正在重新配置不支持HA的HDFS集群的HA被启用以重新使用先前专用于Secondary NameNode的硬件。 部署 配置概述 与联邦配置类似HA配置向后兼容并允许现有的单个NameNode配置工作无需更改。新配置被设计为使得集群中的所有节点可以具有相同的配置而不需要基于节点的类型将不同的配置文件部署到不同的机器。 像HDFS联盟一样HA集群重新使用名称服务ID来标识单个HDFS实例其实际上可能由多个HA名称节点组成。另外一个称为NameNode ID的新抽象与HA一起添加。群集中的每个不同的NameNode具有不同的NameNode ID来区分它。为了支持所有NameNodes的单个配置文件相关配置参数后缀名称服务ID以及NameNode ID。 配置细节 要配置HA NameNodes必须在hdfs-site.xml配置文件中添加多个配置选项。 您设置这些配置的顺序不重要但是您为dfs.nameservices和dfs.ha.namenodes.[nameservice ID]选择的值将决定随后的键。因此在设置其余的配置选项之前您应该决定这些值。 dfs.nameservices 新服务的逻辑名称 为此名称服务器选择一个逻辑名称例如“mycluster”并使用此逻辑名称作为此配置选项的值。你选择的名字是任意的。它将用于配置和集群中绝对HDFS路径的权限组件。 注意如果您还使用HDFS联合则此配置设置还应包含其他名称服务HA或其他的列表以逗号分隔列表。 propertynamedfs.nameservices/namevaluemycluster/value
/property dfs.ha.namenodes.[nameservice ID] 名称服务中每个NameNode的唯一标识符 使用以逗号分隔的NameNode ID的列表进行配置。DataNodes将使用它来确定集群中的所有NameNodes。例如如果以前使用“mycluster”作为nameervice ID并且想要使用“nn1”和“nn2”作为NameNodes的个别ID则可以将其配置为 propertynamedfs.ha.namenodes.mycluster/namevaluenn1,nn2/value
/property 注意目前每个名称服务器最多只能配置两个NameNodes。 dfs.namenode.rpc-address.[nameservice ID].[name node ID] 每个NameNode要收听的完全限定的RPC地址 对于以前配置的两个NameNode ID请设置NameNode进程的完整地址和IPC端口。请注意这将导致两个单独的配置选项。例如 propertynamedfs.namenode.rpc-address.mycluster.nn1/namevaluemachine1.example.com:8020/value
/property
propertynamedfs.namenode.rpc-address.mycluster.nn2/namevaluemachine2.example.com:8020/value
/property 注意如果您愿意也可以配置“servicerpc-address”设置。 dfs.namenode.http-address.[nameservice ID].[name node ID] 每个NameNode要监听的完全限定的HTTP地址 类似于上面的rpc-address设置两个NameNodes的HTTP服务器进行监听的地址。例如 propertynamedfs.namenode.http-address.mycluster.nn1/namevaluemachine1.example.com:50070/value
/property
propertynamedfs.namenode.http-address.mycluster.nn2/namevaluemachine2.example.com:50070/value
/property 注意如果您启用了Hadoop的安全功能您还应该为每个NameNode设置类似的https地址 dfs.namenode.shared.edits.dir 标识NameNodes JN组进程将写/读EditLog的URI 这是一个配置提供共享编辑存储的JournalNodes的地址由Active nameNode写入并由Standby NameNode读取以保持Active NameNode所做的所有文件系统更改的最新。虽然您必须指定几个JournalNode地址但您只能配置其中一个URI。URI的格式应为“qjournal// host1port1; host2port2; host3port3 / journalId”。日记帐ID是此名称服务的唯一标识符允许单个JournalNodes集合为多个联合名称系统提供存储。虽然不是一个要求但是重新使用日志标识符的名称服务ID是个好主意。 例如如果此群集的JournalNodes在机器“node1.example.com”“node2.example.com”和“node3.example.com”上运行并且名称服务ID为“mycluster”则将使用以下作为此设置的值JournalNode的默认端口为8485 propertynamedfs.namenode.shared.edits.dir/namevalueqjournal://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因此除非您使用自定义的。例如 propertynamedfs.client.failover.proxy.provider.mycluster/namevalueorg.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider/value
/property dfs.ha.fencing.methods 在故障切换期间将用于隔离Active NameNode的脚本或Java类的列表 对于系统的正确性期望在任何给定时间只有一个NameNode处于活动状态。重要的是当使用Quorum Journal Manager时只有一个NameNode将被允许写入JournalNodes所以不存在从裂脑场景中破坏文件系统元数据的可能性。但是当发生故障切换时以前的Active NameNode可能会向客户端提供读取请求这可能是过期的直到该NameNode在尝试写入JournalNodes时关闭。因此即使使用Quorum Journal Manager仍然需要配置一些防护方法。但是为了提高系统在防护机制发生故障时的可用性建议配置防护方法保证将其作为列表中最后的防护方法返回成功。请注意如果您选择不使用实际的防护方法您仍然必须为此设置配置一些东西例如“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私钥文件列表。例如 propertynamedfs.ha.fencing.methods/namevaluesshfence/value/propertypropertynamedfs.ha.fencing.ssh.private-key-files/namevalue/home/exampleuser/.ssh/id_rsa/value/property 或者可以配置非标准用户名或端口来执行SSH。也可以为SSH配置超时时间以毫秒为单位之后该防护方法将被认为失败。它可以像这样配置 propertynamedfs.ha.fencing.methods/namevaluesshfence([[username][:port]])/value/propertypropertynamedfs.ha.fencing.ssh.connect-timeout/namevalue30000/value/property shell 运行一个任意的shell命令来终止Active NameNode shell防护方法运行任意shell命令。它可以像这样配置 propertynamedfs.ha.fencing.methods/namevalueshell(/path/to/my/script.sh arg1 arg2 ...)/value
/property and之间的字符串直接传递给bash shell可能不包括任何关闭括号。 shell命令将运行环境设置为包含所有当前的Hadoop配置变量_字符替换任何。。配置键中的字符。所使用的配置已经具有提升为其通用形式的任何特定于Namenode的配置 - 例如dfs_namenode_rpc-address将包含目标节点的RPC地址即使配置可以将该变量指定为dfs.namenode.rpc-address。ns1.nn1。 另外还可以使用下列变量来指定要围栏的目标节点 $target_hosthostname of the node to be fenced$target_portIPC port of the node to be fenced$target_addressthe above two, combined as host:port$target_nameserviceidthe nameservice ID of the NN to be fenced$target_namenodeidthe namenode ID of the NN to be fenced 这些环境变量也可以用作shell命令本身的替代。例如 propertynamedfs.ha.fencing.methods/namevalueshell(/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文件中可以这样配置 propertynamefs.defaultFS/namevaluehdfs://mycluster/value
/property dfs.journalnode.edits.dir JournalNode守护程序将存储其本地状态的路径 这是日志节点计算机上绝对路径其中JN将使用编辑和其他本地状态。您只能使用单一路径进行此配置。通过运行多个独立的JournalNodes或通过在本地连接的RAID阵列上配置此目录来提供此数据的冗余。例如 propertynamedfs.journalnode.edits.dir/namevalue/path/to/journal/node/local/data/value
/property 部署细节 //TODO HA With NFS 目标 本指南概述了HDFS高可用性HA功能以及如何配置和管理HA HDFS集群使用NFS作为NameNodes所需的共享存储。 本文档假设读者对HDFS集群中的一般组件和节点类型有一般的了解。有关详细信息请参阅HDFS架构指南。 架构 在典型的HA集群中将两台独立的计算机配置为NameNodes。在任何时间点其中一个NameNodes处于活动状态另一个处于待机状态。Active NameNode负责集群中的所有客户端操作而Standby仅作为从站维护足够的状态以在必要时提供快速故障转移。 为了使备用节点将其状态与Active节点保持同步当前实现要求两个节点都可以访问共享存储设备上的目录例如从NAS安装NFS。这种限制在将来的版本中可能会放宽。 当Active节点执行任何命名空间修改时它可以将修改的记录持久记录到共享目录中存储的编辑日志文件中。待机节点一直在观看此目录以进行编辑并且当它看到编辑时它将其应用于其自己的命名空间。在故障切换的情况下待机将确保已经从共享存储中读取所有编辑然后再将其自身升级到活动状态。这将确保名称空间状态在发生故障转移之前完全同步。 为了提供快速故障切换还需要备用节点具有有关集群中块的位置的最新信息。为了实现这一点DataNodes配置有两个NameNodes的位置并向两者发送块位置信息和心跳 对于HA群集的正确操作至关重要因此一次只能有一个NameNodes处于活动状态。否则命名空间状态将在两者之间快速分离冒着数据丢失或其他不正确的结果。为了确保这种属性并防止所谓的“脑裂”JournalNodes将只允许一个NameNode作为一个作者。在故障切换期间要变为活动状态的NameNode将简单地接管写入JournalNodes的角色这将有效地防止其他NameNode继续处于活动状态允许新的Active安全地进行故障转移。 硬件资源 为了部署HA群集您应该准备以下内容 NameNode机器 - 运行Active和Standby NameNodes的机器应具有彼此的等效硬件以及与非HA集群中使用的硬件相同的硬件。 共享存储 - 您将需要一个共享目录这两个NameNode机器可以具有读/写访问权限。通常这是一个远程文件管理器它支持NFS并安装在每个NameNode机器上。目前只支持单个共享编辑目录。因此系统的可用性受到该共享编辑目录的可用性的限制因此为了删除共享编辑目录需要冗余的所有单个故障点。具体来说存储的多个网络路径以及存储本身的冗余磁盘网络和电源。扼杀这一点建议共享存储服务器是高品质的专用NAS设备而不是一个简单的Linux服务器。 请注意在HA群集中Standby NameNode还执行命名空间状态的检查点因此不需要在HA群集中运行Secondary NameNodeCheckpointNode或BackupNode。其实这样做会是一个错误。这还允许正在重新配置不支持HA的HDFS集群的HA被启用以重新使用先前专用于Secondary NameNode的硬件。 转载于:https://www.cnblogs.com/Dhouse/p/7447428.html
