[原创]Hadoop-2.5.2-HA原文译

欲忘树

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

　　* 与HDFS联合一样，HA群集使用名称服务ID（nameservice>　　* 配置详情
　　* hdfs-site.xml
　　* 要配置HA NameNode，必须向hdfs-site.xml配置文件中添加多个配置选项。

　　* 设置这些配置的顺序并不重要，但是为dfs.nameservices和dfs.ha.namenodes [nameservice>　　* dfs.nameservices - 新nameservice的逻辑名
　　* 为此名称服务选择一个逻辑名称，例如“mycluster”，并将此逻辑名称用于此配置选项的值。你选择的名字是任意的。它将用于配置和作为集群中绝对HDFS路径的权限组件。
　　Note:如果您还使用HDFS Federation，此配置设置还应包括其他名称服务（HA或其他）的列表，以逗号分隔列表。
　　<property>
　　<name>dfs.nameservices</name>
　　<value>mycluster</value>
　　</property>

　　* dfs.ha.namenodes.[nameservice>
　　* 使用逗号分隔的NameNode>　　* 例如，如果以前使用“mycluster”作为名称服务ID，并且您希望使用“nn1”和“nn2”作为NameNode的各个ID，您可以这样配置：
　　<property>
　　<name>dfs.ha.namenodes.mycluster</name>
　　<value>nn1,nn2</value>
　　</property>
　　Note:目前，每个nameservice最多只能配置两个NameNode。

　　* dfs.namenode.rpc-address.[nameservice>
　　* 对于之前配置的NameNode>　　<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>
　　Note:如果您愿意，您可以类似地配置“servicerpc-address”设置。

　　* dfs.namenode.http-address.[nameservice>　　* 与上面的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>
　　Note:如果您启用了Hadoop的安全功能，您还应该为每个NameNode设置类似的https地址。
　　* dfs.namenode.shared.edits.dir - 标识NameNode将要读写edits的JNs组的URI
　　* 这是配置提供共享编辑存储的JournalNode的地址的地方，由Active NameNode写入并由Standby NameNode读取以保持最新与Active NameNode做出的所有文件系统更改。

　　* 虽然必须指定多个JournalNode地址，但您只应配置其中一个URI。 URI的格式应为：“qjournal：// host1：port1; host2：port2; host3：port3 / journalId”。Journal>　　* 例如，如果此群集的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>　　* 配置将由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 - 将用于在故障转移期间屏蔽Active 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 给Active NameNode 并 杀掉此进程
　　* sshfence选项SSH到目标节点，并使用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配置变量的环境运行，其中“_”字符替换在配置键中的任何“.”字符。
　　* 所使用的配置已经将任何特定于namenode的配置提升为其通用形式
　　* 例如dfs_namenode_rpc-address将包含目标节点的RPC地址，即使配置可能将该变量指定为dfs.namenode.rpc-address.ns1.nn1。
　　* 此外，还可以使用以下指向要保护的目标节点的变量：
　　$target_host:   hostname of the node to be fenced
　　$target_port:   IPC port of the node to be fenced
　　$target_address:    the above two, combined as host:port

　　$target_nameserviceid:  the nameservice>
　　$target_namenodeid: the namenode>　　* 这些环境变量也可以用作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，则确定防护成功。如果它返回任何其他退出代码，防护不成功，将尝试列表中的下一个防护方法。
　　Note:此防护方法不实现任何超时。如果超时是必要的，它们应该在shell脚本本身中实现（例如通过派生子shell在几秒钟内杀死它的父进程）。
　　* 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>         
　　* core-site.xml (可选的)
　　* fs.defaultFS - 当没有给出时，Hadoop FS客户端使用的默认路径前缀
　　* 可选的配置项，您现在可以配置Hadoop客户端的默认路径以使用新的HA启用的逻辑URI。
　　* 如果您之前使用“mycluster”作为名称服务ID，则这将是所有HDFS路径的权限部分的值。
　　* 这可能是这样配置的，在您的core-site.xml文件中：
　　<property>
　　<name>fs.defaultFS</name>
　　<value>hdfs://mycluster</value>
　　</property>
　　* 部署详情
　　* 在设置了所有必需的配置选项后，必须在将要运行它们的计算机集上启动JournalNode守护程序。
　　* 这可以通过运行命令“hdfs-daemon.sh journalnode”并等待守护程序在每个相关机器上启动来完成。
　　* 一旦启动了JournalNode，必须首先同步两个HA NameNode的磁盘元数据。
　　* 如果要设置一个新的HDFS集群，您应该首先在一个NameNode上运行format命令（hdfs namenode -format）。
　　* 如果您已经格式化了NameNode，或者正在将非HA启用的集群转换为启用HA，那么现在应该通过在未被格式化的NameNode上运行命令“hdfs namenode -bootstrapStandby" 复制元数据目录的内容到别的，未被格式化的NameNode上。
　　* 运行此命令还将确保JournalNode（由dfs.namenode.shared.edits.dir配置）包含足够的编辑事务，以便能够启动两个NameNode。
　　* 如果要将非HA NameNode转换为HA，则应运行命令“hdfs -initializeSharedEdits”，该命令将使用来自本地NameNode edits目录的edits数据初始化JournalNodes。
　　* 此时，您可以像启动一个NameNode一样启动两个HA NameNode。
　　* 您可以通过浏览其配置的HTTP地址单独访问每个NameNodes的网页。
　　* 您应该注意到，配置的地址旁边将是NameNode的HA状态（“备用”或“活动”。）每当HA NameNode启动时，它最初处于备用状态。
　　* 管理命令
　　* 现在您的HA NameNode已配置并启动，您将可以访问一些其他命令来管理HA HDFS集群。
　　* 具体来说，您应该熟悉“hdfs haadmin”命令的所有子命令。
　　* 运行此命令而没有任何其他参数将显示以下使用信息：
　　Usage: DFSHAAdmin [-ns <nameserviceId>]

[-transitionToActive <serviceId>]

[-transitionToStandby <serviceId>]

[-failover [--forcefence] [--forceactive] <serviceId> <serviceId>]

[-getServiceState <serviceId>]

[-checkHealth <serviceId>]

[-help <command>]

　　* 本指南介绍了每个子命令的高级用法。有关每个子命令的具体使用信息，应运行“hdfs haadmin -help <command>”。
　　* transitionToActive and transitionToStandby - 将给定NameNode的状态转换为Active或Standby.
　　* 这些子命令分别使给定的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，否则为非零。可以使用此命令进行监视。
　　Note:这还没有实现，并且目前将始终返回成功，除非给定的NameNode完全关闭。