Hadoop之HDFS中HA的搭建

Hadoop 1.0存在的问题：单点故障和内存受限

（1）NameNode单点故障（NameNode只有一个，一旦宕机了，则数据就会丢失，虽然有配置SecondaryNameNode，但是SecondardyNameNode

合并元数据和日志文件需要时间的，所有还是会有部分数据会丢失）

（2）NameNode压力大（单节点只有一个NameNode，所有的请求都访问一个NameNode）

Hadoop 2.0解决方案：

单点故障：HA（通过主备NameNode解决，如果主NameNode发生故障，则切换到备NameNode上）

内存受限问题：F(HDFS Federation 联邦)

水平扩展，支持多个NameNode,每一个NameNode分管一部分目录，并且所有NameNode共享DateNode存储资源

现在只讨论HA的实现：

HA：客户端只有和一个NameNode（主）进行通信，而元数据部分是如何和NameNode(备)进行共享的？（首先dataNode 的信息是共享的，主NameNode和备NameNode这部分信息是一致的，而元数据不一样，不是实时的）

想法一：主Namenode和备Namenode之间建立一个socket通信（阻塞型通信），这样两个NameNode和DataNode的元数据就是一致的了（同时会引发一个问题，IO网络通信的问题，如果之间网络一旦出现问题，则客户端会认为主Namenode出现了问题，因为整个流程是这样的，客户端发送一个请求给主NameNode，然后主Namenode再发送给备Namenode,而此时网络发生波动的话，请求就会一直阻塞在那里直到备NameNode返回成功的状态，所以客户端会认为是主Namenode有问题），所以这个想法不可行。

想法二：主NameNode和备NameNode之间建立一个非阻塞的通信（就是客户端发送请求给主Namenode,然后主NameNode再发送给备NameNode,不需要等待备NameNode的返回状态，这样的话如果备NameNode发生问题，就会导致两个NameNode之间元数据不一致）所以这个想法也不可行。

想法三：当客户端发送请求给主NameNode时，元数据写到一个共享的磁盘中（两个Namenode都可以访问），这样元数据就可以保持一致了。这种技术就叫做NFS技术。

NFS:

但是NFS运维成本太高，所以Hadoop本身开发了一种技术，JNN(JournalNode)还是集群部署的,（保证了NameNode的高可用性）

ZookeeperFailOverController :Hadoop 配置ZKFC来实现自动故障转移，这两个都是在namenode上的JVM进程，用来监测主NameNode是否发生宕机的，如果发送宕机则向zookeeper汇报，zookeeper将原先注册的锁事件进行删除，然后zookeeper在锁事件删除后会回调备用NameNode发送的锁请求，将自动将备用NameNode变成主Namenode，并且备Namenode的状态由standby变成了Active

Zookeeper在HDFS-HA中起着什么样的角色？

Zookeeper:在HDFS-HA搭建的过程中起着分布式协调作用

1、 zookeeper提供目录结构树机制，两个ZKFC进行资源抢夺，谁抢夺上了，谁就可以在zookeeper上建立一个节点目录,并且创建一把锁，与此同时将与自身关联的Namenode的状态置为Active活跃状态(主Namenode)，另一个置为standBy(静态的也叫备NameNode)。

2、事件回调和监控,zkfc一旦监测到主NameNode发生宕机则，主Namenode节点上的zkfc会将zookeeper上创建的节点目录进行删除，此时zookeeper会回调之前备zkfc在zookeeper上注册的事件，将备zkfc从standBy变成Active的状态。

3、 Session机制：如果zkfc的进程挂了，那么tcp连接就会断开，tcp断开有个会话超时时间范围，一旦超过这个范围，zookeeper就会将主zkfc之前注册的节点进行删除事件的操作，此时zookeeper就会回调备zkfc注册的节点事件，将备zkfc下的Namenode进行状态转换为Active,并且同时将主Namenode的状态变成standBy,这样的话就不会同时存在两个Active的NameNode。

Zkfc（zookeeper Failover Controller）和namenode是在同一个节点上。

HDFS Fedration联邦方式解决高可用问题：

两个NameNode的状态都是活跃的，但是两个NameNode的元数据是不一样的，也就是说存储的目录机构是不一样的。但是接受客户端访问的请求量上去了，但与此同时NameNode还是有单点故障的，所以还是要加上HA，就可以解决单点故障的问题。至于客户端访问那个NameNode这就交给代理来处理就可以了，就比如说Ngix,搭建一个ngix来负载均衡。

这里邦联不细究了。

现在来搭建一下HDFS-HA来实现HDFS的高可用。（解决单点故障问题），下面是结构图：

