公告

为了让standby node保持与active node同步状态，node使用独立的守护进程JournalNodes来交流。当任何namespace修改都是在active node上。然后会修改到多数的JNs。Standby node可以从JNs中读取editlog，并且不断查看editlog的修改。Standby node会查看edit，然后应用到自己的namespace。如果failoverstandby会保证已经读取了所有的editlog。保证namespace在failover之前被完全同步。

为了提供最快的failover，standby node必须有集群block中最新的信息。为了达到，namenode被配置为location在所有的namenode，并且block location信息和心跳会发送到所有的namenode。

Namenode一个时间内只能有一个active，为了避免出现脑裂JouralNodes只允许一个namenode写入。在failover时，namenode会变成active也会替换写入JournalNodes的角色，这样可以防止其他namenode变成active，让新的active进行安全的切换。

4.5 硬件资源

为了部署HA集群，你需要准备一下：

· Namenode设备，active和standby namenode需要有一样的设备

· JournalNode设备，JournalNode是比较轻量的，可以和其他hadoop进程一起存在。Node:至少要有3个JournalNode进程，因为edit log修改会要求写入多数JNs。允许系统去兼容单点故障。一般都适用3个进程，也可以增加，从而增加容错。

在HA集群中，standby的namenode也会执行checkpoint，因此不需要secondary node，backup node，checkpoint node。

4.6 部署

4.6.1 配置概述

配置类似于namenode联合，HA的允许配置已经存在的单个namenode继续工作不需要修改。新的配置被设计成，所有cluster的node都有一样的配置，不需要为不通的设备配置不通的配置文件。

和HDFS联合一样，HA集群使用nameserivce ID来识别一个HDFS实例，也可能是一个多个Namenode 的HA。另外一个新的抽象Namenode ID在HA中被使用。每个不通的Namenode有一个不通的namenode id来分别。为了支持一个配置文件到处使用，有些配置使用nameservice id或者namenode id后缀。

4.6.2 详细配置

为了配置namenode HA，你必须增加一些选项在hdfs-site.xml里面

这些配置的顺序是不重要的，但是dfs.nameservices和dfs.ha.namenodes.[nameservice ID]的值是比较重要的。因此你需要知道这些值，才能配置后面的参数：

· Dfs.nameservices 新的nameservice的逻辑名
为nameservice选择一个逻辑名，比如mycluster，并且使用这个逻辑名，完成后面的配置。这个名字是任意的。会用来配置和HDFS绝对路径的组件。
注意，如果你也使用HDFS联合，那这个配置要包含其他的namespace，HA等，使用逗号分隔。
<property>
<name>dfs.nameservices</name>
<value>mycluster</value>
</property>

· dfs.ha.namenodes.[nameservice ID] 用来唯一标识nameservice中的namenode
使用逗号来分割，可以让datanode确定所有的集群中的namenode，比如你使用mycluster作为nameservice ID，使用nn1,nn2,nn3标识namenode。
<property> <name>dfs.ha.namenodes.mycluster</name> <value>nn1,nn2, nn3</value></property>
注意：namenode的最小数量是2，但是可以配置的更多，但是不建议超过5个，推荐3个，因为有交互的压力。

· dfs.namenode.rpc-address.[nameservice ID].[name node ID] 设置每个namenode监听的端口。
通过之前配置的namenode id来配置namenode监听的端口。
<property>
<name>dfs.namenode.rpc-address.mycluster.nn1</name>
<value>machine1.example.com:9820</value>

</property>

<property>
<name>dfs.namenode.rpc-address.mycluster.nn2</name>
<value>machine2.example.com:9820</value>

</property>

<property>
<name>dfs.namenode.rpc-address.mycluster.nn3</name>
<value>machine3.example.com:9820</value>

</property>

Servicerpc-address也可以差不多一样来配置。

· dfs.namenode.http-address.[nameservice ID].[name node ID] 配置namenode 的http监听

如果启动了hadoop的安全选项，还需要为每个namenode配置https-address

