我要评论
HDFS High Availability Using the Quorum Journal Manager
4.2 Note: Using the Quorum Journal Manager or Conventional Shared Storage
4.9 启动HA的HDFS Upgrade/Finalization/Rollback
这个手册的目的是对HDFS HA的概述，和如何配置和管理HA HDFS集群，使用Quorum Journal Manager(QJM)特性。
这里讨论如何配置和使用 QJM配置HDFS HA。使用QJM在standby和activenamenode共享edit log。HDFS HA可以使用NFS。可以查看
之前的hadoop 2.0.0,namende在HDFS集群是单点错误(SPOF)，如果机器或者进程不可用，整个cluster就变的不可用。
· 机器crash，整个namenode都不可用，整个集群就不可用。
· 计划的维护，在namenode设备上，软件和硬件的更新。
HDFS高可用功能可以解决以上问题。这个功能允许namenode 的机器crash的时候快速的进行切换，或者由管理员发起的切换。
在典型的HA集群，2个或者多个机器被配置为了namenode。时间点内，只有一个active状态的namenode，其他都是standby的。Active namenode为所有client服务。Standby在需要的时候只用来做failover。
为了让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进行安全的切换。
为了部署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。
配置类似于namenode联合，HA的允许配置已经存在的单个namenode继续工作不需要修改。新的配置被设计成，所有cluster的node都有一样的配置，不需要为不通的设备配置不通的配置文件。
和HDFS联合一样，HA集群使用nameserivce ID来识别一个HDFS实例，也可能是一个多个Namenode 的HA。另外一个新的抽象Namenode ID在HA中被使用。每个不通的Namenode有一个不通的namenode id来分别。为了支持一个配置文件到处使用，有些配置使用nameservice id或者namenode id后缀。
为了配置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来冗余
一些必要的配置都配置了之后，启动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状态。
现在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。这个功能还没实现。
上面描述配置手动故障转移。如果namenode报错也不会自动转移。
自动故障转移增加了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。
在通常部署，Zookeeper配置运行3个或者5个node，Zookeeper自身是轻量的可以放在namenode或者standby node上。很多会部署在和Zookeeper进程会和yarn resourcemanager同一个node上。推荐把Zookeeper node保存在独立的磁盘上，用于隔离性能问题。
在开始配置自动故障转移前，需要先关闭集群。当在集群运行的情况下，把手动转移转化为自动转移是不可能的。
为了自动故障转移，配置2个参数，hdfs-site.xml中：
指定那些需要自动故障转移的node,core-site.xml中：
运行了Zookeeper服务的host和端口。
这些设置可以配置在每个nameservice上，使用nameservice的前缀。比如cluster启动了联合，那么就可以为某个nameservice配置自动故障转移，配置dfs.ha.automatic-failover.enabled.my-nameservice-id。
这里还有一些其他配置自动故障，但是对大多数来说是没必要的。
配置好之后，下一步就是初始化Zookeeper的状态。可以用一下命令在一个namenode上运行：
然后在Zookeeper中创建znode，里面保存了自动故障转移的数据。
因为自动故障转移已经在配置文件中设置，start-dfs.sh脚本会自动启动ZKFC进程，启动之后会自动选择一个namenode称为active。
如果是手动管理cluster的，需要手动启动zkfc进程。
如果运行了安全的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：
一旦自动故障转移已经启动，那么就需要测试操作。首先定位在active namenode。可以从namenode 的网站查看namenode 的状态。
一旦定位到活动的namenode，使用 kill -9 pid来模拟jvm崩溃，或者可以关机，或者拔网线来模拟。一旦触发，在几秒内其他的namenode会自动变active。发现错误，触发failover的时间取决于配置，ha.zookeeper.session-timeout.ms，默认是5秒。
如果测试没有成功，可能有配置错误。检查zkfc进程和namenode进程日志来发现问题。
· 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,
如对本文有疑问，
点击进行留言回复！！
您可能感兴趣的文章:
去 HBase，Kylin on Parquet 性能表现如何？
如何找到Hive提交的SQL相对应的Yarn程序的applicationId
如何在 HBase Shell 命令行正常查看十六进制编码的中文？哈哈~
网友评论