[HDFS Manual] CH4 HDFS High Availability Using the Quorum Journal Manager

为了让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命令。