· dfs.namenode.shared.edits.dir 设置namenode可以读写编辑的JNs
配置了提供shared edit storage的journalnode，由active namenode写入，standby namenode读取更新standby node。尽管你必须制定多个JournalNode地址，但是只需要配置一个。URI的格式如下：qjournal://*host1:port1*;*host2:port2*;*host3:port3*/*journalId*。Journal ID是nameserivce的唯一标识，允许一个journalnode来自于多个联合的namesystem。尽管不是需要的，但是使用nameservice id作为journal标识是很好的选择。
比如journalnodes运行在“node1.example.com”, “node2.example.com”, 和“node3.example.com”，nameservice id是mycluster，可以用这些来配置了（默认端口是8485）

· dfs.ha.fencing.methods 在failover时，用这个脚本或者java classes来隔离活动的namenode。
这在一个时间内只有一个active namenode是可取的。当使用Quorum Journal Manager，只有一个namenode允许被写入到journalnode，那么就有可能因为脑裂出现元数据损坏。然而当failover发生，之前的active namenode还是会服务客户端的读请求，当尝试写入journalnode的时候namenode被关闭，从而过期。对于这个原因，还是可以在使用Quorum Journal Manager的时候使用一些隔离的方法。
sshfence SSH来kill活动的进程
sshfence选项SSH到目标服务器使用fuser kill监听端口的服务。为了让这个隔离工作需要设置无验证ssh到目标服务器上。因此还需要配置dfs.ha.fencing.ssh.private-key-files，使用逗号分隔：

其他选项，因为连接可能会超时，或者指定其他用户和端口来连接。超时单位是毫秒

shell 运行任意的shell命令来隔离活动的namenode
shell隔离方法是指定一个shell命令：

括号里面的值会直接被传到bash中。

· fs.defaultFS当没有指定的时候，客户端连接的默认的hadoop fs
配置启动ha之后的uri。如果使用mycluster作为nameservice id，那么可以作为HDFS路径的一部分比如：

· dfs.journalnode.edits.dir journalnode进程用来保存本地状态的路径
journalnode设备的绝对路径用来保存edit和其他JNs使用的local状态。这个配置可能只使用一个路径。通过配置多个journalnode来冗余

4.6.3 部署细节

一些必要的配置都配置了之后，启动journalnode进程。使用命令hdfs --daemon start journalnode启动journalnode。

一旦journalnode被启动之后需要做个初始化操作，磁盘上同步元数据。

· 如果你设置了HDFS集群，就需要在其中一个namenode上启动命令

· 如果已经有了初始化有的namenode，或者已经有一个没有启动HA的集群要设置为启动HA，那么就要复制namenode的元数据目录到其他的node中。运行hdfs namenode –bootstrapStandby在非格式化的namenode中。使用这个命令也保证了joournalnode有足够的日志来启动2个namenode。

· 如果你转化非HA的namenode到HA的。需要运行hdfs namenode –initializeSharedEdits，从namenode edit目录初始化journalnode。

这个时候所有的namenode就和一个namenode一样。

你可以访问每个namenode 的网站。然后注意HA状态是standby还是active，当每个namenode启动时，一开始的状态都是standby状态。

4.6.4 管理命令

现在HA namenode已经配置好了并且已经启动了，那么就会有一些额外的管理命令，

Usage: haadmin

[-transitionToActive <serviceId>]

[-transitionToStandby <serviceId>]

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

[-getServiceState <serviceId>]

[-getAllServiceState]

[-checkHealth <serviceId>]

[-help <command>]

子命令的帮助可以查看hdfs haadmin -help <command>

· transitionToActive和transitionToStandby 转化standby和active的状态。
这2个子命令会导致namenode的状态转化。这个命令不会有隔离，因此尽量不要用。应该使用hdfs haadmin –failover命令

· failover 在2个namenode之间做切换
这个子命令会导致namenode之间的failover。如果第一个namenode是standby状态，这个命令只是把第二个node设置为active。如果第一个namenode是active的，就会被转化为standby。如果出现错误那么隔离方法（dfs.ha.fencing.methods）就会尝试直到成功。这个过程完了之后第二个node会变成active状态。如果隔离方法没有成功，第二个namenode不会被转化为active状态，会错误退出。

