NameNode 保存了整个 HDFS 的元数据信息,一旦 NameNode 挂掉,整个 HDFS 就无法访问。为了提高HDFS的高可用性,在 Hadoop2.0 中,HDFS NameNode支持了高可用架构,如下图。
从上图中,我们可以看出 NameNode 的高可用架构主要分为下面几个部分:
Active NameNode 和 Standby NameNode:两台 NameNode 形成互备,一台处于 Active 状态,为主 NameNode,另外一台处于 Standby 状态,为备 NameNode,只有主 NameNode 才能对外提供读写服务。
主备切换控制器 ZKFailoverController:ZKFailoverController 作为独立的进程运行,对 NameNode 的主备切换进行总体控制。ZKFailoverController 能及时检测到 NameNode 的健康状况,在主 NameNode 故障时借助 Zookeeper 实现自动的主备选举和切换,当然 NameNode 目前也支持不依赖于 Zookeeper 的手动主备切换。
Zookeeper 集群:为主备切换控制器提供主备选举支持。
共享存储系统:共享存储系统是实现 NameNode 的高可用最为关键的部分,共享存储系统保存了 NameNode 在运行过程中所产生的 HDFS 的元数据。主 NameNode 和NameNode 通过共享存储系统实现元数据同步。在进行主备切换的时候,新的主 NameNode 在确认元数据完全同步之后才能继续对外提供服务,主要有JournalNode 。
DataNode 节点:除了通过共享存储系统共享 HDFS 的元数据信息之外,主 NameNode 和备 NameNode 还需要共享 HDFS 的数据块和 DataNode 之间的映射关系。DataNode 会同时向主 NameNode 和备 NameNode 上报数据块的位置信息。
当Active NN故障时,Zookeeper创建的临时节点ActiveStandbyElectorLock将要被删除,其他NN节点注册的Watcher 来监听到该变化,NN节点的ZKFailoverController 会马上再次进入到创建/hadoop-ha/${dfs.nameservices}/ActiveStandbyElectorLock 节点的流程,如果创建成功,这个本来处于 Standby 状态的 NameNode 就选举为主 NameNode 并随后开始切换为 Active 状态。
新当选的Active NN将确保从QJM(Quorum Journal Manager)同步完所有的元数据文件EditLog文件,然后切换为主节点,并向外提供服务。
1.Active NN节点通过QJM组件Standby NN同步EditLog文件。
2.Standby 节点定时checkpoint生成Fsimage文件,并通过http协议传给Active NN节点。
hdfs-site.xml名称可自定义,建议取个合理的名字。该配置影响到其它配置,也会影响到hdfs文件系统存储的绝对路径。
•dfs.nameservices
<property>
<name>dfs.nameservices</name>
<value>HDFS80476</value>
</property>
•dfs.ha.namenodes.nameservice ID
让dn确定集群中有多少个nn。nn至少两个,推荐3个,不建议超过5个。
<property>
<name>dfs.ha.namenodes.HDFS80476</name>
<value>nn1,nn2</value>
</property>
•dfs.namenode.rpc-address.nameservice ID.name node ID
侦听的每个NameNode的完全限定的RPC地址。
<property>
<name>dfs.namenode.rpc-address.HDFS80476.nn2</name>
<value>172.21.0.16:4007</value>
</property>
<property>
<name>dfs.namenode.rpc-address.HDFS80476.nn1</name>
<value>172.21.0.13:4007</value>
</property>
•dfs.namenode.http-address.nameservice ID.name node ID
侦听的每个NameNode的完全限定HTTP地址。 注意:如果启用了Hadoop的安全功能,则还应为每个NameNode设置https-address。
<property>
<name>dfs.namenode.http-address.HDFS80476.nn1</name>
<value>172.21.0.13:4008</value>
</property>
<property>
<name>dfs.namenode.https-address.HDFS80476.nn1</name>
<value>172.21.0.13:4009</value>
</property>
•dfs.namenode.shared.edits.dir
配置JournalNodes (JN)地址。如果是管理脚本,则会根据改地址启动jn,如果是active nn,则会通过该地址传输命名空间变更信息。备用的nn则会通过该配置地址拉取变更数据。配置值最后的/mycluster作为存储的根路径,多个HA可公用服务器进行数据存储,节约服务器成本。因此每个HA服务的根路径不能一样,便于区分.
<property>
<name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://172.21.0.12:4005;172.21.0.15:4005;172.21.0.4:4005/hadoop</value>
</property>
•dfs.journalnode.edits.dir
这是JournalNode本地存储绝对路径。
<property>
<name>dfs.journalnode.edits.dir</name>
<value>/data/emr/hdfs/journalnode</value>
</property>
•dfs.client.failover.proxy.provider.nameservice ID
便于客户端确定哪个nn是主节点。对于第一次调用,它同时调用所有名称节点以确定活动的名称节点,之后便直接调用主节点(active nn),可以理解帮助客户端获取主节点的代理。 ConfiguredFailoverProxyProvider 和RequestHedgingProxyProvider 选其一即可。
<property>
<name>dfs.client.failover.proxy.provider.HDFS80476</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>
•dfs.ha.fencing.methods
当发生故障转移时,以前的Active NameNode仍可能向客户端提供读取请求,这可能已过期,直到NameNode在尝试写入JournalNode时关闭。因此,即使使用Quorum Journal Manager,仍然需要配置一些防护方法。但是,为了在防护机制失败的情况下提高系统的可用性,建议配置防护方法,能确保不会发生此类情况。请注意,如果您选择不使用实际的防护方法,则仍必须为此设置配置某些内容,例如“shell(/ bin / true)”。 故障转移期间使用的防护方法配置为回车分隔列表,将按顺序尝试,直到指示防护成功为止。 Hadoop有两种方法:shell和sshfence。
默认设置为/bin/true,表示什么也不做。在Linux中,true命令啥都不做,只设置退出码为0。
<property>
<name>dfs.ha.fencing.methods</name>
<value>shell(/bin/true)</value>
</property>
sshfence选项通过SSH连接到目标节点,并使用fuser来终止侦听服务TCP端口的进程。如果设置为sshfence,则还需要设置免密文件路径。设置如下:
<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>
•dfs.ha.automatic-failover.enabled
开启故障自动切换
<property>
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
</property>
•fs.defaultFS
配置和nameservice ID值一样。将通过mycluster结合hdfs配置中的dfs.nameservices和dfs.ha.namenodes.HDFS80476找到该服务下的所有nn,确认主节点。
<property>
<name>fs.defaultFS</name>
<value>hdfs://HDFS80476</value>
</property>
命令详细见这里hadoop命令。
hdfs haadmin -checkHealth <serviceId>
hdfs haadmin -failover [--forcefence] [--forceactive] <serviceId> <serviceId>
hdfs haadmin -getServiceState <serviceId>
hdfs haadmin -help <command>
hdfs haadmin -transitionToActive <serviceId> [--forceactive]
hdfs haadmin -transitionToStandby <serviceId>
3.nn1 为 standby , nn2 为active
hdfs haadmin -transitionToStandby -forcemanual nn2
则会发生切换, nn1 为 active , nn2 为standby
4.nn1 为 active , nn2 为standby
hdfs haadmin -transitionToStandby -forcemanual nn2
则不会做任何改变
5.nn1 为 active , nn2 为standby
hdfs haadmin -transitionToActive -forcemanual nn1
则不会做任何改变
6.nn1 为 active , nn2 为standby
hdfs haadmin -transitionToActive -forcemanual nn2
报错,不会做任何改变 19/03/11 16:49:21 WARN ha.HAAdmin: Proceeding with manual HA state management even though automatic failover is enabled for NameNode at /172.21.0.13:4007 transitionToActive: Node nn1 is already active
7.nn1 为 active , nn2 为 standby
hdfs haadmin -transitionToActive --forceactive --forcemanual nn2
则会发生切换, nn1 为 standby ,进程重启, nn2 为 active
8.nn1 为 standby , nn2 为 active
hdfs haadmin -transitionToActive --forceactive --forcemanual nn1
则会发生切换, nn1 为 active, nn2 为 standby ,进程重启
9.nn1 为 active, nn2 为 standby
hdfs haadmin -transitionToActive --forceactive --forcemanual nn1
则不会做任何改变。
综合以上情况,当开启自动切换功能时: 1,当active节点正常时,执行hdfs haadmin -transitionToStandby 命令可以将active的namenode节点转换成standby状态,同时原来的standby自动切换为active。 2, 当active节点正常时,使用hdfs haadmin -transitionToActive 命令对两个namenode节点切换都不起作用。 3, 当加了--forceactive 参数,可以将standby的namenode节点转换成active状态,另外的节点自动转为 standby。 4, zk的节点ActiveBreadCrumb, ActiveStandbyElectorLock数据会自动切换。
10.nn1 为 active , nn2 为 standby 停掉nn1, 则nn2自动切换为active
11.强制故障转移,nn1 为 active, nn2 为 standby
hdfs haadmin -failover --forcefence --forceactive nn2 nn1
或
hdfs haadmin -failover --forcefence --forceactive nn1 nn2
报错 forcefence and forceactive flags not supported with auto-failover enabled.
小结论:
hdfs haadmin [-failover --forcefence ]命令在配置故障自动切换(dfs.ha.automatic-failover.enabled=true)之后,无法手动进行。可将该参数更改为false(需要重启进程)后,重新执行该命令即可。
10.当停掉ZKFailoverController 进程时,可以对节点状态进行转换, 也可能存在两个standby或两个active的情况,zk不存在ActiveStandbyElectorLock 节点。
解决办法:重启NameNode,拉起ZKFailoverController 进程,触发自动选主过程。
12.nn1 为 active , nn2 为 standby
hdfs haadmin -transitionToStandby -forcemanual nn2
则不会做任何改变
13.nn1 为 active , nn2 为 standby
hdfs haadmin -transitionToStandby -forcemanual nn1
nn1 , nn2 和都为 standby,不能读写任何数据。
14.nn1 为 standby , nn2 为 standby
hdfs haadmin -transitionToActive --forceactive --forcemanual nn1
则正常切换,nn1 为 active , nn2 为 standby
15.nn1 为 active , nn2 为 standby
hdfs haadmin -transitionToActive --forceactive --forcemanual nn1
则不会做任何改变
16.nn1 为 active , nn2 为 standby
hdfs haadmin -transitionToActive --forceactive --forcemanual nn2
在短时间内,两个都为active, 一分钟后,nn1 进程重启,为 standby , nn2 为 active。
17.nn1 为 active , nn2 为 standby 停掉nn1,nn2不会自动切换为active
结论,当关闭自动切换功能时:
1,hdfs haadmin -transitionToStandby将active的namenode节点转换成standby状态, 因此可能存在两个standby的情况。 2,hdfs haadmin -transitionToActive 将standby转为 active。 3,zk对应节点只有ActiveBreadCrumb(遗留未删除的),没有ActiveStandbyElectorLock 节点。
JournalNode集群,默认三个节点。
1, 当一个节点故障时,集群能正常工作 2, 当出现两个节点故障时,集群不能正常工作,NN节点进程反复退出,重启。
解决办法:重启QJM组件。
18.《高HA配置说明》
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。