因为资源有限所以这么搭建：

本来zookeeper集群搭建就应该放三台服务器

JNN应该放三台服务器上

NameNode放在两台服务器上

Node1节点上有NameNode 和一个zkfc(JVM进程负责监测NameNode并且和zookeeper进行通信的)和JNN(主NameNode 和从Namenode元数据同步的技术，一般都是集群搭建,至少3个)

Node2节点上有NameNode 和一个secondaryNameNode（在搭建HA之前是有SecondaryNamenodede,但是搭建HA时，是不需要SecondaryNameNode的，这是冲突的，hdfs-site.xml中需要取消这个配置）和一个DataNode 和一个zookeeper

和一个zkfc 和一个JNN

HDFS中免秘钥应用场景有哪些？

（1）启动脚本控制节点起停，就是node1（Namenode）启动时顺便把node2,node3,node4上的dataNode启动

（2）对方Zkfc（A对象的zkfc）控制对方namenode(B对象的namenode)状态时需要通信，需要免秘钥，当其中一个zkfc(A对象的zkfc)挂掉时，对方的zkfc(B对象的zkfc)将会把对方的namenode(A对象的namenode)的状态变成standby,然后将自身的namenode(B对象的Namenode)的状态置为Active。

HA配置文件：

（1）逻辑位置到物理位置的映射（因为有两个Namenode，客户端无法直接同时访问两个Namenode,所以要配置一个逻辑位置，然后逻辑位置映射到实际的物理位置）

（2） JouaryNode的配置，写入到磁盘文件的路径（就是两个Namenode共享的元数据的信息Edits.Log中的信息。）还有journalNode的位置信息

（3）免秘钥配置，failover zkfc发生故障时，需要通信将对方的namenode状态修改

同一个zookeepr集群可以为多个hdfs集群服务（只要hdfs集群取不同的名称就可以具体的在hdfs-site.xml文件中配置）

同一个JouaryNode集群可以为多个hdfs集群服务（只要hdfs集群取不同的名称就可以具体的在hdfs-site.xml文件中配置）

关于HDFS-HA方式部署大概有哪些步骤？

（1）配置好HA的配置文件(看文章最后面有贴出配置)

（3）启动JNN(jouaryNode集群)(hadoop-daemon.sh start journalnode)hadoop-daemon.sh start journalnode

（4） Hdfs namenode –format（格式化namenode前启动jouaryNode是因为namenode格式化fsimage和edits.log文件，如果两个namenode都格式化，会造成fsimage中的数据不一致，所以要先启动jounaryNode，然后再格式化Namenode,然后将fsimage共享给另一个namenode）hdfs namenode -format

（5）启动第一个namenode(hadoop-daemon.sh start namenode)

（6）然后以-bootstrapStandby启动第二个namenode (将这个namenode设置为备用namenode) hdfs namenode -bootstrapStandby 如果这步报错了，看下面注意部分

（7）启动zookeeper集群,每个zookeeper节点上执行： zkServer.sh start

（8）格式化zkfc：hdfs zkfc -formatZK(因为zkfc依赖于zookeeper，因为格式化后会加一把锁在zookeeper上，会在zookeeper集群上创建一个节点，如果此时zookeeper未启动的话，会报错)

（9）启动zookeeper客户端查看zkfc是否生成对应的目录结构 zkCli.sh 回车

（10）启动hadoop集群 start-dfs.sh

（11）在zookeeper客户端可以查看到生成了锁，使用get获取锁的信息：锁是node1的

特别要注意的是（我已经踩了这个坑）：/etc/hosts文件 127.0.0.1 localhost node1 localhost4 localhost4.localdomain4一定要写成192.168.234.11 localhost node1 localhost4 localhost4.localdomain4，因为在主namenode格式化然后启动之后，将第二个namenode置为standby状态时，会报错（FATAL ha.BootstrapStandby: Unable to fetch namespace information from active NN at node1/192.168.234.11:8020: Call From node2/127.0.0.1 to node1:8020 failed on connection exception: java.net.ConnectException: Connection refused;），其实报错的时候可以看下主namenode下监听8020端口时的ip地址(命令：netstat -antp | fgrep 8020)，这时你会发现是127.0.0.1所以备namenode在置为standby时会报错，主namenode拒接链接备namenode.

如果发生了做如下操作：（1）修改/etc/hosts文件将127.0.0.1修改成实际的ip (2)重启sshd服务 service sshd restart (3)重启网络 service network restart

现在进页面看下效果

看下在zookeeper 那里注册的锁信息：

Node1为active

Node2为standby