· getServiceState 确定namenode是active还是standby
连接到namenode并确定当前的状态，standby或者active会输出。

· getAllServiceState 返回所有namenode的状态
连接到配置好的namenode来决定当前的状态，输出standy或者active

· checkHealth 检查指定namenode的健康
连接到namenode来检查健康。Namenode有能力自己诊断，包括检查服务是否预期运行。如果返回0表示健康，否则非0。这个功能还没实现。

4.7 自动切换

4.7.1 说明

上面描述配置手动故障转移。如果namenode报错也不会自动转移。

4.7.2 组件

自动故障转移增加了2个新的组件，zookeeper quorum和ZKFailoverController进程(ZKFC)。

Apache Zookeeper是高可用的服务维护了少量的协作数据，通知客户端数据的修改，并且监控客户端的错误。HDFS的自动故障转移依赖于Zookeeper:

· 错误诊断每个nanenode在ZooKeeper中维护了一个长连接。如果机器crash，ZooKeeper会话会过期，通知其他namenode做failover

· Active Namenode选举，Zookeeper提供简单的机制选举一个node作为active。如果当前的active namenode crash。另外一个node会获取一个在ZooKeeper的排他锁，表示它会变成下一个active

ZKFailoverController(ZKFC)是一个新的组件，是一个ZooKeeper客户端可以用来监控和管理namenode 的状态。每个namenode都运行了ZKFC,ZKFC主要工作：

· Health监控 ZKFC 定期的ping 本地的namenode作为健康检查。如果namenode定期回复那么就认为是健康的，如果node crash，frozen或者其他原因不健康，那么健康监控会标记为不健康。

· ZooKeeper会话管理当本地namenode 是健康的，ZKFC会在ZooKeeper打开一个会话。如果本地namenode是活动的，会获取一个指定的lock。这个lock会使用ZooKeeper支持的ephemeral node如果会话过期，lock node会被自动删除。

· ZooKeeper基于选举如果namenode是健康的，ZKFC发现没有lock znode,那么就会去获取这个锁，如果成功，那么就赢得了选举，返回failover结果local namenode acitive。Failover过程和手动failover相似：第一，之前的active隔离是必要的，然后local namenode 转化为 active 。

自动failover，查看HDFS-2185，HDFS JIRA。

4.7.3 部署Zookeeper

在通常部署，Zookeeper配置运行3个或者5个node，Zookeeper自身是轻量的可以放在namenode或者standby node上。很多会部署在和Zookeeper进程会和yarn resourcemanager同一个node上。推荐把Zookeeper node保存在独立的磁盘上，用于隔离性能问题。

4.7.4 开始配置前

在开始配置自动故障转移前，需要先关闭集群。当在集群运行的情况下，把手动转移转化为自动转移是不可能的。

4.7.5 配置自动故障转移

为了自动故障转移，配置2个参数，hdfs-site.xml中：

指定那些需要自动故障转移的node,core-site.xml中：

运行了Zookeeper服务的host和端口。

这些设置可以配置在每个nameservice上，使用nameservice的前缀。比如cluster启动了联合，那么就可以为某个nameservice配置自动故障转移，配置dfs.ha.automatic-failover.enabled.my-nameservice-id。

这里还有一些其他配置自动故障，但是对大多数来说是没必要的。

4.7.6 初始化Zookeeper中的HA状态

配置好之后，下一步就是初始化Zookeeper的状态。可以用一下命令在一个namenode上运行：

然后在Zookeeper中创建znode，里面保存了自动故障转移的数据。

4.7.7 启动start-dfs.sh

因为自动故障转移已经在配置文件中设置，start-dfs.sh脚本会自动启动ZKFC进程，启动之后会自动选择一个namenode称为active。

4.7.8 手动启动cluster

如果是手动管理cluster的，需要手动启动zkfc进程。

4.7.9 Zookeeper安全访问

