NameNode 高HA

一、HA原理和架构

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节点。

三、高可用部署

3.1 hdfs-site.xml

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>

3.2 core-site.xml

•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>

4.1 故障切换操作

4.1.1 dfs.ha.automatic-failover.enabled 设置为true,设置自动切换。

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 进程,触发自动选主过程。

4.1.2 dfs.ha.automatic-failover.enabled 设置为 false 时

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 节点。

4.2 QJM故障

JournalNode集群,默认三个节点。

1, 当一个节点故障时,集群能正常工作 2, 当出现两个节点故障时,集群不能正常工作,NN节点进程反复退出,重启。

解决办法:重启QJM组件。

参考文献

18.《高HA配置说明》

19.《Hadoop NameNode 高可用 (High Availability) 实现解析》

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券