模拟HA的高可用性（zookeeper实现故障自动转移）

(1)下面模拟active的namenode发生故障 kill -9 ，看看效果

看下页面，好像无法刷新了

再看下Namenode2,由standby变成了Active

好的，现在再看下zookeeper锁的信息：变成了node2了

现在恢复namenode

现在启动恢复下node1上的namenode的看下node2状态有没有被修改：

从上面看知道node2还是active ,node1就变成,standby

(2)现在来模拟zkfc挂了(在node2上模拟kill -9 zkfc的进程)：

现在看看node2的状态：变成了standby

看看node1:变成了active

从zookeeper客户端看下是否是现在的锁是node1的：

这就是zkfc的自动故障转移功能，利用zookeeper来分布式协调。

搭建zookeeper集群：

（1） /usr/zookeeper/zookeeper-3.4.6/conf : cp zoo_samp.conf zoo.conf

（2）修改data.dir zookeeper数据文件的目录: dataDir=/usr/zookeeper/tmp/data

（3）添加3个节点的地址（

server.1=192.168.234.12:2888:3888
server.2=192.168.234.13:2888:3888
server.3=192.168.234.14:2888:3888

）

（4）手动创建数据文件的目录

（5） Echo 1 >> 数据文件目录/myid 注：然后分发到各个节点，修改myid 如果（zoo.conf文件中）当前节点的ip地址对应server.2 那么myid就修改为2

（6）修改各个节点的profile文件，要保持一致

（7） . /etc/profile (使得修改后的profile文件生效)

（8）启动zookeeper zkService.sh start (只要超过一半的zookeeper就可以认为zookeeper启动，否则认为未启动，可以启动一个zookeeper时查看状态)

下面附上配置文件内容：

zookeeper配置文件： /usr/zookeeper/zookeeper-3.4.6/confzoo.cfg文件的最低端加上如下的内容

server.1=192.168.234.12:2888:3888
server.2=192.168.234.13:2888:3888
server.3=192.168.234.14:2888:3888

hdts-site.xml

<configuration>

<property>
<name>dfs.nameservices</name>
<value>hacluster</value>
</property>

<property>
<name>dfs.ha.namenodes.hacluster</name>
<value>nn1,nn2</value>
</property>

<property>
<name>dfs.namenode.rpc-address.hacluster.nn1</name>
<value>node1:8020</value>
</property>

<property>
<name>dfs.namenode.rpc-address.hacluster.nn2</name>
<value>node2:8020</value>
</property>

<property>
<name>dfs.namenode.http-address.hacluster.nn1</name>
<value>node1:50070</value>
</property>

<property>
<name>dfs.namenode.http-address.hacluster.nn2</name>
<value>node2:50070</value>
</property>

<property>
<name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://node1:8485;node2:8485;node3:8485/hacluster</value>
</property>

<property>
<name>dfs.journalnode.edits.dir</name>
<value>/usr/hadoop/journal/node/local/data</value>
</property>

<property>
<name>dfs.client.failover.proxy.provider.hacluster</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>

<property>
<name>dfs.ha.fencing.methods</name>
<value>sshfence</value>
</property>

<property>
<name>dfs.ha.fencing.ssh.private-key-files</name>
<value>/root/.ssh/id_rsa</value>
</property>

<property>
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
</property>






<property>
<name>dfs.namenode.name.dir</name>
<value>${hadoop.tmp.dir}/name</value>
</property>

<property>
<name>dfs.datanode.data.dir</name>
<value>${hadoop.tmp.dir}/data</value>
</property>

<property>
<name>dfs.replication</name>
<value>2</value>
</property>
</configuration>

转载于：https://www.cnblogs.com/yehuili/p/9942453.html

发表于 2021-01-18 21:12 金色的鱼儿阅读(392) 评论(0) 编辑收藏举报

刷新页面返回顶部

Hadoop之HDFS中HA的搭建

Hadoop 1.0存在的问题：单点故障和内存受限

Hadoop 2.0解决方案：

现在只讨论HA的实现：

Zookeeper在HDFS-HA中起着什么样的角色？

HDFS Fedration联邦方式解决高可用问题：

HDFS中免秘钥应用场景有哪些？

HA配置文件：

关于HDFS-HA方式部署大概有哪些步骤？

现在进页面看下效果

模拟HA的高可用性（zookeeper实现故障自动转移）

(1)下面模拟active的namenode发生故障 kill -9 ，看看效果

(2)现在来模拟zkfc挂了(在node2上模拟kill -9 zkfc的进程)：

搭建zookeeper集群：

下面附上配置文件内容：

core-site.xml文件里面的内容：

公告