如果运行了安全的cluster，也需要保证保存在Zookeeper也是安全的。这样可以防止用户恶意修改元数据，活导致错误的faliover。

为了安全的Zookeeper，在core-site.xml添加一下信息：

这里的@，配置的值不是这个值，而是指向的文件。

第一个文件列出了Zookeeper的验证，和ZK CLI的格式一样：

Hdfs-zkfcs是Zookeeper的唯一用户名，mypassword是密码。

下一步生成关联到验证的Zookeeper ACL，使用命令行如下：

然后把输出的->之后的字符串复制到zk-acls.txt,并且带着digest前缀：

为了让ACL生效，需要运行zkfc –formatZK命令。

然后就可以在ZK CLI验证ACLS：

4.7.10 验证自动failover

一旦自动故障转移已经启动，那么就需要测试操作。首先定位在active namenode。可以从namenode 的网站查看namenode 的状态。

一旦定位到活动的namenode，使用 kill -9 pid来模拟jvm崩溃，或者可以关机，或者拔网线来模拟。一旦触发，在几秒内其他的namenode会自动变active。发现错误，触发failover的时间取决于配置，ha.zookeeper.session-timeout.ms，默认是5秒。

如果测试没有成功，可能有配置错误。检查zkfc进程和namenode进程日志来发现问题。

4.8 自动故障转移FAQ

· Is it important that I start the ZKFC and NameNode daemons in any particular order?

No. On any given node you may start the ZKFC before or after its corresponding NameNode.

· What additional monitoring should I put in place?

You should add monitoring on each host that runs a NameNode to ensure that the ZKFC remains running. In some types of ZooKeeper failures, for example, the ZKFC may unexpectedly exit, and should be restarted to ensure that the system is ready for automatic failover.

Additionally, you should monitor each of the servers in the ZooKeeper quorum. If ZooKeeper crashes, then automatic failover will not function.

· What happens if ZooKeeper goes down?

If the ZooKeeper cluster crashes, no automatic failovers will be triggered. However, HDFS will continue to run without any impact. When ZooKeeper is restarted, HDFS will reconnect with no issues.

· Can I designate one of my NameNodes as primary/preferred?

No. Currently, this is not supported. Whichever NameNode is started first will become active. You may choose to start the cluster in a specific order such that your preferred node starts first.

· How can I initiate a manual failover when automatic failover is configured?

Even if automatic failover is configured, you may initiate a manual failover using the same hdfs haadmin command. It will perform a coordinated failover.

4.9 启动HA的HDFS Upgrade/Finalization/Rollback

在HDFS版本移动，有时候新的软件可以简单的被安装，然后重启cluster。有时候更新HDFS，可能需要修改磁盘中的数据。这个时候在安装的新的软件之后必须使用HDFS Upgrade/Finalize/Rollback。在HA环境下这个过程会变得更加复杂，因为磁盘上的元数据是分布式的，包括HA NN和journal node。这里介绍HA下使用HDFS Upgrade/Finalize/Rollback过程：

执行HA更新步骤，操作如下：

1.关闭所有NN，安装新的软件。

2.启动所有的JNs。注意在执行更新，回滚或者完成操作的时候JNs是运行的。如果在操作的时候JNs down，操作就会失败。

3.以-upgrade 启动其中一个。

4.在移动的时候，NN不会进入standby状态，NN会进入active状态，然后更新本地存储目录，并且执行edit log的更新。

5.这个时候其他NN没有和更新后的NN保持同步。为了回到同步，并且重启高可用，需要在namenode上重新执行带-bootstrapStandby标记。如果第二个也使用-upgrade那么就会报错。

注意如果在finalizing或者rollback更新前，任何时候你想要重启namenode，需要以政策方式启动namenode，不需要其他参数。

完成HA更新，当已经有一个namenode是active，使用命令hdfs dfsadmin –finalizeUpgrade。

回滚更新，namenode需要先被关闭。需要在namenode执行rollback命令。

posted on 2018-03-22 13:00 Fanr_Zh 阅读(449) 评论(0) 编辑收藏举报

刷新页面返回顶部